MozillaTranslator and Sourceforge.net
Ricardo Palomares Martinez
Supposedly, I've got CVS access to MozillaTranslator's sources on
SourceForge.net:
http://sourceforge.net/projects/moztrans/
Now, before I commit the current MT 5.13 source code, I'd like to
gather opinions about the best way to organize things.
AFAIK, there only a main branch with three directories hanging from it:
- "moztrans", which is basically empty,
- src, which seems to have sources a MT 5.0beta1 level [1], and
- newsrc, which stopped at some point before MT 5.05 [2]. This was my
starting point.
Now, I think that instead a newsrc dir, a new branch should have been
created. I remember two different strategies for branching and
merging, but for the sake of better understanding, I think that we
should follow mozilla.org's model, ie., trunk having the active
development with branches as a certain feature set is more or less
reached. Do everybody (interested in MT) agree with course of action?
Assuming everybody agree, my other question relates to how to manage
the MT 5.13 commit. Should I branch before changing anything? If so,
what should I do regarding MT 5.05pl5 (the latest MT with
component/subcomponent model) sources? We could end having something
like this (ASCII art follows):
TRUNK-+---(source update to MT 5.13)---+---(new developments)----->>
| |
\-MT pre 5.05 \-MT 5.13
|
\--MT 5.05pl5 (latest MT with Subcomponent)
BTW, I'm fairly novice when it comes to branching, tagging, etc. I've
read some CVS material, but still, if anyone is willing to help me in
a IRC/Jabber session, please let me know... Currently I only have
limited developer privileges and I can't grant CVS access anyone else
by myself; I suppose Serhiy will fully hand over the project once he
gets sure I'm not going to badly screw anything. :-)
TIA
[1]
http://moztrans.cvs.sourceforge.net/moztrans/src/org/mozillatranslator/mozillatranslator/kernel/DefaultSettings.java?view=markup
[2]
http://moztrans.cvs.sourceforge.net/moztrans/newsrc/org/mozillatranslator/kernel/Settings.java?view=markup
--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?
Robert Kaiser
> Now, I think that instead a newsrc dir, a new branch should have been
> created. I remember two different strategies for branching and
> merging, but for the sake of better understanding, I think that we
> should follow mozilla.org's model, ie., trunk having the active
> development with branches as a certain feature set is more or less
> reached. Do everybody (interested in MT) agree with course of action?
Sounds really good, yes.
> Assuming everybody agree, my other question relates to how to manage
> the MT 5.13 commit. Should I branch before changing anything? If so,
> what should I do regarding MT 5.05pl5 (the latest MT with
> component/subcomponent model) sources?
I think it would be best to use the src/ dir, do a non-branch static tag
on it current source (MT_5_0beta1_RELEASE or similar), then copy the
newsrc stuff there and again do some static tag, then update to 5.05pl5,
tag it again, then update to 5.13, tag once again, and then commit your
current (maybe evene newer) source to trunk.
With this, we have at least some good and consistent history there
again. You only need a branch tag if you want/need to do parallel
development on both trunk and the branch, e.g. when still releasing
stability/minor updates from the branch while doing agressive, unstable,
new development on trunk (like with Mozilla tree). For only marking a
set of files (e.g. a release or the base of a branch) on trunk or a
specific branch, a static (normal) tag is enough.
I hope this helps a bit.
Robert Kaiser
Giacomo Magnini
the same newsrc dir) from the new 5.1x sources.
This is beacuse 5.1x is a major rewrite, and to ensure that people with
problems working with the new version (like me) can safely continue
working with the old one.
Coming to the problems, while I was inclined to believe that 5.1x wasn't
working for me because of JDK6, I'm now more inclined to think that the
problem lies somewhere in the update process. I've rebuilt the program
with NB 5.5 and JDK6(RC), but the problem persists: I always lose large
parts of the Glossary whenever I try to update the SeaMonkey product,
while upgrading the other products seems to work fine.
SeaMonkey product includes these jars: en-US, en-mac, en-win, en-unix,
US (in this oredr of appearence). The same import gives no problems with
MT5.05 under JDK6.
Now, if the problem happens to me because I've a(n almost) broken
Glossary (maybe with illegal chars) or because there were some
incompatible changes in the new JDK which influence the update progress,
or for some unchecked methods, I don't really know. Still, if the old
version works for me even after recompiling with the new JDK, than the
problem is hidden somewhere in the new changes.
A real pain to switch back and forth both version to use the new
features without compromising the integrity of the usual Glossary...
Ciao, Giacomo.
Ricardo Palomares Martinez
> IMHO you should clearly separate MT 5.05 sources (which can
> continue in the same newsrc dir) from the new 5.1x sources. This is
> beacuse 5.1x is a major rewrite, and to ensure that people with
> problems working with the new version (like me) can safely continue
> working with the old one.
Please, send me your Glossary.zip (you did it, but before I started
changes that resulted in MT 5.1x series; if you think the one I have
would be valid for testing, let me know) and try to give an
step-by-step procedure to detect information loss, so I can debug it
into Netbeans. You can use my above address removing ".PUBLI", or any
other mine you already know. :-)
Based on this and Robert's input:
> I think it would be best to use the src/ dir, do a non-branch
> static tag on it current source (MT_5_0beta1_RELEASE or similar),
> then copy the newsrc stuff there and again do some static tag, then
> update to 5.05pl5, tag it again, then update to 5.13, tag once
> again, and then commit your current (maybe evene newer) source to
> trunk.
...I think I will debug your Glossary.zip and, in case the fix is
trivial, I will just tag 5.05pl5. If things look bad, I will tag AND
branch on 5.05pl5. In any event, I will tag again on 5.13, and will
start fixing the problem affecting you on trunk. Does this sound good
enough? Keeping the src and newsrc looks to me as doing the wrong use
of CVS. :-?
TIA
Giacomo Magnini
> Please, send me your Glossary.zip (you did it, but before I started
> changes that resulted in MT 5.1x series; if you think the one I have
> would be valid for testing, let me know) and try to give an
> step-by-step procedure to detect information loss, so I can debug it
> into Netbeans. You can use my above address removing ".PUBLI", or any
> other mine you already know. :-)
I'll follow up with a detailed mail (as much as possible) with the
suspect Glossary file. I was about to do just that before you started
this thread, so had to rush. I'll try once again to reproduce the
problem here while taking notes: configuration file will be included, too.
> ...I think I will debug your Glossary.zip and, in case the fix is
> trivial, I will just tag 5.05pl5. If things look bad, I will tag AND
> branch on 5.05pl5. In any event, I will tag again on 5.13, and will
> start fixing the problem affecting you on trunk. Does this sound good
> enough? Keeping the src and newsrc looks to me as doing the wrong use
> of CVS. :-?
Sounds very reasonable to me.
Btw, compiling under JDK6 shows the use of a single deprecated function
that is easily resolved by importing another class and changing a single
line (IIRC, it's a .toURL that should be changed to .toURI [1.4]: I
can't move from bed, and the changes are on the desktop).
Ciao, Giacomo.
Ricardo Palomares Martinez
> I'll follow up with a detailed mail (as much as possible) with the
> suspect Glossary file. I was about to do just that before you started
> this thread, so had to rush. I'll try once again to reproduce the
> problem here while taking notes: configuration file will be included, too.
Just for the record, the problem is solved, and it doesn't really look
as an incompatibility between MT 5.13 and JRE 1.6.0, but a different
behaviour between JRE 1.6.0 on Windows and other JVMs, including JRE
1.6.0 on Linux.
I'm trying now to checkout MT sources from Sourceforge.net with my
authenticated account. I'll let all you know when I manage to put MT
sources up to date in sf.net.
> Btw, compiling under JDK6 shows the use of a single deprecated function
> that is easily resolved by importing another class and changing a single
> line (IIRC, it's a .toURL that should be changed to .toURI [1.4]: I
> can't move from bed, and the changes are on the desktop).
I didn't remember this point, and I didn't pay enough attention when
compiling on Windows, but I didn't see anything unusual. I'll
double-check it.
Ricardo.
Ricardo Palomares Martinez
>
> I'm trying now to checkout MT sources from Sourceforge.net with my
> authenticated account. I'll let all you know when I manage to put MT
> sources up to date in sf.net.
>
Well, I haven't had much time to do it, but I found that the original
course of action wasn't as easy as I thought at first sight (or maybe
I'm just scared, I'm not sure). :-)
At http://moztrans.cvs.sourceforge.net/moztrans/ you can see the
CVSROOT for MozillaTranslator. As I said previously, there are three
directories:
- "moztrans", which is basically empty, although it has 2 dead files,
- src, which seems to have sources a MT 5.0beta1 level [1], and
- newsrc, which stopped at some point before MT 5.05 [2]. This was my
starting point.
I assume I should be removing everything under and including moztrans
(no need to tag here, I guess). Then, I should tag src and then "move"
newsrc to src, tagging again. The problem is that newssrc has this layout:
newssrc -> org -> mozillatranslator -> (everything else)
with a lib directory also under newssrc; however, src has this layout:
src -> org -> mozillatranslator -> mozillatranslator -> (everytyhing else)
with a shared directory, also with some dead files, under the first
mozillatranslator dir. This means a whole batch of cvs remove, which I
don't know if it is safe and sensible. I'm willing to accept any help
here, even with a Jabber or IRC session. Anyone, any hint?
TIA.
Ricardo Palomares Martinez
> (...)
> I assume I should be removing everything under and including moztrans
> (no need to tag here, I guess). Then, I should tag src and then "move"
> newsrc to src, tagging again. The problem is that newssrc has this layout:
>
> newssrc -> org -> mozillatranslator -> (everything else)
>
> with a lib directory also under newssrc; however, src has this layout:
>
> src -> org -> mozillatranslator -> mozillatranslator -> (everytyhing else)
>
> with a shared directory, also with some dead files, under the first
> mozillatranslator dir. This means a whole batch of cvs remove, which I
> don't know if it is safe and sensible. I'm willing to accept any help
> here, even with a Jabber or IRC session. Anyone, any hint?
Since I got no replies, I've taken the plunge and I've already tagged
for MT_5_0_BETA_1 and MT_5_05. I must go now, but I hope to be able
tomorrow to remove moztrans and newsrc directories, and to commit MT
5.13. In the meanwhile, if anyone could take a look and report if I'm
doing something wrong (this is my first time messing around with tags
and so), I'd be grateful.
TIA
Ricardo Palomares Martinez
>
> Since I got no replies, I've taken the plunge and I've already tagged
> for MT_5_0_BETA_1 and MT_5_05. I must go now, but I hope to be able
> tomorrow to remove moztrans and newsrc directories, and to commit MT
> 5.13. In the meanwhile, if anyone could take a look and report if I'm
> doing something wrong (this is my first time messing around with tags
> and so), I'd be grateful.
I've "released" MT 5.05 built upon the source code in CVS just before
I got involved in it. I think I'm going to also tag and release MT
5.05pl5 before going with MT 5.13.
Ricardo.
Ricardo Palomares Martinez
>
> I've "released" MT 5.05 built upon the source code in CVS just before
> I got involved in it. I think I'm going to also tag and release MT
> 5.05pl5 before going with MT 5.13.
I've tagged and released MT 5.05pl5 and MT 5.13. At this moment, the
CVS at Sourceforge.net is up to date. I'm going to do a couple of
fixes, and I hope to be able to start tomorrow with existing bugs at bmo.