There are a couple of other things you might consider...
1. Security. It can be easier to maintain security boundaries if you
segregate at the repo level. It's not impossible to isolate parts of
a repo from an access standpoint (even if using the svn:// protocol),
but sometimes its easier to follow the natural boundaries that a repo
represents.
2. Backup. If these repos are going to get big, backup can be easier
if you have a number of medium sized chunks instead of one big one.
3. Sharing. You should try to avoid situations in which you want to
share stuff across a repo boundary. The only work-arounds are manual
copies between repos (yuck) or externals, which can get messy to
maintain over time (think spaghetti). So if there is any chance you
will be sharing assets between clients, think of using a single repo.
Otherwise, I think one repo per client might be a good compromise.
--Tim
On Nov 13, 2006, at 8:13 AM, Jiho Han wrote:
> Not sure. Are you saying that a repository can never go faulty by any
> user actions? (granted we implement all the security measures you
> mention)
>
> The other side of the issue is political I guess (perhaps a bigger
> factor than the techincal). It'd be easier for me to say, here's your
> repository, go do whatever you want, than to say, here's your project,
> and any time you want to make changes to it (add users, permission,
> etc.), let me know.
>
> Other than that, would there be a techincal reason why a single
> repository might be a better option?
>
> -----Original Message-----
> From: Andy Levy [mailto:andy.levy@gmail.com]
> Sent: Monday, November 13, 2006 10:51 AM
> To: Jiho Han
> Cc: users@subversion.tigris.org
> Subject: Re: Re: How many repositories question
>
> On 11/13/06, Jiho Han <jhan@infinityinfo.com> wrote:
>> Well, you guys are not making it any easier :)
>>
>> I'm leaning towards having multiple repositories just because it'd
>> create boundaries for each client/projects. If the only advantage of
>> having a single repository is being able to merge between projects,
>> then I don't think that's a huge win over clean separation in this
> case.
>>
>> Although I can see how things can be overwhelming with 100s and 100s
>> of small repositories, if one pm/dev team messes up a repository,
>> then
>
>> only that team is affected.
>
> Messes up the repository in what way?
>
> Only give each pm/dev team access to the sections of the repository
> they
> need access to, and definitely don't give them access to the
> filesystem
> where the repository actually lives. Once these 2 things are locked
> down, what level of "messing up a repository" are you concerned about?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 14 18:14:41 2006