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 <ste...@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 >