> > C. Michael Pilato wrote:
> >> 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
> >> $
OK, the tree conflict.
In subversion/libsvn_wc/update_editor.c:open_file(), we say
/* Is this path the victim of a newly-discovered tree conflict? */
if (!already_conflicted)
SVN_ERR(check_tree_conflict(&tree_conflict, eb, local_abspath,
pb->log_accum, entry,
svn_wc_conflict_action_edit,
svn_node_file, fb->new_URL, pool));
I tested using file:// (I know your script says I must use http:// but
I'm trying file://), and can reproduce the tree conflict. We assume that
because the editor driver called "open_file" it is making an "edit" to
this file, either a text edit or a property edit. Because the file is
locally deleted, this raises a tree conflict. It looks like that
assumption is wrong, or the other possible explanation could be the
editor is being driven wrongly.
Then I disabled the tree conflict detection by commenting out the
above-quoted lines, to find out why it's opened the file. In GDB I see
the editor driver is doing neither a text edit nor a (user-visible)
property edit, but it is calling
open_file()
change_file_prop(svn:entry:committed-rev)
change_file_prop(svn:entry:committed-date)
change_file_prop(svn:entry:last-author)
change_file_prop(svn:entry:uuid)
close_file()
It doesn't seem to do anything with the lock token, which is odd.
It looks like we should defer the tree conflict detection until
"apply_textdelta" and "change_file_prop" callbacks instead of assuming
that one of those will be called, and we should ensure that entry-prop
changes do not trigger a tree conflict.
On the other hand, I'm wondering whether the server should be opening
that file at all. If I change your script around to lock the file after
it is initially committed, and then unlock it just before deleting it
from disk, then open_file/change_file_prop/close_file are not called at
all. Is that asymmetry intended or part of the problem here?
> >> 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?
In my test, using a file:/// URL, I see change_file_prop() being called
with svn:entry:last-author = "jrandom". I can't easily try http:// URLs
(though I've been meaning for ages to try again to set up Apache so I
can).
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2395146
Received on 2009-09-15 18:22:36 CEST