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 _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
