"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?
Well, from another user of this list (Andy Glew):
(I usually work off a "main development" branch which is
not the trunk, with task branches off this. More rarely, I do
a task branch off a task branch off my development branch.)
===
In my own experience, I've (twice) been making changes to a branch from the
trunk, and then made a sub-branch off that (permits me to easily discard
changes that don't work).
I'd like to be able to tell both 'How has this branch changed on this
investigation/exploration', and 'how has this all changed since the trunk'.
I now know how to do the second.
If I'm not in a script, and I branch on a per-module basis, then I have a tag
at the base of my branch for the 1st. That doesn't work if I am in a script,
or if it varies per file.
> 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!
Doesn't help.
I create a CVS directory with 'cvs import'. That's (I hope) the only use of
vendor branches. I then make changes, and as far as I know, I'm changing 1.1
into 1.2.
Later, I have some files 1.1, some 1.2, some 1.5, etc. I make a branch, and
edit things.
My 1.2 becomes 1.2.2.1.
My 1.5 becomes 1.5.2.1
My 1.1 is really 1.1.1.1, and becomes 1.1.1.1.2.1.
If you can eliminate that, and permit me to branch a 1.1 into 1.1.2.1, then
that won't be a problem any more.
Ideally, the vendor branch should only be used on imports -- importing a
directory twice would put the changes onto the vendor branch, and no other use
of any cvs commands will affect the vendor branch. But that's not how it
actually works.
(Ok, if I explicitly say 'update -r1.1.1', then give me the vendor branch.
Otherwise, don't.)
> 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.
>
> > 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?
I do, generally, mark my branches this way.
But it sounds like the only way to get a script to be able to know all this is
to manually code a 'check every file, don't use CVS's recursive features, but
do your own recursion'.
> > 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)
And so why can't I use a special tag to tell CVS to determine this on a
per-file basis?
