RE: bug / enhancement regarding cvs log
> 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" > > "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
RE: bug / enhancement regarding cvs log
= = RCS file: /mnt/cvsroot/WSA/iCare/CustomInfo.plist,v Working file: CustomInfo.plist head: 1.1 branch: 1.1.1 locks: strict access list: symbolic names: dev2310: 1.1.1.1 iCare060: 1.1.1.1 iCare059: 1.1.1.1 iCare058: 1.1.1.1 dev0910: 1.1.1.1 iCare057A: 1.1.1.1 iCare057: 1.1.1.1 iCare056: 1.1.1.1 iCare055: 1.1.1.1 iCare054: 1.1.1.1 iCare053: 1.1.1.1 iCare052A: 1.1.1.1 BRANCH_ICARE052: 1.1.1.1.0.2 iCare052: 1.1.1.1 iCare051A: 1.1.1.1 iCare051: 1.1.1.1 iCare050A: 1.1.1.1 iCare050: 1.1.1.1 iCare049: 1.1.1.1 iCare048: 1.1.1.1 iCare047: 1.1.1.1 iCare046: 1.1.1.1 iCare045: 1.1.1.1 iCare044: 1.1.1.1 iCare043: 1.1.1.1 iCare042: 1.1.1.1 iCare041: 1.1.1.1 iCare040: 1.1.1.1 iCare039: 1.1.1.1 iCare038: 1.1.1.1 iCare037: 1.1.1.1 iCare036: 1.1.1.1 iCare035: 1.1.1.1 iCare34preFrank: 1.1.1.1 iCare033: 1.1.1.1 iCare032: 1.1.1.1 iCare031: 1.1.1.1 dev2108: 1.1.1.1 iCare030: 1.1.1.1 iCare029: 1.1.1.1 iCare028: 1.1.1.1 iCare027: 1.1.1.1 iCare026: 1.1.1.1 dev0208: 1.1.1.1 dev0108: 1.1.1.1 iCare025: 1.1.1.1 iCare024: 1.1.1.1 version023: 1.1.1.1 iCare022: 1.1.1.1 iCare021: 1.1.1.1 dev1407: 1.1.1.1 dev1107: 1.1.1.1 dev0507: 1.1.1.1 iCare018: 1.1.1.1 dev-0626: 1.1.1.1 dev1: 1.1.1.1 v017: 1.1.1.1 wsa: 1.1.1 keyword substitution: kv total revisions: 2; selected revisions: 0 description: = RCS file: /mnt/cvsroot/WSA/iCare/DirectAction.java,v Working file: DirectAction.java head: 1.1 branch: 1.1.1 locks: strict access list: symbolic names: dev2310: 1.1.1.1 iCare060: 1.1.1.1 iCare059: 1.1.1.1 iCare058: 1.1.1.1 dev0910: 1.1.1.1 iCare057A: 1.1.1.1 iCare057: 1.1.1.1 iCare056: 1.1.1.1 iCare055: 1.1.1.1 iCare054: 1.1.1.1 iCare053: 1.1.1.1 iCare052A: 1.1.1.1 BRANCH_ICARE052: 1.1.1.1.0.2 iCare052: 1.1.1.1 iCare051A: 1.1.1.1 iCare051: 1.1.1.1 iCare050A: 1.1.1.1 iCare050: 1.1.1.1 iCare049: 1.1.1.1 iCare048: 1.1.1.1 iCare047: 1.1.1.1 iCare046: 1.1.1.1 iCare045: 1.1.1.1 iCare044: 1.1.1.1 iCare043: 1.1.1.1 iCare042: 1.1.1.1 iCare041: 1.1.1.1 iCare040: 1.1.1.1 iCare039: 1.1.1.1 iCare038: 1.1.1.1 iCare037: 1.1.1.1 iCare036: 1.1.1.1 iCare035: 1.1.1.1 iCare34preFrank: 1.1.1.1 iCare033: 1.1.1.1 iCare032: 1.1.1.1 iCare031: 1.1.1.1 dev2108: 1.1.1.1 iCare030: 1.1.1.1 iCare029: 1.1.1.1 iCare028: 1.1.1.1 iCare027: 1.1.1.1 iCare026: 1.1.1.1 dev0208: 1.1.1.1 dev0108: 1.1.1.1 iCare025: 1.1.1.1 iCare024: 1.1.1.1 version023: 1.1.1.1 iCare022: 1.1.1.1 iCare021: 1.1.1.1 dev1407: 1.1.1.1 dev1107: 1.1.1.1 dev0507: 1.1.1.1 iCare018: 1.1.1.1 dev-0626: 1.1.1.1 dev1: 1.1.1.1 v017: 1.1.1.1 wsa: 1.1.1 keyword substitution: kv total revisions: 2; selected revisions: 0 description: = -Original Message- From: Larry Jones [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 23 October 2001 1:22 AM To: Navin Daryanani Cc: [EMAIL PROTECTED] Subject: Re: bug / enhancement regarding cvs log Navin Daryanani writes: > > Sorry I don't mean to bug anybody - but I just checked out a version of ccvs > and tried to build it from sources and wanted to checkout the feature I > needed. I don't seem to get the right results. I mean when I do a log of a > range of revisions I still get a log of a ver old file which was not > modified in that revision range. Could you post an example? -Larry Jones It works on the same principle as electroshock therapy. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
RE: bug / enhancement regarding cvs log
Sorry I don't mean to bug anybody - but I just checked out a version of ccvs and tried to build it from sources and wanted to checkout the feature I needed. I don't seem to get the right results. I mean when I do a log of a range of revisions I still get a log of a ver old file which was not modified in that revision range. I tried looking thru the sources to see if I can quickly see if there is an option or something else - but couldn't locate it. Can you pls tell me what option do I have to use (If you are aware of it). FYI: Currently I am solving my problem by a small perl script I wrote which does a cvs history and greps all commits and then builds a file(s) list - which I pass to the cvs log command eventually. It is not a very clean method bec' the history command's options on revision tag and log command's revision tags are different. So I was just hoping if I could find an alternative soln. Maybe start working on it too - if it has not been started yet :-) thanks & regards navin -Original Message- From: Larry Jones [mailto:[EMAIL PROTECTED]] Sent: Saturday, 20 October 2001 3:53 AM To: Navin Daryanani Cc: [EMAIL PROTECTED] Subject: Re: bug / enhancement regarding cvs log Navin Daryanani writes: > > Consider a command 'cvs log -rMod13:Mod15' > > This command does not filter out (and there are no options as far as I can > see) the files which have not been modified in this tag ranges. It would be > nice to have a log on files modified in this tag range only. This way we can > see exactly which files have changed and with what log messages. I believe this is fixed in the current development version of CVS. -Larry Jones Oh, now don't YOU start on me. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
bug / enhancement regarding cvs log
Hi Sorry for this email but I tried to submit an issue at cvshome but could not bec' it said I had to login in to submit one - and I was already logged in. Not sure where the problem is. Anyway, I was wondering if I could submit an enhancement request regarding cvs log command. Consider a command 'cvs log -rMod13:Mod15' This command does not filter out (and there are no options as far as I can see) the files which have not been modified in this tag ranges. It would be nice to have a log on files modified in this tag range only. This way we can see exactly which files have changed and with what log messages. Currently if a file has not been modified within this tag range - the log is done on it's last revision - which may be any level below on the change list. Sorry if this has already been requested. I tried searching the Issue Tracking search page but did not find an appropriate issue. Regards Navin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
