Re: Starting New Repository - Vendor Branch - Bug/Feature? (was: CVS IMPORT Help)

[Eric Siegerman]

On Mon, Oct 30, 2000 at 10:12:31PM +0000, Spencer L. Swift wrote:
> I am a fairly experienced CVS user, but only recently understood the
> basic concept behind the Vendor Tag/Branch and the main trunk when you
> first import an existing set of source files.  In effect, the initial
> Vendor Tag specifies a branch with revision number 1.1.1 containing
> files all of revision 1.1.1.1.  These are IDENTICAL to the initial
> files (all at revision 1.1) on the main trunk.

Correct.  Not just "in effect", but in literal fact.  To see
this, look carefully at the output of "cvs log" for such a
newly-imported file.

> lonestar(11)$ cvs status -v wdrivn.f 
> ===================================================================
> File: wdrivn.f          Status: Up-to-date
> 
>    Working revision:    1.1.1.1
>    Repository revision: 1.1.1.1 
> /Repository/Applications/Gent_Cane/src/wdrivn.f,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)
> 
>    Existing Tags:
>         GentCane_v1                     (revision: 1.1.1.1)
>         code970                         (branch: 1.1.1)
> 
> 
> Why does CVS report that my working revision is 1.1.1.1?  Is that a
> bug or a feature?  Shouldn't it say 1.1?

It's a feature; it should not say "1.1".

Recall that a major use (arguably the main use) of "cvs import"
is not to initially bring your existing project under CVS
control, but to help you track third-party sources (eg. the CVS
distribution itself, if you plan to hack the code) on an ongoing
basis.

You're using CVS 1.10.  Suppose you've just done "cvs import"ed
that; as you've noted, all the files are on the vendor branch, at
rev. 1.1.1.1.  Now you modify configure.in, since you had to do
some work to port CVS to your version of IRIX :-)  You commit the
results.  You write and commit the corresponding ChangeLog entry
:-), so now (as you've noted) ChangeLog is at rev. 1.2, on the
trunk.  But IRIX portability fixes aren't NEWSworthy, so you
leave the NEWS file alone; it's still at rev. 1.1.1.1 on the
vendor branch.  Actually, it took you a couple of tries to get
the configure.in changes right, so now configure.in is at 1.3 on
the trunk (ignore the bootstrapping problem of how you committed
rev 1.2 of configure.in before you'd managed to get CVS to
compile :-)

Now consider what happens when you decide to upgrade to CVS 1.11
(which you should, by the way -- it's lots better!).
You do a "cvs import" of the 1.11 distribution.  Each of the
files mentioned has changed between 1.10 and 1.11; the new
version of each goes onto the vendor branch, as rev. 1.1.1.2.
After you've merged your changes (using "cvs update" with a -j
option or two) and committed the results, configure.in now looks
like:

 Dflt: 1.1---->1.2---->1.3---->1.4
        \      *       *       *
         \    *    *          *
          \  * *             *   
          1.1.1.1------->1.1.1.2
          cvs_1_10       cvs_1_11

where the solid lines show actual predecessor-successor
relationships, and the "*" lines show "influence" that (alas) is
not reflected in the data structures; ie. 1.2 and 1.3 are
"1.1.1.1 plus your changes", and 1.4 is "1.1.1.2 plus your
changes".  The diagram also shows the release tag(s) assigned by
"cvs import" to each revision on the vendor branch.

Because there are local changes, the latest-and-greatest revision
is the latest one on the trunk, ie. 1.4.  CVS keeps track of this
by flagging the trunk as the default branch.  I show this with
"Dflt:" in the diagram.  In practice, you can see it by looking
at the "Branch:" entry in the output of "cvs log":  if a file is
"on the trunk", that entry will be blank.

Since you didn't make any local changes to NEWS, it looks like
this:

       1.1
        \
         \
          \
    Dflt: 1.1.1.1------->1.1.1.2
          cvs_1_10       cvs_1_11

The latest revision on the vendor branch (now 1.1.1.2) is still
the latest-and-greatest; thus the vendor branch, 1.1.1, is
flagged as the default branch.

The GPL hasn't changed in years, so the file COPYING is even
simpler.  It hasn't changed between 1.10 and 1.11, and you didn't
make any local changes(!).  That file looks like:

       1.1
        \
         \
          \
    Dflt: 1.1.1.1
          cvs_1_10
          cvs_1_11

CVS didn't create a new vendor-branch revision, since the file
hasn't changed; it just added a cvs_1_11 release tag to the
existing revision.

This last is your situation (except that you only have one
release tag so far).  It should be clear by now that the
behaviour which puzzles you makes perfect sense in general, and
only looks odd in this degenerate case.

It might be useful to think of the first import as looking like:

    Dflt: 1.1.1.1
          cvs_1_10

Then again, maybe that's more confusing.  Either way, you should
just ignore rev. 1.1 completely, as CVS tries its best to do.
It's only there because the underlying data structure (which,
recall, was borrowed from RCS, not invented for CVS) requires it
-- you can't have a branch that isn't rooted anyplace.

> "Fred W." <address@hidden> writes:
> 
> > Prior to making changes I want to tag the current version as 'REL_1_0 '
> > . Assume I only have one file 'test.txt'. When I look at the log it
> > shows the tag on 1.1.1.1 of the file. How can I tag version 1.1?
> 

You can't, and you don't want to.  I hope I've convinced you that
CVS really is doing the right thing here.

> I believe this suggests the answer to the original post is that if he
> makes a tag on the working version of his files, it will be applied to
> the trunk and not the vendor branch.

Depends what the working version consists of.  In the example cases above,
suppose you type "cvs update -A; cvs tag mytag".  That tag will
be applied as follows:
        configure.in    1.4
        NEWS            1.1.1.2
        COPYING         1.1.1.1

ie. to the latest-and-greatest revision of each file, whether
that's the vanilla one from the distribution, or the one you've
modified locally.  (Strictly speaking, "cvs tag mytag" just tags
whichever revisions are in the sandbox; it was the preceding "cvs
update -A" that ensured that the sandbox contained all the
latest-and-greatest revisions as described above).

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
Nobody ever got fired for buying Microsoft -- but they could get
fired for relying on Microsoft.
        - Chris Garrigues