I'd just like to clarify what I should make the focus of the raised issue?
The fact that the particular repro recipe I produced breaks the WC?
e.g. "Switch from branch that contains new directory with ignores breaks WC"
Or a way to fix up the WC after it gets broken like this?
PaperCut Software Pty. Ltd.
Phone: +61 (3) 9571 1151
Erik Huelsmann wrote:
>On 12/6/05, Matt Doran <firstname.lastname@example.org> wrote:
>>Does anyone know the best way to recover your WC after the switch fails half
>>way though (like I've encountered below)?
>>Toby Johnson ... also asked a similar question and hasn't been answered:
>Could you log this in the issue tracker as a DEFECT for the libsvn_wc
>>Matt Doran wrote:
>>I've been using svn daily for over a year ... but only been working with
>>branches more recently. Today I encountered a problem switching from a
>>feature branch back to trunk. The branch added a new subproject with it's
>>own build output (that was svn:ignore'd). After committing my work I tried
>>to 'switch' back to trunk that's when the trouble started. Although I
>>originally encountered this using the latest TSVN release, I have been able
>>to reproduce it using svn 1.2.3 on Debian (repro recipe attached).
>>The switch fails with the unfriendly message:
>>svn: Won't delete locally modified directory '.'
>>svn: Left locally modified or unversioned files
>>That really confused me. For one the '.' indicated that the current
>>directory was the modified (when it wasn't), but in fact the problem was
>>deeper down. Not knowing what the problem was I tried a number of things
>>to fix (try switching again, try switching back, revert, update, cleanup,
>>etc) .... nothing worked. And the errors got worse ...
>> svn: Working copy '<foldername>' is missing or not locked
>>I eventually figured out that the problem was due to some unversioned and
>>ignored files in the new subproject on the branch. And I don't remember how
>>I fix the WC .... but it wasn't obvious.
>>I've attached a recipe that reproduces this problem (and my unhelpful
>>attempts to clean things up). I've also attached the output of the script.
>>Could someone explain how I could avoid this situation in the future.... and
>>resolve it if it happens again?
>>Should this be raised as an issue? In the very least the initial error that
>>is displayed could be improved to make it clearer what went wrong, and how
Received on Wed Dec 7 00:16:06 2005