[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

different projects sharing the same code

From: Kynn Jones <kynnjo_at_gmail.com>
Date: Fri, 20 Mar 2009 13:15:18 -0400

I'm sure that the following is a very basic question...

I have two separate in-house projects under Subversion, call them A and B,
that both use the same library C, also developed in-house. This library C,
which is a collection of several dozen files, is in fact a
Subversion-controlled project of its own right, and, to make matters worse,
it lives in a repository (lets call it rC) different from the one that holds
A and B (let's call this one rAB).
In order to deploy A and B to our hosts conveniently, I like to bundle
copies of C along with A and B respectively. So currently both the A and B
projects that are committed to rAB include *within* them their own copies of

Needless to say, I don't like the fact that C lives in both rC and rAB (and
twice in the latter, to boot), because it seems to me to defeat the whole
principle of version control.

Ideally, as far as repositories go, I would like C to reside only in rC, and
not in rAB. So if I'm going to salvage this idea of bundling C along with A
and B (which is extremely convenient for code-deployment), I need a way to
have these internal C copies to refer to C's trunk in rC instead of copies
under A's and B's trunks in rAB. Does that make sense? I hope so.

Anyway, is there a way to do this?

If not, what are other ways to deal with the situation I am describing?



P.S. All the projects in question, A, B, and C, are intended strictly for
in-house use. There is no expectation to distribute any of them. We use
Subversion only to facilitate the work of teams of developers that work on
the same codebase, and the periodic deployment of the code to our production


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-20 18:19:18 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.