Re: sticky non-branch tags are sometines treated as branches in empty
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 WHATEVER 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 WHATEVER 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
On Tue, 9 Dec 2003, Larry Jones wrote: Alvaro Martinez Echevarria writes: 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). There is no right answer in this case. CVS simply does not have sufficient information to tag parent directories correctly, whatever that means. (Note that CVS works on a directory at a time; there is no mechanism for files contained in a subdirectory to affect the processing of the parent directory.) If parent directories weren't tagged at all, then new files would be added to the tip of the trunk, which might be better in your situation, but would undoubtedly be much worse in other, equally common situations. Hmmm, I see. It all depends on how you use you repository, I guess. If you're doing something like: CVSROOT/gnu/bash CVSROOT/gnu/libc CVSROOT/linux/kernel CVSROOT/linux/modules where each of those second level subdirectories are (non-branching-)tagged independently from the others, you're in trouble. When you create a new directory CVSROOT/gnu/grep, the last thing you want is that to go under branch 2-05a because such happened to be the last version of bash you checked out. Because this behaviour is clearly wrong in this situation, but the alternative (do not create Tag files in parent directories) would also be clearly wrong in other circumstances, would it be crazy to add a command line option to checkout/update to control which way it goes? Just checking, it doesn't hurt to ask... :) 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: Using rdiff to check if tag exists
On Thu, 13 Nov 2003, Aldo TENDRON wrote: Hello, I have a problem using rdiff to check it a tag exists for a given module. [...] Hehe, I've tried that before, and stumbled with the same problem. The reason is, I think, when a tag has been successfully used it ends up in the cache file CVSROOT/val-tags; that will be the first thing looked at by the subsequent rdiff commands you are issuing. As long as the tag is there, no error is shown. So the first time you rdiffed on d, the actual files in the module had to be looked at, and the tag wasn't there, so an error happened. Then you rdiffed on c, which contains the tag, so the tag is added to val-tags. The second time you check on d, the tag exists, even though the diff will be obviously empty. The only reliable way I've found to check for the existence of tags is 'cvs stat -v' (but that's a pain for directories). Regards, -- Álvaro Martínez Echevarría[EMAIL PROTECTED] 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
bug in diff/rdiff with HEAD?
I guess it wasn't a good idea to send my first post on a Friday night :)... Sorry, but I have to try again, in case anyone knows what's going on here... Is there any other list with cvs gurus that might have a clue about this? There's a bug in diff/rdiff with HEAD, or maybe I'm just going crazy. The problem has to do with diffing between a given tag (say FOO) and HEAD, when there are files (say blah/blah.c) that appeared after FOO but were deleted before now (i.e., HEAD). I'm not worried about branches at this point, so we can assume a single linear trunk. On one of the pservers I am using (cvs-1.11.1p1-8.7 on RH7.1), both: cd blah; cvs diff -r FOO -r HEAD and cvs -d :pserver:... rdiff -r FOO -r HEAD blah result in a diff where blah/blah.c is created: Index: blah/blah.c === RCS file: blah/blah.c diff -N blah/blah.c --- /dev/null 1 Jan 1970 00:00:00 - +++ blah/blah.c20 Mar 2002 04:22:22 - 1.9 @@ -0,0 +1,1034 @@ + + The whole file that shouldn't be here anyway + [...] When I run into the same situation on both cvs versions 1.11.1p1debian-8.1 and 1.12.1-7 on Debian unstable, the result is different. Now rdiff behaves correctly (i.e., no difference is shown for that file), but diff still shows blah/blah.c as a created file. Setting aside the incongruent results above, and in my mind at least, the correct behaviour would be for both diff and rdiff to not show anything: since that file didn't exist in FOO, and it's been deleted in HEAD, that's no difference. Otherwise, it's impossible to get accurate diffs that show what has changed in a repository from a tag to the present. By accurate I mean diffs that can be applied with patch to a non-cvs file hierarchy to get an exact copy of the HEAD of the trunk. Am I doing anything wrong? Is this a known bug? Any advice? Thanks, -- Álvaro Martínez Echevarríaalvarom AT_BUT_NO_SPAM cisco.com Cisco Systems SJC24/3/A5-3 510 McCarthy Blvd. Milpitas, CA 95035 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
bug in diff/rdiff with HEAD?
Hi, Theres' a bug in diff/rdiff with HEAD, or maybe I'm just going crazy. The problem has to do with diffing between a given tag (say FOO) and HEAD, when there are files (say blah/blah.c) that appeared after FOO but were deleted before now (i.e., HEAD). I'm not worried about branches at this point, so we can assume a single linear trunk. On one of the pservers I am using (cvs-1.11.1p1-8.7 on RH7.1), both: cd blah; cvs diff -r FOO -r HEAD and cvs -d :pserver:... rdiff -r FOO -r HEAD blah result in a diff where blah/blah.c is created: Index: blah/blah.c === RCS file: blah/blah.c diff -N blah/blah.c --- /dev/null 1 Jan 1970 00:00:00 - +++ blah/blah.c20 Mar 2002 04:22:22 - 1.9 @@ -0,0 +1,1034 @@ + + The whole file that shouldn't be here anyway + [...] When I run into the same situation on both cvs versions 1.11.1p1debian-8.1 and 1.12.1-7 on Debian unstable, the result is different. Now rdiff behaves correctly (i.e., no difference is shown for that file), but diff still shows blah/blah.c as a created file. Setting aside the incongruent results above, and in my mind at least, the correct behaviour would be for both diff and rdiff to not show anything: since that file didn't exist in FOO, and it's been deleted in HEAD, that's no difference. Otherwise, it's impossible to get accurate diffs that show what has changed in a repository from a tag to the present. By accurate I mean tags that can be applied with patch to a non-cvs file hierarchy to get an exact copy of the HEAD of the trunk. Am I doing anything wrong? Is this a known bug? Any advice? Thanks, -- Álvaro Martínez Echevarríaalvarom AT_BUT_NO_SPAM cisco.com Cisco Systems SJC24/3/A5-3 510 McCarthy Blvd. Milpitas, CA 95035 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
