RE: first change on a branch causes no change to show up in -rTAGA::TAGB
Hi Everyone, This is to let you know that I have just tried out the development version of cvs post Larry's latest fix to log.c, and i'm now getting spot-on tag-to-tag version histories using cvs2cl, including when the tags are on branches. So it gets the big thumbs up from me! Thanks Larry. Cheers, matt -Original Message- From: Larry Jones [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 20 November 2002 04:57 To: Matthew Herrmann Cc: [EMAIL PROTECTED] Subject: Re: first change on a branch causes no change to show up in -rTAGA::TAGB Matthew Herrmann writes: I have taken Larry's suggestion and installed the latest dev version and it is better, but still not 100%. I've just checked in a new revision of log.c that I think fixes the problem. Let me know how it works. -Larry Jones The real fun of living wisely is that you get to be smug about it. -- Hobbes ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: first change on a branch causes no change to show up in -rTAGA::TAGB
Hi All, I have taken Larry's suggestion and installed the latest dev version and it is better, but still not 100%. Here is the problem I found on development version of CVS: For a file, FILE1: Tags: = TAG2: 1.3.2.1 TAG1: 1.3 TAG2_BRANCH: 1.3.2.1.0.2 Revisions: = revision 1.3 date: 2001/12/16 23:13:12; author: matthew; state: Exp; lines: +1 -1 branches: 1.3.2; ... - revision 1.3.2.1 date: 2002/10/17 23:36:14; author: matthew; state: Exp; lines: +1 -1 ... = the revision 1.3.2.1.0.2 doesn't exist, i'm guessing because it is a magic branch tag. anyway, that seemed a little weird to me because all my other tags, even branch tags are always on a physical tag (or so I thought). doing: cvs log -rTAG1::TAG2 should produce log info for 1.3.2.1, but it produces info for 1.3 instead. The interesting thing is that 1.3.2.1 is the start of another branch which was a branch off our production branch for a minor bug-fix. So I think this is the case that is not handled. I have got some other extraneous changes but I think they are very likely due to this same problem. cheers, matt Matthew Herrmann wrote: Hi All, I'm using cvs2cl to generate version differences on branches, but I'm having trouble with picking up changes where no change was previously there. I think the problem is one in cvs log, though, not cvs2cl. Here's the command I use cvs2cl -w -f ChangeLog_%1_To_%2.txt -r%1::%2 the scenario that breaks it is: working on branch BRANCH1 at TAG1, on BRANCH1 : file is on 1.23 at TAG2, on BRANCH1 file is on 1.23.1.4 after changes the problem is that even when looking at 2 tags on the same branch, it is only after the first change to the file that it becomes _really_ on the branch, before that, the tag is still officially on the trunk. What would fix this for me is for 1.23 = 1.23.x.y to be considered on the same line. At the moment the line is only being start just after 1.23 which means I'm losing a significant number of changes out of these history logs. are there any patches available for this problem? some others must have had this problem with log -r. cheers, matt I assume you are speaking of either http://search.cpan.org/author/FLUFFY/CVSUtils-1.00/ or http://www.red-bean.com/cvs2cl/ the '-r' option to cvs2cl is for: [-r, --revisions Show revision numbers in output] what I think you want is to pass options to cvs log so you should use -l options: [-l OPTS, --log-opts OPTS Invoke like this cvs ... log OPTS] if you want to pass revisions to cvs log I believe it should be something like cvs2cl -l -r%1::%2 -w -f ChangeLog_%1_To_%2.txt I use the global compress option as cvs2cl.pl -g -z9 -r -t -f cl.txt so I think the line I gave you above will work, if cvs log will accept whatever -r%1::%2 evaluates to. -- I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: first change on a branch causes no change to show up in -rTAGA::TAGB
Matthew Herrmann wrote: Hi All, I'm using cvs2cl to generate version differences on branches, but I'm having trouble with picking up changes where no change was previously there. I think the problem is one in cvs log, though, not cvs2cl. Here's the command I use cvs2cl -w -f ChangeLog_%1_To_%2.txt -r%1::%2 the scenario that breaks it is: working on branch BRANCH1 at TAG1, on BRANCH1 : file is on 1.23 at TAG2, on BRANCH1 file is on 1.23.1.4 after changes the problem is that even when looking at 2 tags on the same branch, it is only after the first change to the file that it becomes _really_ on the branch, before that, the tag is still officially on the trunk. What would fix this for me is for 1.23 = 1.23.x.y to be considered on the same line. At the moment the line is only being start just after 1.23 which means I'm losing a significant number of changes out of these history logs. are there any patches available for this problem? some others must have had this problem with log -r. cheers, matt I assume you are speaking of either http://search.cpan.org/author/FLUFFY/CVSUtils-1.00/ or http://www.red-bean.com/cvs2cl/ the '-r' option to cvs2cl is for: [-r, --revisions Show revision numbers in output] what I think you want is to pass options to cvs log so you should use -l options: [-l OPTS, --log-opts OPTS Invoke like this cvs ... log OPTS] if you want to pass revisions to cvs log I believe it should be something like cvs2cl -l -r%1::%2 -w -f ChangeLog_%1_To_%2.txt I use the global compress option as cvs2cl.pl -g -z9 -r -t -f cl.txt so I think the line I gave you above will work, if cvs log will accept whatever -r%1::%2 evaluates to. -- I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: first change on a branch causes no change to show up in -rTAGA::TAGB
Matthew Herrmann writes: What would fix this for me is for 1.23 = 1.23.x.y to be considered on the same line. At the moment the line is only being start just after 1.23 which means I'm losing a significant number of changes out of these history logs. I believe that's fixed in the current development version of CVS. -Larry Jones I'm not a vegetarian! I'm a dessertarian. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
FW: first change on a branch causes no change to show up in -rTAGA::TAGB
oops sorry Larry, just saw your post after I sent my reply. thanks for the input Larry and Todd, I'll upgrade asap. -Original Message- From: Matthew Herrmann [mailto:matt;faredge.com.au] Sent: Thursday, 14 November 2002 10:27 To: Todd Denniston Cc: CVS Mailing List Subject: RE: first change on a branch causes no change to show up in -rTAGA::TAGB Thanks todd, but with this option I see the exact behaviour. The problem, as I verified is that the -rTAG1::TAG2 option will not output any revisions when TAG1 and TAG2 are not on the same branch. cvs log -rBRANCHTAG1::BRANCHTAG2 main\Main.bas What is frustrating about this is that these tags _are_ on the same branch, but that it is only after the first commit that the revision number moves from being a trunk revision number to a branch revision number. Ie. BRANCHTAG1 was taken before I made any changes to the file on the branch, and BRANCHTAG2 was taken after I made some changes to it. This effectively nullifies the use of cvs2cl in this manner or -rTAG1::TAG2, unless one makes a dummy commit to every single file to force it to 'really' be on the branch, when one starts one. I personally find this a pretty messy workaround, especially since I can't apply it retrospectively. The other alternative would be to say that, for a given revision X1.X2.X3. ... .Xn (ie. 1.52.1.20) the file: X1.X2.X3. ... .Qn (ie. 1.52.1.13) is on the branch (current behaviour), and so is the file: X1.X2.X3. ... .X(n-2) (ie. 1.52) and is before all revisions from X1.X2.X3. ... .1 to X1.X2.X3. ... .infinity Are there any philosophical problems with this approach? I don't know of too many people who fiddle with revision numbers, and even less who fiddle with branch numbers. I think the likelihood of someone branching off 1.52 and renumbering the branch 1.53.1.2 extremely unlikely. In my reading of the Cederqvist, renumbering the branch in this way would actually go against what branching of a file is actually means. Intuitively, 1.53 is the parent of the branch 1.53.xx.yy. What do other people think? Does anyone know a workable workaround, or know of a patch for this? cheers, matt -Original Message- From: [EMAIL PROTECTED] [mailto:tdennist;glock.ssa.crane.navy.mil]On Behalf Of Todd Denniston Sent: Thursday, 14 November 2002 01:10 To: Matthew Herrmann Cc: CVS Mailing List Subject: Re: first change on a branch causes no change to show up in -rTAGA::TAGB Matthew Herrmann wrote: Hi All, I'm using cvs2cl to generate version differences on branches, but I'm having trouble with picking up changes where no change was previously there. I think the problem is one in cvs log, though, not cvs2cl. Here's the command I use cvs2cl -w -f ChangeLog_%1_To_%2.txt -r%1::%2 the scenario that breaks it is: working on branch BRANCH1 at TAG1, on BRANCH1 : file is on 1.23 at TAG2, on BRANCH1 file is on 1.23.1.4 after changes the problem is that even when looking at 2 tags on the same branch, it is only after the first change to the file that it becomes _really_ on the branch, before that, the tag is still officially on the trunk. What would fix this for me is for 1.23 = 1.23.x.y to be considered on the same line. At the moment the line is only being start just after 1.23 which means I'm losing a significant number of changes out of these history logs. are there any patches available for this problem? some others must have had this problem with log -r. cheers, matt I assume you are speaking of either http://search.cpan.org/author/FLUFFY/CVSUtils-1.00/ or http://www.red-bean.com/cvs2cl/ the '-r' option to cvs2cl is for: [-r, --revisions Show revision numbers in output] what I think you want is to pass options to cvs log so you should use -l options: [-l OPTS, --log-opts OPTS Invoke like this cvs ... log OPTS] if you want to pass revisions to cvs log I believe it should be something like cvs2cl -l -r%1::%2 -w -f ChangeLog_%1_To_%2.txt I use the global compress option as cvs2cl.pl -g -z9 -r -t -f cl.txt so I think the line I gave you above will work, if cvs log will accept whatever -r%1::%2 evaluates to. -- I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: first change on a branch causes no change to show up in -rTAGA::TAGB
Thanks todd, but with this option I see the exact behaviour. The problem, as I verified is that the -rTAG1::TAG2 option will not output any revisions when TAG1 and TAG2 are not on the same branch. cvs log -rBRANCHTAG1::BRANCHTAG2 main\Main.bas What is frustrating about this is that these tags _are_ on the same branch, but that it is only after the first commit that the revision number moves from being a trunk revision number to a branch revision number. Ie. BRANCHTAG1 was taken before I made any changes to the file on the branch, and BRANCHTAG2 was taken after I made some changes to it. This effectively nullifies the use of cvs2cl in this manner or -rTAG1::TAG2, unless one makes a dummy commit to every single file to force it to 'really' be on the branch, when one starts one. I personally find this a pretty messy workaround, especially since I can't apply it retrospectively. The other alternative would be to say that, for a given revision X1.X2.X3. ... .Xn (ie. 1.52.1.20) the file: X1.X2.X3. ... .Qn (ie. 1.52.1.13) is on the branch (current behaviour), and so is the file: X1.X2.X3. ... .X(n-2) (ie. 1.52) and is before all revisions from X1.X2.X3. ... .1 to X1.X2.X3. ... .infinity Are there any philosophical problems with this approach? I don't know of too many people who fiddle with revision numbers, and even less who fiddle with branch numbers. I think the likelihood of someone branching off 1.52 and renumbering the branch 1.53.1.2 extremely unlikely. In my reading of the Cederqvist, renumbering the branch in this way would actually go against what branching of a file is actually means. Intuitively, 1.53 is the parent of the branch 1.53.xx.yy. What do other people think? Does anyone know a workable workaround, or know of a patch for this? cheers, matt -Original Message- From: [EMAIL PROTECTED] [mailto:tdennist;glock.ssa.crane.navy.mil]On Behalf Of Todd Denniston Sent: Thursday, 14 November 2002 01:10 To: Matthew Herrmann Cc: CVS Mailing List Subject: Re: first change on a branch causes no change to show up in -rTAGA::TAGB Matthew Herrmann wrote: Hi All, I'm using cvs2cl to generate version differences on branches, but I'm having trouble with picking up changes where no change was previously there. I think the problem is one in cvs log, though, not cvs2cl. Here's the command I use cvs2cl -w -f ChangeLog_%1_To_%2.txt -r%1::%2 the scenario that breaks it is: working on branch BRANCH1 at TAG1, on BRANCH1 : file is on 1.23 at TAG2, on BRANCH1 file is on 1.23.1.4 after changes the problem is that even when looking at 2 tags on the same branch, it is only after the first change to the file that it becomes _really_ on the branch, before that, the tag is still officially on the trunk. What would fix this for me is for 1.23 = 1.23.x.y to be considered on the same line. At the moment the line is only being start just after 1.23 which means I'm losing a significant number of changes out of these history logs. are there any patches available for this problem? some others must have had this problem with log -r. cheers, matt I assume you are speaking of either http://search.cpan.org/author/FLUFFY/CVSUtils-1.00/ or http://www.red-bean.com/cvs2cl/ the '-r' option to cvs2cl is for: [-r, --revisions Show revision numbers in output] what I think you want is to pass options to cvs log so you should use -l options: [-l OPTS, --log-opts OPTS Invoke like this cvs ... log OPTS] if you want to pass revisions to cvs log I believe it should be something like cvs2cl -l -r%1::%2 -w -f ChangeLog_%1_To_%2.txt I use the global compress option as cvs2cl.pl -g -z9 -r -t -f cl.txt so I think the line I gave you above will work, if cvs log will accept whatever -r%1::%2 evaluates to. -- I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
first change on a branch causes no change to show up in -rTAGA::TAGB
Hi All, I'm using cvs2cl to generate version differences on branches, but I'm having trouble with picking up changes where no change was previously there. I think the problem is one in cvs log, though, not cvs2cl. Here's the command I use cvs2cl -w -f ChangeLog_%1_To_%2.txt -r%1::%2 the scenario that breaks it is: working on branch BRANCH1 at TAG1, on BRANCH1 : file is on 1.23 at TAG2, on BRANCH1 file is on 1.23.1.4 after changes the problem is that even when looking at 2 tags on the same branch, it is only after the first change to the file that it becomes _really_ on the branch, before that, the tag is still officially on the trunk. What would fix this for me is for 1.23 = 1.23.x.y to be considered on the same line. At the moment the line is only being start just after 1.23 which means I'm losing a significant number of changes out of these history logs. are there any patches available for this problem? some others must have had this problem with log -r. cheers, matt ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
