> > > Now you have a heavily modified project. No single file has been modified in
> > > every branch. But you want to (somehow) get the list of "project branches" --
> > > what versions branched from what original versions, nestings (if any), etc.
> >
> > No, but you could. If you could guarantee that any directory created on the
>project
> > always has a file created with it. Say, ".alwaysthere". Do it as a convention or
> > convert an old repository. Assuming you always operated on directories from then
>on,
> > you would only have to check a single file per directory.
>
> Won't help. That file won't be modified in any version; checking it will do
> nothing more
> than checking any single file. It will tell you the list of branches, but
> nothing about
> the nesting order (unless there's more going on than I know of).
*** Manual procedures can create a file modified in every
branch. Here's what I do:
Over the last year, I have fallen into the habit of always having a file
called "status" in my source tree. More recently (3 months) I have
also started using a file called branch-status.
Whenever I create a branch, I do
cvs ci -f *status
or, basically
cvs ci -f status branch-status.
I usually write a note mentioning the name of the branch
that I am creating, what I am doing on it. I also try to
mention the parent branch, the branch that I am branching
off. (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.)
Similarly, I may do
cvs ci -f status branch-status.
when I merge from a branch into the development branch,
or when I stop working on a branch, and expect to
do no more work on it.
I'll do simply
cvs ci -f status
entering a log message only in the status file,
for statuses that do not involve creating a new branch.
Things like "The tag XYZZY tests pretty completely
on Solaris, but fails some tests on LINUX". Basically,
a way to expand on cryptic tag names.
By doing this I have been able to do away with
other vague attempts to attach comments to contour
and branch tags. These other attempts, such as placing
such comments in README.cvs-tags, fail because
of branching and merging.
To get a full picture, just
cvs log status
or
cvs log branch-status
for an understanding of the branch structure.
*** This should be automated
Yes: you can figure out the parent branch by reading version
numbers in the log, but it is a pain to do so. The branch-status
file collects it all in one place. If you have entered comments,
great, hopefully they are accurate. If no comments, well, at least
the branch version numbers are tagged to the always present
status and branch-status files.
It would be nice to have PARENT(branch) as a "function".
Similarly, the status and branch-status files are just
kluges to make up for CVS's inability to attach comments
to tags.
Similarly^2, notes about the state of branches, like
"Branch XYZZY has been merged, and should have no further
work done on it" should also be enforced.
