7

For some reason my local copy of an SVN repo stopped recognising the parent directory as a working copy. I would normally fix this by checking out again into another folder and overwriting the new working copy with my changed files. I would then do a commit from the new folder.

I want to avoid doing that on this occasion because the repo contains thousands of large images and checking out takes a long time. So what I want to do is check out non-fully recursively into a new directory, copy my existing files into the new directory, and then check the whole thing in.

The trouble is that SVN knows I only checked out a few files. Is there a way I can fake it and make SVN think I just did a full checkout? (e.g. a way I can get hold of just the .svn folder for a complete checkout without actually checking everything out)

Zoe
  • 27,060
  • 21
  • 118
  • 148
wheresrhys
  • 22,558
  • 19
  • 94
  • 162
  • First: Are the huge files directly in the root of the working copy or at least one directory below? Second: Did you delete the `.svn` dir only in the working copy root or is this dir missing in other dir too? – A.H. Oct 23 '11 at 12:41
  • The files aren't in teh main root, adn it appears to be only the root .svn directory that is corrupted - within any subdirectory all the usual icons appear next to the files – wheresrhys Oct 23 '11 at 19:02

4 Answers4

3

A sparse checkout of your repository in a new location should do what you want (http://svnbook.red-bean.com/en/1.5/svn.advanced.sparsedirs.html). If I understand you correctly, you will want to do an empty checkout of the topmost directory and then do an 'svn up' on just the artifacts you want, setting the depth as you go.

For example, let's say I have a top level folder called 'foo' and it contains two folders, 'bar' and 'zoog'. 

/foo
  /bar
    -the files I want
  /zoog
    -the universe

The folder 'zoog' has a large number of files that I don't care about at the moment but I want to be able to work with 'bar'. I would do the following:

svn co --depth empty file:///var/svn/repos/FooRepo foo
cd foo
svn up --set-depth infinity bar

Now 'svn up' shows everything is up to date and I can make changes in 'foo' and 'bar' and commit them as if I had also checked out 'zoog' without all of the overhead.

(The arguments to --set-depth in svn update are exclude, empty, files, immediates, and infinity)

Matt Hulse
  • 5,496
  • 4
  • 29
  • 37
  • I've plus one'd your answer as it looks like it's probably what I needed, but in order to run command line svn (instead of tortoise gui) I ended up having to upgrade SVN to 1.7, which has a completely different metadata structure to v1.6, so I can't really test your answer to see if it works – wheresrhys Nov 03 '11 at 11:44
  • I call `svn up --set-depth infinity bar/folder1` in step three and get error `E155007 - Not a working copy` So I first call `svn up --set-depth empty bar` then `svn up --set-depth infinity bar/folder1` – Bernhard Döbler Dec 15 '16 at 18:00
1

You most likely damaged or deleted the hidden .svn folder inside every checkout.

Use the command line to do svn co svn://your/svn/repository --depth immediates elsewhere and restore the .svn folder from there. Then you will need to go through a lot of svn update . and svn cleanup sequences to re- associate the subfolders with the parent folder.

aquaherd
  • 444
  • 4
  • 12
  • I've already tried that, but checking out immediates seems to take just as long as checking out the whole thing - no idea why. It seems very perverse to me. – wheresrhys Oct 03 '11 at 16:41
  • 1
    Then try `svn co svn://your/svn/repository --depth empty` and cherry-pick the files you want. – aquaherd Oct 05 '11 at 22:26
0

First backup your full working copy. Then update to last revision your working copy. your last revision has root folder. SVN will try to write that folder again. Then a tree conflict will show. Then run cleanup and commit it again.

Md. Rashidul Hasan
  • 91
  • 7
  • I can't update to latest revision as SVN doesn't recognise it as a working copy and I can't run any SVN commands on the directory – wheresrhys Oct 03 '11 at 16:14
0

If only the root of the working copy has been damaged and the large (or many files) are in directories below the working copy root the following procedure should work without downloading the files from the repo again:

> # 1) adjust these:
> WC=/bad/root/of/working/copy
> REPO=svn://localhost/url/to/repo/trunk/proj

> cd $WC
> # 2) make sure there is no half-baked stuff
> rm -rf .svn

> # 3) remove files in WC-root (would wreck havok later)
> rm -v $(svn ls --depth=files $REPO)

> # 4) ckeck out a clean .svn for this dir into another place
> svn co --depth=immediates $REPO /tmp/tmp-wc
> # 5) copy .svn this to this place
> cp -a /tmp/tmp-wc .

> # 6) "reconnect" children, download files in root
> svn up --set-depth=infinity .
Revision 42.

After that normal operation should be possible - if there are no other damages.

Notes:

  • Step 3+4) Since the repository root does not contain much data, this step should be painless. However you may backup these before if there might be any changes not checked in.
  • Step 6) Since the data in the subdirectories is untouched, it will not be downloaded again. Data in the root directory will be fetched again.
A.H.
  • 63,967
  • 15
  • 92
  • 126