C.R., did you read
Ron's article,
and the other links I give at the top of my document? Ron's article
is probably the best introduction to this stuff. But, here we're not
talking about testing periodic Dev -> Staging -> Production releases,
we're talking about creating two ongoing parallel lines of
development, one on the trunk, one on a branch. So the mechanics are
what Ron describes as the "two branch" method.
You always want to place branch tags across the whole
project, never just a few individual files. If you want, you can tag
only a few individual files in order to do merge operations across the
two branches, but when creating the branch you'd better tag
all the files.
One thing I'm foggy on, is how to best keep track of what changes
you've already merged from one branch to the other, and which ones you
haven't. (Incidentally, I say "branch" all the time when I mean
"branch or trunk". The trunk is really just another branch.)
If you make a change on your OpenACS Fixes branch, then presumably
you're always going to want to merge all those changes back to your
Custom branch. So my gut tells me you probably just want to
periodically tag everything on the OpenACS Fixes branch with
a myproject-openacs-fixes-2001-11-01 tag or something
like that, and merge it all into your Custom branch.
Where it gets hairy is merging changes from Custom to OpenACS Fixes,
because presumably you only want to merge some of those
changes across. I don't have a good answer for that, I think I'd have
to do it for real for a while in order to decide how to cope.
But when merging from Custom to OpenACS Fixes, I suspect that one way
or another, you're going to end up with a whole bunch of random tags
saying "fix-4239-blah-blah" scattered all over various files. I think
you'd want to place tags just on the individual affected files in that
case, not the whole checkout, but I don't remember for sure. All
these random tags everywhere do sound kind of ugly, though. This
might be a good reason to instead make all your bug-fix changes in
your OpenACS Fixes branch first, and then merge them into your Custom
branch, rather than vice versa. That way you'd only ever be merging
in one direction, from OpenACS Fixes back to Custom, which should help
keep things simpler. But again, my thinking is kind of foggy on this,
and in practice, no matter how much you plan to only do merges in one
direction, eventually you're going to modify something on the "wrong"
branch and have to merge in the other direction, too. But limiting
the number of such "wrong direction" merges may help to keep things
manageable.
