RE: Working copy corrupted by branch deletion

I'm not 100% sure how to reproduce this yet, but updating the folder to r0
and then updating it again should give you all children again. (You can also
use -set-depth excluded, and then an explicit update on the target)

I don't have suggestions on how you can do this with TortoiseSVN.

                Bert

From: Maxwell Ballenger [mailto:Maxwell.Ballenger_at_spacex.com]
Sent: zaterdag 19 januari 2013 00:44
To: users_at_subversion.apache.org
Subject: Working copy corrupted by branch deletion

Hi Subversion Users,

We're experiencing some new behavior after upgrading from TortoiseSVN 1.6.14
(Subversion client library 1.6.16) to TortoiseSVN 1.7.10 (Subversion client
library 1.7.7). We noticed this using TortoiseSVN, but some folks on their
mailing list believe that this is a result of the Subversion client library,
not Tortoise. I am not sure whether this is a bug or intended behavior. Here
is what happens:

1. Branch a subfolder of your working copy
2. Switch that subfolder onto that branch
3. Delete that branch using another working copy or the repo-browser
4. Update your working copy
5. That subfolder disappears. There is no way to recover that subfolder and
have your working copy match the trunk again without doing a fresh checkout.

In TortoiseSVN 1.6.14 (Subversion 1.6.16), a mistake like this was much
easier to recover from. Commanding a switch of a parent folder to trunk
would restore the missing subfolder.

Is this intended behavior, or could it qualify for a bug fix? Does anyone
know of a faster way to recover than a fresh checkout?

Thanks!

Max Ballenger
Received on 2013-01-19 17:37:57 CET