Re: Again: multiple vendors

[Greg A. Woods]

[ On Wednesday, March 2, 2005 at 22:19:22 (+0100), Baurzhan Ismagulov wrote: ]
> Subject: Again: multiple vendors (was: Re: Long version numbers | Tedious to 
> keep track)
>
> 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.

Do not use "cvs import".  It can not work as any part of what you want
to do.

Just create a separate, normal, branch (direct from the trunk) for each
supplier to "work on", and "manually" commit each of their releases to
their branch as you obtain them (this can all be automated with very
simple little scripts).

You can then manually merge their changes to the trunk, and any other of
your local branches as necessary and desired, from one supplier's branch
at a time.

(you'll of course have to start the module, i.e. with the files at the
base 1.1 revision, with some variant of the code -- presumably all these
suppliers have started with some common baseline too, so maybe that
would be the best to start your module with, though it really doesn't
matter provided none of the other maintainers have mucked around with
unnecessary filename changes)

As for the "tracking changes which introduce bugs", well that's up to you! :-)

-- 
Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>  Secrets of the Weird <[EMAIL 
PROTECTED]>


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Again: multiple vendors

[Baurzhan Ismagulov]

Hello Greg,

thanks for your answer!

On Thu, Mar 03, 2005 at 03:58:42AM -0500, Greg A. Woods wrote:
> > 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.
> 
> Do not use "cvs import".  It can not work as any part of what you want
> to do.

Hmm, Cederqvist recommends it in
https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs_13.html#SEC108


> Just create a separate, normal, branch (direct from the trunk) for each
> supplier to "work on", and "manually" commit each of their releases to
> their branch as you obtain them (this can all be automated with very
> simple little scripts).

I thought about that, but this is going to be a bit time-consuming due
to:

1. Added and deleted files: I have to track them manually when I apply
   the delta for a new upstream release. I have to grep for 1970 and add
   / remove the files.

2. CVS keywords in the upstream patches. I have to import the previous
   and the current release into a temporary module and produce the diff
   with -kk.


That is why I was wondering if the method described in the manual could
work for me.


With kind regards,
Baurzhan.


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Again: multiple vendors

[Greg A. Woods]

[ On Thursday, March 3, 2005 at 21:31:58 (+0100), Baurzhan Ismagulov wrote: ]
> Subject: Re: Again: multiple vendors
>
> On Thu, Mar 03, 2005 at 03:58:42AM -0500, Greg A. Woods wrote:
> > 
> > Do not use "cvs import".  It can not work as any part of what you want
> > to do.
> 
> Hmm, Cederqvist recommends it in
> https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs_13.html#SEC108

Read again.

There's nothing in there about multiple vendors (or if there is and I've
forgotten about it, it's blatantly wrong and misleading).

Multiple vendor branches CANNOT work for what you want.  Period.

The idea of using multiple vendor branches was hinted at in the original
CVS-II paper, but the design of how vendor branches work prohibits them
from working properly with multiple vendor branches.  Any attempt to
extend that hint into the modern documentation is a mistake.  Just
because "cvs import" lets you specify alternate branches doesn't mean it
is sane to do so.

