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 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. >>> 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? ;-) No, of course not. >> 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... Andrew.
