Change depth in existing SVN working copy without redownloading

Question

I have a working copy of an entire SVN repository, but I want to change it into a sparse working copy because of disk space issues.

One way to do this would be:

Answer 1

Woo hoo, I had this problem, and TortoiseSVN has supported solutions for both add and delete an item from the sparse checkout. http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-checkout.html

1.To add: In windows explorer, Right click on the checked out folder, then use TortoiseSVN ? Repo-Browser to bring up the repository browser. Find the sub-folder you would like to add to your working copy, then use Context Menu ? Update item to revision....

2.To delete; From your root, right-click / Repo-Browser / Update item to revision; then select 'Exclude'.

Answer 2

I don't know why people are doing things the hard way in the other answers.

Since Subversion 1.6 it's possible to simply do svn update --set-depth exclude <directory_you_want_to_prune_from_local_working_copy>

Answer 3

I had the same problem, but what you wrote doesn't seem be possible in SVN 1.7, since the metadata format looks different.

Here's what I ended up doing (using the directories in your situation). First, I copied project1 and project2 somewhere safe.

svn co --depth immediates svn_url/projects 

This checks out projects with empty directories project1 and project2. I then delete the empty folders and put the actual directories in their place. SVN gives me some weird messages but it seems to work and allows me to commit. (It does not work with --depth empty and then copying the folders in, but immediates seems to work.)

I agree this situation is not ideal, but that's why I'm switching to Git for future projects! I've used SVN for a long time, but it is getting beyond hope.

Answer 4

I ended up hacking it:

• Manually edit the depth setting to "immediates" for projects *.
• Hard delete (not SVN delete) all children of projects except project1 and project2
• svn up projects

[*] To do this, open up projects/.svn/entries in a text editor and change

b125e325-6f7c-4931-9942-d1ea1ea1441a
X

into

b125e325-6f7c-4931-9942-d1ea1ea1441a







immediates
X

Note: That UUID-looking line is probably different per repo, and X is actually hex value 0x0C which I can't get displayed here on SO.

Answer 5

Nothing like reviving an old SO Question.

I have been working with a very similar problem where I branch from trunk to create a release package but due to limitations I have to clone files which are only intended for dev.

asset
└── js
    └── some
        └── directories
            ├── assets
            │   ├── files ...
            ├── dev       **<------------ This folder needs to be empty**
            │   ├── apis
            │   ├── campaign
            │   ├── features
            │   ├── modules
            │   ├── main.js
            │   └── tags
            └── release
                ├── apis
                ├── data
                ├── features
                ├── modules
                ├── main.js
                └── tags

I decided that I would exclude the dev files to remove the temptation to patch a fix in the release branch in the wrong directory.

I do a lot of sparse checkouts to avoid large folders in trunk but have never done it retrospectively on a working copy. It seems this is pretty straight forward.

To modify the working copy so that asset/js/some/directories/devis empty you can simply run the svn co command again on the working copy.

In my case the following works

svn co --depth empty ^/branches/releases/latest/asset/js/some/directories/dev \
asset/js/some/directories/dev

You are basically running a partial checkout on your pre-existing working copy and this will work at any level. In the original case you would simply run the following.

svn co --depth immediates ^/branches/mybranch/projects projects
svn co --depth immediates ^/branches/mybranch/project1 project1
svn co --depth immediates ^/branches/mybranch/project2 project2

For those that don't know the caret ^ is shorthand for the repository root so it works like a relative path on your repository a little like ../some/location.

The key here is that you are not creating a new working copy to fix your problem. You are running these commands on your existing working copy and resetting the depth of your chosen directories.