(indeed vendor branches don't mix well with normal branches either)

"cvs import" is a very cheap-trick hack that works well for trivial
maintenance of local changes to third party modules.  It does work very
well for that job (I've used it for ten years or more on gigabytes of
source), but it's still just a very cheap-trick hack.


> I thought about that, but this is going to be a bit time-consuming due
> to:
> 
> 1. Added and deleted files: I have to track them manually when I apply
>the delta for a new upstream release. I have to grep for 1970 and add
>/ remove the files.

That part can _very_ trivially be scripted and totally automated.

The only hard part is merging with your changes IFF you locally modify a
removed file, etc.

BTW, if your code suppliers add and remove files frequently, and
especially if doing so causes them to diverge significantly from each
other, then your hope to use a tool like CVS to more easily merge
changes from each supplier into one common baseline is bound to fail
eventually (unless you have a _lot_ of patience and you are willing to
do a _lot_ of manual and complex merging).


> 2. CVS keywords in the upstream patches. I have to import the previous
>and the current release into a temporary module and produce the diff
>with -kk.

Yeah, so?  This problem exists regardless of how you deal with third
party code that also uses RCS keywords.

Also, you can trivially preprocess the third-party code to remove or
adjust those keyword instances if you want to avoid this hassle all
together.


> That is why I was wondering if the method described in the manual could
> work for me.

You say you want to do something that is not described at all in the
manual, so nothing in the manual can work for your purposes.

(The manual probably should be fixed to be more descriptive of these
issues and to give procedures and processes for dealing with these kinds
of issues, but it hasn't been yet.)

-- 
Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>  Secrets of the Weird <[EMAIL 
PROTECTED]>


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Again: multiple vendors

[Pierre Asselin]

Greg A. Woods <[EMAIL PROTECTED]> wrote:

> Multiple vendor branches CANNOT work for what you want.  Period.

Maybe with the new "import -X" in cvs 1.12.x ?  This was touched
upon briefly in another thread.
https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs_16.html#SEC154

I once did a two-vendor series of imports after gathering historical
tarballs from the net.  The "main" vendor went on 1.1.1 and the
"secondary" went to 1.1.3 .  The purpose was to merge some of
the patches in the secondary line into a late main-vendor release.

The multiple vendor branch was not funny, so I agree with Greg.
I had to manually reset many "admin -b" values, move files in and
out of the Attic (I think), etc.  When I got to the point where
a plain trunk checkout gave me a current main-vendor release,
I could start working.

The net result of all the imports plus surgery is that I had my
tarballs in CVS, each with a unique tag.  I could diff any two of
them, examine the patches, decide what to apply, etc.  That part
went very well !  The fact that the tarballs were on vendor branches
was pretty irrelevant.

The new "-X" import seems to create independent, non-interfering
vendor branches (and an empty trunk!).  The OP could try that,
merge one of them to the trunk and start merging deltas.  It
might work without surgery.  Then again, I havent' actually done it,
this is just an impression from reading the docs.


-- 
pa at panix dot com
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Again: multiple vendors

[Pierre Asselin]

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

RE: Again: multiple vendors

[Andy Cheong Kok Mung]

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


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: Again: multiple vendors

[Fabian Cenedese]

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

List-Id: Announcements and discussions for the CVS version control system

List-Unsubscribe: ,

List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,


bye  Fabi




___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: Again: multiple vendors

[Andy Cheong Kok Mung]

Tnks :)

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Fabian Cenedese
Sent: Friday, March 04, 2005 3:09 PM
To: info-cvs@gnu.org
Subject: RE: Again: multiple vendors



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

List-Id: Announcements and discussions for the CVS version control
system

List-Unsubscribe: <http://lists.gnu.org/mailman/listinfo/info-cvs>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://lists.gnu.org/pipermail/info-cvs>
List-Post: <mailto:info-cvs@gnu.org>
List-Help: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <http://lists.gnu.org/mailman/listinfo/info-cvs>,
<mailto:[EMAIL PROTECTED]>

bye  Fabi




___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Again: multiple vendors

[Larry Jones]

Baurzhan Ismagulov writes:
> 
> 1. Added and deleted files: I have to track them manually when I apply
>the delta for a new upstream release. I have to grep for 1970 and add
>/ remove the files.

That shouldn't be necessary -- a normal merge using two revision tags
should note and process added and deleted files correctly.

-Larry Jones

Mom must've put my cape in the wrong drawer. -- Calvin


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Again: multiple vendors

[Baurzhan Ismagulov]

Thanks to all for comments and suggestions!

On Thu, Mar 03, 2005 at 05:50:02PM -0500, Greg A. Woods wrote:
> > > Do not use "cvs import".  It can not work as any part of what you want
> > > to do.
> > 
> > Hmm, Cederqvist recommends it in
> > https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs_13.html#SEC108
> 
> Read again.
> 
> There's nothing in there about multiple vendors (or if there is and I've
> forgotten about it, it's blatantly wrong and misleading).
> 
> Multiple vendor branches CANNOT work for what you want.  Period.

I'm not challenging your opinion, I'm trying to understand how the thing
works. I would be glad if you could elaborate one level deeper and
answer the question _why_ it isn't going to work with imports (a pointer
to the manual would be also ok).

For concreteness, let's look at the following scenario: assume I create
the branches in the way that Pierre suggested:

LINUS  1.1.3
RMK1.1.5
PXA1.1.7
HWVENDOR   1.1.9

If the last tag in HWVENDOR is called bsp102 and I do "cvs import -b
1.1.9 linux HWVENDOR bsp106", what is going to go wrong? The goal is
to do "cvs update -jbsp102 -jbsp106" in HEAD.


