[Top][All Lists]

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

Re: importing vendor branches

From: David L. Martin
Subject: Re: importing vendor branches
Date: Fri, 4 May 2001 00:58:52 -0500

> > Fergus Henderson writes:
> > > 
> > > The reason that this broke things is that `cvs checkout'
> > > was checking out inconsistent versions of different files.
> > > After the import, some files -- those which we had not modified -- now
> > > had revision 1.1.2 on the vendor branch, and only 1.1 on the main branch,
> > > and `cvs update -A' retrieved revision 1.1.2, i.e. the vendor branch.
> > > But for other files, their version on the main branch was 1.2, and on
> > > the branch it was 1.1.2', and `cvs update -A' retrieved revision 1.2,
> > > i.e. the main branch.  So `cvs update -A' was checking out some files
> > > from the main branch (based on gc_4_1 with our modifications)
> > > and some from the vendor branch (gc_6_0_alpha6).
> > > Trying to mix incompatible versions naturally broke things.
> > > 

When a new RCS file is created as a result of cvs import, the
RCS archive's default branch is 1.1.1.  When/If the first local modification
is committed, the default branch becomes blank (= the trunk).  See the
output of cvs log in the "Branch:" field.  The tip of the default branch
appears to be what is regarded by CVS as the revision to retrive
in an update -A.

To make update -A retrieve the trunk revision (1.1) for locally
unmodified files which have been imported, you could use cvs admin -b
on all files created by the import to force the default branch to be empty
(i.e. the trunk).

To avoid this mess, you might consider moving your development
from the trunk to a branch.  You'd be guaranteed that a vendor
import would not affect the contents of your development branch,
until you decide to merge the vendor branch deltas yourself using
standard merge procedures.

Hope this helps,
David Martin

reply via email to

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