Re: Sticky tags

[Eric Siegerman]

--- irina sturm <address@hidden> wrote:
> I don't understand: if I am doing what you say,
> I am not preserving myself of integrating the
> other users' modifications before finishing
> with my own, but just doing the same as for file_1.

To do this (i.e. make and commit changes without (yet)
integrating other peoples' changes), you'd need to create a
branch.

> In which case also I can't understand what the
> sticky [non-branch] tag is useful for.

Not that much, really, IMO.  I suspect that they weren't really
designed into CVS, but came about as a side-effect of
sticky-branch-tag support -- the code just lets you make *any*
tag sticky.

Here's one use for sticky non-branch tags.  Suppose someone
commits a buggy version of a file, and it's not appropriate for
me to just go fix the bug.  Besides complaining to the person who
did that, I do this in my own sandbox:
        cvs update -r<previous version> file

I can't always get away with this (it'll fail if the buggy
revision also contains an API change that some other committed
file depends on), but when it works, it lets me keep testing
while I wait for the person to fix the bug.

Of course, I then have to remember to clear the sticky tag once
they've checked in a fix.

The alternative would be something like:
        cvs update -p -r<previous version> file >file
to get the previous version without making it sticky.  But then
CVS would think the file was simply locally modified, and would
be willing to commit my "changes" if I told it to.  So I'd have
to be careful not to do any whole-directory commits until the
problem had been resolved.

So both the sticky and non-sticky ways of dealing with this
problem make it easy for me to make a mistake -- but in the
non-sticky case, my mistake will pollute the repo; in the sticky
case, I'm the only one who'll suffer.

--

|  | /\
|-_|/  >   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)