Tree conflicts from incoming entry prop edits?

I was attempting to test a theory today. The theory goes like this: when
committed the deleted of a locked file over HTTP, if the commit fails and
--no-unlock was *not* specified, the lock will be dropped by the server but
the client won't know it until it next updates. I think I proved that to be
true, but I ran into a tree conflict along the way. I setup my test,
eventually resulting in my having a working copy with a deleted, locked
file. I add a pre-commit hook to my repository that fails all commits. I
try to commit from my working copy, and (surprise!) the commit fails. But
then I tried to update that working copy, and got a tree conflict. What?

$ svn st lock-wc
D KC lock-wc/foo
> local delete, incoming edit upon update
$

The traced update looks like so:

<S:update-report xmlns:S="svn:"
xmlns:V="http://subversion.tigris.org/xmlns/dav/" xmlns:D="DAV:"
send-all="true">
<S:target-revision rev="1"/>
<S:open-directory rev="1">
<D:checked-in><D:href>/tests/lock-repos/!svn/ver/1/</D:href></D:checked-in>
<S:set-prop name="svn:entry:committed-rev">1</S:set-prop>
<S:set-prop
name="svn:entry:committed-date">2009-09-14T18:27:25.596545Z</S:set-prop>
<S:remove-prop name="svn:entry:last-author"/>
<S:set-prop
name="svn:entry:uuid">2d4da764-a15c-11de-b414-7f3668e1b5e6</S:set-prop>
<S:open-file name="foo" rev="1">
<D:checked-in><D:href>/tests/lock-repos/!svn/ver/1/foo</D:href></D:checked-in>
<S:set-prop name="svn:entry:committed-rev">1</S:set-prop>
<S:set-prop
name="svn:entry:committed-date">2009-09-14T18:27:25.596545Z</S:set-prop>
<S:remove-prop name="svn:entry:last-author"/>
<S:set-prop
name="svn:entry:uuid">2d4da764-a15c-11de-b414-7f3668e1b5e6</S:set-prop>
<S:remove-prop name="svn:entry:lock-token"/>
<S:prop><V:md5-checksum>d41d8cd98f00b204e9800998ecf8427e</V:md5-checksum></S:prop>
</S:open-file>
<S:prop></S:prop>
</S:open-directory>
</S:update-report>

I have a pair of questions.

1. Is the tree conflicts code balking at the removal of the lock token as
an edit to the file scheduled for deletion?

2. Why is the server also trying to remove the last-committed-author?

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2394734