If the code is being shared between the two "repositories", you are probably
not thinking of "repository" as much as it is a "project". For that, you
really don't need separate repositories -- even if the permission to commit
between the two projects will be different.
I normally simply setup separate projects in the same repository. In your
example, you'd have a framework "project" and then have other projects that
might share that code, or use the framework. You'd use a layout like this:
Your framework is under the frameworks area while your projects are under
the project area. Note that all the frameworks and all the projects share
the same repository (http://subversion/repos). They're simply located in two
different areas of the repository structure.
The limitation of using the same repository are few:
- Let's say that someone in a project commits a 20 gigabyte wad of a file
that really shouldn't be there. If the framework and project were in two
separate repositories, you'd be able to take down the project repository
without taking down the framework repository. However, what's the likelyhood
you really need to do this?
- Really, really anal people don't like the fact that Subversion
repository revisions aren't for a single project, but are for the whole
repository. Someone in a project commits revision 1,234, and then someone in
Framework commits revision 1,235 to 1,239. The next revision for the project
will be 1,240 which makes some people upset. It's not that there's anything
wrong with skipping repository revisions when you look at the project. The
repository revision is still unique and gives you a snapshot in time of the
repository. It's just not in consecutive numeric order. If you can get over
the fact that revision numbers will be shared between all projects and
frameworks in your repository, you'll be fine.
- Resource issues. If you separate out your repositories, you can use
multiple processes to service them instead of a single process. However,
Apache httpd already pretty much does this and Subversion isn't a resource
hog. You're biggest concern should be network bandwidth.
- Security. Separate repository instances can allow you to set read/write
security separately for each repository. Actually, you can do this with
separate projects. It's just a bit messier, and I haven't been able to do
this with LDAP. However, you can control "write" permissions with pre-commit
triggers. In most situations, you probably want your developers to have read
access on the whole repository anyway, and if there is any restrictions, it
is on the "write" side which are handled easily with pre-commit triggers
based upon repository directory/file name.
- Hooks. Each repository can have its own set of hooks, but I have never
had a case where I have to use one set of hooks with one repository and
another set with another.
Meanwhile the advantages are many: Much easier setup and maintenance. Plus,
it is much easier to copy, move, and even share code via svn:externals if
everything is in the same repository.
So, the best thing to do is to simply have your repository setup to do
On Mon, Jul 13, 2009 at 1:42 PM, Alejandro Moraga <moraga86_at_gmail.com>wrote:
> I already have a repository. I will start the second repository, this
> project must use the first repository because it is based.
> The first repository would be the engine and the other was specializations.
> Is it possible? Have a repository that uses and updates from other
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-14 19:04:26 CEST