Re: [cp-patches] RFC: @file support for gjavah gjar
Hi Andrew, thanks a lot for fixing the remaining issues and committing this. Regards Robert Andrew John Hughes schrieb: Committed with the amendments suggested by Tom and Mario: 2008-06-06 Andrew John Hughes [EMAIL PROTECTED] * tools/gnu/classpath/tools/common/ClasspathToolParser.java: Fixed indentation and changed to use OptionException. * tools/gnu/classpath/tools/getopt/OptionException.java: (OptionException(String,Throwable)): Added. 2008-06-03 Robert Schuster [EMAIL PROTECTED] * tools/gnu/classpath/tools/jar/Main.java: (run): Call different ClasspathToolParser.parse() variant. (getParser): Changed return type to ClasspathToolParser. * tools/gnu/classpath/tools/javah/GcjhMain.java: (getParser): Changed return type to ClasspathToolParser. * tools/gnu/classpath/tools/javah/Main.java: (getParser): Changed return type to ClasspathToolParser. * tools/gnu/classpath/tools/getopt/Parser.java: Make 'programName' protected. * tools/gnu/classpath/tools/common/ClasspathToolParser.java: (parse(String[], FileArgumentCallback,boolean): New method. (parse(String[], boolean): New method. (parseFileList): New method. (parseLine): New method. (AtFileArgumentCallback): New inner class. signature.asc Description: OpenPGP digital signature
[cp-testresults] FAIL: regressions for mauve-gij on Fri Jun 6 07:56:46 UTC 2008
Baseline from: Thu Jun 5 22:42:18 UTC 2008 Regressions: FAIL: java.util.logging.SocketHandler.getFilter Totals: PASS: 2896 XPASS: 0 FAIL: 253 XFAIL: 0 ___ Classpath-testresults mailing list Classpath-testresults@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-testresults
[cp-testresults] FAIL: regressions for mauve-kaffe on Fri Jun 6 09:19:47 UTC 2008
Baseline from: Tue Jun 3 14:27:37 UTC 2008 Regressions: FAIL: java.awt.Scrollbar.ScrollbarPaintTest FAIL: javax.swing.JComboBox.ComboRobot Improvements: PASS: org.omg.CORBA.ORB.parallelRunTest Totals: PASS: 2930 XPASS: 0 FAIL: 200 XFAIL: 0 ___ Classpath-testresults mailing list Classpath-testresults@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-testresults
[cp-testresults] FAIL: classpath build with ecj on Fri Jun 6 15:03:01 UTC 2008
mv -f gorbd.1.T$$ gorbd.1) || \ (rm -f gorbd.1.T$$ exit 1) perl ../../doc/texi2pod.pl -D grmid ../../doc/cp-tools.texinfo grmid.pod echo timestamp grmid.1 (pod2man --center=GNU --release=0.98-pre --section=1 grmid.pod grmid.1.T$$ \ mv -f grmid.1.T$$ grmid.1) || \ (rm -f grmid.1.T$$ exit 1) perl ../../doc/texi2pod.pl -D grmiregistry ../../doc/cp-tools.texinfo grmiregistry.pod echo timestamp grmiregistry.1 (pod2man --center=GNU --release=0.98-pre --section=1 grmiregistry.pod grmiregistry.1.T$$ \ mv -f grmiregistry.1.T$$ grmiregistry.1) || \ (rm -f grmiregistry.1.T$$ exit 1) perl ../../doc/texi2pod.pl -D gserialver ../../doc/cp-tools.texinfo gserialver.pod echo timestamp gserialver.1 (pod2man --center=GNU --release=0.98-pre --section=1 gserialver.pod gserialver.1.T$$ \ mv -f gserialver.1.T$$ gserialver.1) || \ (rm -f gserialver.1.T$$ exit 1) perl ../../doc/texi2pod.pl -D gtnameserv ../../doc/cp-tools.texinfo gtnameserv.pod echo timestamp gtnameserv.1 (pod2man --center=GNU --release=0.98-pre --section=1 gtnameserv.pod gtnameserv.1.T$$ \ mv -f gtnameserv.1.T$$ gtnameserv.1) || \ (rm -f gtnameserv.1.T$$ exit 1) make[3]: *** No rule to make target `../../doc/invoke.texi', needed by `gjdoc.pod'. Stop. rm gtnameserv.pod gcjh.pod gorbd.pod grmid.pod gjar.pod gappletviewer.pod gkeytool.pod gjavah.pod gnative2ascii.pod gserialver.pod gjarsigner.pod grmiregistry.pod make[3]: Leaving directory `/home/cpdev/Nightly/classpath/build/classpath-0.98-pre/_build/doc' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/cpdev/Nightly/classpath/build/classpath-0.98-pre/_build/doc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/cpdev/Nightly/classpath/build/classpath-0.98-pre/_build' make: *** [distcheck] Error 2 ___ Classpath-testresults mailing list Classpath-testresults@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-testresults
[cp-testresults] FAIL: cacao build on Fri Jun 6 15:08:56 UTC 2008
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/VMField.java:242:
warning: .
native int getInt(Object o)
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/VMMethod.java:243:
error: Class or interface declaration expected.
}
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/VMMethod.java:249:
error: syntax error.
private synchronized native MapClass? extends Annotation, Annotation
declaredAnnotations();
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/VMField.java:249:
warning: .
* @param o the object to get the value of this Field from
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/VMMethod.java:251:
error: Class or interface declaration expected.
}
^
../../../cacao/src/classes/gnuclasspath/sun/misc/Unsafe.java:229: error:
Invalid character '@' in input.
@Deprecated
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/Constructor.java:81:
error: '{' expected.
public final class ConstructorT
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/Constructor.java:81:
confused by earlier errors, bailing out
make[3]: *** [vm.zip] Error 1
make[3]: Leaving directory `/home/cpdev/Nightly/cacao/build/src/classes'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/cpdev/Nightly/cacao/build/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/cpdev/Nightly/cacao/build'
make: *** [all] Error 2
___
Classpath-testresults mailing list
Classpath-testresults@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-testresults
[cp-testresults] FAIL: ecj built with ecj on jamvm on Fri Jun 6 15:10:12 UTC 2008
xargs: jamvm: No such file or directory ___ Classpath-testresults mailing list Classpath-testresults@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-testresults
[cp-testresults] FAIL: regressions for mauve-gij on Fri Jun 6 18:01:53 UTC 2008
Baseline from: Thu Jun 5 22:42:18 UTC 2008 Regressions: FAIL: java.net.ServerSocket.AcceptTimeout FAIL: java.util.logging.SocketHandler.getFormatter Totals: PASS: 2895 XPASS: 0 FAIL: 254 XFAIL: 0 ___ Classpath-testresults mailing list Classpath-testresults@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-testresults
[cp-testresults] FAIL: regressions for mauve-kaffe on Fri Jun 6 19:42:33 UTC 2008
Baseline from: Tue Jun 3 14:27:37 UTC 2008 Regressions: FAIL: java.awt.Scrollbar.ScrollbarPaintTest FAIL: java.net.HttpURLConnection.responseHeadersTest FAIL: javax.swing.JComboBox.ComboRobot Improvements: PASS: gnu.java.security.util.TestOfIntegerUtil Totals: PASS: 2929 XPASS: 0 FAIL: 201 XFAIL: 0 ___ Classpath-testresults mailing list Classpath-testresults@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-testresults
[cp-testresults] FAIL: classpath build with ecj on Sat Jun 7 00:48:36 UTC 2008
mv -f gorbd.1.T$$ gorbd.1) || \ (rm -f gorbd.1.T$$ exit 1) perl ../../doc/texi2pod.pl -D grmid ../../doc/cp-tools.texinfo grmid.pod echo timestamp grmid.1 (pod2man --center=GNU --release=0.98-pre --section=1 grmid.pod grmid.1.T$$ \ mv -f grmid.1.T$$ grmid.1) || \ (rm -f grmid.1.T$$ exit 1) perl ../../doc/texi2pod.pl -D grmiregistry ../../doc/cp-tools.texinfo grmiregistry.pod echo timestamp grmiregistry.1 (pod2man --center=GNU --release=0.98-pre --section=1 grmiregistry.pod grmiregistry.1.T$$ \ mv -f grmiregistry.1.T$$ grmiregistry.1) || \ (rm -f grmiregistry.1.T$$ exit 1) perl ../../doc/texi2pod.pl -D gserialver ../../doc/cp-tools.texinfo gserialver.pod echo timestamp gserialver.1 (pod2man --center=GNU --release=0.98-pre --section=1 gserialver.pod gserialver.1.T$$ \ mv -f gserialver.1.T$$ gserialver.1) || \ (rm -f gserialver.1.T$$ exit 1) perl ../../doc/texi2pod.pl -D gtnameserv ../../doc/cp-tools.texinfo gtnameserv.pod echo timestamp gtnameserv.1 (pod2man --center=GNU --release=0.98-pre --section=1 gtnameserv.pod gtnameserv.1.T$$ \ mv -f gtnameserv.1.T$$ gtnameserv.1) || \ (rm -f gtnameserv.1.T$$ exit 1) make[3]: *** No rule to make target `../../doc/invoke.texi', needed by `gjdoc.pod'. Stop. rm gtnameserv.pod gcjh.pod gorbd.pod grmid.pod gjar.pod gappletviewer.pod gkeytool.pod gjavah.pod gnative2ascii.pod gserialver.pod gjarsigner.pod grmiregistry.pod make[3]: Leaving directory `/home/cpdev/Nightly/classpath/build/classpath-0.98-pre/_build/doc' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/cpdev/Nightly/classpath/build/classpath-0.98-pre/_build/doc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/cpdev/Nightly/classpath/build/classpath-0.98-pre/_build' make: *** [distcheck] Error 2 ___ Classpath-testresults mailing list Classpath-testresults@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-testresults
[cp-testresults] FAIL: jamvm build on Sat Jun 7 00:50:12 UTC 2008
^^^ Syntax error on tokens, delete these tokens -- -- 12. ERROR in ../../jamvm/lib/java/lang/reflect/Method.java (at line 45) import gnu.java.lang.ClassHelper; Method.java ^ Syntax error on tokens, delete these tokens -- 13. ERROR in ../../jamvm/lib/java/lang/reflect/Method.java (at line 46) Method.java Syntax error on token java, ; expected after this token -- 14. ERROR in ../../jamvm/lib/java/lang/reflect/Method.java (at line 48) === ^^^ Syntax error on tokens, delete these tokens -- 15. ERROR in ../../jamvm/lib/java/lang/reflect/Method.java (at line 51) 1.7 ^^^ Syntax error on tokens, delete these tokens -- 15 problems (12 errors, 3 warnings)make[2]: *** [classes.zip] Error 255 make[2]: Leaving directory `/home/cpdev/Nightly/jamvm/build/lib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/cpdev/Nightly/jamvm/build/lib' make: *** [all-recursive] Error 1 ___ Classpath-testresults mailing list Classpath-testresults@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-testresults
[cp-testresults] FAIL: jamvm release build on Sat Jun 7 00:51:24 UTC 2008
4. ERROR in ../../jamvm/lib/java/lang/reflect/Constructor.java (at line 236) CPStringBuilder sb = new CPStringBuilder(128); ^^^ CPStringBuilder cannot be resolved to a type -- 5. ERROR in ../../jamvm/lib/java/lang/reflect/Constructor.java (at line 236) CPStringBuilder sb = new CPStringBuilder(128); ^^^ CPStringBuilder cannot be resolved to a type -- 6. ERROR in ../../jamvm/lib/java/lang/reflect/Constructor.java (at line 258) static void addTypeParameters(CPStringBuilder sb, TypeVariable[] typeArgs) ^^^ CPStringBuilder cannot be resolved to a type -- 7. ERROR in ../../jamvm/lib/java/lang/reflect/Constructor.java (at line 274) CPStringBuilder sb = new CPStringBuilder(128); ^^^ CPStringBuilder cannot be resolved to a type -- 8. ERROR in ../../jamvm/lib/java/lang/reflect/Constructor.java (at line 274) CPStringBuilder sb = new CPStringBuilder(128); ^^^ CPStringBuilder cannot be resolved to a type -- 8 problems (6 errors, 2 warnings)make[2]: *** [classes.zip] Error 255 make[2]: Leaving directory `/home/cpdev/Nightly/jamvm-release/build/lib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/cpdev/Nightly/jamvm-release/build/lib' make: *** [all-recursive] Error 1 ___ Classpath-testresults mailing list Classpath-testresults@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-testresults
[cp-testresults] FAIL: cacao build on Sat Jun 7 00:53:37 UTC 2008
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/VMField.java:242:
warning: .
native int getInt(Object o)
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/VMMethod.java:243:
error: Class or interface declaration expected.
}
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/VMMethod.java:249:
error: syntax error.
private synchronized native MapClass? extends Annotation, Annotation
declaredAnnotations();
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/VMField.java:249:
warning: .
* @param o the object to get the value of this Field from
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/VMMethod.java:251:
error: Class or interface declaration expected.
}
^
../../../cacao/src/classes/gnuclasspath/sun/misc/Unsafe.java:229: error:
Invalid character '@' in input.
@Deprecated
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/Constructor.java:81:
error: '{' expected.
public final class ConstructorT
^
../../../cacao/src/classes/gnuclasspath/java/lang/reflect/Constructor.java:81:
confused by earlier errors, bailing out
make[3]: *** [vm.zip] Error 1
make[3]: Leaving directory `/home/cpdev/Nightly/cacao/build/src/classes'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/cpdev/Nightly/cacao/build/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/cpdev/Nightly/cacao/build'
make: *** [all] Error 2
___
Classpath-testresults mailing list
Classpath-testresults@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-testresults
[cp-testresults] FAIL: ecj built with ecj on jamvm on Sat Jun 7 00:54:48 UTC 2008
xargs: jamvm: No such file or directory ___ Classpath-testresults mailing list Classpath-testresults@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-testresults
[cp-testresults] FAIL: regressions for mauve-kaffe on Sat Jun 7 05:21:56 UTC 2008
Baseline from: Tue Jun 3 14:27:37 UTC 2008 Regressions: FAIL: java.awt.Component.clickModifiers FAIL: java.awt.Component.keyPressTest FAIL: java.awt.Scrollbar.ScrollbarPaintTest FAIL: java.net.HttpURLConnection.responseCodeTest FAIL: javax.net.ssl.SSLEngine.TestHandshake Totals: PASS: 2926 XPASS: 0 FAIL: 204 XFAIL: 0 ___ Classpath-testresults mailing list Classpath-testresults@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-testresults
Re: Savannah has Mercurial!
Hi Andrew, I just noticed this announcement when submitting the news announcement for 0.97.2. What do people think to the idea of switching? Maybe post 0.98? As soon as possible. IMO. /Roman -- http://kennke.org/blog/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Savannah has Mercurial!
Hi Andrew, On Fri, 2008-06-06 at 03:37 +0100, Andrew John Hughes wrote: I just noticed this announcement when submitting the news announcement for 0.97.2. Thanks for doing 0.97.2. I see Michael Koch already pushed it into Debian! What do people think to the idea of switching? Maybe post 0.98? I wouldn't object (although I don't really have trouble with CVS at this point with classpath). So if enough developers think it is a positive switch lets do it. We would be the second project on savannah though, so expect some first adopter issues. The only thing we have to really look out for is doing a good conversion, some experimentation with hg convert and/or tailor might be necessary. Also a better understanding (best practices for) release branches would be nice. I found the in-tree branching of mercurial somewhat confusing at times, so it would be good to make sure we have clear guidelines for those who want to do (release) branches on the tree would be nice. Cheers, Mark
Re: Savannah has Mercurial!
Mark Wielaard wrote: Hi Andrew, On Fri, 2008-06-06 at 03:37 +0100, Andrew John Hughes wrote: I just noticed this announcement when submitting the news announcement for 0.97.2. Thanks for doing 0.97.2. I see Michael Koch already pushed it into Debian! What do people think to the idea of switching? Maybe post 0.98? Mercurial is a disaster as far as I can see. It doesn't seem to be possible to work locally and merge back into the trunk without having to do a complex and error-prone three-way merge, and several times I've got into a state that it was impossible to recover from, even with the help of the best Mercurial experts we have at RH. The only way people work successfully is to merge from trunk, check in, and then push their changes immediately to the mater repo before someone else does any updates to the same files. If you don't get in fast enough, merge time. This approach doesn't scale at all. I wouldn't object (although I don't really have trouble with CVS at this point with classpath). So if enough developers think it is a positive switch lets do it. We would be the second project on savannah though, so expect some first adopter issues. The only thing we have to really look out for is doing a good conversion, some experimentation with hg convert and/or tailor might be necessary. Also a better understanding (best practices for) release branches would be nice. I found the in-tree branching of mercurial somewhat confusing at times, so it would be good to make sure we have clear guidelines for those who want to do (release) branches on the tree would be nice. Indeed. The conversion of the history for gcc was done excellently with no loss of data. We must maks sure we do just as well. Andrew.
Re: Savannah has Mercurial!
2008/6/6 Mark Wielaard [EMAIL PROTECTED]: Hi Andrew, On Fri, 2008-06-06 at 03:37 +0100, Andrew John Hughes wrote: I just noticed this announcement when submitting the news announcement for 0.97.2. Thanks for doing 0.97.2. I see Michael Koch already pushed it into Debian! Wow, that was quick! I guess because he was already testing pre-releases earlier this week. What do people think to the idea of switching? Maybe post 0.98? I wouldn't object (although I don't really have trouble with CVS at this point with classpath). So if enough developers think it is a positive switch lets do it. We would be the second project on savannah though, so expect some first adopter issues. The only thing we have to really look out for is doing a good conversion, some experimentation with hg convert and/or tailor might be necessary. Also a better understanding (best practices for) release branches would be nice. I found the in-tree branching of mercurial somewhat confusing at times, so it would be good to make sure we have clear guidelines for those who want to do (release) branches on the tree would be nice. A lot of thought does need to go into it, which is why if we do switch, I wouldn't want to do so before 0.98 is out, as it could delay it even further. I did try to hg convert it once and didn't get very far. A tree as old as Classpath will be non-trivial. As to release branches, I actually prefer a completely separate tree (like icedtea/icedtea6) rather than in-tree branches, but I'm not sure Savannah would support this. Cheers, Mark Cheers, -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Savannah has Mercurial!
2008/6/6 Andrew Haley [EMAIL PROTECTED]: Mark Wielaard wrote: Hi Andrew, On Fri, 2008-06-06 at 03:37 +0100, Andrew John Hughes wrote: I just noticed this announcement when submitting the news announcement for 0.97.2. Thanks for doing 0.97.2. I see Michael Koch already pushed it into Debian! What do people think to the idea of switching? Maybe post 0.98? Mercurial is a disaster as far as I can see. It doesn't seem to be possible to work locally and merge back into the trunk without having to do a complex and error-prone three-way merge, and several times I've got into a state that it was impossible to recover from, even with the help of the best Mercurial experts we have at RH. The only way people work successfully is to merge from trunk, check in, and then push their changes immediately to the master repo before someone else does any updates to the same files. If you don't get in fast enough, merge time. This approach doesn't scale at all. Yes, I recall reading your discussion of this on IRC. I think CVS has similar issues, if not worse, if you try to work in this way. Of course, doing so is pretty infeasible because even generating a diff requires server access. This and branch management are probably the biggest flaws for me; file/directory versioning is also another issue, but I fall prey to it less often. I do agree that Mercurial seems to be incredibly unintelligent when it comes to merges though - I presume it has it's own system rather than using patch. When Classpath had the same level of commits as IcedTea, we used to be more prone to these sort of mid-air collisions. I can remember the days of working on a patch, updating the repository when finished, testing with all the new changes that would have happened, then committing and failing because the ChangeLog had changed again in the interim. I don't think any VCS is perfect, and most buckle under heavy commits to a single repository. Distributed ones like Mercurial are a lot more flexible in allowing offline working and different development models, which I think is advantageous. I've been using it a lot just to maintain my own material between multiple machines. It's useful to me in this respect just for recording what I've done and for syncing between locations. This is more feasible largely because Mercurial trees are so much easier to create and make available. SSH (and optionally HTTP) access is all you really need. I assume most of your experience comes from working with IcedTea and Mercurial, where I think the project structure itself doesn't help. There are a relatively small number of files which increases the possibility of collision (e.g. nearly all the commits will be to Makefile.am, configure.ac and/or one of the patches). I found in doing the IcedTea6-IcedTea merge that having the autogenerated files from autoconf/automake in there didn't help either, as you'd never want to merge them manually and the newly generated version would differ depending on the version of the autotools it was generated on. By comparison, Classpath should have a much lower hit rate, with fewer developers and a much larger codebase, so I'm more hopeful there. That said, I think running a Mercurial tree in parallel with CVS for some time would be the best option, if feasible. If we do think switching would be a major disaster, we can then abandon it altogether or consider a simpler move to e.g. SVN. I wouldn't object (although I don't really have trouble with CVS at this point with classpath). So if enough developers think it is a positive switch lets do it. We would be the second project on savannah though, so expect some first adopter issues. The only thing we have to really look out for is doing a good conversion, some experimentation with hg convert and/or tailor might be necessary. Also a better understanding (best practices for) release branches would be nice. I found the in-tree branching of mercurial somewhat confusing at times, so it would be good to make sure we have clear guidelines for those who want to do (release) branches on the tree would be nice. Indeed. The conversion of the history for gcc was done excellently with no loss of data. We must maks sure we do just as well. Couldn't agree more. Andrew. -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Savannah has Mercurial!
Andrew John Hughes wrote: 2008/6/6 Andrew Haley [EMAIL PROTECTED]: Mark Wielaard wrote: Hi Andrew, On Fri, 2008-06-06 at 03:37 +0100, Andrew John Hughes wrote: I just noticed this announcement when submitting the news announcement for 0.97.2. Thanks for doing 0.97.2. I see Michael Koch already pushed it into Debian! What do people think to the idea of switching? Maybe post 0.98? Mercurial is a disaster as far as I can see. It doesn't seem to be possible to work locally and merge back into the trunk without having to do a complex and error-prone three-way merge, and several times I've got into a state that it was impossible to recover from, even with the help of the best Mercurial experts we have at RH. The only way people work successfully is to merge from trunk, check in, and then push their changes immediately to the master repo before someone else does any updates to the same files. If you don't get in fast enough, merge time. This approach doesn't scale at all. Yes, I recall reading your discussion of this on IRC. I think CVS has similar issues, if not worse, if you try to work in this way. Of course, doing so is pretty infeasible because even generating a diff requires server access. CVS is ancient and FUBAR. This and branch management are probably the biggest flaws for me; file/directory versioning is also another issue, but I fall prey to it less often. I do agree that Mercurial seems to be incredibly unintelligent when it comes to merges though - I presume it has it's own system rather than using patch. Patch often seems to be the only way to save the situation. When Classpath had the same level of commits as IcedTea, we used to be more prone to these sort of mid-air collisions. I can remember the days of working on a patch, updating the repository when finished, testing with all the new changes that would have happened, then committing and failing because the ChangeLog had changed again in the interim. I don't think any VCS is perfect, and most buckle under heavy commits to a single repository. Distributed ones like Mercurial are a lot more flexible in allowing offline working and different development models, which I think is advantageous. But the problem is that, while Mercurial may support a lot of exciting and novel development models, it doesn't support the most simple and basic models in any reasonable way. I admit that I have not the slightest interest in offline working; I never do that, and I have no intention of starting. I've been using it a lot just to maintain my own material between multiple machines. It's useful to me in this respect just for recording what I've done and for syncing between locations. This is more feasible largely because Mercurial trees are so much easier to create and make available. SSH (and optionally HTTP) access is all you really need. I assume most of your experience comes from working with IcedTea and Mercurial, where I think the project structure itself doesn't help. This is what's known as Poisoning The Well: Your experience is specific to Project XX and therefore not generally applicable, whereas my experience is. I'm not buying it: I've spent plenty of time trying to do really simple things with Mercurial; a VCS firstly needs to do the simple things well before the novel things become interesting. There are a relatively small number of files which increases the possibility of collision (e.g. nearly all the commits will be to Makefile.am, configure.ac and/or one of the patches). I found in doing the IcedTea6-IcedTea merge that having the autogenerated files from autoconf/automake in there didn't help either, as you'd never want to merge them manually and the newly generated version would differ depending on the version of the autotools it was generated on. By comparison, Classpath should have a much lower hit rate, with fewer developers and a much larger codebase, so I'm more hopeful there. That said, I think running a Mercurial tree in parallel with CVS for some time would be the best option, if feasible. If we do think switching would be a major disaster, we can then abandon it altogether or consider a simpler move to e.g. SVN. SVN seems to be a better *basic* VCS in every way. Maybe Mercurial does have its wonderful tools for doing exotic things. Andrew.
Re: Savannah has Mercurial!
Hi Andrew, What do people think to the idea of switching? Maybe post 0.98? Mercurial is a disaster as far as I can see. It doesn't seem to be possible to work locally and merge back into the trunk without having to do a complex and error-prone three-way merge, and several times I've got into a state that it was impossible to recover from, even with the help of the best Mercurial experts we have at RH. The only way people work successfully is to merge from trunk, check in, and then push their changes immediately to the mater repo before someone else does any updates to the same files. If you don't get in fast enough, merge time. This approach doesn't scale at all. I disagree. I think this impression stems from the attempt to map CVS development behaviour to Mercurial (or any other DVCS). I think the way that HG handles this is conceptionally better than CVS. Think about it: Developer A and B both clone the repository at Changeset (CS) 1. Both make changes and end try to push them back. We end up with: /-2 1 \-3 This needs to be merged, no matter if the changes are disjoint or not. Merging disjoint changes is easily done automatically. Now you could argue that CVS does this automatically when committing. I argue that this is not a good idea, because even disjoint changes might lead to a broken tree (although it doesn't happen that often in a well-structured project like Classpath. But I've run into it several times). Even worse, with CVS you basically loose some in-between information (one of the CSs automatically get merged, while with HG you retain all the changesets and get one additional merge CS). The problem you describe occurs when too many people work on one 'trunk'. Then it is possible that you run into a kind of race. E.g. you try to push and get aborted because somebody else pushed in between. You do fetch (which is a great help for such situations instead of pull update merge commit), and try to push again and fail again, because again, somebody has pushed stuff. I agree, that this kind of development doesn't scale beyond a handful of developers. I see two practical solutions to that. A project with so many developers should be structured on the level of the VCS. AFAICS, there are two reasonable approaches to that: 1. the almost-anarchistic Linux kernel model: Every core developer (or maintainer) basically maintains his own public tree and pulls all the changes he cares about from somewhere else (mailing lists, other repos, etc). The release is rolled from one of those trees (Linus' tree in the case of the kernel). 2. A hierarchical model like Sun does for OpenJDK. Developers never push to the master repository, but instead work in their group repository. This decreases the size of each group to a reasonable level, thus avoiding the above problem to a great degree. Pushing then means to do hg fetch hg push. A maintainer guy then pulls all the changes into the master tree on a regular basis, at which point only disjoint CSs are merged, and he can be reasonable certain that the thing ends up in a consistent way (because the groups have reasonable stable interfaces against each other). As a bonus, the maintainer guy should run a test before pushing the stuff to the master repo. I wouldn't object (although I don't really have trouble with CVS at this point with classpath). So if enough developers think it is a positive switch lets do it. We would be the second project on savannah though, so expect some first adopter issues. The only thing we have to really look out for is doing a good conversion, some experimentation with hg convert and/or tailor might be necessary. I think both tailor and hg convert are pretty good and yield reasonable results for large-scale conversions. I think tailor is a little more stable. I did conversion of Jamaica using tailor and had no problems so far. It makes sense to use username mapping, if you want full usernames instead of the CVS shorts. Also a better understanding (best practices for) release branches would be nice. I found the in-tree branching of mercurial somewhat confusing at times, so it would be good to make sure we have clear guidelines for those who want to do (release) branches on the tree would be nice. I prefer separate trees for branches. In-tree branches are only confusing and don't make so much sense. Same for tags. In my experience, trying to map CVS behaviour in this respect is only confusing and creates the impression that HG is in some way not mature. I had a lot of trouble in the autobuild infrastructure of Jamaica, which sets and deletes tags, and found that using clones for that is the only reasonable solution, because a shell script cannot reliably merge things (like tags and branches). Cheers, Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Straße 18 * D-76131 Karlsruhe *
Re: Savannah has Mercurial!
Roman Kennke wrote: Hi Andrew, What do people think to the idea of switching? Maybe post 0.98? Mercurial is a disaster as far as I can see. It doesn't seem to be possible to work locally and merge back into the trunk without having to do a complex and error-prone three-way merge, and several times I've got into a state that it was impossible to recover from, even with the help of the best Mercurial experts we have at RH. The only way people work successfully is to merge from trunk, check in, and then push their changes immediately to the mater repo before someone else does any updates to the same files. If you don't get in fast enough, merge time. This approach doesn't scale at all. I disagree. I think this impression stems from the attempt to map CVS development behaviour to Mercurial (or any other DVCS). I think the way that HG handles this is conceptionally better than CVS. Think about it: Developer A and B both clone the repository at Changeset (CS) 1. Both make changes and end try to push them back. We end up with: /-2 1 \-3 This needs to be merged, no matter if the changes are disjoint or not. Merging disjoint changes is easily done automatically. Now you could argue that CVS does this automatically when committing. I argue that this is not a good idea, because even disjoint changes might lead to a broken tree (although it doesn't happen that often in a well-structured project like Classpath. But I've run into it several times). Even worse, with CVS you basically loose some in-between information (one of the CSs automatically get merged, while with HG you retain all the changesets and get one additional merge CS). I'm not going to try to defend the worst points of CVS, such as its non- atomic commits; a commit should either commit all files or fail. I use svn, and it does the right thing, more or less all the time. The problem with Mercurial is that its main advantage, that of being distributed, is much less of a big deal than the basic day-to-day business of commits, merges, branches and so on, almost all of which AFAICS it does worse than svn. Even when I was new to CVS (and svn) I never managed to get into a state where I had to abandon my changes and start again. The problem you describe occurs when too many people work on one 'trunk'. Then it is possible that you run into a kind of race. E.g. you try to push and get aborted because somebody else pushed in between. You do fetch (which is a great help for such situations instead of pull update merge commit), and try to push again and fail again, because again, somebody has pushed stuff. I agree, that this kind of development doesn't scale beyond a handful of developers. I see two practical solutions to that. A project with so many developers should be structured on the level of the VCS. AFAICS, there are two reasonable approaches to that: 1. the almost-anarchistic Linux kernel model: Every core developer (or maintainer) basically maintains his own public tree and pulls all the changes he cares about from somewhere else (mailing lists, other repos, etc). The release is rolled from one of those trees (Linus' tree in the case of the kernel). 2. A hierarchical model like Sun does for OpenJDK. Developers never push to the master repository, but instead work in their group repository. This decreases the size of each group to a reasonable level, thus avoiding the above problem to a great degree. Pushing then means to do hg fetch hg push. A maintainer guy then pulls all the changes into the master tree on a regular basis, at which point only disjoint CSs are merged, and he can be reasonable certain that the thing ends up in a consistent way (because the groups have reasonable stable interfaces against each other). As a bonus, the maintainer guy should run a test before pushing the stuff to the master repo. This is more or less what we do with gcc, except that we don't need to have multiple repos because svn has zero-overhead branches. Any developer can create a branch any time they like, and work on that branch as though it were their own repo, all changes are tracked, and everything is safely backed up. Also, everyone gets to see and share the work on the branch. Andrew. I wouldn't object (although I don't really have trouble with CVS at this point with classpath). So if enough developers think it is a positive switch lets do it. We would be the second project on savannah though, so expect some first adopter issues. The only thing we have to really look out for is doing a good conversion, some experimentation with hg convert and/or tailor might be necessary. I think both tailor and hg convert are pretty good and yield reasonable results for large-scale conversions. I think tailor is a little more stable. I did conversion of Jamaica using tailor and had no problems so far. It makes sense to use username mapping, if you want full usernames instead of
Re: Savannah has Mercurial!
Heyo, What do people think to the idea of switching? Maybe post 0.98? Mercurial is a disaster as far as I can see. It doesn't seem to be possible to work locally and merge back into the trunk without having to do a complex and error-prone three-way merge, and several times I've got into a state that it was impossible to recover from, even with the help of the best Mercurial experts we have at RH. The only way people work successfully is to merge from trunk, check in, and then push their changes immediately to the mater repo before someone else does any updates to the same files. If you don't get in fast enough, merge time. This approach doesn't scale at all. I disagree. I think this impression stems from the attempt to map CVS development behaviour to Mercurial (or any other DVCS). I think the way that HG handles this is conceptionally better than CVS. Think about it: Developer A and B both clone the repository at Changeset (CS) 1. Both make changes and end try to push them back. We end up with: /-2 1 \-3 This needs to be merged, no matter if the changes are disjoint or not. Merging disjoint changes is easily done automatically. Now you could argue that CVS does this automatically when committing. I argue that this is not a good idea, because even disjoint changes might lead to a broken tree (although it doesn't happen that often in a well-structured project like Classpath. But I've run into it several times). Even worse, with CVS you basically loose some in-between information (one of the CSs automatically get merged, while with HG you retain all the changesets and get one additional merge CS). I'm not going to try to defend the worst points of CVS, such as its non- atomic commits; a commit should either commit all files or fail. I use svn, and it does the right thing, more or less all the time. And I'm not going to defend Mercurial either. I'm just saying that simply mapping concepts and workflows from CVS or SVN to HG just doesn't work. It will get you in trouble soon. It probably doesn't help that certain commands are named similar in Mercurial, just because they do something similar like CVS or Subversion (but not exactly). BTW, I think the problem I described above also applies to Subversion AFAIK, correct me if I'm wrong. But committing changes to files (that doesn't trigger a conflict) will get the remote repository into a different state than you (and therefore anybody else) have on your machine, and is therefore not possible to prove that this is a reasonable state at all. I don't consider automatic merging at push-time a feature. You cannot even get back to the state to where you have been before committing, because CVS and SVN don't bother to separate your changeset from the actual merge. I know, this is not a big deal in almost all situations, mostly because we got used to handle this, but again, HG appears to be more explicit about what happens. The problem with Mercurial is that its main advantage, that of being distributed, is much less of a big deal than the basic day-to-day business of commits, merges, branches and so on, almost all of which AFAICS it does worse than svn. Even when I was new to CVS (and svn) I never managed to get into a state where I had to abandon my changes and start again. Frankly, I've never managed to get into such a state with HG either. In my experience, HG does the basic things like commit, merge, branches, etc just right. 2. A hierarchical model like Sun does for OpenJDK. Developers never push to the master repository, but instead work in their group repository. This decreases the size of each group to a reasonable level, thus avoiding the above problem to a great degree. Pushing then means to do hg fetch hg push. A maintainer guy then pulls all the changes into the master tree on a regular basis, at which point only disjoint CSs are merged, and he can be reasonable certain that the thing ends up in a consistent way (because the groups have reasonable stable interfaces against each other). As a bonus, the maintainer guy should run a test before pushing the stuff to the master repo. This is more or less what we do with gcc, except that we don't need to have multiple repos because svn has zero-overhead branches. Which is the equivalent of having multiple repos in HG. They are also almost zero-overhead because they use hard links. Ok, these will be broken, as branches move on, but well, you can't have zero overhead when branches move on, can you? ;-) Any developer can create a branch any time they like, and work on that branch as though it were their own repo, all changes are tracked, and everything is safely backed up. Also, everyone gets to see and share the work on the branch. Cool. This seems to map perfectly with a distributed model then ;-) Except that everybody would have to find a backup solution on his own. OTOH, a hg clone is a
Re: Savannah has Mercurial!
Il giorno ven, 06/06/2008 alle 11.23 +0200, Roman Kennke ha scritto: Cheers, Roman I tend to second Roman, and I give a +1 to the switch as soon as possible! HG needs some time to get used to, so I expect we will have some troubles, but I think it's worth in the long time. Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-53 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Geschäftsführer: Dr. James J. Hunt Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/
Re: Savannah has Mercurial!
Roman Kennke wrote: What do people think to the idea of switching? Maybe post 0.98? Mercurial is a disaster as far as I can see. It doesn't seem to be possible to work locally and merge back into the trunk without having to do a complex and error-prone three-way merge, and several times I've got into a state that it was impossible to recover from, even with the help of the best Mercurial experts we have at RH. The only way people work successfully is to merge from trunk, check in, and then push their changes immediately to the mater repo before someone else does any updates to the same files. If you don't get in fast enough, merge time. This approach doesn't scale at all. I disagree. I think this impression stems from the attempt to map CVS development behaviour to Mercurial (or any other DVCS). I think the way that HG handles this is conceptionally better than CVS. Think about it: Developer A and B both clone the repository at Changeset (CS) 1. Both make changes and end try to push them back. We end up with: /-2 1 \-3 This needs to be merged, no matter if the changes are disjoint or not. Merging disjoint changes is easily done automatically. Indeed. This is the easy stuff, or should be. What you're seeing here is that the easy stuff (or stuff that *should* be easy) is made hard for developers because of a policy to deal with the super-hard rare stuff such as merges that break even though they have no file conflicts. Now you could argue that CVS does this automatically when committing. I argue that this is not a good idea, because even disjoint changes might lead to a broken tree (although it doesn't happen that often in a well-structured project like Classpath. But I've run into it several times). Even worse, with CVS you basically loose some in-between information (one of the CSs automatically get merged, while with HG you retain all the changesets and get one additional merge CS). Sure, but let's get away from arguing about CVS, which is ancient and almost as broken as hg. I'm not going to try to defend the worst points of CVS, such as its non- atomic commits; a commit should either commit all files or fail. I use svn, and it does the right thing, more or less all the time. And I'm not going to defend Mercurial either. I'm just saying that simply mapping concepts and workflows from CVS or SVN to HG just doesn't work. It will get you in trouble soon. It probably doesn't help that certain commands are named similar in Mercurial, just because they do something similar like CVS or Subversion (but not exactly). BTW, I think the problem I described above also applies to Subversion AFAIK, correct me if I'm wrong. As far as I can understand the problem you're describing above, it doesn't apply. But committing changes to files (that doesn't trigger a conflict) will get the remote repository into a different state than you (and therefore anybody else) have on your machine, and is therefore not possible to prove that this is a reasonable state at all. Sure, but if none of the files you are committing has changed on the trunk since the versions you edited, I don't expect a complaint about merging from the VCS when none of the files have been merged. This is just broken, whether it's deliberate policy or not. Here's how I want to work: Clone the repo. Do work locally, comitting as I go along. Pull from the repo, merging changes from trunk with the changes I just made. Make sure it all works. Push back my changes. If there's a merge conflict at Stage 3 because someone has changed the same lines in a file that I have changed, then I expect to have to fix a conflct. If there isn't, I don't want any complaints from the VCS. I don't consider automatic merging at push-time a feature. You cannot even get back to the state to where you have been before committing, because CVS and SVN don't bother to separate your changeset from the actual merge. I know, this is not a big deal in almost all situations, mostly because we got used to handle this, but again, HG appears to be more explicit about what happens. I don't want automatic merging at push-time. I *do* want automatic merging of trunk with the changes I have committed locally when I pull, and if there are no real conflicts I want a subsequent push to work. The problem with Mercurial is that its main advantage, that of being distributed, is much less of a big deal than the basic day-to-day business of commits, merges, branches and so on, almost all of which AFAICS it does worse than svn. Even when I was new to CVS (and svn) I never managed to get into a state where I had to abandon my changes and start again. Frankly, I've never managed to get into such a state with HG either. In my experience, HG does the basic things like commit, merge, branches, etc just right. Well, I know it's possible in theory, but I also know what happens when I try. And I've been around this in IRC, where
Re: Savannah has Mercurial!
Hi Andrew, What do people think to the idea of switching? Maybe post 0.98? Mercurial is a disaster as far as I can see. It doesn't seem to be possible to work locally and merge back into the trunk without having to do a complex and error-prone three-way merge, and several times I've got into a state that it was impossible to recover from, even with the help of the best Mercurial experts we have at RH. The only way people work successfully is to merge from trunk, check in, and then push their changes immediately to the mater repo before someone else does any updates to the same files. If you don't get in fast enough, merge time. This approach doesn't scale at all. I disagree. I think this impression stems from the attempt to map CVS development behaviour to Mercurial (or any other DVCS). I think the way that HG handles this is conceptionally better than CVS. Think about it: Developer A and B both clone the repository at Changeset (CS) 1. Both make changes and end try to push them back. We end up with: /-2 1 \-3 This needs to be merged, no matter if the changes are disjoint or not. Merging disjoint changes is easily done automatically. Indeed. This is the easy stuff, or should be. What you're seeing here is that the easy stuff (or stuff that *should* be easy) is made hard for developers because of a policy to deal with the super-hard rare stuff such as merges that break even though they have no file conflicts. Yeah, I agree. But how should that be implemented for real? I mean, when you push, the remote side should _try_ a merge, and if it fails, then roll back and complain, and if not, then accept it? I guess, this could be done. I'm not sure if it can be implemented in a way that it works reliable though. Now you could argue that CVS does this automatically when committing. I argue that this is not a good idea, because even disjoint changes might lead to a broken tree (although it doesn't happen that often in a well-structured project like Classpath. But I've run into it several times). Even worse, with CVS you basically loose some in-between information (one of the CSs automatically get merged, while with HG you retain all the changesets and get one additional merge CS). Sure, but let's get away from arguing about CVS, which is ancient and almost as broken as hg. Yeah. I'm not going to try to defend the worst points of CVS, such as its non- atomic commits; a commit should either commit all files or fail. I use svn, and it does the right thing, more or less all the time. And I'm not going to defend Mercurial either. I'm just saying that simply mapping concepts and workflows from CVS or SVN to HG just doesn't work. It will get you in trouble soon. It probably doesn't help that certain commands are named similar in Mercurial, just because they do something similar like CVS or Subversion (but not exactly). BTW, I think the problem I described above also applies to Subversion AFAIK, correct me if I'm wrong. As far as I can understand the problem you're describing above, it doesn't apply. Oh wow. I admit I haven't used SVN so much though. I was suspecting that it works similar to CVS in this respect. But committing changes to files (that doesn't trigger a conflict) will get the remote repository into a different state than you (and therefore anybody else) have on your machine, and is therefore not possible to prove that this is a reasonable state at all. Sure, but if none of the files you are committing has changed on the trunk since the versions you edited, I don't expect a complaint about merging from the VCS when none of the files have been merged. This is just broken, whether it's deliberate policy or not. I disagree. It is just a different view of the system. CVS and Subversion view a project as a bunch of files (Subversion not so much as CVS, but still). HG and other modern VCSs view the thing as a project with certain states and a line (or graph) of development (ChangeSets). If 2 developers both derive from the same version, they create a (implicit) branch, which naturally needs to merge. I think, this is pretty easy logic, but yeah, it interfers with the workflow people are used from CVS and Subversion. Here's how I want to work: Clone the repo. Do work locally, comitting as I go along. Pull from the repo, merging changes from trunk with the changes I just made. Make sure it all works. Push back my changes. If there's a merge conflict at Stage 3 because someone has changed the same lines in a file that I have changed, then I expect to have to fix a conflct. If there isn't, I don't want any complaints from the VCS. This is exactly how it works: hg clone /some/rep cd repo $DO_WORK hg commit blabla hg fetch (or pull merge commit update) hg push Merging is usually done automatically in the fetch (or merge) stage. If it is not possible to do automatically,
Re: Savannah has Mercurial!
2008/6/6 Andrew Haley [EMAIL PROTECTED]: Roman Kennke wrote: What do people think to the idea of switching? Maybe post 0.98? Seems I've opened a proverbial can of worms with this... Mercurial is a disaster as far as I can see. It doesn't seem to be possible to work locally and merge back into the trunk without having to do a complex and error-prone three-way merge, and several times I've got into a state that it was impossible to recover from, even with the help of the best Mercurial experts we have at RH. The only way people work successfully is to merge from trunk, check in, and then push their changes immediately to the mater repo before someone else does any updates to the same files. If you don't get in fast enough, merge time. This approach doesn't scale at all. I disagree. I think this impression stems from the attempt to map CVS development behaviour to Mercurial (or any other DVCS). I think the way that HG handles this is conceptionally better than CVS. Think about it: Developer A and B both clone the repository at Changeset (CS) 1. Both make changes and end try to push them back. We end up with: /-2 1 \-3 This needs to be merged, no matter if the changes are disjoint or not. Merging disjoint changes is easily done automatically. Indeed. This is the easy stuff, or should be. What you're seeing here is that the easy stuff (or stuff that *should* be easy) is made hard for developers because of a policy to deal with the super-hard rare stuff such as merges that break even though they have no file conflicts. Indeed. It's surprised me how often Mercurial has prompted me with merges, as if it can't do any of the job itself. The only time it should be done manually is when the same area of the same file differs. Patching manages to work just fine if a function has moved a few lines down, for example. So why can't Mercurial do this? I'm sure I've had clean merges though with local changes. Now you could argue that CVS does this automatically when committing. I argue that this is not a good idea, because even disjoint changes might lead to a broken tree (although it doesn't happen that often in a well-structured project like Classpath. But I've run into it several times). Even worse, with CVS you basically loose some in-between information (one of the CSs automatically get merged, while with HG you retain all the changesets and get one additional merge CS). Sure, but let's get away from arguing about CVS, which is ancient and almost as broken as hg. Unfortunately we can't completely, because this is what Classpath uses. If we were already on SVN like GCC, I suspect there'd be much less of an issue. snip... But committing changes to files (that doesn't trigger a conflict) will get the remote repository into a different state than you (and therefore anybody else) have on your machine, and is therefore not possible to prove that this is a reasonable state at all. Sure, but if none of the files you are committing has changed on the trunk since the versions you edited, I don't expect a complaint about merging from the VCS when none of the files have been merged. This is just broken, whether it's deliberate policy or not. Here's how I want to work: Clone the repo. Do work locally, committing as I go along. Pull from the repo, merging changes from trunk with the changes I just made. Make sure it all works. Push back my changes. If there's a merge conflict at Stage 3 because someone has changed the same lines in a file that I have changed, then I expect to have to fix a conflict. If there isn't, I don't want any complaints from the VCS. This is how I also tend to work. snip.. Frankly, I've never managed to get into such a state with HG either. In my experience, HG does the basic things like commit, merge, branches, etc just right. Well, I know it's possible in theory, but I also know what happens when I try. And I've been around this in IRC, where I explain the simple thing I've been trying to do, the fact it doesn't work, and no-one has any clue how to repair the situation. I suspect that most of the icedtea developers solve this problem simply by not doing local hg operations at all. It would be interesting to ask icedtea developers just how much they use hg to do local develeopment. The little work I've done on IcedTea has been multiple-commit-pull-push as you outline above. The merging of the pull has required a little more of me than I'd expect, but I've not really had anything broken yet. snip... Any developer can create a branch any time they like, and work on that branch as though it were their own repo, all changes are tracked, and everything is safely backed up. Also, everyone gets to see and share the work on the branch. Cool. This seems to map perfectly with a distributed model then ;-) I have no idea what you mean by this. There seems to be a world of difference between multiple
Re: Savannah has Mercurial!
Roman Kennke wrote: I'm not going to try to defend the worst points of CVS, such as its non- atomic commits; a commit should either commit all files or fail. I use svn, and it does the right thing, more or less all the time. And I'm not going to defend Mercurial either. I'm just saying that simply mapping concepts and workflows from CVS or SVN to HG just doesn't work. It will get you in trouble soon. It probably doesn't help that certain commands are named similar in Mercurial, just because they do something similar like CVS or Subversion (but not exactly). BTW, I think the problem I described above also applies to Subversion AFAIK, correct me if I'm wrong. As far as I can understand the problem you're describing above, it doesn't apply. Oh wow. I admit I haven't used SVN so much though. I was suspecting that it works similar to CVS in this respect. svn is a real database, and has real atomic multi-file change sets. The idea of svn was just to fix the things about CVS that everyone knew were broken, and this was one of them. But committing changes to files (that doesn't trigger a conflict) will get the remote repository into a different state than you (and therefore anybody else) have on your machine, and is therefore not possible to prove that this is a reasonable state at all. Sure, but if none of the files you are committing has changed on the trunk since the versions you edited, I don't expect a complaint about merging from the VCS when none of the files have been merged. This is just broken, whether it's deliberate policy or not. I disagree. It is just a different view of the system. CVS and Subversion view a project as a bunch of files (Subversion not so much as CVS, but still). HG and other modern VCSs view the thing as a project with certain states and a line (or graph) of development (ChangeSets). If 2 developers both derive from the same version, they create a (implicit) branch, which naturally needs to merge. I think, this is pretty easy logic, but yeah, it interfers with the workflow people are used from CVS and Subversion. Here's how I want to work: Clone the repo. Do work locally, comitting as I go along. Pull from the repo, merging changes from trunk with the changes I just made. Make sure it all works. Push back my changes. If there's a merge conflict at Stage 3 because someone has changed the same lines in a file that I have changed, then I expect to have to fix a conflct. If there isn't, I don't want any complaints from the VCS. This is exactly how it works: hg clone /some/rep cd repo $DO_WORK hg commit blabla hg fetch (or pull merge commit update) hg push Merging is usually done automatically in the fetch (or merge) stage. If it is not possible to do automatically, then it pops up kdiff3 or whatever tool it finds to let you merge manually. I suspect that the problem was that I didn't use fetch because it wasn't installed when I tried to work this way, and I didn't realize that it was necessary to do the full pull merge commit update part. It sounds like fetch does the Right Thing, anyway. then it pops up kdiff3 or whatever tool it finds to let you merge manually. Well, yes, it did that, and it was talking about files that *I had not changed locally*, so I had no way to know what to do. These were files that had been changed by someone else since I pulled, I guess. I don't consider automatic merging at push-time a feature. You cannot even get back to the state to where you have been before committing, because CVS and SVN don't bother to separate your changeset from the actual merge. I know, this is not a big deal in almost all situations, mostly because we got used to handle this, but again, HG appears to be more explicit about what happens. I don't want automatic merging at push-time. I *do* want automatic merging of trunk with the changes I have committed locally when I pull, and if there are no real conflicts I want a subsequent push to work. I understand. What exactly was the original problem then? hg fetch does exactly this. The only thing I see is that another developer _might_ have pushed his own changes while you merge, which is usually easily fixed by doing hg fetch again. BTW: The same usually happens with all other VCSes too, at least when ChangeLog files are involved ;-) Oh, sure if the files had really changed locally and on trunk, but that wasn't what I was seeing. Well, I know it's possible in theory, but I also know what happens when I try. And I've been around this in IRC, where I explain the simple thing I've been trying to do, the fact it doesn't work, and no-one has any clue how to repair the situation. I suspect that most of the icedtea developers solve this problem simply by not doing local hg operations at all. It would be interesting to ask icedtea developers just how much they use hg to do local develeopment. Eh. Is there anyway to interact with
Re: Savannah has Mercurial!
Andrew John Hughes wrote: To be honest, one of the greatest advantages of Mercurial for me goes away when someone like Savannah is hosting the tree i.e. the setup and maintenance costs are much weightier with CVS or Subversion. It means I know tend to put things in a repository right away, so changes are being tracked from day zero, and it's also now my preferred way of distributing stuff. Yes. The idea that all these developers are sitting on local hg databases with their own random backup cycles is appalling, like a return to the stone age before version control systems. My model is to commit early and often, whenever I make changes that might break things. Andrew.
Re: Savannah has Mercurial!
Andrew John Hughes wrote: I just noticed this announcement when submitting the news announcement for 0.97.2. What do people think to the idea of switching? Maybe post 0.98? Hi, just to give a different perspective. For Jikes RVM there's been no choice to use Mercurial as SourceForge don't provide it, this may actually have been no bad thing. There are lots of different version control tools, but both Mercurial and GIT support pulling and pushing to a SVN repository. Clearly using SVN with SVN isn't a problem and CVS is out-of-date anyway. So in summary, having a central repository that's an SVN repository can be a good thing as it supports the maximum number of version control tools. We have a list of different tools for working with our repository (hg, git, svn, svk, darcs, svm, rsync) and how to set them up with Jikes RVM here: http://jikesrvm.org/Using+Distributed+And+Local+Version+Control+Tools I may be talking rubbish as I'm not a version control guru. Regards, Ian -- http://www.cs.man.ac.uk/~irogers/
Re: Savannah has Mercurial!
Il giorno ven, 06/06/2008 alle 15.05 +0100, Ian Rogers ha scritto: Andrew John Hughes wrote: I just noticed this announcement when submitting the news announcement for 0.97.2. What do people think to the idea of switching? Maybe post 0.98? Hi, just to give a different perspective. For Jikes RVM there's been no choice to use Mercurial as SourceForge don't provide it, Hi Ian! We use hg with escher, and it's hosted on sf. You may give a look at this: http://www.selenic.com/mercurial/wiki/index.cgi/MercurialOnSourceforge It's not publicized, but allowed by the sf team as far as I know. So in summary, having a central repository that's an SVN repository can be a good thing as it supports the maximum number of version control tools. We have a list of different tools for working with our repository (hg, git, svn, svk, darcs, svm, rsync) and how to set them up with Jikes RVM here: http://jikesrvm.org/Using+Distributed+And+Local+Version+Control+Tools I may be talking rubbish as I'm not a version control guru. Regards, I'm not sure I understand, but I don't think it's a good idea for development to mix up. Just my 2 cents :) Mario
Re: Savannah has Mercurial!
2008/6/6 Mario Torre [EMAIL PROTECTED]: Il giorno ven, 06/06/2008 alle 15.05 +0100, Ian Rogers ha scritto: Andrew John Hughes wrote: I just noticed this announcement when submitting the news announcement for 0.97.2. What do people think to the idea of switching? Maybe post 0.98? Hi, just to give a different perspective. For Jikes RVM there's been no choice to use Mercurial as SourceForge don't provide it, Hi Ian! We use hg with escher, and it's hosted on sf. You may give a look at this: http://www.selenic.com/mercurial/wiki/index.cgi/MercurialOnSourceforge It's not publicized, but allowed by the sf team as far as I know. Bah! You beat me to it! So in summary, having a central repository that's an SVN repository can be a good thing as it supports the maximum number of version control tools. We have a list of different tools for working with our repository (hg, git, svn, svk, darcs, svm, rsync) and how to set them up with Jikes RVM here: http://jikesrvm.org/Using+Distributed+And+Local+Version+Control+Tools I may be talking rubbish as I'm not a version control guru. Regards, I'm not sure I understand, but I don't think it's a good idea for development to mix up. Just my 2 cents :) I've been contemplating this idea as the discussion went on. I think a switch to something other than CVS is needed, as it just doesn't track things well enough in general. For me the speed of diffs/status checks in CVS is appalling and has a significant impact on my work habits. Maybe we should instead think about switching to SVN as our main tree and those who want to use Mercurial, git, darcs, etc. could work with them in the way Ian describes? Again, we'd obviously need a trial period. Mario -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Savannah has Mercurial!
Andrew == Andrew John Hughes [EMAIL PROTECTED] writes: Andrew For me the speed of diffs/status checks in CVS is appalling Andrew and has a significant impact on my work habits. For diff I can't help you, but for status I recommend the cvs utils. I've used these upwards of ten years, I can't really picture using cvs without them. FWIW, I'm ambivalent about changing Classpath's VC system. We haven't had many branches historically (do we have any now?), bypassing one of cvs's big problems. The diff thing is annoying, though I guess I'm used to it. One consideration is whether there is Eclipse support for the new system. Assuming, that is, that any active Classpath developers are using Eclipse. Tom
