On Thu, Jan 22, 2009 at 11:28 AM, Julian Foad
<julianfoad_at_btopenworld.com> wrote:
> On Thu, 2009-01-22 at 17:07 +0100, Stephen Butler wrote:
>> Quoting Mark Phippard <mphippard_at_collab.net>:
>>
>> > On Thu, Jan 22, 2009 at 9:56 AM, Julian Foad
>> > <julianfoad_at_btopenworld.com> wrote:
>> >> FYI I'm just about to look at this.
>> >
>> > I added an svn info to the script to look at the tree conflict. The
>> > problem is that after running update the local revision in the WC for
>> > the folder is 1 when it should have been updated to 2 by the update
>> > command. So this is why it is out of date when you try to commit.
>> > When the tree conflict was created it should have still allowed the WC
>> > revision to be updated.
>>
>> Turning off the skipping of tree conflict victims is pretty
>> straightforward, at least for this use case (#1 in
>> notes/tree-conflicts/detection.txt).
>
> Is it? "Turning off skipping" means "designing and implementing some
> behaviour other than skipping". The local node is scheduled for
> deletion. The incoming change is to modify it. I assume the existing
> "update" code would not handle this case already.
That is exactly what 1.5.5 does. The base is updated, you can revert
etc. That said, I did not test this exhaustively, but that is what it
seemed to do to me.
> The behavior we want for UC1 is: the WC should end up scheduled for
> delete, but with an updated base, like it would if we reverted the local
> delete, updated, and then re-did the local delete.
>
> I am doing the corresponding thing for Use Case 2 (where the deletion is
> incoming and the modification is local) in issue #3334. It is
> straightforward in concept, but hard because the WC entry state
> manipulations are so hard to get right.
>
> It would be great if we can do this for Use Case 1 too. It sounds like
> it is important.
>
>> What should we do if the user runs update again without resolving the
>> existing tree conflict first? Skipping is not an option.
>
> Why is skipping not an option when there's an existing tree conflict?
> Skipping is exactly what we should do when there's any existing conflict
> (tree or otherwise), as per the comment I put at the top of
> libsvn_wc/update_editor.c.
>
> There are certainly better things we could aim to do, but let's get the
> basic handling right before we try to allow updating a node that's
> already in conflict.
I had the same thought, but since Stephen said it was not an option
and I do not know the details too well, I did not suggest it.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1043312
Received on 2009-01-22 17:30:55 CET