Repository design suggestions

[Martyn Klassen]

I'm trying to design the repository structure for a group of projects under 
team development and was wondering if anyone with more experience might have 
some recommendations for an efficient design.

The projects are extensions to a commercial application and consist largely 
of text files (macros, menus, c-code, etc.). To be useful, tested/debugged, 
the project files have to be in the directories dictated by the application. 
Initial I thought this wouldn't be a problem, you simply make the repository 
tree structure the same as that used by the application and check out a 
working copy on top of the directories used by the application. Of course 
releasing the project becomes difficult because "cvs release -d" is not 
smart enough to only delete files under cvs control, but more problematic is 
the issue of when you need two or more projects checked out at the same 
time. CVS will not allow you to check out files from two trees in the 
repository to the same working directory. You could put all the projects 
into one tree in the repository and use the module definition to check out 
different groups, however when you have 100+ files in a group it gets 
tedious to define and maintain the module definitions, and seems apt to 
cause many problems. The only other idea I could come up with was to have 
separate trees for each project in the repository and use install and 
uninstall scripts to create and destory links in the application directory, 
but the application has the annoying tendency to break links when it 
modifies a file making this less than ideal.

I'd appreciate any insights on possible design solutions that others have 
found to work.

Martyn

_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.  
http://join.msn.com/?page=features/virus