2008/6/6 Andrew Haley <aph@xxxxxxxxxx>: > 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
