> Which is exactly what you should expect. Note that -r and -w do not > specify which *files* to log, they specify which *revisions* to log. > So, you should expect a header for every file, but only files that meet > the specifications will have "selected revisions" greater than zero. In > this case, you're asking for all revisions that have the tag dev2310 > that were checked in by navin, which isn't even close to what you want > since there's no requirement that that revision be different from the > revision identified by any other tag.
I agree. I also know that -r and -w options will not give what I want. They do exactly what they "mean" or "say" they will do. No arguments about that. > It doesn't make sense to talk about files being modified "in" a tag -- > tags just mark revisions. The only sensible thing to talk about is > files modified *between* two different tags. Asking for revisions after > iCare060 is what you want, I think; files with "selected revisions" > greater than zero should be exactly those files that were modified after > that tag was applied. You could also do something like > -riCare060:dev2310 and look for files with more than one selected > revision. > Ok. Sorry I was dumb. I did not mean to say files modified "in" a tag. I surely meant to say files modified between a range of tags, or atleast the tag I give and the tag placed just before this tag. That is why in my workaround I have always needed to give a set of two tags. When I was preparing the output for you - I did try out a number of options before actually submitting it - including the one you suggest, i.e., -riCare060:dev2310. But I still got the same output. You see they "do" do what the docs say. I have no arguments about that. All I would have liked was to have an option, within the log command, to completely filter out files whose revision numbers have not "changed" in the tag range I give. So before doing a release I will have to 1) tag the current repository 2) tell cvs to give a log of files modified since the last release and the current one, and 3) run programs like cvs2cl.pl which builds a ChangeLog automatically. Later I may or may not manually filter out output which I do not want. Thanks for your time. Regards Navin -----Original Message----- From: Larry Jones [mailto:[EMAIL PROTECTED]] Sent: Friday, 26 October 2001 4:48 AM To: Navin Daryanani Cc: [EMAIL PROTECTED] Subject: Re: bug / enhancement regarding cvs log Navin Daryanani writes: > > current status of the repository module : WSA/iCare - everything commited > and in sync and the latest version tagged with iCare060 > > modified Application.java - say for e.g., added a line break at the > beginning of the file > > "cvs commit Application.java" <and gave a log : cvs testing> > > "cvs rtag dev2310 WSA/iCare " > > when you do a "cvs log -rdev2310 -wnavin " you get the foll. output. (For > brevity I have kept the log of the first 3-4 files only.) Which is exactly what you should expect. Note that -r and -w do not specify which *files* to log, they specify which *revisions* to log. So, you should expect a header for every file, but only files that meet the specifications will have "selected revisions" greater than zero. In this case, you're asking for all revisions that have the tag dev2310 that were checked in by navin, which isn't even close to what you want since there's no requirement that that revision be different from the revision identified by any other tag. > Notice that I had modified only Application.java in the revision tag dev2310 > and I got many more files which weren't even modified in this tag - and I get the same output > even if I do "cvs log -riCare060::". It doesn't make sense to talk about files being modified "in" a tag -- tags just mark revisions. The only sensible thing to talk about is files modified *between* two different tags. Asking for revisions after iCare060 is what you want, I think; files with "selected revisions" greater than zero should be exactly those files that were modified after that tag was applied. You could also do something like -riCare060:dev2310 and look for files with more than one selected revision. -Larry Jones In short, open revolt and exile is the only hope for change? -- Calvin _______________________________________________ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
