What are the benefits of "svn: externals"?

Question

I would not recognize svn: externals if I did not come across this page . So, I am setting up a working folder. Then

mkdir lib/vendor svn add --parents lib/vendor svn ps svn:externals 'symfony http://svn.symfony-project.com/branches/1.4/' lib/vendor/ svn ci -m "add externals" svn update 

"Update svn" completes the entire symfony folder and runs rather slowly. I thought it would be a one-time pain. However, SVN will check the external repository every time I type "svn up". I have to use --ignore-externals to do the "svn update" fast enough.

I am wondering what are the benefits of svn: externals if it is so slow. I would rather copy symfony into my own repository, which is certainly a faster solution.

Answer 1

External external SVN elements also have much in common with project organization. External resources can be completely different SVN repositories, which means that you can configure different types of security, protection, access, intercept commits, intercept messages, etc. ... It is difficult to make different access levels for different folders inside a single SVN- repo (without the help of something like VisualSVN ), and it is very difficult (and perhaps unreasonable) to try and make another backup or protection method for different folders within the same SVN repo. External features allow us more freedom, allowing us to stitch several different repositories with one svn up .

Subversion External Actions Use Cases:

• A common use case is that the external object contains a library or some other element of immutable code. If you have a .dll, you can simply simply plunge it into your SVN repo and consider it as part of your code base, but you have hidden the fact that .dll should be considered read-only and has not been developed by you or your team.

• Another use case (which you discovered) - allowing your libraries to remain in a remote repository - may be supported by an active open source project. In this case, you can always point to a specific version of the external device and not worry about saving it yourself.

• Finally, external elements can be pulled in the trunk, branches or tags, which means that you can use them to sew a project consisting of different tags with their own modules. This will more accurately mimic something like Rational ClearCase or any other large version control system. This can be done by maintaining an SVN repo for each module or component of your code base, creating a tag for each mode / component, and then refer to the tags using the externals property of the main repository - which exists to simply bring them together into a working project.

Answer 2

The way you use external resources is people who want to work on revising the chapter of some code, for example, if you work in an internal project where all types of libraries and applications are jointly developed. As a rule, you should not do this without a good reason, because revision of the code in the external can violate your code - and if you do not have the right to correct the external, then working with it becomes a little cumbersome.

You can either get a specific revision of the external repository in the so-called branch of your own repo provider, or add the revision argument parameter to the external user definition, as described here, for example:

http://thinkinging.com/2008/10/21/set-the-revision-of-your-svnexternals-or-else/

Answer 3

The svn: externals mechanism behaves as advertised. The problem is that you are using a public subversion repository (Internet access) inside what I assume is a local repository. As a result, you will find a significant time difference for updating the internal repository compared to the external one.

Copying to your repository is definitely a viable solution. How to do this is explicitly documented in the Subversion book .