Re: Again: multiple vendors

[Pierre Asselin]

Baurzhan Ismagulov <address@hidden> wrote:

> Could a Branching Expert please help me drawing the same for my needs?
> I've got 4 upstream vendors and want to keep them in different branches.
> I have two goals: importing new upstream versions and merging the deltas
> into the main trunk, and tracking which change introduced a particular
> bug.

> [ complicated, reticulated branching diagram omitted ]

Maybe something simple:



            /1.1.1------------>
           /
MAIN      1.1
          \
          |\
LINUS     | \1.1.2------------>
          |
          \
          |\
RMK       | \1.1.4------------>
          |
          \
          |\ 
PXA       | \1.1.6------------>
          |
          \
           \
HWVENDOR    \1.1.8------------>


That is:  ALL of them branched from 1.1 .  The "MAIN" series is
imported on a vendor branch for convenience, but all others are
regular branches off of the first trunk revision.  (Maybe the MAIN
series should be a regular branch too.)

Or maybe the common branch point can be the tip of the trunk after
the main import, so you'll have weird branch numbers like 1.1.1.12.8.x
different for each file.  Doesn't matter, don't look at the numbers.

I don't think the actual branch structure matters.  What you do want
is all the various releases *somewhere* in the hierarchy, and *tagged*.
Keep good notes about your tags.  Your notes *should* have the filiation
of the various releases if known, but only for reference.  With tagged
sets in your repository you can look at diffs and merge abritrary
deltas to your trunk.  That should be enough (but you have a hell of
a lot of vendors !).


To start a new vendor series you would probably do something like this.

    cvs checkout -rCOMMON_BRANCHPOINT the_mess
    cd the_mess
    :
    : start new branch
    cvs tag -b LINUX
    cvs update -r LINUX
    :
    : remove all files, keep CVS metadata
    : (not tested)
    find . -type d ! -name CVS | while read d; do
        (cd $d && rm *)
    done
    :
    : Overlay first tarball
    cp -r path/to/fresh/tarball/* .
    :
    : See what files are new or removed
    cvs -nq update -I! -ICVS
    :
    : "U" or "P" files need to be cvs-deleted
    : "?" files need to be cvs-added
    : "?" directories need to be recursively added
    " "M" files can stay
    :
    cvs commit
    cvs tag LINUX-1
    :
    : remove all files again,
    : overlay second tarball, repeat


As Greg Woods said, if your vendors do a lot of file renaming and
directory remodeling CVS will lose.  You won't be able to do
effective automated merges and you'll need a more powerful tool.
Looking at your branch names, this may be a job for bitkeeper...
I know nothing about bitkeeper, other than it was designed for
insanely decentralized development.


-- 
pa at panix dot com