Felix Gilcher wrote:
>We're using both approaches, some projects have their own repository, others share one repo and both ways are pretty much equal. Both ways offer advantages of their own kind, but I would not agree to the point that having multiple projects sharing one repository renders versioning across the board meaningless in any way. The only important point is that a version number alone does not describe a checkout, it's always the tupel (versionnumber, path) that uniquely identifies an object - even in the "one project, one repo" approach.
>While we're a relativly small shop and only have like 20 developers I can't imagine major advantages of having multiple repositories, unless you have to balance the load and distribute the repositories over multiple servers.
>
>[snip]
>
>
>
The problem I see with multiple sharing a repository are:
- unless you make special allowances, you get 'trunk' / 'branches' etc
all over the place in build paths in Makefiles and elsewhere. With
project-per-repo, you can check each one out at the trunk or
branches/xxx level, and those directory names are invisible for build.
You could do something equivalent with multiple prjects per repo, but it
seems messy and harder to explain to users
- various groups of developers working on unrelated things may be having
to update all the time, even though none of their stuff is being
changed. It might even be that someone else makes a gross error and
messes up the repository, or perhaps decides to change the design of it,
without realising the effect on all developers. Having project-per-repo
seems a good way of minimising unintended side effects
- you have to manage access control on a directory basis, not just a
repository basis. This should work fine, until someone decides to change
the directory structure in some way - then you have to remember to go
and change the access control file as well. Whereas you wouldn't
normally rename a repository - access control settings per-repository
should be safe, and only have to be updated when the team changes.
- backups can be done separately if needed, or together
- corruptions or other show-stopper problems don't kill everybody's
work, only those working on the repository in question
I am not a long term subversion user, so I accept that people with more
experience with it may have other (better informed) opinions on this;
but this is how it seems to me at the moment (and we have about 9
repositories, and we have had no problems with managing them).
- thomas beale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 1 18:33:44 2005