Issue with "Schedule: replace" ?

First of all: we've been using Subversion successfully for some time and
are generally quite pleased with it. That being said, I just got through
doing a rather large merge (with several hundred files changed). Two
files gave us fits because a developer had deleted the files and then
added them again later (without history). This ended up confusing the
heck out of the merge and left us struggling to fix it. There seems to
be at least one bug if not a couple in this scenario.

Here are the repro steps I used to cause it in a sandbox repository:

* Create test trunk and file.txt within it (commit)
* Branch trunk to branches (commit)
* Delete file.txt in branches (commit)
* Add (not copy) file.txt in branches with similar, but edited
text (commit)
* Merge branch to trunk
* Attempt to commit:

Replacing: Temp\Stuff\svntest\trunk\File1.txt

Error: Commit failed (details follow):

Error: Item '/svntest/trunk/File1.txt' is out of date

Error: You have to update your working copy first.

It's not out of date (I'm the only user of my sandbox)... but just for
fun I do an update:

Error: REPORT request failed on '/svn/sandbox/!svn/vcc/default'

Error: Working copy path 'trunk/File1.txt' does not exist in repository

A check to "svn info" gives:

Path: File1.txt

Name: File1.txt

URL: http://ghost/svn/sandbox/svntest/trunk/File1.txt

Repository Root: http://ghost/svn/sandbox

Repository UUID: fa1f3b68-fe77-2b4c-a867-e9ce4e4282b3

Revision: 0

Node Kind: file

Schedule: replace

Copied From URL: http://ghost/svn/sandbox/svntest/branches/File1.txt

Copied From Rev: 48

Last Changed Author: jstiff

Last Changed Rev: 48

Last Changed Date: 2006-06-14 17:30:55 -0700 (Wed, 14 Jun 2006)

Text Last Updated: 2006-06-14 17:32:54 -0700 (Wed, 14 Jun 2006)

Properties Last Updated: 2006-06-14 17:32:54 -0700 (Wed, 14 Jun 2006)

Checksum: fbfb08319e171bbeab660d257ffe45f1

This more or less looks correct.. except I don't know what replace
means. In my experience replace means it's not going to work.

If I try to recover from this I do a revert.

This ends up with the "svn info":

Path: File1.txt

Name: File1.txt

URL: http://ghost/svn/sandbox/svntest/trunk/File1.txt

Repository Root: http://ghost/svn/sandbox

Repository UUID: fa1f3b68-fe77-2b4c-a867-e9ce4e4282b3

Revision: 0

Node Kind: file

Schedule: normal

Copied From URL: http://ghost/svn/sandbox/svntest/branches/File1.txt

Copied From Rev: 48

Last Changed Author: jstiff

Last Changed Rev: 48

Last Changed Date: 2006-06-14 17:30:55 -0700 (Wed, 14 Jun 2006)

Text Last Updated: 2006-06-14 17:32:54 -0700 (Wed, 14 Jun 2006)

Properties Last Updated: 2006-06-14 17:35:12 -0700 (Wed, 14 Jun 2006)

Checksum: fbfb08319e171bbeab660d257ffe45f1

So it did "revert" it by changing the schedule. It does not revert the
"Copied From" settings nor does it correctly revert the author,
revision, etc.

I can't at this point edit that file because of the state of the svn
info settings:

Error: Commit failed (details follow):

Error: Entry for 'C:\Temp\Stuff\svntest\trunk\File1.txt' is marked as
'copied' but is not itself scheduled

Error: for addition. Perhaps you're committing a target that is

Error: inside an unversioned (or not-yet-versioned) directory?

It does let me commit the merge (if there were other files to commit) -
however my working copy is still screwed up on this particular file. The
file (and it's .svn\text-base friend) have been changed to the version
from the merge. So basically my local copy differs from anything the
repository actually has in it. The only way I know to "refresh" it is to
delete the parent directory of the file and do a checkout (or update its
parent) again. Then I can at least manually merge the changes in.

It seems to me that

a) it should be able to handle this. Is this that odd of a use case (or
can I realistically train every developer to not add files with names
that may have been deleted in the past)?

b) there are issues with revert not fully reverting files scheduled as
"replace"

c) it can be a real problem to end up with a working copy that differs
from the repository without knowing or being able to correct

Is this indeed an issue?

I think I understand why it's a replace (because there is a file that
needs to be deleted and added with the same name), and potentially why
that corrupts the text-base, but Shouldn't I be able to commit a
replace? Shouldn't there need to be a way for me to recover from this?

Thanks for any help/ideas!

- Jared

 
Received on Fri Jun 16 16:28:35 2006