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 pretty reasonable backup solution, so... 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 * Germany http://www.aicas.com * Tel: +49-721-663 968-0 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Geschäftsführer: Dr. James J. Hunt
