Re: branch tags

[Eric Siegerman]

On Fri, Aug 10, 2001 at 10:38:44AM -0400, Greg A. Woods wrote:
> [ On Thursday, August 9, 2001 at 13:55:32 (-0400), Eric Siegerman wrote: ]
> > Subject: Re: branch tags
> >
> > There's no distinction between sticky and non-sticky tags.
> > Stickiness isn't an attribute of the tag itself, but of the
> > sandbox when you use
> >     cvs {update|checkout} -r<tag-name>
> > 
> > That people (and the program itself) often refer to "sticky tags"
> > is admittedly misleading; the phrase is shorthand for something
> > like "a sticky revision in a sandbox, when what it's stuck to is
> > a tag name" (i.e. as opposed to a date).
> 
> Just to clarify a wee bit:  there is a slight difference in the way CVS
> treats different types of "sticky tags"

read "sandbox files that have been stuck to tags"

> depending on whether they're

i.e. the tags in the previous phrase

> ~branch tags" or not....  IIRC the main command affected is "cvs commit"

Sorry for being pedantic here; I just want to avoid letting an
explanation of this confusing usage lapse back into the same
confusion.  I promise not to do it when the distinction isn't the
precise topic at hand :-)


> (I suppose if the sticky thing is a revision number and not a tag then
> CVS would treat it as a "sticky branch", but I've not tested that.

Depends on the number, specifically on whether it looks like an
RCS revision or branch number (even or odd, resp., number of
components).

If you say "cvs update -r 1.3 foo", it'll act like a revision tag,
holding the sandbox file at exactly that revision, and forbidding
commits.

If you say "cvs update -r 1.3.2 foo", it'll act kind of like a
branch tag, but without the CVS magic:
  - If something has already been committed to the branch (i.e.
    there's already a rev. 1.3.2.1), it'll act like the
    corresponding "1.3.0.2" branch tag.

  - If not, it'll act like the corresponding branch tag -- on a ,v
    file that doesn't have that tag:
      - the above update will delete the file from the sandbox,
        saying:
            foo is no longer in the repository
      - if you recreate the file and try to update, it'll fail
        with:
            move away foo; it is in the way
            C foo

"-r revision-number" is occasionally useful (but should be warned
about, as is under discussion in another current thread).  I have
yet to find a use for "-r branch-number".


> You'd probably create quite a mess though if you try to use explicit
> branch numbers unless you were very careful because, as seems necessary
> to remind people quite often, revision numbers are potentially different
> for each file, and that goes for branch numbers too -- only tags are
> common across all files in a module.)

Emphatically agreed.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)