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

Re: Absence of warning

From: Christopher Ness <chris_at_nesser.org>
Date: 2005-05-04 16:03:50 CEST

On Wed, 2005-04-05 at 10:33 +0200, Dave Neary wrote:
> I was explaining to a colleague the logic behind a directory not
> updating automatically when he committed a file removal, and came across
> something which isn't really a bug, but which struck me as a little
> perplexing.
> I was expecting an out-of-date error when I tried to update to a
> revision which deleted a file I had modified locally, but svn happily
> updated, while leaving the locally modified file outside revision control.

Yes, so it did not delete the file with changes from your working copy,
it is still there but now unversioned. SVN expects that it's users know
best. Some people can't seem to handle that power though.

> Efforts to return to the old revision to see what changes I'd made or
> other things like that did not succeed.
> Would it be possible to have either a warning ("Warning: a locally
> modified file has been deleted in a later revision"), an error ("svn:
> Out of date: '/trunk/test/a'") or a conflict for such a change?

An astute developer would have noticed the file was deleted on the
update and questioned it.

> The steps to reproduce follow.
> [dn_at_plrademe src]$ svn co svn://plrademe/svn/trunk/test test1
> A test1/a
> A test1/b
> A test1/c
> Checked out revision 784.
> ^[[A[dn_at_plrademe src]$ svn co svn://plrademe/svn/trunk/test test2
> A test2/a
> A test2/b
> A test2/c
> Checked out revision 784.
> [dn@plrademe src]$ svn rm test1/a
> D test1/a
> [dn@plrademe src]$ svn ci -m "Remove a" test1/
> Deleting test1/a
> Committed revision 785.
> [dn@plrademe src]$ vim test2/a
> [dn@plrademe src]$ svn stat test2
> M test2/a
> [dn@plrademe src]$ svn up test2
> D test2/a
> Updated to revision 785.
> [dn@plrademe src]$ svn stat test2
> ? test2/a
> [dn@plrademe src]$ svn up -r 784 test2
> svn: Failed to add file 'test2/a': object of the same name already exists

You have some options here. You could roll back the last change in 785
since it only deleted one file.

    svn merge -r 785:784 test2/a

Or manually re-add the file

    mv test2/a test2/a.785
    svn up -r784 test2/a
    # You now have the last revision of the non-deleted file
    mv test2/a.784 test2/a
    svn add && commit

This loses the history of the file, which is bad. I'd attempt to roll
back first with the merge command.

None of those commands were tested, they may contain typos or be
completely wrong.


Software Engineering IV,
McMaster University
PGP Public Key: http://www.nesser.org/pgp-key/
09:52:51 up 13:43, 3 users, load average: 0.04, 0.14, 0.08 

Received on Wed May 4 16:06:11 2005

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.