How to recover a working copy after switch

[Walden Mathews <wa...@eqwality.com>]

Hello,

I'm seeing several cases where an svn switch does not
complete normally, leaving the working copy in a state
where many folders show up in Switched status.

Update doesn't seem to help; switching again doesn't
seem to help...

In addition, I saw one case where the project's root folder
had its .svn subfolder deleted (probably by developer
error), at which point commands issued from  the root
folder resulted in the expected '. is not a working copy'.

I have tried a checkout -N of the root folder, and although
that does restore the svn metadata, it leaves the rest of
the project looking unversioned.

I'm trying to avoid using the checkout command each
time a working copy looks a little funky.  But the cases
above have stumped me.  Are there specific techniques
or best practices that can address these?

I realize I have not reported a specific failure here.  I am
looking for general advice, perhaps variants of the commands
which I have not tried yet.  My theory is that after a while,
doing development across trunk and private branches,
the working copy, for whatever reason, will fall ill.  What then?

Thanks,

Walden Mathews

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: How to recover a working copy after switch

[Chris Jensen <cj...@edex.com.au>]

Walden Mathews wrote:
> Hello,
> 
> I'm seeing several cases where an svn switch does not
> complete normally, leaving the working copy in a state
> where many folders show up in Switched status.

I need a fix for this too. I'm keeping /etc in subversion on a couple of 
servers - at one point a switch totally borked /etc - server wouldn't 
boot - turned out a key boot file had been corrupted, it didn't 
correspond to *any* version of the file ever placed in the repository, 
but "svn st" and "svn up" said the file was unchanged from the latest 
revision.

The best I've come up with so far to fix this is to checkout the entire 
heirachy in another directory, and then copy all the .svn directories 
accross to the original tree (/etc)
It would be much preferable if an "svn switch" or "svn up -r" would fix 
this. Maybe "svn up -f -r" should force subversion to verify that the 
base it has in the working copy is equivalent to whats in the repository?

-- 
---------------------------------------------------------------------
Chris Jensen cjensen@edex.com.au

Educational Experience (Australia)
Postal Address: PO Box 860, Newcastle NSW 2300
Freecall:       1-800-025 270      International: +61-2-4923 8222
Fax:            (02) 4942 1991     International: +61-2-4942 1991

Visit our online Toy store! http://www.toysandmore.com.au/
---------------------------------------------------------------------