> My company recently selected Subversion as our new source code control
> tool. We have several hundred developers spread around dozens of
> departments. I've been playing around with the tool and I am starting to
> understand some of the basic functions. However, I'm not getting a good
> feel for how the repositories should be configured. I am thinking of
> setting the repositories up like svn\repositories\<department>\<group>,
> for example:
> One question is should projectA and B be repositories or just
> subdirectories under the group1 repository? Project A & B do not need to
> share files, so I would initially say repositories, but if we did that
> company wide, we'd have thousands of repositories. Should that be a
Every repository constitutes an overhead in maintainance, diskspace,
backupspace etc. Splitting the up reduces the impact of problems with one
repository though, since all others still work. It also opens the possibility
to spread load among servers.
Here, we have a handful of repositories, mostly for unrelated areas: artwork,
documentation, internal sources, external sources. This is pretty much split
at borders that files will probably never have to cross.
Oh, and we have one more repository: used for testing, with rw-acces for
everyone so people can test how things work before they try them on live
repositories with relevant data.
> If we go with them as subdirectories, then our concern is that
> we have repositories with thousands of revisions, which might confuse
> users (the revision of my project changed, but I didn't make a change)
> and be inefficient.
Users will have to wrap their head around the meaning of Subversion's
repository revision number, there is no way around some initial confusion in
that context, no matter if you split your code into several repositories or
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Feb 15 11:19:04 2005