Re: cvs checkout

[Alexander Kamilewicz]

irina sturm wrote:
> 
> I've noticed the following behaviour
> on the "cvs co" command and I would
> like to know if this is normal, and why.
> 
> I have the following situation in the
> repository:
> 
>         -----
>        | 1.1 | Tagged with Head_vers_1_1
>         -----
>           |
>            ----> Branch br_1
> 
> There is, an initial version of all the
> files which have been tagged with
> Head_vers_1_1, and a branch on which some
> developments have been made (and some
> successive versions 1.1.2.1, 1.1.2.2, ...
> are already available).
> 
> When I execute "cvs co" on all the repository,
> I get the version on the main trunk, but
> the tag Head_vers_1_1 is not available
> (accessible to further cvs commands); moreover,
> when I then have a look with "cvs status"
> the tag appears in the list of existing
> tags and not as a sticky tag.

In my experience, this is because you didn't specify a "sticky" tag when
using checkout (co), so the tag's there (i.e. in the status & log of the
file), but it's not sticky.  Stickiness only comes about when you
specify, explicitly, to get or update the sandbox based on a certain tag
(i.e. cvs get -r Build7-1 module).

> If I then do "cvs co -r Head_vers_1_1",
> everything works fine: the tag Head_vers_1_1
> is recognized, and "cvs status" prints
> it as a sticky tag.

Yep, because you specified that the workspace should be based around
that tag, so it's sticky.

> My questions then are the following:
> - is that normal that tag Head_vers_1_1
> is sticky?
> - is that normal that "cvs co" is equivalent
> with "cvs co -A"? (I would have expected
> that "cvs co" gets the final version on
> the trunk, with all the associated tags).

cvs co does not equal cvs co -A, per se.

Plain cvs co just means "get me the head", while cvs co -r rtag module
-A means "get me the module based on this tag, but don't make that tag
sticky in the workplace".

It's a very subtle distinction.

I hope that helps!

Alex