info-cvs
[Top][All Lists]
Advanced

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

Re: vendor tag


From: Eric Siegerman
Subject: Re: vendor tag
Date: Thu, 8 Aug 2002 16:26:41 -0400
User-agent: Mutt/1.2.5i

On Thu, Aug 08, 2002 at 12:31:17PM -0700, Schwenk, Jeanie wrote:
> How can a vendor tag and vendor branch be verified as being present?

This:
> branch: 1.1.1
is a red herring.  It names the "default branch"; it's *not* used
to determine whether a given tag names a branch or a release.

That's done by looking at the form of the "revision" number in
the tag's "symbolic names" entry.  In terms of how they're
represented in the ,v file, there are three kinds of tags:

  - Normal-branch tags, which look like:
      i_made_this_one_up: 1.1.0.2

      - Even number of components
      - Second-last component == 0
      - Last component is even
      - The rest (in this case, "1.1") gives the branch point
      - Take out the "0." and you'll get the branch number as
        reported by "cvs status", in this case "1.1.2".

  - Release tags, which look like:
      V2_1: 1.1.1.1

      - Even number of components
      - Second-last component is non-zero
      - The whole thing gives the revision number that the tag
        refers to; this is reported verbatim by "cvs status"

  - Vendor-branch tags, which look like:
      SomeText: 1.1.1
      FunnyOne: 1.1.3

      - Odd number of components
      - Strip off the last component; the rest indicates the
        branch point ("1.1" in both of the above cases; I don't
        know whether, in practice, any other revision ever serves
        as the branch point for a vendor branch)
      - The whole thing gives the branch number, which is
        reported verbatim by "cvs status"


The default branch (the red herring I mentioned) determines
whether a checkout or update gives you the latest version from
the trunk (i.e. when there are local modifications) or the latest
from the vendor branch (i.e. when there aren't).

Here's your first example:
> head: 1.1
> branch: 1.1.1
> locks: strict
> access list:
> symbolic names:
>         V2_1: 1.1.1.1
>         SomeText: 1.1.1
> keyword substitution: kv
> total revisions: 2;     selected revisions: 2

There are no local modifications (2 revs total, presumably 1.1
and 1.1.1.1), so a fresh checkout gives the latest rev on the
vendor branch, as specified by:
> branch: 1.1.1

Here's the second one:
> head: 1.2
> branch:
> locks: strict
> access list:
> symbolic names:
>         V2_1: 1.1.1.1
>         SomeText: 1.1.1
> keyword substitution: kv
> total revisions: 3;     selected revisions: 3

This time, there is a local modification (rev. 1.2), which is
what you'll get on a fresh checkout because this:
> branch:
*doesn't* instruct CVS to the contrary.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
Anyone who swims with the current will reach the big music steamship;
whoever swims against the current will perhaps reach the source.
        - Paul Schneider-Esleben



reply via email to

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