Hi, can advice how to unsubscribe form the mailing list? thanks
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pierre Asselin Sent: Friday, March 04, 2005 11:13 AM To: [email protected] Subject: Re: Again: multiple vendors Baurzhan Ismagulov <[EMAIL PROTECTED]> 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 [email protected] http://lists.gnu.org/mailman/listinfo/info-cvs _______________________________________________ Info-cvs mailing list [email protected] http://lists.gnu.org/mailman/listinfo/info-cvs
