Re: sticky non-branch tags are sometines treated as branches in empty

[Larry Jones]

"Paul Gelderblom \(ptok\)" writes:
> 
> This is a multi-part message in MIME format.

Please do not send MIME and/or HTML encrypted messages to the list.
Plain text only, PLEASE!

> However, we have found out that sometimes commit on these sticky tags
> succeed, because CVS somewhere in the process _converts_ the sticky
> normal tag into
> a branch! This happens when there are empty directories in the
> tree on which cvs update -r TAG has been done.

The problem is that tags do not have an independent existance -- they
only exist inside RCS files.  Thus, a tag can be a branch tag in one
file and a non-branch tag in another.  The rule CVS uses is that if the
tag is a non-branch tag in any file in the directory, then the tag is
marked as a non-branch tag in the CVS/Tag file; otherwise, it is marked
as a branch tag, which naturally results in a branch tag in an empty
directory.  Just one more reason why you should always use -P on
checkout and update and not try to store empty directories in CVS.

> I guess that N means Tag and T means Branch(!), but could not
> find documentation on the Tag file format in the CVS dox.

Did you try looking in the index?



-Larry Jones

I've never seen a sled catch fire before. -- Hobbes


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: sticky non-branch tags are sometines treated as branches in empty

[Alvaro Martinez Echevarria]

On Wed, 3 Dec 2003, Larry Jones wrote:

> > However, we have found out that sometimes commit on these sticky tags
> > succeed, because CVS somewhere in the process _converts_ the sticky
> > normal tag into
> > a branch! This happens when there are empty directories in the
> > tree on which cvs update -r TAG has been done.
>
> The problem is that tags do not have an independent existance -- they
> only exist inside RCS files.  Thus, a tag can be a branch tag in one
> file and a non-branch tag in another.  The rule CVS uses is that if the
> tag is a non-branch tag in any file in the directory, then the tag is
> marked as a non-branch tag in the CVS/Tag file; otherwise, it is marked
> as a branch tag, which naturally results in a branch tag in an empty
> directory.  Just one more reason why you should always use -P on
> checkout and update and not try to store empty directories in CVS.

Unfortunately the problem seems a bit deeper than that: the above
rule doesn't seem to make any sense for parent directories (which
by nature aren't empty), even if there are files there that
contain the non-branch tag, as long as nothing is checked out on
them. For example, starting on an empty directory:

   mkdir repo
   cd repo
   cvs -d  co -r MYTAG parent/anotherparent/subdir

In this case cvs has to create parent and then
parent/anotherparent before checking out the subdirectory we are
really interested in. Not only parent and parent/anotherparent
have a CVS/Tag file (IMO they shouldn't at all), but their tag is
marked as branch (which, again, is wrong).

The problem keeps happening every time you check out a tagged
subdirectory, i.e.:

   cvs -d  co -r SOMEOTHERTAG parent/subdir2

will put a "fake branch" SOMEOTHERTAG on parent/CVS/Tag. So if
you are not careful you end up generating random branches all
over the place every time you try to add new files or directories.

My question is, because I invoke the above commands from a
wrapper, is it a valid and safe workaround to manually remove
CVS/Tag files from the parent directories after running the
checkouts?
Regards,

--
Álvaro Martínez Echevarríaalvarom NO_SPAM_NONONO cisco.com
Cisco Systems
SJC24/3/A5-3
510 McCarthy Blvd.
Milpitas, CA 95035
Phone: +1-408-526-7179




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: sticky non-branch tags are sometines treated as branches in empty

[Eric Siegerman]

On Tue, Dec 09, 2003 at 04:06:49PM -0800, Alvaro Martinez Echevarria wrote:
> cvs -d  co -r MYTAG parent/anotherparent/subdir
> [...]
> My question is, because I invoke the above commands from a
> wrapper, is it a valid and safe workaround to manually remove
> CVS/Tag files from [parent and parent/anotherparent] after running the
> checkouts?

If you do that, then instead of "generating random branches all
over the place every time you try to add new files or
directories", you'll simply generate random trunk revisions.
Probably not what you want.

Instead, rewrite those directories' CVS/Tag files to contain
revision tags.  That way, if a user tries to commit something in
parent/anotherparent, they'll get a nasty error message.  It's
ugly, but at least it fails safe.  The user can "cvs update -l
-r" to put the directory on the branch they really want
it on, and try again.

I'd be tempted to rewrite the revision tag itself, not just the
what-kind-of-tag-am-i flag, to something obviously bogus like
"this_is_a_phony_tag-ask_a_guru_for_help".  That way, a user
who's seen this before will recognize the bogus tag name and know
what the situation is.

For users who are new to it, they won't know what's going on, but
again it'll fail safe, this time on the human scale:  the user
will *know* he doesn't know what's going on, whereas a legitimate
tag name in the error message might have fooled him into thinking
he did know :-)

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
It must be said that they would have sounded better if the singer
wouldn't throw his fellow band members to the ground and toss the
drum kit around during songs.
- Patrick Lenneau


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs