On Thu, Dec 15, 2011 at 11:54:36AM +0100, Jojakim Stahl wrote:
> Hi all!
>
> Before several years we had a HDD crash and lost part of our svn history.
> Now we have old projects (we have many customer-individual projects) where
> we only have the working copy. This WC refers to an old svn server, it
> cannot be switched because the WC head revision has been lost. Till svn 1.6
> we could use svn diff to see changes that we implemented after the initial
> crash. With 1.7 this doesn't work anymore because svn refuses to upgrade the
> WC because it cannot contact the old server.
>
>
> I found that here http://blogs.collab.net/subversion/ (section "Subversion
> 1.7 Q & A, part 1") is stated regarding svn upgrade: "This is a local
> metadata storage change only, though. 'svn upgrade' does not contact the
> server and does not modify the content of the users' working files."
>
> So why my svn tries to contact the server at all?
'svn upgrade' contacts the server when upgrading very old working
copies which didn't store the repository root and UUID. This information
must be stored in the 1.7 format so it needs to be retrieved from the
server if not already cached by the local working copy meta data.
Early versions of Subversion did not cache this data locally.
Your working copies must be several years old. You will likely be better
of with a new checkout, given that such old working copies often exhibit
problems during or after an upgrade to the 1.7.x format anyway.
Mostly because of meta-data corruption which can lurk undetected in 1.6
and ealier working copies for a long time (due to the data being
distributed across many files and directories some of which are rarely
accessed). Such problems are uncovered when trying to convert the working
copy to the 1.7 format.
Received on 2011-12-15 12:37:40 CET