Not a holy war - just some salient facts

[Mike Meyer]

On Tue, 13 Apr 2010 00:44:13 +0200
Sune Foldager <cryo at cyanite.org> wrote:
> > Most people seem to hate the
> > perforce three-phase merge;
> 
> I actually don't know it. I don't know how many phases mercurial's is
> in? resolve, test, commit?

I'd say two, based on the number of commands: merge/commit, where
merge runs the resolve phase. Perforce is three commands:
integ/resolv/submit.

> > I personally feel like everything else is
> > just tossing my code against a wall and hoping the right parts stick
> > (I've got an outline for a mercurial merge tool that DTRT; one of
> > these days I hope to finish it).
> Yeah that'll be the day... No, seriously, it's not possible to do the
> right thing in all situations. Correct merging is not something that can
> be automated.

Exactly. Perforce is the only CVS I've run into that doesn't have to
have the automated merging turned off out of the box.

> > Perforce has real change tracking;
> Ehm.. and Mercurial doesn't? Are you refering to tracking 'cherry
> picks'? In my experience, tracking those things doesn't really help
> anything except serving as a documentation of what has been going on,
> and mercurial's transplant does save it in metadata.

Well, cherry picks are the primary use, but in any workflow where you
might pick up a change more than once, it's really nice to have. Last
time I checked, mercurial didn't do this properly. The documentation
is important, but letting you skip repeatedly merging in changesets
makes saves work.  I.e. - if I look at a series of four changsets and
merge them into my branch by taking two as is, tweaking one a bit, and
ignoring the fourth because it's not needed, if I then do a merge from
another branch those have been merged into, I shouldn't have to remake
those decisions.

15 years of not having to deal with repeated merges makes it painfully
obvious when you run into it :-(. But this - and the truly messy
merges that make the perforce integ/resolv/submit shine - aren't that
big a problem for a small shop.

> > The git community seems to think rebase is a
> > simple operation that everyone should use; the mercurial community
> > treats it as a special case, and provides tools for handling workflows
> > that git does with rebase (one of the reasons I'm using hg instead of
> > git), whereas most CVCS's make you do one or more merges to get that
> > effect. And so on.
> At work (where we are about 150 people using mercurial), we generally
> use rebase to avoid having one million merges all over the revision
> graph. It's pretty nice, and in the end rebase and merge invoke the
> exact same merge-based logic underneath, so there is no real difference
> in how the merges are resolved.

Like I said, a lot of these are "but we like it that way" type
thing. Me, I'd rather have the merges; that may be because I'm used to
having real change tracking and full control of my merges, or it may
be just me.

       <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org