[ On Monday, March 27, 2000 at 08:38:38 (-0600), Cameron, Steve wrote: ]
> Subject: RE: Proposed new aliases, like HEAD
>
> Greg woods wrote:
>
> [...]
> > 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')
> >
> I can see how that interpretation of HEAD could be useful, so that
> scrpts may operate on arbitrary branches without having to know
> what branch they are on, or in a sandbox containing modules from
> different branches. (if that's not using CVS "incorrectly" :)
>
> My view of it was that currently HEAD appears to mean the head
> of the trunk, with the one exception being that "cvs diff" treats it
> differently. So my reasoning was to "fix" that one excetption, is all.
The question is how many times have you ever used "HEAD", and how many
times with "cvs diff" and how many times with other commands?
I mostly use it with "cvs diff" and I've been very annoyed when it
doesn't work the same way with "cvs log", for example.
Admittedly the current definition of "HEAD" in the manual is very vague:
`HEAD' refers to the most recent version available in the
repository
and makes no mention of branches. One could even make the assumption
that this means the same as the concept of "top" from SCCS. However
even in SCCS it's possible to divert this to mean the top of a given
branch (from the SysVr3.2 manual):
-t Used to access the most recently created delta in a given
release (eg., -r1), or release and level (eg., -r1.2).
As I recall the original AT&T SCCS would always get the truly most
recent delta (i.e. the delta with the most recent "sequence-number")
regardless of what branch that delta was on if a '-r' wasn't given and
if there was no "default" SID specified by the SCCS file's 'd' flag.
(GNU CSSC seems to want to get the highest revision on the trunk if no
release is specified and no 'd' flag is set.)
Placing special emphasis on the meaning of the trunk makes lots and lots
of sense in SCCS, less sense in RCS, and much less sense in CVS (unless
of course you're working in a vendor-branched module where the trunk is
the equivalent of the "local" branch). The trunk can be given one of
many quite different meanings in a module where branches are used and it
all depends on how your process works.
> > and make "BASE" always refer to the base of
> > the current branch (or the trunk if there is no branch in effect).
OOPS!!! I seem to have forgotten what "BASE" really means.
I didn't mean to change that meaning so perhaps the base of the branch
(i.e. the point in the parent branch where it was forked) should be
referred to by a new pseudo-tag such as "BRBASE".
> > 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?
>
> [smc] How do you do that?
>
> [smc] I'm pretty sure
>
> cvs rtag -b -r 1 TRUNK everything
>
> won't work... right? It will create a branch that's called
> TRUNK, but it won't _be_ the trunk.
Indeed so just skip the '-b'. You don't really want it to be a CVS
magic branch tag but rather just the real RCS trunk branch identifier.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
