Re: Proper Repository setup for newbe

[Pierre Asselin]

Jeff Douglass <address@hidden> wrote:
> I am new to VCS and just started using Tortoise to control all my SW
> projects locally. I have many different SW products. Some are just a bunch
> of c files while other more advanced Windows apps are comprised of different
> libraries and and DLLs. My quesiton is how should setup vcs to handle all
> this.

I assume you'll be doing this by yourself with a private CVS
repository on your hard drive?  The first thing you should do is
gather a *source tree* of *all* your products, organized by
directories in whatever way makes the most sense.  For example, a
library with a well-defined interface should have its own subtree
with header and source files.  Do *not* put the .lib or .dll files
in there, just the *sources* and support files needed to build
them, such as Visual <mumble> Studio .dsw and .dsp project files
or nmake files.

Then put the lot into CVS with Tortoise's "Make New Module", followed
by "CVS --> Add Content" and "CVS commit".  See the FAQ at
http://www.tortoisecvs.org/faq.shtml#cvsinit .

After that, you might want to check out the "CVSROOT" module that
all repositories have, and edit the "modules" file to define subsets
of your big tree, mainly full subtrees.  That way you can check
out these subsets by themselves without the rest of the system.
See http://ximbiot.com/cvs/manual/cvs-1.11.20/cvs_18.html#SEC158 .

If possible, arrange your build support files so they work
both ways.  For example, the preprocessor flags of a library
client could look for header files under both
"..\..\libraries\mylib\include" and "C:\Program Files\mylib\include"
so they use the big tree's headers and fall back on installed
headers if you happen to be working on a checked out subset.
(Not sure that works;  if not, you'll need two sets of support
files, yecch.)


> Should I just have a single repository with different projects/modules
> for each product or have seperated repositories for each.

A single repository is usually best.


> Also what is the
> best way to handle a single product that constists of a number of different
> libraries, DLLs, and other components.

More or less by layering in directory subtrees as I outlined.  Once again
do *not* put dlls in CVS even if they are required to build client
subprojects.  Rebuild them from sources or use installed copies.
You can make exceptions for third party libraries but even those
should probably be installed and left alone.

If you have a team of developers you'll have to worry about revision
skew where a library wants to evolve faster than its clients.  You can
handle that with CVS tags, but the best solution is to not let it
happen:  keep the libraries backward-compatible or keep the clients
up to date.


-- 
pa at panix dot com