Thomas Davie wrote:
On 6 Feb 2009, at 10:12, Paolo Losi wrote:
Henning Thielemann wrote:
4) hg commit -m "message" this commits my changes locally. I always do this before pulling since then I'm sure my changes are saved in the case a merge goes wrong. In old darcs its precisely the other way round. Since it is so slow on merging ready patches, you better merge uncrecorded changes.
IMO pulling & merging before commit is a good practise also for hg: it avoids a (very often useless) merge commit in the history.
I don't understand this view. Isn't the point of a commit that you flag working points. In each branch, before you merge (hopefully) you have a working repository, so flag it as such, and commit. When you merge, you may or may not have a working repository, fix it until it is, and merge.
I would never do a merge without the two branches I was merging having a commit just before the merge.
Bob
I think you're right. but: - if you synch with the central repo at every commit you usually have a sort of out of band protocol with your peers for avoiding conflicts and in case of conflicts the manual merge is easy (if you occasionally merge unrelated branches that is obviously a different story) - the problem with mercurial is that it doesn't allow to amend history (you cannot afford to "merge" the first commit with the "merge" commit) and the commit history becomes cluttered. That's the reason why I prefer (in the case of commit/sync/commit/sync... scenario) pulling and updating before committing. AFAIK darcs and git doesn't have this problem, so the approach your suggesting should be the best in any case. I'm an "old" user of mercurial but I'm starting seeing some shortcomings with respect to git (and probably darcs). I really hope there will be some sort of convergence on a de facto DVCS soon in the opensource community :-) Paolo