I've been following this thread a bit and I just can't help but post too
:)
On the topic of creating a magic ever-present branch 'tag' (at least as
far as a user is concernced), I assume this is so one can easily deal with
running a 'cvs diff' when the local context is the branch, and make 'cvs
update' easier without going through the current 'workaround' process of
cvs update -A
cvs rtag foo
cvs update -r branch
cvs update -j foo
The quotes are around the 'workaround' because at least this method enforces
you to create a tag, which (especially when dealing with merges) will save
your ass later if anything goes wrong.
As for the others, I'm all for them, its a real mess when working with a
branch of a branch system and you want to script something. I kind of wish
the non-branch tags were at least localized to the branch they are on and
treated more seperately behind the scenes. The list of tags just gets
insanely long. A naming convention helps, but still, yesh tag central.
Without going into what to call them specifically (these will just be
examples like the others thrown out in discussion earlier) them I'm all for
'magic tagnames' with the following unambiguous meanings:
TAIL_REVISION : the oldest version of the current branch (which
coincidentally is the original file in the parent branch before the branch
occured)
PARENT_HEAD : a magic branch tag, which corresponds to the parent
branch. If there is not one (i.e. you are already on the trunk), the
operation fails.
PARENT_TAIL : a magic branch tag, which corresponds to the
TAIL_REVISION of the parent branch. If there is not one (i.e. you are
already on the trunk), the operation fails.
TRUNK : a magic branch tag, which always refers to the most
recent version of the files on the trunk branch
Am i missing anything here? I suppose the question becomes, does a
branch 4 levels down ever need to access the parent of the parent (which
would be neither PARENT_HEAD nor TRUNK) with any method other than standard
tagnames at this point? If you are working in some environment this
complex, I'd say you probably have a really well planend out tagging scheme
which you should use anyway. These 4 magic tags should handle like 95% of
the grunt work there is now.
Accessing a 'magic branch tag' is just like accessing any other, the
files it points to are the most recent version in that branch, etc.
I could see the following useful things happen if these were available:
Tagging files on the parent branch to coincide with when you created the
branch, if you forgot to create a normal tag in the first place. This
avoids the whole mess of using the -D date options and getting weirdness
with that when working in someplace other than the TRUNK. I love when I can
fix things 'after the fact.' ex:
cvs tag -r TAIL_REVISION branched-foo-here
Tagging the parent branch without having to know what it is called, so
that you can more easily script regular merges. ex:
cvs tag -r PARENT_HEAD branch-merged-9
cvs tag pre-merge-9
cvs update -j branch-merged-8 -j branch-merged-9
.. check changes and commit
cvs tag post-merge-9
or even just a
'cvs diff -r PARENT_HEAD' and see what's up
Diffing against the entire trunk fileset while the local repository's
state is in a branch becomes possible. Normally you need to commit
everything (you might or might not find that convenient) and switch your
context to the trunk (or checkout another copy to a dummy dir) then diff it
against the branch. ex:
cvs diff -r TRUNK
Now that I think about it, PARENT_TAIL and TAIL_REVISION would obviate
the need to ever create a normal tag to mark the occasion of creating a
branch tag. I imagine it would help cut down on the tag clutter quite a bit
by having these magic tagnames. Now if there was a nice way to cut down on
the necesity to create tags to mark regularly recurring merges . . .
----- Original Message -----
From: "Michael Gersten" <[EMAIL PROTECTED]>
To: "CVS-II Discussion Mailing List" <[EMAIL PROTECTED]>
Sent: Thursday, March 30, 2000 11:43 AM
Subject: Re: Proposed new aliases, like HEAD
> Regarding 'HEAD', and it not matching '-r 1' when the version number has
been
> increased, what about '-r 9 -f'?
>
etc
