Re: Request for Help: Bulk adding new files to a branch

[Eric Siegerman]

On Wed, Mar 06, 2002 at 04:54:53PM -0800, Terry Spafford wrote:
> We have decided that we don't care about the history of the files from 
> the old CM system, BUT we want the current versions of all those 
> branches from the old CM system checked into CVS as branches off of the 
> current project. (Since they were all derived from this trunk at some 
> point and we want to easily be able to compare them together when needed).
> [...] 
> Note that we are never expecting to have to merge any of these customer 
> branches back onto the Trunk; we just want to be able to compare the 
> code CustomerA has with what CustomerB has and make changes to their 
> code to fix bugs and/or add improvements as needed/requested.

CVS branches are better at handling temporary branches in
development than they are at handling permanent -- and thus
permanently diverging -- variants.  If nothing else, in sheer
mechanical terms -- the more revisions you commit to a branch,
the slower it gets; the trunk doesn't slow down that way.
(Recall that the trunk revisions are stored as reverse deltas
from HEAD, whereas branch revisions are stored as *forward*
deltas from the branch point.)

Since you never expect to merge, one could think of your code
base as consisting of not one application, but a collection of
(presumably) very similar ones.  Given that, I don't believe they
all belong together in CVS.

Better to keep customer's version of the code in its own separate
CVS module; then, if appropriate, use branches within each of
those modules for their more usual purposes -- ones that *do*
ultimately end up merging back into the trunk, like bugfix
branches, experimental lines of development, and such.

I know that this suggestion goes very much against the grain.  It
does for me too; I've thought carefully before recommending it.
But I think that in your situation, it might make sense.

Ideally, of course, you'd refactor the code into common and
per-customer modules, so that the former need be maintained only
once.  That would give you a much saner code base, which could
reasonably be thought of as one application with customizations.
But practically speaking, if that's just not going to happen,
thinking of it instead as N related applications might be more
useful, as hard a pill as that might be to swallow.  (And if
you're really lucky, perhaps an argument along those lines might
persuade the powers that be to fund a refactoring effort :-)

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
"Outlook not so good."  That magic 8-ball knows everything!
I'll ask about Exchange Server next.
        - Anonymous