[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Info-cvs Digest, Vol 11, Issue 3

From: Matthew Herrmann
Subject: RE: Info-cvs Digest, Vol 11, Issue 3
Date: Wed, 08 Oct 2003 16:32:55 +1000

Hi Rod,

If you don't need file merging, then I suggest creating a script which is
stored in the customisations, which automatically checks out the required
version and performs the xcopy across. We do a similar thing in our
"release" script for our software -- it checks out the version to release,
runs the test cases, compiles and packages. You may even be able to do
something more exciting using the "modules" file, though it has some strange
limitations -- so your mileage may vary. This is suitable if the changes are
quite loosely coupled.

Another approach which does what you want is a checked out CVS folder for
each customer. Every time you run "cvs up", it will get the latest updates
from the main branch. You would never commit from these folders. This is
basically a way to simulate vendor branches without going down that path.
The drawback with this is that you lose your ability to version control your
vendor files (unless you store them as a series of tar files containing
working directories).

Yet another, but more hands-on approach requires storing diff3 files, and
their ancestor. Effectively, it gives you a CVS ancestor behaviour without
the extra baggage. I use this for modifications I make to generated code,
though it could also work for cases like yours. It's only suitable where
there are a small number of files being modified, since the set-up is
explicit (far cry from xcopy).

All depends on the complexity of the customisations you're doing.



Matthew Herrmann
VB6/SQL/Java/CVS Consultancy
Far Edge Technology

-----Original Message-----
Date: Sat, 4 Oct 2003 11:06:18 -0700
From: "Rod Macpherson" <address@hidden>
Subject: Branch Manager
To: <address@hidden>
Content-Type: text/plain; charset="us-ascii"

Apologies in advance if this is the wrong mailing list but it's the only
one that looked promising.

We have a base set of files that we customize on a per-client basis.
Each client has a mirror image of the base directory structure. Each
client does not have a mirror image of the base files but rather only
those files that require customization exist in the client directory
tree. Prior to building a client we merge the client tree with the base
tree using a simple recursive copy and then build. That simple approach
is well organized and effective however there are some drawbacks.

This is not the typical branching situation since there will never be
any merging of client code back in to the main trunk. There is also
resistence to using CVS branches since everybody contributing to the
project (content developers, technical writers) must now manage branch
labels versus just plopping changes for Acme in the Acme folder. I would
really be interested in hearing from anybody who has ideas on managing
highly selective client changes for a large number of clients.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]