Subversion misses new directories during update

Question

I'm using SVN 1.6.3 and TortoiseSVN 1.6.6. Periodically when I do an update from the root of my project, SVN fails to pickup a newly added directory (added by a co-worker). I've verified the revision number is correct and can even see the new directory (and its files) in the log for that revision. This doesn't seem to affect all computers the same (worked fine on another one) and multiple updates won't correct it. But, if I delete the directory above where this new directory is supposed to be and do another SVN update...the issue is resolved.

My first thought is that its either an issue that has been resolved with a subsequent SVN release (1.6.6, etc) or an issue with my TortoiseSVN client version. Can anyone confirm/deny either of these? Is it easy to upgrade to a new SVN version with an existing repository?

thanks...

Answer 1

It sounds like you have a sparse working copy. Try svn update --set-depth infinity and see if that does it.

The equivalent in Tortoise is setting Update Depth to "Fully recursive" when you pull up the Update dialog.

Answer 2

Maybe this might help?

When I update a working copy, new files are not added!

Between TortoiseSVN 1.6.0 and 1.6.1, added folders were added with a depth of "Only this item". This lead to a so called "sparse checkout" of that part of your working copy.

Please update to the latest version of TortoiseSVN to avoid such problems in the future.

To fix your sparse working copy, instead of "Update", use the "Update to revision..." command from the TortoiseSVN submenu (right-click in explorer), change the "Update depth" combobox to "Fully recursive".

Answer 3

We are seeing a situation where a previous merge causes a tree conflict and then particular directories do not update at all but do not throw an error message either on update. In fact, once it occurs, we can't seem to find any programmatic way of detecting the situation. The tree conflict does not show up when checking for modification and the only way we knew we had a problem was by manually comparing the files to the repo-browser and logs. Only by deduction did we figure out that it had something to do with a tree conflict.

We had to remove the original directory and re-checkout. And we have found no programmatic way of detecting when this occurs. It is infrequent but has reproduced itself a handful of times.

Terribly sparse info, I know.

Answer 4

I get these sort of problems around once per month. In my case, there was a file in the repository that was missing locally (I could browse the repository and see it), but svn thought my version of the directory was up to date. The internal version number of the directory stored in the local files was right, but the file I needed wasn't there. I just checked out a fresh local copy of the whole enchilada to fix it.

Answer 5

SVN has in the past always been backwards compatible with regards to repositories, so you needn't worry about that. Especially since the latest version is only 1.6.6 so you're not far behind.

Can you confirm that the directories you're expecting are indeed in the repository?

svn ls <repository-url>

On the parent directory of the directories you're expecting to be added or use Tortoise's repository browser to check they're there.