Andrew John Hughes wrote: > 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. 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.
