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

Re: best practices for nested externals

From: JOHN WAYCOTT <javajohn_at_cox.net>
Date: Tue, 6 Jan 2009 06:52:06 -0700

On Jan 5, 2009, at 9:51 AM, Brian Marshall wrote:

> I am a long time SVN user, but rather new to setting up repository
> structures and administration.
>
> Here's my situation. I have a core library and a math library that
> depends on the core library. Many products need both libraries. What
> is the best way to handle this? Math has core as an external. When
> Product brings in Math that in turn brings in core. Product also
> needs to reference core files, but I don't like having the same core
> files in 2 places. For example the product has externals core and
> math, and math has core as an external.
>
> Is there a better way to do this?

I think you would be better off having the product dictate the version
of each library to use. You would never checkout the math library by
itself; there would always be a product associated with it, even if it
is just a regression test. So, there is no need for it to have an
external dependency to the core library. I have found that having
multiple dependencies creates problems in the long run. It is too easy
to make the mistake of having the product point to one version of the
core library and the math library pointing to another version.

-- John

>
>
> Thanks,
> Brian
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1005733
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org
> ].

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

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-01-06 14:53:26 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.