[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Undesired Sticky Tags With cvs update

From: Chuck Taylor
Subject: Re: Undesired Sticky Tags With cvs update
Date: Tue, 26 Feb 2002 13:27:41 GMT

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

  -- 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...").

>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.

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.

>By tagging only some
>files (I presume, those you either have changed or intend to
>change), you're explicitly telling CVS, "at this moment, the
>project consists of only these few files" -- which is very wrong,
>of course.  When you update to your tag, CVS gives you only the
>tagged files -- which isn't what you want, but is just what you
>told it to do.  And using -f to override that, though of course
>it shouldn't put CVS's data structures into an invalid state,
>also shouldn't be expected to make up for the initial "garbage

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.

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?

Chuck Taylor

reply via email to

[Prev in Thread] Current Thread [Next in Thread]