info-cvs
[Top][All Lists]
Advanced

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

rlog: How to get log messages *after* one tag up to another tag


From: David Carson
Subject: rlog: How to get log messages *after* one tag up to another tag
Date: 11 Apr 2002 21:26:10 -0700

Unfortunately, by ISP does not carry gnu.cvs.help and google groups
won't let me respond to this thread for some reason.  So, I'm posting
a "new" message that is really a continuation of this thread.

Larry Jones wrote:

> Jim Doyle writes:
> 
>>Is there a chance the cvs log features recently added can be further
>>extended to work across branches?  To a user, I think 1.3, 1.3.2.1,
>>1.3.2.2, ... looks like a legal sequence that cvs log should be able
to
>>follow.  Would it make sense to allow ranges A::B, where A precedes
B on
>>the same branch, *or* A::B' is itself a legal range, where B' is the
>>origin of the branch B is on?  Then the code could walk backwards
from
>>B, jumping to the branch origin of B while A has fewer "numdots"
than
>>B.  Does this make sense when coming at it from the point of view of
>>implementing CVS?
>>
> 
> Yes, I noticed that as a potential problem when I was adding the ::
> support, but I didn't worry about it too much since I don't recall
> anyone ever reporting it.  Unfortunately, the code is full of


It seems to me that one of the basic features of a version control
system is the ability to retrieve the history of a file from point A
to point B.  It matters not that point A is on the trunk and point B
is on a branch.  We primarily work on branches, so we are suffering
greatly as a result of this shortcoming.  Every time we create a new
branch, we tag the trunk so that we can do something like:

   cvs rlog -rroot-of-foo::branch-foo module/name/bar.c

This should give me all revisions of bar.c that occurred on
branch-foo. However, this is rejected with "invalid branch or revision
pair" as discussed earlier. Please, please, consider this a problem
that needs to be fixed.


> assumptions that the starting and ending revision numbers have the same
> number of dots, so there's a lot of rewriting to do.  It's also not
> quite as simple as it might seem, since I believe that 1.2:4.5.6.7.8.9
> should also be a valid range, no?  (All revisions with a single dot are



I'm sure there is some complication involved, but it is apparently
possible.  The "cvs rdiff -r<revA> -r<revB>" syntax handles this
problem correctly, going from <revA> to <revB> even if from trunk to
branch.  As long as point A is an ancestor of point B, then there is
only one way to get to B from A.

Thanks,
David


reply via email to

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