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 <stsp_at_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_at_post-bump-rev in case of an update, or the BASE_at_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_at_post-bump rev in case
> of an update, tree_at_merge-left in case of a merge) right now.
>
> Stefan
>
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1596059
Received on 2009-04-08 14:52:10 CEST