You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by dk...@micron.com on 2005/02/14 18:21:01 UTC
Repository Configuration Question
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:
svn\repositories\mfg\group1
projectA
trunk
branches
tags
projectB
trunk
branches
tags
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
concern? 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.
One other question that came up is whether or not hosting the
repositories on Windows is a bad idea or not? Most of our experience is
with Windows servers, so we are leaning that way. However, if there are
performance and stability issues on that platform, our minds could be
changed.
Any other tips, tricks, or advice would be appreciated. Thanks.
-Dan
Re: Repository Configuration Question
Posted by Ulrich Eckhardt <ec...@satorlaser.com>.
dkrobbins@micron.com wrote:
> 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:
>
> svn\repositories\mfg\group1
> projectA
> trunk
> branches
> tags
> projectB
> trunk
> branches
> tags
>
> 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
> concern?
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
not.
Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Repository Configuration Question
Posted by Tom Mornini <tm...@infomania.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've voted with 1 repository per project.
If a repository with 1,000 projects in it gets hosed, you'd lose 1,000
projects.
If a repository with 1 project in it gets hosed, you'd lose 1 project.
Even with backups, do you want the developers of 999 projects waiting
while you
restore a repository to fix an issue with 1?
On Feb 14, 2005, at 10:21 AM, dkrobbins@micron.com wrote:
> 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:
>
> svn\repositories\mfg\group1
> projectA
> trunk
> branches
> tags
> projectB
> trunk
> branches
> tags
>
> 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 concern? 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.
>
> One other question that came up is whether or not hosting the
> repositories on Windows is a bad idea or not? Most of our experience
> is with Windows servers, so we are leaning that way. However, if there
> are performance and stability issues on that platform, our minds could
> be changed.
>
> Any other tips, tricks, or advice would be appreciated. Thanks.
>
> -Dan
>
>
>
>
>
- --
- -- Tom Mornini
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFCEQTWzaKkuvKwKvcRAmKkAKCebMtDwDWdsOXLHDhvl/KtI5rZtwCffN5I
Ls4vLshPa8l8dcprKxX1dc0=
=wRx4
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org