[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Sticky tags
From: |
irina sturm |
Subject: |
Re: Sticky tags |
Date: |
Thu, 12 Jul 2001 15:59:57 +0200 |
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
===========================================================
- Sticky tags, irina sturm, 2001/07/11
- Re: Sticky tags, Mark, 2001/07/11
- Re: Sticky tags, irina sturm, 2001/07/11
- Re: Sticky tags, Mark, 2001/07/11
- Re: Sticky tags, irina sturm, 2001/07/11
- Re: Sticky tags, Eric Siegerman, 2001/07/11
- RE: Sticky tags, Chris Cameron, 2001/07/11
- Re: Sticky tags, Eric Siegerman, 2001/07/12
- Re: Sticky tags,
irina sturm <=