[ On Wednesday, March 29, 2000 at 17:24:44 (-0600), Cameron, Steve wrote: ]
> Subject: RE: Proposed new aliases, like HEAD
>
>
> > I'd be interested but don't bother to do it just on my account alone --
> > I'll be able to to the same when I get some free time too....
> >
> [smc] Is there anything lost by doing this, that is.
> is there anything that can be done with the current
> implementation of HEAD that, were it changed
> in this way, could not be done in some other way?
The only thing that would be "lost" would be the documentation -- it
would need updating too.
> Hmm. I jsut tried the following:
>
> cvs co -r 1 everything
> cd everything
> (edit some files)
> cvs commit -m 'changed some stuff'
>
> And, oh miracle! it worked! I really didn't expect that,
> since ordinarily, giving revision numbers like that is
> definitely not akin to giving a branch tag...
Yup, like I said -- it's really just that simple! ;-)
Remember that in RCS parlance the lone "1" is a real RCS branch number
that just happens to indicate the "trunk" (well, at least that holds
true so long as the release number on the trunk isn't bumped).
A "branch tag" in CVS is magic and has a ".0" inserted before the level
number, which of course is impossible to do for the trunk without ending
up with a leading '.' (eg. ".0.1") which is why it won't work right.
The only time you should really ever have to refer to the trunk
explicitly though is with "cvs update -j ... -j ..." or with "cvs diff"
or perhaps "cvs log". It's normally the "default" when you're doing a
checkout (or when no sticky tag is in effect), which is another reason
why I think hard-coding a magic pseudo-name for the trunk into CVS isn't
really worth the hardship.
> But hang on a sec. I just tried this:
>
> echo aaaa >> somefile
> cvs commit -r 2.0 -m whatever somefile
> cd someplace else
> cvs co -r 1 everything
> cvs status somefile
>
> I got revision 1.3 of somefile, not 2.0...
Ah, well, that I sort of expected. "cvs co" is a really bad example of
how not to use the "TRUNK". If you want to check out the trunk then
just don't specify anything -- that's the default! ;-)
The tests I did with "cvs log" showed that '-r 1' worked as expected and
always found the newest 2.x revision.
> So, for "cvs co", -r 1 doesn't appear to work in such
> a way that it may be used as a kind of branch tag for the trunk.
> (I won't say that it works wrong, 'cause I don't know how the heck
> it's supposed to work...)
I think the behaviour you got is "right". It's what I expected at least
for 'co' because that's what RCS would do -- get the top revision for
the specified release. All of this is meaningless in CVS though so
maybe it's not quite "right".
Unfortunately further tests indicate that "cvs diff" falls prey to the
old RCS behaviour (ala "cvs co") too though.... I guess that's to be
expected too because really all that happens is a "co -p" in order to do
the diff.
Bumping the release number in CVS is in effect a mixing of different
kinds of magic and you can't always expect the result to taste so good.
It makes me wonder though if a magic pseudo-tag could even be
implemented right in the case of bumped release numbers without jumping
through a whole lot of hoops. I can't at the moment think of a way to
inidicate to RCS that the top of the trunk should be always used without
getting the "default branch" stuff involved and messing with that
doesn't work well with CVS either since it's effectively reserved for
internal use only.
I guess if you are bull-headed enough to want to bump your release
numbers (or stuck with a repository that was copied from an old RCS
repository where this was the "right" way of doing things) then you can
always just manually pick the right number to use when creating the
TRUNK tag and indeed if you are insisting on continuing down such a
questionable track you can still move the TRUNK tag every time you bump
the release number.....
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
