"Butlin, Jason \(UK - Epsom\)" <jbutlin@deloitte.co.uk> wrote:
> The alternative approach would be to place the trunk, branches and tags
> directories above the project levels. This would make it easier from a
> management point of view, in that everything is controlled from a single root
> point. However, you then get the issue (if it is an issue) that creating a
> branch for a release of projectA would also include the files of projectB at
> that point in time, which could be in any sort of state. I realise this is a
> cheap copy, but if a developer were to checkout a branch for bug fixing
> projectA, they would also get the unnecessary code for projectB.
I'm in the process of migrating our CVS repository to Subversion, and
we'll be facing a similar (though not identical) problem. I plan on
doing a write-up on our solution as we go and making that available at
the end.
Our situation is that we have one repository that has somewhere around
300 projects in it. About 12 of them are libraries that aren't
released but that are used to link other projects against. Most of
the rest are separately releasable tools, some single-source perl
scripts, and others big programs with 10s of thousands of lines.
There are many controlled interdependencies among the projects, and
the interdependencies are all managed through variables in each
Makefile and through a release specification file that happens to be
an XML file. A few well-encapsulated tools know the arrangement of
the repository can therefore calculate relative paths of other tools.
Our development model is that everyone has the shared "packages" and
"tools" directories checked out all the time and, otherwise, checks
out only what they need.
For purposes of example, say we have three projects and one library
upon which some of the projects depend. Our repository will look
something like this:
main/
frame/
software/
library/
project1/
project2/
project3/
trunk/
software/
library/
<library files>
project1/
<project 1 files>
project2/
<project 2 files>
project3/
<project 3 files>
branches/
branch/
branchpoint/
software/
project1/
...
work/
software/
project1/
...
releases/
product/
version/
os/
software/
library/
project1/
...
The idea here is that every place a copy of something from some
revision on the trunk may appear (branches, tags, releases, etc.), all
components that are present will be in the same relative structure
under "software" as they are in the trunk. The "frame" directory
contains empty directories for all projects in the system. All users
would initialize their working copies by checking out frame. When
someone wants to work on a specific project, they go to that project's
directory and those of its dependencies in their working copy and
switch to the trunk or a branch as needed. When we release, we copy
from trunk into the appropriate directory under releases, including
all nodes that are needed but nothing else, thus getting around the
problem you mention. The trunk represents the current development
state of every project. The entire trunk is checked out daily into a
read-only reference area so that people can easily look at code from
other projects while they are working.
We have some tool support to help us with this. Most of the tools
don't yet exist, though they are fully designed. I will make them
available when they are finished in case anyone wants to use them or
take code from them. The three main features of the tools are
checking the integrity between frame and trunk, performing all mkdir
and copy operations required to create a subset of the tree in a
separate directory (for creating branches, tags, releases, etc.) and a
wrapper around svn switch that replaces the part of the URL between
"main" and "software" with the specific path components. This tool
will use the APIs directly (and will probably be written in Perl) and
will allow all the necessary intermediate paths and copies to be set
up in a single transaction.
Gratuitous remark: our branch structure has branchpoint and work to
make diffing and merging a little easier. I don't want to rely on
--stop-on-copy for finding the revision at which the branch was
created because that breaks down if you rename directories as part of
a big repository reorganization. I've only done three or four big
repository reorgs in 9 years, but the next one will come immediately
after running cvs2svn to initially create this structure. We tag all
branchpoints in CVS now, so setting up this structure will be easy
after running cvs2svn and will enable us to continue working on any
branches that may exist at the time of the conversion if we so choose.
I don't know whether this information is useful to you or not, but it
presents an example of a layout that is slightly different from the
usual layout to handle a somewhat different style of development. I
should add that we've been working this way under CVS for years, and
it has helped make it possible for us to manage this large number of
projects with a very small development team.
I've sketched this out pretty quickly here since I'm at least a few
weeks and possibly a few months from having this implemented. (I only
have a few days of work left, but I'm squeezing this in between other
things!) As I said, I will make a more formal presentation of this
available once it's done.
--
Jay Berkenbilt <ejb@ql.org>
http://www.ql.org/q/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Feb 19 23:24:44 2005