Hi Andrew, > >>>>>> 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.
Yeah, I agree. But how should that be implemented for real? I mean, when you push, the remote side should _try_ a merge, and if it fails, then roll back and complain, and if not, then accept it? I guess, this could be done. I'm not sure if it can be implemented in a way that it works reliable though. > >>> 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. Yeah. > >> 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. Oh wow. I admit I haven't used SVN so much though. I was suspecting that it works similar to CVS in this respect. > > 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. I disagree. It is just a different view of the system. CVS and Subversion view a project as a bunch of files (Subversion not so much as CVS, but still). HG and other modern VCSs view the thing as a project with certain states and a line (or graph) of development (ChangeSets). If 2 developers both derive from the same version, they create a (implicit) branch, which naturally needs to merge. I think, this is pretty easy logic, but yeah, it interfers with the workflow people are used from CVS and Subversion. > 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. This is exactly how it works: hg clone /some/rep cd repo && $DO_WORK hg commit blabla hg fetch (or pull & merge & commit & update) hg push Merging is usually done automatically in the fetch (or merge) stage. If it is not possible to do automatically, then it pops up kdiff3 or whatever tool it finds to let you merge manually. > > 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. I understand. What exactly was the original problem then? hg fetch does exactly this. The only thing I see is that another developer _might_ have pushed his own changes while you merge, which is usually easily fixed by doing hg fetch again. BTW: The same usually happens with all other VCSes too, at least when ChangeLog files are involved ;-) > >> 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. Eh. Is there anyway to interact with Mercurial other than locally? I don't think all the developers log into the server, and do all the work directly in the master repo. Infact, I think this is not possible at all, technically. > >> 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. Ok, I think I misunderstood something. Yes, having things all in one location is sweet. Infact, it is quite easy (and makes a lot of sense) to mimic Subversion: Simply create a directory structure on the server with trunk/, branches/ and tags/ in it, and clone the stuff for branching and tagging. Yes, I consider tags and in-tree branches broken in HG, and would strongly recommend to use clones for all that. /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
