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
