Re: Repository base for another repositories

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:

http://subversion/repos/framworks/myframwork/trunk
http://subversion/repos/projects/myproject/trunk

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
multiple projects.

On Mon, Jul 13, 2009 at 1:42 PM, Alejandro Moraga <moraga86_at_gmail.com>wrote:

> Hi,
>
> 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
> repository?
>
> Thanks,
> Alejandro
>

-- 
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2371282
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].