wc-ng and add/add tree conflicts

[Stefan Sperling <st...@elego.de>]

Greg,

on IRC yesterday, you said:

<gstein> here is the sequence of operation:
<gstein> * bump DIR to NEW with children {..., omicron, ...}
<gstein> * for each child, insert an "incomplete" base node if a base isn't
           already present
<gstein> * if a WORKING is present, but no base (local add), then insert the
           not-present node at pre-bump rev. add info to tc being collected
<gstein> * attempt to remove BASE nodes not mentioned in new list of children
<gstein> * this removal may trigger more tc info, but we arrange nodes before continuing
<gstein> * DIR bump is complete
<gstein> something like that

We also said:

<stsp> gstein, keep in mind that we won't get a tree conflict if the locally added omicron and the incoming omicron have the same content...
<stsp> (just in case this makes a difference)
<gstein> stsp: unrelated, but thanks

I thought about this again, and given the sequence of operations you
lined out, I'm not convinced its unrelated.

I think you need to revise this step:
"if a WORKING is present, but no base (local add), then insert the
not-present node at pre-bump rev. add info to tc being collected".

Because if a WORKING is present, and its content matches the incoming
BASE@post-bump-rev in case of an update, or the BASE@merge-left in case
of a merge, than there is no tree conflict and you can simply add the
incoming BASE at post-bump rev (i.e. install it as the base for the
locally added file, obsoleting its locally-added status). There's no
need for adding a fake node to keep the BASE pinned at pre-bump rev in
this case.

That's an extra condition your current plan does not represent.

Note that we'll eventually need similar magic for directories, but because
of difficulties with the current diff implementation, we cannot compare
a WORKING tree to the tree in the repository (tree@post-bump rev in case
of an update, tree@merge-left in case of a merge) right now.

Stefan

Re: wc-ng and add/add tree conflicts

[Stefan Sperling <st...@elego.de>]

On Wed, Apr 08, 2009 at 02:51:50PM +0200, Greg Stein wrote:
> Hmm. A very good point!
> 
> Okay... I'll ponder more on this.
> 
> For the update case, if the WORKING node's checksum is up to date,
> then we could "compare" the incoming text and the locally-added text
> (and the two sets of properties) to determine equality.

Yeah, right now, we do a full content comparison IIRC.
Comparing checksums might be better if we have checksums available.

Stefan

Re: wc-ng and add/add tree conflicts

[Greg Stein <gs...@gmail.com>]

Hmm. A very good point!

Okay... I'll ponder more on this.

For the update case, if the WORKING node's checksum is up to date,
then we could "compare" the incoming text and the locally-added text
(and the two sets of properties) to determine equality.

Will think more, and then see how this might fit into the editor API
revamp (if at all).

Thanks,
-g

On Wed, Apr 8, 2009 at 12:01, Stefan Sperling <st...@elego.de> wrote:
> Greg,
>
> on IRC yesterday, you said:
>
> <gstein> here is the sequence of operation:
> <gstein> * bump DIR to NEW with children {..., omicron, ...}
> <gstein> * for each child, insert an "incomplete" base node if a base isn't
>           already present
> <gstein> * if a WORKING is present, but no base (local add), then insert the
>           not-present node at pre-bump rev. add info to tc being collected
> <gstein> * attempt to remove BASE nodes not mentioned in new list of children
> <gstein> * this removal may trigger more tc info, but we arrange nodes before continuing
> <gstein> * DIR bump is complete
> <gstein> something like that
>
> We also said:
>
> <stsp> gstein, keep in mind that we won't get a tree conflict if the locally added omicron and the incoming omicron have the same content...
> <stsp> (just in case this makes a difference)
> <gstein> stsp: unrelated, but thanks
>
> I thought about this again, and given the sequence of operations you
> lined out, I'm not convinced its unrelated.
>
> I think you need to revise this step:
> "if a WORKING is present, but no base (local add), then insert the
> not-present node at pre-bump rev. add info to tc being collected".
>
> Because if a WORKING is present, and its content matches the incoming
> BASE@post-bump-rev in case of an update, or the BASE@merge-left in case
> of a merge, than there is no tree conflict and you can simply add the
> incoming BASE at post-bump rev (i.e. install it as the base for the
> locally added file, obsoleting its locally-added status). There's no
> need for adding a fake node to keep the BASE pinned at pre-bump rev in
> this case.
>
> That's an extra condition your current plan does not represent.
>
> Note that we'll eventually need similar magic for directories, but because
> of difficulties with the current diff implementation, we cannot compare
> a WORKING tree to the tree in the repository (tree@post-bump rev in case
> of an update, tree@merge-left in case of a merge) right now.
>
> Stefan
>
>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1596059