Hi,
I'm evaluating svn as a replacement for our current source control
system and I am looking for suggestions on how to structure the
repository to address specific issues (to follow). I've only been
lurking on this list for a couple of weeks, and I wasn't able to turn
anything up in the archives after about 30 minutes of searching, so I
realize the answer may already have been given. In this case,
references would be greatly appreciated.
Say I have a collection of libraries (lib1, lib2, lib3, ...) that are
shared among multiple projects (proj1, proj2, ...). Each project is
composed of some project-specific files and some number of libraries.
I would like to be able to check out a working copy of a project that
looks something like:
/proj1
proj1_file1
proj1_file2
.
.
.
/lib2
/lib5
another project might be:
/proj2
proj2_file1
proj2_file2
.
.
.
/lib3
/lib5
/lib6
.
.
.
Alternatively, the project-specific files might appear under a
sub-directory called projN_core/ in the working copy of each project.
I would like there to be only one instance on the trunk of each
library (meaning I shouldn't have to merge changes in a given library
to different instances of that ilbrary on the trunk), and I would like
to be able to branch and tag these working copies. This is something
I can arrange in cvs using the 'modules' administrative file, or in
vss by applying the concept of 'sharing' that vss has.
Based on my reading, it seems that externals would give me the ability
to compose working copies as I would like, but I would have trouble
when it came to tagging and branching.
Any insight into how to accomplish what I wish to do (or into other
repository structures for dealing with multiple projects that share
code) using svn would be greatly appreciated.
Thanks,
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Sep 28 06:19:17 2004