I am maintaining a long-lived branch and I periodically merge changes from
trunk into the branch using the svnmerge.py tool. I'm currently having
trouble with a merge that I can't seem to find a way around.
The trouble is that, on trunk, someone mistakenly deleted a file (let's call
it "foo" for reference), and then "restored" the file on a subsequent
revision. However, when foo was "restored", it was done using "svn cat", and
therefore Subversion doesn't consider the new foo file to be related to the
original foo file that was deleted.
Now, when I try to merge from trunk, the svn merge process faithfully deletes
foo in my branch, and then adds a new foo in my branch. No changes to foo
have been made on the branch.
Now, when I try to commit the merge to the repository, it fails, saying that
the file is "out of date". Here is a transcript with path names modified for
$ svn commit
svn: Commit failed (details follow):
svn: Item '.../foo' is out of date
This seems strange to me since I can't think of any reason why foo should
be "out of date". I haven't made any changes on the branch, so I thought it
should simply replace my foo with the new "restored" foo. In any case, since
the error message says it is out of date, I try to run 'svn up' to get it up
$ svn up
svn: REPORT request failed on '...'
svn: Working copy path '.../foo' does not exist in repository
So, my copy of foo is supposedly "out of date", but trying to bring it up to
date fails. What's even more frustrating is that there have been no
modifications to foo on the branch or on trunk, with the exception of the
mistaken delete and botched restore.
Can anyone help with this scenario?
A rolling stone gathers momentum.
Received on Tue Jan 2 17:21:09 2007
- application/pgp-signature attachment: stored