It's only a bad idea to use svn:externals if you don't know what they're for
and don't want to invest the time to learn.
If you do not want multiple copies of code, for instance, a library shared
by more than one app, then it is not only smart, it's the best (only) way to
do it.
If you only are going to ever put 1 application in your SVN repository you
don't need them.
If you never are going to share code between > 1 application in SVN, you
don't need them.
My $0.02.
I have some great examples for you. I do websites using a couple different
frameworks. Both frameworks have CMS's built for the back end. Both backends
use TinyMCE or CKEditor. All my apps also send email. Therefore I have 1
repo with CKEditor, 1 repo with TinyMCE, and 1 repo with SwiftMailer. All
the web apps in their own repos reference these libraries via svn:externals,
and it works great.
On Tue, Jun 14, 2011 at 12:34 PM, Stefan Hett <stefan_at_egosoft.com> wrote:
> Hi,
>
> More noob questions about svn...
>
> 1. Is using externals a good idea?
>
> I've been told that it's generally a bad idea, and it feels to me like a
> bad idea, since it obfuscates what's going on in the repo. Is it often done
> for professional projects?
>
> It depends on the use-case.
> There are situations where using externals are beneficial, but there are
> also several caveats related to externals.
>
> One real-life example we in our company had trouble with was with a 1.6
> repository where we wanted to replace externals with a real copy of the
> source (i.e. remove the external property and copy the real source to the
> folder). That lead to tree conflicts when merging/updating WCs/branches and
> took a lot more time than anticipated. That was especially a PITA since
> these externals weren't actually necessary in the first place.
>
> You might wanna check-out the issues related to externals which might give
> you a rough feeling of known bugs (search for "external" in the summary and
> optionally limit the search to issues for 1.6.x)
> http://subversion.tigris.org/issues/query.cgi
>
> Several of the known issues with externals have been dealt with in the
> upcoming 1.7 release, so things will improve with the next version beyond
> what has already been solved in the 1.6-branch.
>
> Another caveat of externals is that they are generally slower when doing an
> update, since each external has to be checked individually to verify wheter
> it's up-to-date in the WC.
>
> I tend to live with a rule of thumb here:
> Use externals where necessary, avoid them where possible.
>
> Regards,
> Stefan
>
Received on 2011-06-14 22:23:19 CEST