[ On Sunday, March 26, 2000 at 12:41:17 (-0600), Michael Gersten wrote: ]
> Subject: Re: Proposed new aliases, like HEAD
>
> "Greg A. Woods" wrote:
> >
> > 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.
>
> Because, at any given point, it would be nice to be able to see what has
> changed since the last branch on this file, as well as what has changed
> since it left the main trunck.
>
> Often they will be the same, but perhaps, not always.
OK, but *why*? What development method causes you to creat branches
from branches and still gives you reason to want to know what has
changed from the time the current branch left the trunk? Is there any
reason why you can't just use tags to mark the branch points for these
more complex cases anyway?
Sure it might be "interesting" or "nice", but is there any real reason
for doing this? At least until the time these pseudo-tags are given a
naming pattern that prevents them from ever clashing there is reason to
avoid adding additional pseudo-tags that will be infrequently used.
> 1: The trunk might not be "1". 'cvs commit -r 2.0' will make it '2' for old
> files, and '1' for new files.
To put it bluntly: "Too bad, so sad." I.e. don't do that! This has
been warned against and documented as unsupported for a *long* time
(despite the fact that some ``helpful'' participants in this forum
continue to suggest it to those who won't take no for an answer).
That said I'm not so sure that simply using "1" won't work anyway. Have
you tried this?
> 2: If you have just imported files, the trunk is 1.1.1.1, and a branch.
Don't use branches in vendor-branched modules. They only lead to
confusion. BTW, the trunk in a vendor-branched module is still "1".
The vendor *branch* is a branch, though it is a magical branch. The
sole reason for using vendor-branched modules is to enable the special
conflict detection code in CVS. If you don't want to do that then don't
use vendor branches!
However if you want to use branches and at the same time want to track a
vendor release then you should create an "ordinary" CVS branch for the
vendor version and check it in normally on that branch, and do your own
merging and conflict detection of course....
> 3: Please tell me how to make a "TRUNK" tag for the top of the trunk? Make
> sure it works for 2.0, 3.0, vendor branch (unmodified) files, etc.
See question 1.
> > 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.
>
> If you know the branch tag. How can a script determine this?
How can you not know the branch tag!?!?!?
If the current working directory is checked out on a branch then "cvs
status" of some file will show the branch tag's name quite clearly.
> Looking in "CVS/Tag" doesn't necessarily tell you the tag of the file, only
> the tag from the last module update. (You can have different files checked
> out from different places).
Huh? I'm not sure what you mean here. The manual is pretty clear on
the definition of the CVS/Tag administrative file:
>From "Node: Working directory storage":
`Tag'
This file contains per-directory sticky tags or dates. The first
character is `T' for a branch tag, `N' for a non-branch tag, or
`D' for a date, or another character to mean the file should be
silently ignored, for future expansion. This character is
followed by the tag or date. Note that per-directory sticky tags
or dates are used for things like applying to files which are
newly added; they might not be the same as the sticky tags or
dates on individual files. For general information on sticky tags
and dates, see *Note Sticky tags::.
However a script should use "cvs status" to determine the branch tag,
not the contents of the *private* CVS administrative files. They are
documented so that an administrator can find and fix damaged working
directories, not as an API (the manual is slightly more lax on this
issue, unfortunately).
> I want to do a cvs diff from something that is two levels down in the
> branching, to see how it has changed in the full development from the last
> known good commit.
I'm not sure what you mean here. Do you not have tags marking the last
"stable" release that can be used to do the diff regardless of the
current branch structure? If not, why not?
> Incidently, I didn't see any way in your letter to determine the name of
> the parent branch, or to tell if the parent branch was the trunk.
Externally there's no safe way to do this. However internally CVS can
do this quite easily. (the issue being of course that every file can
have a different version ID)
Generally speaking these kinds of issues should be solved by using a
strucutred naming convention for your branches.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
