RE: bug / enhancement regarding cvs log

[Navin Daryanani]

> 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:larry.jones@sdrc.com]
Sent: Friday, 26 October 2001 4:48 AM
To: Navin Daryanani
Cc: bug-cvs@gnu.org
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