[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Request for Help: Bulk adding new files to a branch
From: |
Eric Siegerman |
Subject: |
Re: Request for Help: Bulk adding new files to a branch |
Date: |
Thu, 7 Mar 2002 13:04:22 -0500 |
User-agent: |
Mutt/1.2.5i |
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