[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: branch tags

From: Teala Spitzbarth
Subject: RE: branch tags
Date: Thu, 16 Aug 2001 19:11:52 -0700

Ah.... Matthew

What you have seen regarding erroneous log output matches
my situation as well.  If I try to diff between two tags
on a branch I will get erroneous 'selected revisions' for 
1) any file that has been deleted from the main trunk
        (i.e. is now moved into the Attic)
2) newly created files under "some conditions"  
   (your surmise that it is new files that are yet untagged would fit
   what I have seen, though haven't explicitly double checked my 
   output yet).

I have found that log commands searching between dates is more
reliable than between tags, but of course aren't specific to a branch.  
I am using a hack where (because I know the exact date/time that 
I tag my tree) I run cvs log between the dates in question, and then 
have my perl script eliminate all non-branch changes. This only works 
for me right now because we have *only* one active branch in our 
tree at time.

The rdiff program does (for some reason) seem to calculate the correct
list of changed file between tags (on branches or not). 
Dtaylor kindly explained this workaround to me. I
use this for quick lists to QA etc. It doesn't get you 
the commit comments though.

cvs -q rdiff -s -rtag1 -rtag2 module  |  awk '{print $2}'

He also mentioned that you can use this with rlog,( I think
this can get you the comments?) but I have an older version of 
cvs so I haven't been able to try yet:

cvs -q rlog -N -rYourBranchName `cvs -q rdiff -s -rtag1 -rtag2 module  |
awk '{print $2}'`

My understanding is that this log problem with branch tags has been
around awhile - it would be great if we could get enough info
on this to nail it!



-----Original Message-----
From: Matthew Herrmann [mailto:address@hidden
Sent: Thursday, August 16, 2001 5:01 PM
To: Derek R. Price
Cc: CVS Mailing List
Subject: RE: branch tags

Hi Derek,

Following your suggestion to look at logs to work out why I was getting
extra log messages, I did a file by file check.

I think I've uncovered a bizarre behaviour in cvs regarding newly

Here's the command I used.

cvs log -rROT_4_4_1_G:ROT_4_4_1_L

Here it works as expected:
RCS file:
Working file: AllelicDiscrimination.frm
head: 1.8
locks: strict
access list:
symbolic names:
        corbett: 1.1.1
keyword substitution: kv
total revisions: 12;    selected revisions: 1
date: 2001/07/02 08:44:16;  author: Matthew;  state: Exp;  lines: +6 -1
improved sample selector Show More/Show Less resizing
improved resizing code to remove magic numbers from frmMeltCurve and
sample selector now autoshrinks

This one hasn't yet had any tags since it's a new file on the dev
Using the above cvs log command, I get every version instead of no
which i'd expect:

RCS file: \\gene\public\development\CVS/rotorgene/Analyses.frm,v
Working file: Analyses.frm
head: 1.2
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 2;     selected revisions: 2
revision 1.2
date: 2001/08/08 06:21:53;  author: Matthew;  state: Exp;  lines: +36
Finished melt screen
revision 1.1
date: 2001/08/07 23:10:29;  author: Matthew;  state: Exp;
Convert software to MDI
Quantitation analysis fully functional
Melt half finished
Incomplete but more stable

Since I was compressing all identical messages at similar times to make
changelog (like that perl script), I was getting ghost entries from
created entries on the main trunk in my "What's changed since the last
release" documents on the ROT_4_4_1_PATCHES trunk.

Is there any way of avoiding this before I get to my program? I'd rather
have my log parser work out "well it's mostly branch-type tags so he
probably wanted this range so I'll ignore the main branch" style hacks.

Any suggestions appreciated.

Matthew Herrmann
Far Edge Technology

reply via email to

[Prev in Thread] Current Thread [Next in Thread]