RE: Again: multiple vendors

[Andy Cheong Kok Mung]

Hi, can advice how to unsubscribe form the mailing list?

thanks

-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of
Pierre Asselin
Sent: Friday, March 04, 2005 11:13 AM
To: address@hidden
Subject: Re: Again: multiple vendors


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 _______________________________________________
Info-cvs mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/info-cvs