[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Committing changes when working copy is newer than repository (disk crash)

From: Ryan Schmidt <subversion-2007b_at_ryandesign.com>
Date: 2007-09-08 20:58:50 CEST

On Sep 8, 2007, at 12:21, Chimoosoft wrote:

> I keep my subversion repository on my local drive and recently had
> a hard drive failure resulting in some lost data. It turns out
> that I had backups of the *working copies* of my version controlled
> data from about three weeks ago, but the backups of the svn
> repository itself were about 3 months old.
> Clearly, I'd like to use the more recently backed up working copies
> as my master, but when trying to commit them back to the subversion
> repository, I get various error messages depending on how recently
> I modified the particular working copy. I saw messages about
> checksums not matching, revision numbers not being in sync, etc.
> Basically my question boils down to whether or not the following is
> safe:
> 1. Checkout a fresh copy of each problematic trunk from the 3
> month old svn repository.
> 2. Copy all the newly modified files from the 3 week old working
> copy backup into the newly checked out trunk working copy, but
> leave all the ".svn" info in place in the working copy.
> 3. Commit.
> Will svn get confused if I do changes like this?

No, that sounds just fine. Sounds like pretty much the strategy
you'll have to use in this case.

In addition, you'll have to issue "svn add", "svn rm", "svn mv"
commands as appropriate for any new files, deleted files, or moved

You'll also lose (and have to redo) and property changes you might
have had in that time. svn:ignore, svn:mime-type, svn:eol-style,
svn:executable, svn:keywords......

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Sep 8 20:57:17 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.