Re: Undesired Sticky Tags With cvs update

[Eric Siegerman]

On Tue, Feb 26, 2002 at 01:27:41PM +0000, Chuck Taylor wrote:
> On Mon, 25 Feb 2002 14:49:38 -0500, Eric Siegerman
> <address@hidden> wrote:
> 
> >...why are you only tagging some of the files?  Just tag
> >everything; then it won't be a problem.
> 
> 
> We have preferred so far to create branches only on files that were
> being modified in conjunction with a task because doing so for the
> entire directory tree introduces another set of "problems," at least
> from our perspective (okay, MY perspective, since I'm the one
> responsible for the scheme we're using).  Such as:
> 
>   -- Creating branches in hundreds of source files, then committing
>      changes to only a few, seems wasteful

Not very.  It takes a couple of minutes, but uses only a few
bytes per file.  And it saves the effort of keeping manual track
of which files you've tagged and which you haven't -- and the
much more than a couple of minutes it takes to recover when
someone inevitably changes a file and forgets to tag it.  Been
there, done that.  That's why I tag everything.

If you're wondering how to tell which files were modified for a
given task, when the whole project has been tagged:  use "cvs -nq
update" or "cvs diff" for that.

If your project grows an order or two of magnitude, the time it
takes to apply a tag will start to make a frequent-tagging
paradigm like this unworkable -- projects like FreeBSD (and
presumably NetBSD) only apply tags at major milestones, not for
every little task.  At that scale, you'll have to either change
your paradigm or abandon CVS.

> 
>   -- The recursive action of cvs tag puts a sticky tag on
>      directories themselves, which interferes with cvs add
>      ("-->Using per-directory sticky tag ..." followed by errors
>      like "cannot add a file on a branch...").

Upgrade!  The current CVS is quite happy to add files on a
branch.  And indeed, it seems to me that that's what you want.
If a file is added in conjunction with a given task, then it
shouldn't appear on the trunk until the task's branch is merged.

> >This was discussed in another thread only a week or two ago, but
> >what it comes down to is: in CVS, a tag marks the state of the
> >*entire project* at a given point in time.
> 
> 
> Do you recall the title of the thread?  I'll read it if I can find it.

"Should I Branch Modules / Files or the Main Line?"  My comments
are largely a paraphrase from memory, and an amplification, of this
post from that thread:
        http://mail.gnu.org/pipermail/info-cvs/2002-February/024968.html

> My group is familiar with using non-branch tags to mark the state of
> the entire project.  We (I) hadn't considered branches and their
> associated tags to do the same.

Please do consider it :-)  You'll save yourselves a lot of grief.

> Thanks.  But that leads me to the same mystery as Mr. Bowen: the -f
> option tends to put CVS into an invalid state, and at least two of us
> think that's a bug, but it's apparently not a high-profile one, so no
> one's been motivated to fix it.

My guess is that few people use -f with any regularity...

> Yet someone took the time to implement the -f option in the cvs tag
> command, and presumably it works as it was meant to work.  What was
> its intended purpose?

No clue.  Sorry.

It occurs to me that this option might be more useful if it
worked properly, but I don't really know what "properly" is.  I
guess your proposal's as good as any...

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
One ring to rule the mall.
        - Movie review headline, eye Magazine