[ On Thursday, March 23, 2000 at 19:33:22 (-0700), Derek R. Price wrote: ]
> Subject: Re: Proposed new aliases, like HEAD
>
> > > > TRUNK - top of the trunk
> > > > BHEAD - head of the current branch (or trunk if not on a branch)
> > > > PHEAD - head of the parent branch (or trunk if the file split from the
> > > > trunk)
> > > > TBASE - point at which this file left the trunk. Same as self if not on a
> > > > branch.
>
> > > > SPLIT - point at which this file left was branched. Same as self if not on
> > > > a branch.
>
> I think I like TSPLIT ("split from trunk") and PSPLIT ("split from parent")
> better (your TBASE and SPLIT, respectively). Seems more consistant. TBASE
> sounds like the base of the trunk to me, especially viewed alongside BHEAD and
> PHEAD.
Why is specific knowledge about the trunk important? Certainly it's
possible to derive from the branch ID, but why? The only things that
I've ever seen as necessary to know about a branch in a symbolic sense
are its current head in the repository, and of course it's base.
My preference would be to do what is effectively the opposite of what
Steve Cameron's proposed patch does.
I.e make "HEAD" always refer to the head of the current branch
(or the trunk if there is no sticky branch in effect; or if no branch
name is given with '-r'); and make "BASE" always refer to the base of
the current branch (or the trunk if there is no branch in effect).
There is no real need for "TRUNK" -- it is the same as specifying "1".
(And of course the base of the trunk is always "1.1", not that this
matters in day-to-day normal usage.) Having a symbolic name for "TRUNK"
isn't necessarily a bad thing, but it does crowd the tag namespace
unnecessarily. If you really want to use it then why not just manually
add a real "TRUNK" tag and be done with it? This way those who want it
can have it and those who don't won't be troubled by it.
Similarly the head of any given branch is found by specifying the branch
tag itself. I believe this works just fine today in 1.10.8.
I can't fathom any reason for knowing "TBASE" (aka "TSPLIT") either.
For branches which split from the trunk this is of course redundant and
for branches which split from other branches it is, IMO, rather
meaningless. If you really want to know the base of a parent branch
then you can find it easily enough (see bellow) once you know the name
of the parent branch, and you can iterate until you hit the trunk if you
want to know the point at which the current branch was originally forked
from the trunk.
"PHEAD" is of course potentially useful and should probably be
implemented. Its use would simplify the merging of changes from a
parent branch when that branch isn't the trunk and when one doesn't want
to have to depend on knowing the name of the parent branch. (eg. when
tracking current development in a private project branch). (I think you
still need to use a pair of inch-worm tags to do this kind of tracking
properly.)
What is necessary, and still missing from even the recent proposals
(though IIRC it was mentioned at least once in this forum in the past),
is a way of finding the base point of a given branch when there's no
working directory from whence to derive the branch name when "BASE" is
specified (eg. to find the delta between base and head of a branch using
"cvs rdiff"). In theory one could do something like concatenating the
branch name and "BASE" with a dot ('.') in between, for example
"BRANCH-TAG.BASE". Given the nature of CVS' magic branch numbers it
might also make sense to allow ".0" to (also) represent the base of the
branch, eg. "BRANCH-TAG.0".
In addition I suppose one could also swap/extend the meaning of a single
'-r' in "cvs rdiff" if the tag given is a branch tag (i.e. then it would
represent all the changes on that branch). This doesn't eliminate the
need to have a way to specify the base of a given branch though.
so, in the end the only new "symbolic" tag I see a need for is "PHEAD".
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
