find changeset for a file

[Arthur Barrett]

Sandeep,

Note: CVSNT (yes it works on linux too, LGPL) has a 'commitid' property
- all files with the same 'commitid' were committed together. CVSNT
also has 'bugid' which is a user defined change set that can occur on
multiple commits.

Todd's suggestion of similar date/time with same comment is great -
until you have a team that has overlapping commits with the same "blank"
message (or some 'standard text'). I see this a lot...

Regards,


Arthur

-----Original Message-----
org] On Behalf Of sandeepk1611
Sent: Thursday, 17 February 2011 9:26 AM
Subject: CVS: find changeset for a file
Hi,
I am doing some research with CVS logs. I used the cvs rlog
command to get
the revision information for the CVS files in a module. I was
wondering
whether there is some way I can also know, for each revision,
how many other
files were modified along with the current file.
For example,
Currently a sample rlog -N command output looks like this,
file1
head: 1.33
locks: strict
keyword substitution: o
total revisions: 35; selected revisions: 2
----------------------------
revision 1.30
date:date1; author: author1; state: Exp; lines: +2 -2;
text1
----------------------------
revision 1.29
date: date2; author: author2; state: Exp; lines: +1 -1;
text2
....
I was wondering if for each revision, I can also get information,
Changeset: ###(some number)
If I cannot get it directly by rlog command, is there any
other command by
which I can get this information?
Any help will be be very useful.
Thanks,
Sandeep
--
http://old.nabble.com/CVS%3A-find-changeset-for-a-file-tp30939

494p30939494.html
Sent from the Gnu - Cvs - Info mailing list archive at Nabble.com.

[Todd Denniston]

Post by Arthur Barrett
Sandeep,
Note: CVSNT (yes it works on linux too, LGPL) has a 'commitid' property
- all files with the same 'commitid' were committed together. CVSNT
also has 'bugid' which is a user defined change set that can occur on
multiple commits.

Out of curiosity please confirm, the 'commitid' only really exists if you have been using CVSNT
since 'commitid' was added as a capability?
i.e. I can't take a normal CVS repo and drop it in under CVSNT and get 'commitid' correct?

Post by Arthur Barrett
Todd's suggestion of similar date/time with same comment is great -
until you have a team that has overlapping commits with the same "blank"
message (or some 'standard text'). I see this a lot...

*I* have been _fortunate_ enough that A) all my projects have forced a comment at commit time, B)
Appropriately disciplined anyone who did not use a reasonable checkin comment. Our biggest problem
is when folks checkin ONE FILE at a time instead of a coherent checkin of the tree (with
individualized comments on EACH file) [has me reaching for my LART, by just thinking about it again].
So I can see what you are talking about, I have just only seen it polar opposite in my environment.

Post by Arthur Barrett
Regards,
Arthur

[sandeepk1611]

Todd and Arthur,

I had another question. Is there any way I can find the first time any file
appeared in the CVS repository,
i.e. the first time it was committed into the repository?

Thanks,
Sandeep

Post by Todd Denniston

Post by Arthur Barrett
Sandeep,
Note: CVSNT (yes it works on linux too, LGPL) has a 'commitid' property
- all files with the same 'commitid' were committed together. CVSNT
also has 'bugid' which is a user defined change set that can occur on
multiple commits.

Out of curiosity please confirm, the 'commitid' only really exists if you
have been using CVSNT
since 'commitid' was added as a capability?
i.e. I can't take a normal CVS repo and drop it in under CVSNT and get 'commitid' correct?

Post by Arthur Barrett
Todd's suggestion of similar date/time with same comment is great -
until you have a team that has overlapping commits with the same "blank"
message (or some 'standard text'). I see this a lot...

*I* have been _fortunate_ enough that A) all my projects have forced a
comment at commit time, B)
Appropriately disciplined anyone who did not use a reasonable checkin
comment. Our biggest problem
is when folks checkin ONE FILE at a time instead of a coherent checkin of the tree (with
individualized comments on EACH file) [has me reaching for my LART, by
just thinking about it again].
So I can see what you are talking about, I have just only seen it polar
opposite in my environment.

Post by Arthur Barrett
Regards,
Arthur

--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter

[Arthur Barrett]

Todd,

Post by Todd Denniston
Out of curiosity please confirm, the 'commitid' only really
exists if you have been using CVSNT
since 'commitid' was added as a capability?

Yes - CVSNT Server to be precise.

Post by Todd Denniston
*I* have been _fortunate_ enough that A) all my projects have
forced a comment at commit time,

Ahh the joys of a disciplined engineering environment. Try financial
services... Or non-tech personel...

Regards,

Arthur

[Arthur Barrett]

Sandeep,

Post by sandeepk1611
I had another question. Is there any way I can find the first
time any file
appeared in the CVS repository,
i.e. the first time it was committed into the repository?

The CVS/CVSNT repository CAN give you all this sort of information, but
it's not really designed for access that way.

Again in CVSNT we added a failsafe audit function that audits all this
type of information to an SQL database of your choice, and provided that
it is always enabled then you can get all this info back with a simple
SQL query or your favourite reporting tool. It's a basic requirement of
most large companiest that important information is independantly
auditable - and so this way you can fulfill an accounting requirement
and obtain a real business benefit at the same time.

At some future point we'll probably make the audit mandatory (to SQLite
or something), and also provide an 'audit import' to pre-load all the
reporting tables with info from the RCS repository...

Regards,


Arthur

[Yaron Yogev]

On Feb 18, 4:25 pm, Todd Denniston

Post by Todd Denniston
*I* have been _fortunate_ enough that A) all my projects have forced a comment at commit time, B)
Appropriately disciplined anyone who did not use a reasonable checkin comment.  Our biggest problem
is when folks checkin ONE FILE at a time instead of a coherent checkin of the tree (with
individualized comments on EACH file) [has me reaching for my LART, by just thinking about it again].
So I can see what you are talking about, I have just only seen it polar opposite in my environment.

Having blank or dummy comments is indeed a problem, and where I work
we try to educate developers to invest the extra 15 seconds in
producing better commit messages.
As for having the same comment for the whole tree - it is not always
the best option. For example: suppose I make some business-logic
change, and to do this I need to add some enhancement in a utility
function in a separate file, e.g. str.c. I prefer to have the comment
on str.c describe what I changed in str.c, although I may include a
comment on the context of the change and a bug ID for easier tracing.

To allow better handling of change sets, we created a review system
that allow developers to aggregate commits by change sets. The commit
message of the first commit to be included in a review is
automatically used as the review title, but the developer can later
edit this title. If the commit message included a bug ID it is
automatically added to a list of bug IDs related to the review.
This system also handles review work-flow (author->reviewer->author)
and auto-merging between branches.

Yaron Yogev

IT Software Developer
Jungo LTD

[Mark D. Baushke]

Post by Arthur Barrett
Note: CVSNT (yes it works on linux too, LGPL) has a 'commitid' property
- all files with the same 'commitid' were committed together. CVSNT
also has 'bugid' which is a user defined change set that can occur on
multiple commits.
Todd's suggestion of similar date/time with same comment is great -
until you have a team that has overlapping commits with the same "blank"
message (or some 'standard text'). I see this a lot...

For what is is worth, cvs 1.12.13 also has a 'commitid' property.

The contrib directory also has a patch to rcs-5.7-commitid.patch to
apply to RCS 5.7 sources of 1995-06-16 to support the newphrase
'commitied' used by CVS and CVSNT.

Enjoy!
-- Mark