Among the Many Plusses:
1. ACL granularity: although you mentioned this, I wanted to promote subversion for handling this gracefully; if anyone has maintained pserver repositories, yes uggh
A. Scalability: imagine the terror when the repository outgrows the partition or the disk(s) -- oh, using LVM? That helps, but still... :)
*. Many others: be creative... we have different home directories, right? But, they're all in /home -- so it depends how you define a project. Since you see foo & bar as separate projects, then yes, although if they were flavors of fubar then we'd have a different story.
Downsides? more sheep to count when going to sleep?
One Last Idea: Maybe it is not so easy to move pieces between repositories (as it is to move pieces between "projects" if they're in the same repository)?? I'm not as experienced at SVN as I am with CVS, unfortunately, so I'll expect other responses... but if your projects share components then this may be warranted, see below.
The only other dowsides I can think of off-hand relate to obscure narrowed decisions about deployment, for instance if someone put a bunch of projects and their shared libs into one SVN, so it could most easily be [re]deployed... and then that was never cleaned up for some legacy reasons and layers of crufty dependencies built on top... heh. Sounds "agile"? ;)
OTOH, that method fits with using a VCS for backups, where the flow is ...production->VCS...
rather than ...VCS->production...
For the latter, I would hope to see some sort of build system in production environments.
cheers,
Ben
On 5/31/06, larry price <[EMAIL PROTECTED]> wrote:
is it better to have one big repository with multiple projects, or
should each project get it's own repository?
one big repository is easier to backup and easier to screw up,
multiple repositories can be treated with fine grain ACL's
which is better.
which do you prefer.
_______________________________________________ EUGLUG mailing list [email protected] http://www.euglug.org/mailman/listinfo/euglug
