Re: Sticky tags

[irina sturm]

Thank you very much, Eric, for your answer.
This helps to understand better, and it is
somehow the way I saw the problem myself.

Irina.


address@hidden wrote:
> 
> --- 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)
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs

-- 
===========================================================
Irina STURM
Functional Verification Center of Competence - CMG 
STMicroelectronics, 9 chem de la Dhuy, 38240 MEYLAN, FRANCE
Phone: (+33) (0)4 76 58 68 90, Fax: (+33) (0)4 76 58 40 11
E-MAIL: address@hidden
===========================================================