Re: Help! Implementing Bi-Directional Merges

[Eric Siegerman]

On Mon, Oct 15, 2001 at 10:52:57AM -0700, Nesbitt, Steve wrote:
> Base question is how can I successfully implement a bi-directional merge
> between two branches when the merge to one branch must be deferred?
> 
> Another way to phrase the question is "How do I force the tip of one branch
> to be identical to the tip of another branch?"

It may occasionally be useful to do this to recover from an
unusual situation, but as an ongoing part of your development
process, it'd be extremely dangerous!

> Here's the scenario...
> 
> HEAD
> 1.1*****1.2*****1.3
> *                 *          ?
> *                  *          ?
> *                   *          ?
> * DEV                *          ?
>     1.1*****1.1.2*****1.1.3*****1.1.4
> 
> 
> I have some ongoing work being supported on the HEAD branch. I have some
> future work being performed on DEV.
> 
> After the initial branch, foo.c on branch DEV is modified resulting in
> version 1.1.2. Head work continues resulting in foo.c versions 1.2 and 1.3.
> 
> The Dev branch needs the changes made to HEAD and a merge is performed
> creating version 1.1.3 which consists of the changes made to create foo.c
> version 1.2.

And 1.3, I think (not too germane -- I'm just being pedantic).

> Work continues on DEV resulting in version 1.1.4 at which point DEV is
> complete and all changes need to be propogated to HEAD. In this case it
> means that the changes made between 1.1 and 1.1.2 and between 1.1.3 and
> 1.1.4 need to be merged into HEAD. Changes made between
> 1.1.2 and 1.1.3 should NOT be merged in because they came from HEAD. 

Here's the problem.  Suppose someone checks in 1.4 and you don't
notice it.  If you brute-force copy 1.1.4 back to the trunk,
you'll overwrite the 1.4 changes.  They'll still be in the repo, of course,
but NOT in 1.5, the result of the copy.

Better would be to do a merge back from DEV to the trunk.  You're
right; you don't want the 1.1.2-1.1.3 changes, so it really takes
two merges, to get the 1.1-1.1.2 and 1.1.3-1.1.4 changes,
respectively.  If you've created both pre- and post-merge tags
for the 1.3-1.1.3 merge shown in the diagram, this will be fairly
straightforward.

What will be harder on an ongoing basis is to keep track of which
tags have been merged and which haven't been.  That ugly bit of
bookkeeping will take a big chart on the wall, or its logical
equivalent.  Subversion (http://subversion.tigris.org/) promises
to solve this problem, but of course it's not out yet.

> Yes, the cleanest answer is probably to switch tasks - work DEV is
> supporting should move to HEAD and vice versa. The problem with that is that
> I have only 5 developers on DEV and 25 on the HEAD task and trying to keep
> 25 developers successfully on a branch (especially when their habitual
> updatecommand includes -A) is guaranteed to make me lose the rest of my
> hair.

As good an argument as I've seen for per-branch permissions!  No,
that would not be secure in the sense that kernel-mediated
permissions are secure -- it would be of NO use against a
malicious attacker.  But it'd guard quite well against
inadvertent errors.  Steve could switch DEV to the trunk and
(what he calls) HEAD off of it, and his "habitual update includes
-A" users would soon learn the error of their ways, i.e. when
their commits kept failing, and they wouldn't be doing damage in
the meantime.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
The world has been attacked.  The world must respond ... [but] we must
be guided by a commitment to do what works in the long run, not by what
makes us feel better in the short run.
        - Jean Chrétien, Prime Minister of Canada