> (indeed vendor branches don't mix well with normal branches either)

What is the difference?


> > 2. CVS keywords in the upstream patches. I have to import the previous
> >and the current release into a temporary module and produce the diff
> >with -kk.
> 
> Yeah, so?  This problem exists regardless of how you deal with third
> party code that also uses RCS keywords.

I didn't notice this when I played with import. I'll recheck.


> Also, you can trivially preprocess the third-party code to remove or
> adjust those keyword instances if you want to avoid this hassle all
> together.

I'm not sure it were that trivial without import and -kk -- keywords
occur not only in comments, some of them occupy more than one line, so
it would require at least half of a day to develop and debug a parser
for that; that is why I asked about that import stuff in the first
place.


> > That is why I was wondering if the method described in the manual could
> > work for me.
> 
> You say you want to do something that is not described at all in the
> manual, so nothing in the manual can work for your purposes.

Well, the section
https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs_13.html#SEC112
is called "multiple vendor branches", and that is what I wanted to have.
Sorry that I didn't know that the manual was wrong :) .


I've started playing with the way you had suggested, but I'd really like
to understand how import works and why it couldn't help me.


With kind regards,
Baurzhan.


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Again: multiple vendors

[Baurzhan Ismagulov]

On Fri, Mar 04, 2005 at 02:42:56AM +, Pierre Asselin wrote:
> Greg A. Woods <[EMAIL PROTECTED]> wrote:
> 
> > Multiple vendor branches CANNOT work for what you want.  Period.
> 
> Maybe with the new "import -X" in cvs 1.12.x ?  This was touched
> upon briefly in another thread.

Thanks for the link, I'll check this. Unfortunately, I can't do this for
the current project since we use 1.11.1 and the server is administered
by other people (I suppose one needs 1.12 both on the client and the
server side; please correct me if this isn't the case).


> The multiple vendor branch was not funny, so I agree with Greg.
> I had to manually reset many "admin -b" values, move files in and
> out of the Attic (I think), etc.  When I got to the point where
> a plain trunk checkout gave me a current main-vendor release,
> I could start working.

Do I understand you correctly: it did work for you with import -b,
right? Do you mean it would be easier to do with normal branches,
applying upstream patches by hand and committing? In particular, I don't
see why you had to reset admin -b values and move files in / out of the
Attic; do you remember concrete scenarios?


With kind regards,
Baurzhan.


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Again: multiple vendors

[Baurzhan Ismagulov]

On Fri, Mar 04, 2005 at 11:38:09AM -0500, Larry Jones wrote:
> Baurzhan Ismagulov writes:
> > 
> > 1. Added and deleted files: I have to track them manually when I apply
> >the delta for a new upstream release. I have to grep for 1970 and add
> >/ remove the files.
> 
> That shouldn't be necessary -- a normal merge using two revision tags
> should note and process added and deleted files correctly.

Yes, if you have the vendor's latest release in CVS already. I've meant
the step of putting that last release into the repository without using
import command, like this:

cvs co -rbsp102 linux
cd linux
patch -p1 <../bsp102-106.diff


Now I have to cvs add and cvs rm those files.

With kind regards,
Baurzhan.


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Again: multiple vendors

[Pierre Asselin]

Baurzhan Ismagulov <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 04, 2005 at 02:42:56AM +, Pierre Asselin wrote:

> > The multiple vendor branch was not funny, so I agree with Greg.
> > I had to manually reset many "admin -b" values, move files in and
> > out of the Attic (I think), etc.  When I got to the point where
> > a plain trunk checkout gave me a current main-vendor release,
> > I could start working.

> Do I understand you correctly: it did work for you with import -b,
> right? Do you mean it would be easier to do with normal branches,
> applying upstream patches by hand and committing?

That's one way, if you are careful about added and deleted files.

> In particular, I don't
> see why you had to reset admin -b values and move files in / out of the
> Attic; do you remember concrete scenarios?

Because you get an inconsistent trunk.  Example with two vendor
branches:

first
bothimported to 1.1.1

both
second  imported to 1.1.3

If you check out a trunk sandbox, you get all three files, which
doesn't correspond to anybody's release.  The "both" that you
get is the 1.1.1.1 revision, not the 1.1.3.1, because its "admin
-b" branch is 1.1.1 from the initial import and was not reset by
the second import.

Hm, maybe it's not as bad as I think.  I just tried this example
and cvs warned me of a conflict.  I don't remember that from before.
Maybe the conflict detectors have improved ? This is cvs 1.11.17 .

First import
--
date > first
date > both
cvs import -m'main vendor' test VENDOR main-1_0
N test/first
N test/both

No conflicts created by this import
--


Second import
--
rm first
date >> both
date > second
cvs import -m'variant' -b 1.1.3 test VARIANT var-1_0
N test/second
C test/both

1 conflicts created by this import.
Use the following command to help the merge:

cvs checkout -j -jvar-1_0 test
--

I guess the broken trunk is just the normal result of an unmerged
import.  To standardize on the main vendor branch,

cvs checkout -d test_main -j var-1_0 -j main-1_0 test

and I get a test_main/ sandbox consistent with the first import.
If I commit that, file "second" gets a dead trunk revision 1.2 and
its "admin -b" branch is reset to empty.  So maybe I could have
saved myself all that surgery by doing proper post-import merges.
Note that I gave my "checkout -j" options in the opposite order
from the cvs suggestion because I want the trunk to look like the
main vendor branch, not the 1.1.3 variant.

Okay, so select a favorite vendor (you can't treat them symmetrically)
and import all his tarballs normally.  Do all your post-import
merges religiously in order to take care of deleted files.

THEN, start importing alternate vendor tarballs to secondary
branches.  Always do the post-import merges to trunk, but
merge from -j to -j.

After that, a trunk checkout should give you the equivalent of a
fresh tarball from your privileged vendor.  All the other tarballs
are in CVS with unique import tags (keep good notes as you import)
so you can start merging tarball deltas.

BTW, you can do this in a private cvs repository on your own
computer, accessed in local mode.  If you stumble, wipe out the
whole thing and start over.  If you succeed, scp your repository
tree to the real cvs server.


-- 
pa at panix dot com
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Again: multiple vendors

[Kaz Kylheku]

On Sun, 6 Mar 2005, Baurzhan Ismagulov wrote:

> Thanks to all for comments and suggestions!

The CVS vendor branch feature has a broken design. At best, it can be
used to track new versions of the original baseline that was used to
create the repository with ``cvs import''. Even for that, it is
troublesome.

The first problem is that ``cvs import'' operates directly on the
repository. It does not create a sandbox which you can inspect for
differences against the repository and possibly throw-away, if
necessary, or commit if you are satisfied. In other words, go through
the regular pre-commit review. Secondly, you can end up with a
half-baked main trunk, in which files that are not locally modified are
replaced by new head revisions from the vendor branch, but files which
are locally modified are not replaced even if new changes exist for
them in the vendor branch. I.e. the most ``obviously safe'' vendor
changes are applied to the main trunk, and the rest you must do by a
manual merge, until which is done, you have inconsistency.

The second problem, the huge one, is that vendor branches all shoot
from revision 1.1 of every file, because they all share the 1.1 digits.
Branch 1.1.1, 1.1.3, 1.1.5, ... all are based on 1.1. This assumption
means that all the teams have exactly the same starting baseline that
they are patching, forever. What's ironic is that vendor branching
plays weird games with the RCS structure, on top of what normal
branches do, in spite of providing fewer features. There is that
question of the strange version 1.1.1.1 that is exactly the same as
version 1.1. You don't see this in a normal branch. If you create a
regular branch off version 1.3, you don't get some 1.3.1.1 version of
the file. You get /no/ new version of the file until you commit
something to the branch, and /then/ you get a version node like
1.3.2.1. (Or 1.3.4.1 if the branch number is 1.3.4, etc).

In the Meta-CVS version control tool, I implemented a tool for
third-party-source tracking that uses regular CVS branches underneath.
(Meta-CVS does not even have an ``import'' command, to avoid confusion.
The underlying ``cvs import'' is only used when one creates a
repository for the first time from some sources, and that command is
``mcvs create'').

In Meta-CVS, to track sources from a third party, first you identify
what baseline they are using. In the ideal case, it corresponds exactly
to some tagged baseline in your repo. So what you do first is create a
branch from that tagged baseline. 

Now that you have a branch from the baseline that the third party
patches are made from, you use ``mcvs grab -r '' to bring
the outside code to the tip of the branch.

What ``mcvs grab'' will do is convert the current directory and its
children into a Meta-CVS sandbox, by adding all the missing pieces that
a sandbox has. Moreover, it will analyze the files, and figure out file
moves and symbolic link reconfigurations.  Thus the sandbox will
basically express a minimized set of edits, including directory
structure edits, which one has to commit to sync the branch
to the new baseline. You can view diffs, make additional touchups, if
needed, and then commit the changes.  If you aren't happy, just delete
the MCVS/ subdirectory and the tree is no longer a sandbox. In fact, it
hasn't been touched at all. Until you commit, nothing happens in the
repository. And after that, nothing happens to your main trunk or any
other branch. Oh, and speaking of the main trunk, you can ``mcvs grab''
onto the trunk too. This takes care of a CVS FAQ: ``help, we branched
wildly, haven't used the main trunk in like a year, and now we just
want to replace the tip of it without merging''. No problem.

To merge the branch, you do it like any other branch. Of course, since
you are using ``managed branches'' in Meta-CVS which track what has
been merged, it's a simple command: ``mcvs merge '',
review everything and commit.  If you screw up the merge, just throw
away the changes, and then ``mcvs remerge '' will re-apply
the last merge.

When you merge from a branch, you can do some useful things, like
manually throw away some renames in order to assert ``we don't want
these directory structure changes being done on this branch, just the
content bugfixes''. The vendor can then continue providing patches
using /their/ modified directory structure, and they get nicely merged
down into /your/ directory structure. 

-- 
Meta-CVS: the working replacement for CVS that has been stable since
2002.  It versions the directory structure, symbolic links and execute
permissions. It figures out renaming on import. Plus it babysits the kids
and does light housekeeping! http://freshmeat.net/projects/mcvs



___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Again: multiple vendors

[Baurzhan Ismagulov]

Hello,

I've tried both and found that normal (as opposed to vendor) branches
were easier to understand and not that difficult to implement ($Log$
turned out to be solvable just like other keywords), so that is what I
did.

Thanks much for all replies!

With kind regards,
Baurzhan.


On Sun, Mar 06, 2005 at 09:54:09PM +, Pierre Asselin wrote:
> Baurzhan Ismagulov <[EMAIL PROTECTED]> wrote:
> > On Fri, Mar 04, 2005 at 02:42:56AM +, Pierre Asselin wrote:
> 
> > > The multiple vendor branch was not funny, so I agree with Greg.
> > > I had to manually reset many "admin -b" values, move files in and
> > > out of the Attic (I think), etc.  When I got to the point where
> > > a plain trunk checkout gave me a current main-vendor release,
> > > I could start working.
> 
> > Do I understand you correctly: it did work for you with import -b,
> > right? Do you mean it would be easier to do with normal branches,
> > applying upstream patches by hand and committing?
> 
> That's one way, if you are careful about added and deleted files.
> 
> > In particular, I don't
> > see why you had to reset admin -b values and move files in / out of the
> > Attic; do you remember concrete scenarios?
> 
> Because you get an inconsistent trunk.  Example with two vendor
> branches:
> 
> first
> both  imported to 1.1.1
> 
> both
> secondimported to 1.1.3
> 
> If you check out a trunk sandbox, you get all three files, which
> doesn't correspond to anybody's release.  The "both" that you
> get is the 1.1.1.1 revision, not the 1.1.3.1, because its "admin
> -b" branch is 1.1.1 from the initial import and was not reset by
> the second import.
> 
> Hm, maybe it's not as bad as I think.  I just tried this example
> and cvs warned me of a conflict.  I don't remember that from before.
> Maybe the conflict detectors have improved ? This is cvs 1.11.17 .
> 
> First import
> --
> date > first
> date > both
> cvs import -m'main vendor' test VENDOR main-1_0
> N test/first
> N test/both
> 
> No conflicts created by this import
> --
> 
> 
> Second import
> --
> rm first
> date >> both
> date > second
> cvs import -m'variant' -b 1.1.3 test VARIANT var-1_0
> N test/second
> C test/both
> 
> 1 conflicts created by this import.
> Use the following command to help the merge:
> 
>   cvs checkout -j -jvar-1_0 test
> --
> 
> I guess the broken trunk is just the normal result of an unmerged
> import.  To standardize on the main vendor branch,
> 
> cvs checkout -d test_main -j var-1_0 -j main-1_0 test
> 
> and I get a test_main/ sandbox consistent with the first import.
> If I commit that, file "second" gets a dead trunk revision 1.2 and
> its "admin -b" branch is reset to empty.  So maybe I could have
> saved myself all that surgery by doing proper post-import merges.
> Note that I gave my "checkout -j" options in the opposite order
> from the cvs suggestion because I want the trunk to look like the
> main vendor branch, not the 1.1.3 variant.
> 
> Okay, so select a favorite vendor (you can't treat them symmetrically)
> and import all his tarballs normally.  Do all your post-import
> merges religiously in order to take care of deleted files.
> 
> THEN, start importing alternate vendor tarballs to secondary
> branches.  Always do the post-import merges to trunk, but
> merge from -j to -j.
> 
> After that, a trunk checkout should give you the equivalent of a
> fresh tarball from your privileged vendor.  All the other tarballs
> are in CVS with unique import tags (keep good notes as you import)
> so you can start merging tarball deltas.
> 
> BTW, you can do this in a private cvs repository on your own
> computer, accessed in local mode.  If you stumble, wipe out the
> whole thing and start over.  If you succeed, scp your repository
> tree to the real cvs server.


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs