2008/6/6 Andrew Haley <aph@xxxxxxxxxx>: > 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 repos all over the place and a single tree > with branches, tags, and so on. > >> Except that everybody would have to find a backup solution on his own. >> OTOH, a hg clone is a pretty reasonable backup solution, so... > > I think Roman's point was that this is already more of a traditional distributed methodology than a centralised one, albeit implemented using a centralised system and branches i.e. the only difference between this and Mercurial is that Mercurial commits locally rather than uploading to a server. The real contrast is between this type of model and a centralised model where everyone commits to one tree. Ironically, it seems GCC is currently using a distributed methodology with a centralised VCS and IcedTea is used a centralised methodology with a distributed VCS, neither of which are 'the norm'. 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. > 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
