If an item has been modified or deleted in the repository since
the item was last updated in the working copy, Subversion should
disallow committing that item. This is a prerequisite for tree
conflict detection. The user should have to update in order to
integrate the repo changes, possibly revealing tree conflicts.
I had assumed that Subversion would block a commit that includes an
item that has been modified or deleted on the repo. But that's not
true in all cases:
WC State Repo State Blocked?
======== ========== ========
Modified Modified Yes
Modified Deleted Yes
Deleted Modified Yes
Deleted Deleted No
We'd like to plug that gap. I have a patch ready that does so,
including an extension to the relevant cmdline test (#28) in
commit_tests.py. Unfortunately, the patch makes merge_tests.py
fail at #33 ("merge a replacement of a directory", w/refs to
issues #2144 & #2607).
It seems that the merge code depends on the loophole in commit.
The attached shell script demonstrates this by replacing a directory
'X' that contains a file 'foo'.
If the dir replacement is done manually via 'svn del' and 'svn add',
the status is nominal:
D 1 1 steve /tmp/del-w-hist/wc/A/X/foo
A 0 ? ? /tmp/del-w-hist/wc/A/X/bar
R 1 1 steve /tmp/del-w-hist/wc/A/X
1 1 steve /tmp/del-w-hist/wc/A
Status against revision: 1
and during commit, foo is implicitly deleted with its parent dir:
Transmitting file data .
Committed revision 2.
If the dir replacement is done via 'svn merge', then the status looks
rather strange (foo appears to be "deleted-with-history"):
D + - 3 steve /tmp/del-w-hist/wc/B/X/foo
A + - 2 steve /tmp/del-w-hist/wc/B/X/bar
R + - 3 steve /tmp/del-w-hist/wc/B/X
M 3 3 steve /tmp/del-w-hist/wc/B
Status against revision: 3
and during commit, foo is deleted explicitly *after* its parent dir
has been deleted.
svn: Commit failed (details follow):
svn: File or directory '/B/X/foo' is out of date
This causes an error in my patched Subversion, which forbids
committing a delete of an item that does not exist in the repository.
Comparing the working copies before the commits, I noticed something
odd in /B/X/.svn/entries: the file foo is marked as "copied". This
explains the 'D +' above. It contradicts the .entries format rules
A boolean: true if this entry was added with history; only allowed
when schedule is add. (### Why aren't the copyfrom attributes
enough for this?)
Certainly we should not mark schedule-delete items as "copied". Is
there a good reason for merge to cause commit to visit all items in a
tree that is already deleted?
I suspect the practical reason for the current behavior is the code
shared with diff, which certainly needs to visit everything. For more
on the diff/merge dependency, see my earlier post at
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
Received on 2008-02-29 15:29:32 CET
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org