Workflow question, advice...

[Doug Philips]

On Tuesday, April 15, 2008, at 02:09PM, "Gregory Collins"  wrote:
...
>There are pros and cons to all of these approaches. At our shop we're
>picky about when new features get pushed to trunk, but we're not too
>worried about the change graph looking "pretty" or "linear". As long as
>the project subbranches are merged frequently, this kind of development
>is quite painless.
...
>http://www.perforce.com/perforce/conferences/us/2005/presentations/Wingerd.pdf

I've looked over that before, thanks to you or whomever
it was that posted it not too long ago!

Let me try to restate the current workflow and potential new workflow issue...
Unlike the approach you use, and the approach in the paper cited above,
I'm focussed on the workflow -within- one branch.
Micro work flow, perhaps would be a reasonable characterization...
I like/agree-with/etc. the larger picture and think that will work for us just fine.


Within one line of development, what we have right now is much like:

mainline -> dev-a; mainline -> dev-b; mainline -> dev-c; ...
(i.e. everyone pulls from the main CVS repo).

dev-a -> mainline-a; dev-b -> mainline-a; dev-c -> mainline-a; ...
(i.e. independent changes are pushed back to mainline and
validated in any order and do not require a cvs up first.)
With CVS this is painless 95% of the time because the changes
coming from dev-<x> are independent, there is no need to
linearize them in any particular order and there is no sense
in which there is, logically, a merge.

With Mercurial, I was hoping to get all the advantages (for our other 5%)
without giving up this advantage in the 95%.

My understanding, however, is that we'll be forced to either:
    do n-1 merges in a linear fashion, or
    accept n heads and then do n-1 "reducing" merges.

Now, I fully admit that even in my 95% scenario there could be
some interactions that would make a merge "interesting", but
for 99% of those 95%, the merges will be just noise and wil
 convey nothing -useful- that the presence of the merged
changeset doesn't -already- tell us. I see this in the mercurial
commit emails all the time on the -dev list.
Oh, look, "thing x happened."
Oh, surprise, surprise, "merge: thing x is now in the tree."
If it weren't for "thing x happened", "merge: thing x is now in the tree"
would not exist and most of the time it is dead boring.

The merges that are interesting are the "Merge: Added thing x, had to adjust thing y."
But to mercurial, merges are just merges...

I'd like to find a way around that, but I seem to be hearing that there isn't.
I agree with some of the other posters on this thread that a log hiding
merges would be a help, and also agree that not all merges are equally ignorable.

Maybe that is addressable with semi-automatic tagging, I'm not sure...

     --Doug