Kynn Jones wrote:
> 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 C.
> 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?
This is pretty much the classic reason for using externals:
Be sure you understand that you need to commit any changes under the
directories pulled in by external references separately, and that
sometimes you'll want references to the trunk that will pull the head
version when you update and sometimes you'll want to make tag copies to
reference so you can freeze the version.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-20 18:46:57 CET