Re: Multiple repositories per project

2009/2/3 <vlad.tepes_at_gmx.net>:
> hello list,
>
> in the company i work we have the questionable policy of creating three repositories for each project by default. in addition to a repository named 'src' we will also have one named 'doc' and another named 'data' (the latter being empty for almost all projects).
>
> i have the feeling that this might be a case of over-engineering (and to be honest i think it's dumb). but i have no technical arguments against this policy either.
>
> so, is it dumb, is it ok, or is it not worth arguing?
>

Subversion, with FSFS backend (but not with BDB one), works fine
with a lot of small repositories.

The "pro"s are:

1) it is easy to set up

E.g., for httpd it is sufficient to use SVNParentPath directive. I have
seen above that you are using svn+ssh, but I have not such
experience, sorry.

2) you can avoid using path-based security (that consumes CPU
and has its limitations)

See, e.g. "Disabling path-based checks" in the SVN Book,
http://svnbook.red-bean.com/en/1.5/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authz.pathauthzoff

See also issue 3242
http://subversion.tigris.org/issues/show_bug.cgi?id=3242

3) it is closer to CVS storage model, where every subdirectory exists
independently of its neighbors

Maybe that is the cause of your policy.

4) it is easier to alienate, archive those repositories, e.g. if all code that
you develop belongs to your customer

Do you have such requirements? Do you have consistent configuration
management policy, or each project/customer can have its
independence?

5) you can have a different set of repository hooks for each repository

6) it is easy and straightforward to merge several repositories into one:
svnadmin load --parent-dir
helps here:
http://svnbook.red-bean.com/en/1.5/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate

Though a known drawback of such operation is that you will lose dates
continuity - beware of that.

The reverse operation requires dump of all + filtering, and thus may be
not that easy, but that also depends on your development history. Also
svnsync since 1.5 should support mirroring a subtree of source
repository.

When I started using subversion several years ago, I also have set it
up with several repositories. I have merged some of them into one since
then, but I still have several ones.

E.g., our sources and official project documentation are in separate
repositories, that have different layout and policies.

The "contra"s:
 - see Andrew Reedick's mail.

My list:

a) Some operations are not possible when you have independent repositories.

b) Relative externals introduced in 1.5 made life easier. Also, note that file
externals that will come in 1.6 will not work across different repositories.

http://subversion.tigris.org/svn_1.6_releasenotes.html

c) When you have a lot of small and scarcely used repositories, some
administrative overheads are increasing. That is, you have to administer,
backup, replicate and verify a lot of small ones, independently of the load.

Also, while you are at it, please check that all of your repositories have
different UUIDs (look at `svn info` output). Having the same UUID is a
common mistake for some administrators that are managing a lot of
repositories.

Best regards,
Konstantin Kolinko

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1104099

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-04 22:23:56 CET