The coding blog of Alastair Smith, a software developer based in Cambridge, UK. Interested in DevOps, Azure, Kubernetes, .NET Core, and VueJS.
I’ve started using svn:externals definitions to manage my libraries and tools like NAnt and NUnit. In the words of the SVN Book:
The convenience of the svn:externals property is that once it is set on a versioned directory, everyone who checks out a working copy with that directory also gets the benefit of the externals definition. In other words, once one person has made the effort to define the nested working copy structure, no one else has to bother—Subversion will, after checking out the original working copy, automatically also check out the external working copies. Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato (2002). Version Control with Subversion. Sebastopol, CA: O'Reilly Media. 155.
This works well for me: my external dependencies are versioned by Subversion, and are automatically downloaded/updated with my working copy of the current project once the externals’ definition has been created. It’s pretty painless. I did hit one bump today, however, when setting up my repository for my web frameworks’ evaluation, and here I’ll detail how I got over it.
Possibly foolishly, I had set up the ASP.NET MVC repository structure under a directory called “ASP.NET MVC”. I did my usual thing of creating my externals’ definition in a file, ran svn propset svn:externals ./ --file FrameworksEvaluation.externals, and BAM! It exploded on me:
Bugger. I tried a couple of things, namely escaping the ‘.’ and the space with a backslash, and quoting the local relative path. No luck: I just kept getting the same error. After a bit of Google searching resulting in my landing here, I remembered something that the SVN book mentioned about externals’ definitions: SVN doesn’t use paths as such; instead it uses URLs. URL-encoding the space as %20 fixed the solution. It seems that there’s a fix for this “bug” in SVN 1.5, so watch out if you’re upgrading.
Whilst it is true that URL-encoding spaces as %20 fixes the issue for the propset, when I ran svn up to download the external dependencies, I ended up with a new directory called “ASP.NET%20MVC”. Not what I wanted. It appears this is a known bug, and further looks to be another instance of the bug I reported as having been fixed. It looks as though I’m going to be upgrading to SVN 1.5 this weekend…