[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Vendor software update and branches

From: Mark D. Baushke
Subject: Re: Vendor software update and branches
Date: Tue, 17 Jan 2006 00:13:54 -0800

Hash: SHA1

Mark <address@hidden> writes:

> "Mark D. Baushke" said...
> >You may wish to do a forced commit of all the files on your mainline
> >which happen to have 1.x.1.y vendor version numbering so that any import
> >you do to the vendor branch would need to be merged into the mainline
> >and committed separately.
> Ok.  It looks like this may work a little better.  But afterward it
> looks like I will have to merge the vendors changes into my 'vendor
> integration' branch (or vendor_update, as I called it previously).  It
> looks like that branch, which was created before the new import, is
> stuck to   This is still pretty painful.

The vendor branch concept is kind of odd... it defaults to 1.1.1 as a
real RCS branch rather than a magic cvs branch that does not get created
until it is used.

Consider the following kind of situation:

cvs import my-module/some/sub/directory VENDOR VENDOR-1_0
... time passes..
cvs import my-module/some/sub/directory VENDOR VENDOR-1_7
... time passes..
cvs import my-module/some/sub/directory VENDOR VENDOR-1_20

By default VENDOR is assigned the 1.1.1 branch number.
for some files, I would expect my-module/some/sub/directory/README
might have as VENDOR-1_0, as VENDOR-1_7 and as VENDOR-1_20.

So, an import on top of an import will add a new 1.1.1.x revision for
existing files on the branch named VENDOR.

You should be able to merge the changes from VENDOR-1_0 through
VENDOR-1_7 using a command like:

    cvs checkout -jVENDOR-1_0 -jVENDOR-1_7 my-module

which would checkout the main trunk and merge the changes from the
VENDOR-1_0 release through the VENDOR-1_7 release into the newly
created tree.

> It seems the real problem is that import wants to work on the main
> trunk and no where else.

This is a misunderstanding of what is happening. It just happens that
the cvs 1.11.x lets the vendor branch be immediately visible on the main
trunk by default. Any changes to the main trun would cause a 1.2
revision to be generated with the changes and from that point forward,
the VENDOR branch changes are no longer directly visible on the main
trunk unless you explicitly merge them for that particular file.

> "Mark D. Baushke" said...
> >If you are using cvs 1.12.13, then the 'cvs import -X' option will
> >automatically create the versions 1.1 (initial version) and
> >(vendor branch) and 1.2 (main trunk) with the 1.2 version being 'dead'
> >and so not visible on the main trunk.
> Well, if I did have 1.12.13, from the manual it sounds like this would
> only help on new files.  Is that right?

        -- Mark
Version: GnuPG v1.2.3 (FreeBSD)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]