[Top][All Lists]

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

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

From: Eric Siegerman
Subject: Re: sticky non-branch tags are sometines treated as branches in empty
Date: Tue, 9 Dec 2003 21:13:30 -0500
User-agent: Mutt/1.2.5i

On Tue, Dec 09, 2003 at 04:06:49PM -0800, Alvaro Martinez Echevarria wrote:
> cvs -d <WHATEVER> 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<branch>" 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.        address@hidden
|  |  /
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

reply via email to

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