[Top][All Lists]

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

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

From: Doyle, Jim
Subject: RE: How to get log messages *after* one tag up to another tag
Date: Wed, 6 Feb 2002 17:49:44 -0500

> > 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,,
> >, ... 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?  
> [snip]
> It's also not
> quite as simple as it might seem, since I believe that 1.2:
> should also be a valid range, no?  (All revisions with a 
> single dot are
> on the trunk, reguardless of the major revision number; on other
> branches, the major componenents of the revision number must 
> be exactly
> equal.)


Thanks for the reply.

I see your point about the trunk major revisions - I thought there might be
additional complications I wasn't seeing.  And yes, the kind of
general functionality I would hope for would support "1.2:" as a
valid range.  

Would this really complicate the code, though?  I haven't looked at the
source much, but I have seen that there seem to be functions for getting the
origin of a branch ("RCS_getbranch"? or "RCS_whatbranch"?).  As long as you
can jump from a branch revision to the branch origin, and get from a
revision to the
one that precedes it within a branch, it looks like listing the revisions
wouldn't be too bad.  

To take the example above, "1.2:", I'd imagine the code:
* starting with ""
* decrementing the minor revision number until it gets to the first branch
revision ""
* jumping to the origin "" of the branch ""
* decrementing the minor revision again until ""
* jumping to the origin "4.5"
* tracing revisions backwards along the trunk, decrementing the minor and
major revisions, until it gets to "1.2"

Do the necessary primitives (getbranch, etc.) exist to support an algorithm
like this?
Would an algorithm like this really cover all the bases?
Would it be possible to confine these code changes to the log command, or
would it affect other parts of the source?


reply via email to

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