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
Received on 2009-04-08 12:02:06 CEST