[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Tree conflicts from incoming entry prop edits?

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 15 Sep 2009 17:23:04 +0100

> > 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_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


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

- Julian

Received on 2009-09-15 18:22:36 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.