Quoting Greg Stein <gstein_at_gmail.com>:
> Actual behavior. update_editor.c, line 3590. When a tree conflict is
> detected for a file, it sets fb->skipped. When apply_textdelta() is
> called, the incoming delta is discarded. Thus... we have lost
> omicron_at_4.
>
> Desired behavior would be to keep it as the "revert base".
>
> Cheers,
> -g
>
> On Wed, Apr 22, 2009 at 16:53, Paul Burba <ptburba_at_gmail.com> wrote:
>> ...
>> Hi Greg,
>>
>> I follow most of what you two are discussing, except this part about
>> skipping. Are you describing desired or actual behavior here? Or
>> something else entirely?
Hi Paul,
yes, the actual behavior is to skip the tree conflict victim. About a
year ago, our naive design for tree conflict handling included
skipping the update of all tree conflict victims. But that led to
issue #3334, the merry-go-round.
http://subversion.tigris.org/issues/show_bug.cgi?id=3334
For 1.6.0 we removed the skipping behavior from almost all of the
tree conflict use cases. For instance, an incoming delete to a
locally-modified item is not skipped entirely. Instead, we reschedule
the file or tree as added-with-history, in
schedule_existing_item_for_re_add().
The only remaining case of skipping a victim is "incoming add
vs. locally added-with-history". If the local item was simply added
without history, the incoming item (of the same kind) takes its place
with no tree conflict.
Our thinking was, if the user wants a specific copy/move source, then
any 'add' from the repos is a conflict. It'd be nice to raise no
conflict if the incoming add has the same copy/move source, but we
didn't get that clever.
We can't reschedule the existing added-with-history item as
"replaced", because it doesn't exist on the server yet. Is that
correct, anyone?
Ideally we'd stash the incoming update somewhere so that it's not
ignored. For a file, we'd update the revert-base, as Greg suggests.
But for a directory tree, there's no place to store it (in wc-1).
Steve
>>
>>>> Point being: I don't care about fixing bugs in wc-1 anymore.
>>>> Make wc-ng do the right thing. You already have the right behaviour
>>>> in your head, so if you can, please make wc-ng do the right thing.
>>>
>>> I worry about an add/add conflict in 1.6, and leaving working copies
>>> in a broken state. At a minimum, it would be nice to have an issue
>>> filed and a test constructed. (/me looks at pburba...)
>>>
>>> For wc-ng, I will see that it does the right thing. Thanks.
>>>
>>> Cheers,
>>> -g
>>>
>>> ------------------------------------------------------
>>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1858850
>>>
>>
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1862100
>
--
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 2009-04-22 18:51:24 CEST