Setting an SVN update depth for a long path with one (or few) commands

Question

Where I work, we have some very large repositories. I use Subversion's sparse directories feature to great advantage. However, I'm at a loss as to why I can't seem to do an empty (or otherwise sparse) checkout of a repository and then "add" the directories of a long path recursively all in one fell swoop. Say, I have a repository called "project1" with the following layout:

foo/
bar/
  baz/
  brak/
  schwing/yadda/etc/i386/package/

(Remember, this is just an example. The real repo is considerably more complex.) I want (for various reasons) to have the working directory layout mirror the repo, except I want to omit some paths like "foo" and "bar/baz" altogether. So right now, I do something like this:

svn checkout --depth=empty svn+ssh://svn/project1 project1
cd project1
svn update --depth=empty bar
svn update --depth=empty bar/baz
svn update --depth=empty bar/baz/schwing
svn update --depth=empty bar/baz/schwing/yadda
svn update --depth=empty bar/baz/schwing/yadda/etc
svn update --depth=empty bar/baz/schwing/yadda/etc/i386
svn update --depth=infinity bar/baz/schwing/yadda/etc/i386/package

Am I being dense or is there no shorter way to do this? I've checked the SVN docs and Googled it good. What I'd like to do is something like this:

svn checkout --depth=empty svn+ssh://svn/project1 project1
svn update --depth=infinity bar/baz/schwing/yadda/etc/i386/package

Such that all the parents of "package" are automatically added to the filesystem (similar to "mkdir -p") but aren't populated with anything except the child specified in the path. When I try the command above, SVN doesn't even give an error, it just says that the path was "skipped" and inspection of the working directory reveals that nothing happened.

I know that I could write a shell function to deal with this (and possibly will), but it just feels like there should be a better way. Thanks for your help.

Answer 1

I don't really know if there is a proper way to do this using the command line client (from the other response it looks like there isn't), but if you're using TortoiseSVN on Windows this is fairly easy.

1. Do your sparse checkout on the top level folder you're interested in.
2. Right click the folder and select "Open repo browser" from the TortoiseSVN integrated explorer shell options
3. Browse to the nested subfolder you care about, right click and select "Update item to revision"
4. Configure anything you need in the dialog (defaults are typically fine) and press ok

Answer 2

Subversion was designed to be compatible with CVS's workflow and to be as simple and easy to use as possible. Sparse checkouts aren't really a high need item, so the feature really wasn't worked on. In 95% of the projects, a developer want to checkout a particular directory, and that's it.

However, seeing what you're doing why not simply do this?

$ svn co svn+ssh://svn/project1/bar/baz/schwing/yadda/etc/i386/package project1-package

You can also set up URL environment variables in your .profile or .bashrc file like this:

PACKAGE_URL=bar/baz/schwing/yadda/etc/i386/package

and then use them like this:

$ svn co $svn+ssh://svn/project1/$PACKAGE_URL project1-package

That way, you're just checking out the directory you're working with.

By the way, there are version control systems that handle sparse checkouts better than Subversion. For example, Perforce is great at it.

Of course, with the power, you lose simplicity. In order to checkout from Perforce, you need to create a view that maps what you're checking out to what directory. You can do all sorts of fancy stuff with Perforce's mapping, but most developers find that the pain gained in the complexity isn't worth the ease you're giving up.

---

Response

As mentioned in the question, I need the working directory layout to more or less mirror the layout of the repository. (Mostly for the benefit of some automated tools.) I'm aware that one can start his/her working directory at an arbitrary path in the repo. Switching VCSes isn't an option, the company I work for is married to Subversion on the backend (most likely a particular version, even) for all eternity. Appreciate the suggestions, though. – eil

I threw in the mention of Perforce for comparison. I understand you can't switch VCS willy-nilly, but Subversion really doesn't do what you want, and that's mainly due to Subversion's initial design.

Subversion was designed to be simple to use and follow CVS workflow. CVS was the most popular version control system, and was also simple in its design. I tossed in the bit about Perforce to mainly emphasize that point. Perforce can do what you're asking for with aplomb, but at the cost of extra complexity that makes Perforce something many developers detest.

You mention this has something to do with mimicking your build tools, and I'm not sure what that means.

Do your build tools put stuff in directories that are super-directories to your checkout directory? That's usually a bad thing for build tools to do. It limits their effectiveness, and can cause side effects since a build might have unwanted effect on the user's files and directories. Can you modify the build not to do this?

Maybe you do this, so binaries can be checked into other locations in your build tree for other builds to use. Build tools like Jenkins have the ability to copy artifacts from one build job to another. This allows you to share build artifacts without first checking them in and out of the build tool. Will that solve your problem?

It's also possible to create an artifact repository. In the Java world, both Maven and Ant with Ivy extensions do this quite well. There is even a world wide repository network for commonly used third party Java artifacts, and it's easy to add ones that are strictly local to your build environment.

Doing this in the non-Java world isn't all that difficult to do with the same Java tools in the non-Java world. I've seen a few places that have used tools like Artifactory to store C++ shared object libraries. A standard Make file can grab the required artifacts using curl or wget at build time, and most build tools have no problems sending built artifacts to Artifactory.

Maybe you need package2 sooner or later that's a sibling directory to package. In your original scheme, you could go up a single directory then do an svn update --set-depth=infinity package2.

You could do something similar with separate checkouts:

 $ svn co svn+ssh://svn/project1/bar/baz/schwing/yadda/etc/i386/package project1/bar/baz/schwing/yadda/etc/i386/package 
 $ cd ..
 $ svn co svn+ssh://svn/project1/bar/baz/schwing/yadda/etc/i386/package2 package2

Now, you mimic the repository structure, but don't have to do all the work with deep sparse checkouts.

If none of the above will help you, there's not much you can do except possibly write a script to do the sparse checkout for you. You could write a script that takes a URL, then parses it into a series of sparse checkouts for you, but there's nothing like that built into the standard Subversion command line client.