Roman Kennke wrote: >>>> 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. svn is a real database, and has real atomic multi-file change sets. The idea of svn was just to fix the things about CVS that everyone knew were broken, and this was one of them. >>> 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 suspect that the problem was that I didn't use fetch because it wasn't installed when I tried to work this way, and I didn't realize that it was necessary to do the full pull & merge & commit & update part. It sounds like fetch does the Right Thing, anyway. > then it pops up kdiff3 or whatever tool it finds to let you merge > manually. Well, yes, it did that, and it was talking about files that *I had not changed locally*, so I had no way to know what to do. These were files that had been changed by someone else since I pulled, I guess. >>> 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 ;-) Oh, sure if the files had really changed locally and on trunk, but that wasn't what I was seeing. >> 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. There is a way: do all your development locally with no commits, then pull and update and commit and push straight away. That way you never get into a situation where you might have merge problems. The only time I ever got in a mess with hg is when I was using it locally and then wanted to push my committed changes upstream. In the end I had to clone the repo again, generate a diff on the old repo that refused to push, apply the diff with patch, and commit. Andrew.
