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

sticky non-branch tags are sometines treated as branches in empty directories - Bug?

[Paul Gelderblom \(ptok\)]

Hi all,
 
We often checkout using a sticky tag, so that 
developers can work with
baselines of code.
Normally, checkins on files or directories with a 
sticky non-branch tag
are disabled, which is correct.
 
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.
 
I isolated the problem in the following set of 
commands and output.
(see below)
Bear with me, although it is a bit 
long...
 
If you look at the contents of the CVS/Tag files, 
it indeed looks as if
the empty directories have a different kind of 
meaning for the tag. See the 'find' 
output below: some directories have an N and some a 
T as first character in the
CVS/Tag file. I guess that N means Tag and T means 
Branch(!), but could not
find documentation on the Tag file format in the 
CVS dox.
 

This does look like a bug to me, unless 
someone can explain this 'feature' ?
 
Paul Gelderblom.

 
 
#    create an empty project in 
repository /home/cvs+ mkdir /home/cvs/project
 
#    check it out+ cvs co 
projectcvs checkout: Updating project+ cd project
 
#    add a directory+ mkdir 
dir1+ cvs add dir1Directory /home/cvs/project/dir1 added to the 
repository+ cd dir1
 
#    create a file in the 
directory+ touch file1+ cvs add file1cvs add: scheduling file 
`file1' for additioncvs add: use 'cvs commit' to add this file 
permanently+ cvs ci -m  file1RCS file: 
/home/cvs/project/dir1/file1,vdoneChecking in 
file1;/home/cvs/project/dir1/file1,v  <--  file1initial 
revision: 1.1done+ cd ..
 
#    tag the entire project with 
nnonbranch tag TAG+ cvs tag TAGcvs tag: Tagging .cvs tag: Tagging 
dir1T dir1/file1
 
#    and checkout with a sticky 
tag+ cvs update -r TAGcvs update: Updating .cvs update: Updating 
dir1
 
#    create a new 
directory
+ mkdir dir2+ cvs add dir2Directory 
/home/cvs/project/dir2 added to the repository--> Using per-directory 
sticky tag `TAG'
 
#    look at all the per directory 
sticky tag files...
#    ... they are different for the 
empty dirs.+ find . -name Tag -print -exec cat {} 
;./CVS/TagTTAG./dir1/CVS/TagNTAG./dir2/CVS/TagTTAG
 
#    add a file in dir1 and check it 
in - not allowed, as it should be+ cd dir1+ touch file3+ cvs add 
file3cvs add: cannot add file on non-branch tag TAG
 
#    add a file in the root and 
check it in - allowed!, and a branch is created+ cd ..+ touch file2+ 
cvs add file2cvs add: scheduling file `file2' for addition on branch 
`TAG'cvs add: use 'cvs commit' to add this file permanently+ cvs ci 
-m  file2RCS file: /home/cvs/project/Attic/file2,vdoneChecking 
in file2;/home/cvs/project/Attic/file2,v  <--  file2new 
revision: 1.1.2.1; previous revision: 1.1done
 
#    add a file in dir2 and check it 
in - allowed!, and a branch is created+ cd dir2+ touch file4+ cvs 
add file4cvs add: scheduling file `file4' for addition on branch 
`TAG'cvs add: use 'cvs commit' to add this file permanently+ cvs ci 
-m  file4RCS file: 
/home/cvs/project/dir2/Attic/file4,vdoneChecking in 
file4;/home/cvs/project/dir2/Attic/file4,v  <--  file4new 
revision: 1.1.2.1; previous revision: 1.1done

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