Re: Diff bug when using the HEAD tag?
Martin Roehrig wrote: Pardon me if I ask a silly question, but how could a single revision be present on multiple branches? As far as I understood the revision number exactly defines where the revision belongs to, doesn't it? When you apply a branch tag to a file, my interpretation is that the revision that was tagged (the origin of the branch) is on the branch. If you make that revision the origin of many branches, it is on each of those branches. Shane
RE: Diff bug when using the HEAD tag?
Martin Roehrig writes: [smc] my words: HEAD as described here definitely has some impossible or at least meaningless cases: for instance, a sticky, non-branch tag (or date or revision) on a file could match a revision that is present on multiple branches, so which is the "correct" current branch for which the tip revision should be found? There's no sensible answer. Pardon me if I ask a silly question, but how could a single revision be present on multiple branches? As far as I understood the revision number exactly defines where the revision belongs to, doesn't it? [smc] When you first create a branch, no new revision is created, so if you create mulitple branches, it's possible (very likely actually) that at least some of the files won't have changed on either branch and thus the same revision is used on both the branches. It works because a branch tag records a "magic" revision number with an extra zero inserted. So if you create a branch off the trunk with foo at revision 1.7, say, then the branch tag will point to revision 1.7.0.2 of foo (which is non-existent, BTW), and the next branch tag would point to 1.7.0.4. (the ending numbers go up 2 at a time for some reason.) Until a revision was actually committed to those branches, any refrence to the branches would "magically" fetch foo 1.7. If a revision was committed to branch 1.7.0.2, the revision number would be 1.7.2.1 (The zero is removed, and ".1" is added at the end.) At that point there would be a unique revision associated with that branch. (I hope I haven't botched this explanation. The essence is correct, the details (revision numbers) may not be _exactly_ right...) (Hmm, lately I'm not getting any mail from info-cvs...I wonder if that's a mailing list problems, or if somebody here, in their infinite wisdom, has decided to block mail from info-cvs.
Re: Diff bug when using the HEAD tag?
Cameron, Steve writes: [smc] "TRUNK" sounds useful, "HEAD" as described here, less so, since the branch tag may currently be used for that purpose, My thoughts exactly. But, does anyone here know how to implement either HEAD or TRUNK as described here? ,, I don't know how. Nor do I, and I seem to recall some previous discussions that concluded it was very difficult if not impossible to get right in all cases. That's what prompted by alternative suggestion. -Larry Jones Wow, how existential can you get? -- Hobbes
RE: Diff bug when using the HEAD tag?
Just a preference: MAIN is much easier to type than TRUNK. Noel [EMAIL PROTECTED] on 06/08/2000 09:22:33 AM To: [EMAIL PROTECTED] cc: (bcc: Noel L Yap) Subject: RE: Diff bug when using the HEAD tag? Martin Roehrig writes: [...] HEAD should then always refer to the latest revision in the branch resp main trunk the current working copy is based on and therefore it should not be allowed in cvs commands that directly work on the repository (like rdiff - don't know if it is already forbidden there). Thus you have TRUNK as an analogue to the branch tags (i.e. it always refers to the main trunk) and you have HEAD which refers to the latest revision of the current "development line" (be it a real branch or be it the main trunk) as denominated by the working directory where the cvs command using the HEAD tag is called. [smc] "TRUNK" sounds useful, "HEAD" as described here, less so, since the branch tag may currently be used for that purpose, (though it might be useful for scripts or something that don't want to have to know what the branch tag is, or in the case of some kind of hybrid sandbox with modules from multiple branches (or even multiple repositorires?)) But, does anyone here know how to implement either HEAD or TRUNK as described here? ,, I don't know how. Well, perhaps someone does... But, if not, the other option, making HEAD at least be consistently interpreted by "cvs diff" seems better than the status quo, and that we do know how to do. -- steve This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates.
Re: Diff bug when using the HEAD tag?
"Cameron, Steve" wrote: [ DELETED STUFF ] HEAD as described here definitely has some impossible or at least meaningless cases: for instance, a sticky, non-branch tag (or date or revision) on a file could match a revision that is present on multiple branches, so which is the "correct" current branch for which the tip revision should be found? There's no sensible answer. I suppose that could be treated as an error and CVS could say, in essence, "you've asked me a nonsense question." for such files. Seems more trouble than it's worth to me though. I think my approach would be that non-branch tags would be treated as the top of a branch with no revisions commited to it. Therefore, for a file that is checked out on the non-branch tag, the difference between it and HEAD would be empty. Now for a file that has not been checked out with a tag, I think the difference would have to be against the top of the trunk.
Re: Diff bug when using the HEAD tag?
Larry Jones schrieb: Peter Wolfe writes [about HEAD meaning the head of the current branch rather than the HEAD of the trunk for diff]: Hmm ... while that might be the design intent my observations are that even this is broken: I think you're right. It looks to me like what's happening is that diff only interprets HEAD as the head of the current branch if the file has actually been checked in on the branch; if the file has been branched but hasn't actually been checked in on the branch, HEAD is interpreted as the head of the trunk instead of the branch point. To solve the problems and misunderstandings around this subject, what do you think about introducing a new built-in tag (say TRUNK) that does the same for the main trunk as a branch tag does for the branch (or should do...), namely always refer to the latest revision on the main trunk (TRUNK) resp. branch (branch tag), consistently in all suitable cvs commands? (I hope my understanding of branch tags is correct so far.) HEAD should then always refer to the latest revision in the branch resp main trunk the current working copy is based on and therefore it should not be allowed in cvs commands that directly work on the repository (like rdiff - don't know if it is already forbidden there). I think this would be clear and easy to understand (and to remember), consistent with the branch tags and it would be more flexible than the current solution as it offers an access to the latest revision on the main trunk from where you want.. Best regards Martin
RE: Diff bug when using the HEAD tag?
Martin Roehrig wrote: Larry Jones schrieb: Peter Wolfe writes [about HEAD meaning the head of the current branch rather than the HEAD of the trunk for diff]: Hmm ... while that might be the design intent my observations are that even this is broken: I think you're right. It looks to me like what's happening is that diff only interprets HEAD as the head of the current branch if the file has actually been checked in on the branch; if the file has been branched but hasn't actually been checked in on the branch, HEAD is interpreted as the head of the trunk instead of the branch point. To solve the problems and misunderstandings around this subject, what do you think about introducing a new built-in tag (say TRUNK) that does the same for the main trunk as a branch tag does for the branch (or should do...), namely always refer to the latest revision on the main trunk (TRUNK) resp. branch (branch tag), consistently in all suitable cvs commands? (I hope my understanding of branch tags is correct so far.) [smc] I like this idea, and have suggested this in the past. I have a patch which I believe makes HEAD work right for "cvs diff" and I have also made a patch at one time that introduced TRUNK that worked just like I wanted HEAD to work but didnt disturb the current behavior of HEAD. If anyone is interested in these patches, I can send them.(I'd post them again, but nobody was ever interested before, so I dont' want to waste the time to try to find them unless someone is actually interested.) -- steve
Re: Diff bug when using the HEAD tag?
Deever, Chris C. writes: When I go to the root directory of the base trunk and diff against the branch it finds all of the changes. However, when I go the the root working directory of the branch and compare it to "HEAD" it finds all but two changes. When you're working on a branch, "HEAD" means the head of the branch, not the head of the trunk, at least for diff. -Larry Jones They say winning isn't everything, and I've decided to take their word for it. -- Calvin
RE: Diff bug when using the HEAD tag?
Deever, Chris C. wrote: When comparing a branch agaist the base trunk, I've noticed a scenario where WinCVS 1.1b13 (client) and CVS 1.10.6 (server) miss some of the differences in the base trunk. In all developement branches, all changes are comitted. When I go to the root directory of the base trunk and diff against the branch it finds all of the changes. However, when I go the the root working directory of the branch and compare it to "HEAD" it finds all but two changes. [smc] You are aware that "cvs diff" treats HEAD differently than all other CVS commands, right? "cvs diff" treats "HEAD" to mean the head revision of the current branch (what you have checked out), if I recall correctly, while the other commands (notably "cvs update") treat HEAD to mean the head revision of the trunk There's a test case for this in sanity.sh that makes sure it's so. (it may be a feature, not a bug that you're seeing.) I wrote a patch some time ago to make "cvs diff" treat HEAD the same as all the other cvs commands do, which is the only thing that really makes any sense as far as I'm concerned, but, there are other opinions on that topic. I was involved in some talk of investigating making all other commands treat HEAD the way that "cvs diff" does as an alternate, (at the time, I thought it was just a matter of calling "RCS_branch_head" instead of RCS_head, but, that's not really all there is to it because RCS_branch_head takes an extra parameter which cannot be known (in a way that I was able to figure out) in all the places that RCS_head is used. And, it's not clear to me that trying to do that is not nonsensical, (to use the rare triple negative :-) This comes back to a discussion that's flared up on this list occasionally lamenting the fact that there is no such thing as the equivalent of a branch tag for the trunk. (for a time it was thought that you could use "1" for this, if I recall right, last time that came up, it was established that it doesn't work in all cases. And HEAD doesn't really work like a branch tag, not even considering its weirdness with "cvs diff") Anyway, if you search deja.com for subject "Alternate HEAD patch" you'll find my patch, though perhaps not in the most convenient form. That may make HEAD behave as you are expecting it to with "cvs diff" -- steve
RE: Diff bug when using the HEAD tag?
When you're working on a branch, "HEAD" means the head of the branch, not the head of the trunk, at least for diff. -Larry Jones Please forgive me if I'm not yet on the same page, but I can't seem to fit that explanation into my scenario. The diff from the branch to HEAD *did* report some of the changes, except for two changes that happened to be in a file which there are in two different copies of the same file located in different parts of the project (a shared data structure between client and server). new branch | base line version - rel tag - a little more development - current The above shows the tree. When I am in "current" and diff against "new branch" I see all of the changes that I expect. However, when I am in, "new branch" and I diff it against HEAD (which I am expecting it to be the latest changes comitted in the repository), I see only part of the changes. Either there is a bug or I'm not understanding something. Branches do not automatically get changes from the trunk, do they? Regards, Chris
Re: Diff bug when using the HEAD tag?
"Cameron, Steve" wrote: Deever, Chris C. wrote: When comparing a branch agaist the base trunk, I've noticed a scenario where WinCVS 1.1b13 (client) and CVS 1.10.6 (server) miss some of the differences in the base trunk. In all developement branches, all changes are comitted. When I go to the root directory of the base trunk and diff against the branch it finds all of the changes. However, when I go the the root working directory of the branch and compare it to "HEAD" it finds all but two changes. [smc] You are aware that "cvs diff" treats HEAD differently than all other CVS commands, right? "cvs diff" treats "HEAD" to mean the head revision of the current branch (what you have checked out), if I recall correctly, while the other commands (notably "cvs update") treat HEAD to mean the head revision of the trunk There's a test case for this in sanity.sh that makes sure it's so. (it may be a feature, not a bug that you're seeing.) Hmm ... while that might be the design intent my observations are that even this is broken: pw.notus.1783 cvs -n update ? .d ? ghr ? ghr_add ? ghr_app_test ? ghr_app_test_db ? ghr_db_test ? ghr_dbtool ? ghr_dump ? ghr_test ? ghr_change ? ghr_test_hlr_id_search ? ghr_delete ? ghr_gen_hlr_sub ? ghr_query ? ghr_report ? ghr_update_sub ? ghr_verify ? ghr_load_db_data ? ghr_db_convert ? ghr_comp_test ? ghr_db_test_comp cvs server: Updating . pw.notus.1784 cvs diff -r HEAD|egrep diff cvs server: Diffing . diff -r1.4 -r1.2 cvs server: ghr_command.c no longer exists, no comparison available diff -r1.10 -r1.9 diff -r1.3 -r1.2 cvs [diff aborted]: cannot open CVS/Root: Permission denied pw.notus.1785 III pw.notus.1785 pwd pw.notus.1785 cvs diff -r b_V3_3_enh ? .d ? ghr ? ghr_add ? ghr_app_test ? ghr_app_test_db ? ghr_db_test ? ghr_dbtool ? ghr_dump ? ghr_test ? ghr_change ? ghr_test_hlr_id_search ? ghr_delete ? ghr_gen_hlr_sub ? ghr_query ? ghr_report ? ghr_update_sub ? ghr_verify ? ghr_load_db_data ? ghr_db_convert ? ghr_comp_test ? ghr_db_test_comp cvs server: Diffing . cvs server: ghr_command.c no longer exists, no comparison available cvs [diff aborted]: cannot open CVS/Root: Permission denied pw.notus.1786 If what you are saying is true then the diff -r HEAD should produce no output - or is it me that is confused? I wrote a patch some time ago to make "cvs diff" treat HEAD the same as all the other cvs commands do, which is the only thing that really makes any sense as far as I'm concerned, but, there are other opinions on that topic. I was involved in some talk of investigating making all other commands treat HEAD the way that "cvs diff" does as an alternate, (at the time, I thought it was just a matter of calling "RCS_branch_head" instead of RCS_head, but, that's not really all there is to it because RCS_branch_head takes an extra parameter which cannot be known (in a way that I was able to figure out) in all the places that RCS_head is used. And, it's not clear to me that trying to do that is not nonsensical, (to use the rare triple negative :-) This comes back to a discussion that's flared up on this list occasionally lamenting the fact that there is no such thing as the equivalent of a branch tag for the trunk. (for a time it was thought that you could use "1" for this, if I recall right, last time that came up, it was established that it doesn't work in all cases. And HEAD doesn't really work like a branch tag, not even considering its weirdness with "cvs diff") Anyway, if you search deja.com for subject "Alternate HEAD patch" you'll find my patch, though perhaps not in the most convenient form. That may make HEAD behave as you are expecting it to with "cvs diff" -- steve -- Peter Wolfe Tel: (604) 303-2300 Telos Engineering Limited, http://www.telostech.com 120 - 13120 Vanier Place,FAX: (604) 276-0501 Richmond, BC, V6V 2J2. email: [EMAIL PROTECTED]
Re: Diff bug when using the HEAD tag?
I think what you are seeing is related to the way that diff handles the meaning of the tag HEAD. Like someone mentioned already, diff sees HEAD as being the latest version on the current branch. I personally think it still lies. Say I have file1 that has two revisions 1.1 and 1.2. There is a branch (BRANCH1) based off of revision 1.1. Say I check out BRANCH1. This results in my getting revision 1.1 of file1. Now I try diffing against HEAD. cvs diff -r HEAD file1 As stated before, this should give me the difference between my current revision on the branch (1.1) and the top revision on the branch (also 1.1). But it doesn't It actually gives me the diff between 1.2 and 1.1. Now if I ran cvs diff -r BRANCH1 file1 I get the correct result. Seems like a bug to me. Now back to your situation: When you are on the TRUNK, you can only do the difference using the branch tag, so everything works as expected. When you are on the BRANCH1 some of the files actually have revisions commited onto the branch, but some of them still only have revisions on the TRUNK. When you diff against the HEAD tag, the files that don't have revisions on the branch, the diff follows the TRUNK for those files. The result is a hybrid diff of things that have changed on the branch and things that have changed on the TRUNK. Hopefully everything made sense. Shane "Deever, Chris C." wrote: When you're working on a branch, "HEAD" means the head of the branch, not the head of the trunk, at least for diff. -Larry Jones Please forgive me if I'm not yet on the same page, but I can't seem to fit that explanation into my scenario. The diff from the branch to HEAD *did* report some of the changes, except for two changes that happened to be in a file which there are in two different copies of the same file located in different parts of the project (a shared data structure between client and server). new branch | base line version - rel tag - a little more development - current The above shows the tree. When I am in "current" and diff against "new branch" I see all of the changes that I expect. However, when I am in, "new branch" and I diff it against HEAD (which I am expecting it to be the latest changes comitted in the repository), I see only part of the changes. Either there is a bug or I'm not understanding something. Branches do not automatically get changes from the trunk, do they? Regards, Chris
