Re: Problem with multiple merges from trunk to tree (and much more. :-)

[Greg A. Woods]

[ On , July 14, 2001 at 22:07:00 (+0200), Garvin Hicking wrote: ]
> Subject: Problem with multiple merges from trunk to tree (and much more. :-)
>
> [1] Requirements:
>  * Maintain a development line, and a final line
>  * Easy to export the production version of the project via a never-
>    changing tag/branch
>  * Easy to modify files in the development line without integrating them
>    into the final line
>  * Easy to modify files from the final line, which will immediately get
>    modified in the development version (or vice versa)
>  * No need to create working directory apart from beta/, final/ and
>    production/
>  * Easy tagging, if possible (I don't want to tag every single file in the
>    project with specific revisions only because of one file getting
>    updated)

You can't expect to merge a branch onto another branch more than once,
at least not with CVS (or RCS or SCCS for that matter).

When you ask CVS to merge a branch it literally takes all the delta
between the base of the branch and its head and applies it to the
working directory you're doing the merge.

It's the equivalent of doing:

        cvs rdiff -r br_base -r br_head | patch

(where br_base and br_head are non-branch tags that point to the base
and head of a branch respectively)

If you want to only merge the changes since the last merge then you
either have to: a) recreate the branch; or b) tag the head of the branch
at the time you do each merge (and only merge from the previous tag to
the new head); or c) keep track of each change you make on the branch
and manually apply the same changes to the trunk when you're ready.

Somewhere someone's documented explicit procedures for doing a leap-frog
tag/merge scheme to only merge new changes from one branch to another
with a minimum of tags.  I don't have a reference handy but someone else
might....

You might be better off putting your production branch on the trunk and
doing development on separate branches that can be closed off and merged
only once to the trunk.  Strictly speaking there should be no logical
difference between using the trunk or a separate branch for either
development or release management, but there are some things that just
work better on the trunk, and are harder to screw up on the trunk.  I
think given the model of development you've described it would be best
for the release to be on the trunk and for all development to occur on
one or more branches.  The only problem is that this can lead to
accidents should anyone commit directy to the trunk (which is also an
easy mistake to make).  However in your environment this would seem to
be less of a worry.

I think you may be slightly confusing yourself by talking about the
"production version" too.  Isn't it really just what happens to be on
the "final" branch at the time you update the production system(s)?  You
might want to tag what's put into production each time though, just in
case you lose track of what it is should you ever (have to) do multiple
merges without updating the production system(s).

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>