On Mon, Nov 12, 2012 at 12:23:44PM +0000, Philip Martin wrote:
> Two problems occurred to me over the weekend. First, we have to update
> the nodes rows even when there is no tree-conflict otherwise the source
> and destination no longer match.
Right, given the current plan to update moves entirely within the resolver,
the update process would either have to always flag a tree conflict even
if there is none (ugh!) or update NODES rows for the move destination as
part of the update process if there is no tree conflict. And it doesn't
seem right to make update behave differently based on whether or not
a conflict occurred, so neither approach makes sense.
Hmmm... tricky. Seems we need a better design.
> Second, we cannot simply use the trees
> in wc.db to drive the merge into the working files as we don't know
> whether A/f_at_3 and A/f_at_6 are the same node. In order to merge the
> changes properly the resolver is going to have to contact the repository
> (only the tree changes are required, all the content changes are already
> in the wc.db).
Which means most of my update-editor code is never going to work right.
Well, I'm starting to think that we underestimated the size of the problem
(again, as we did in 1.6), and should probably try to find a correct
design before writing more code for this (except maybe XFAILing tests).
Which means we should be prepared to pull the moves feature from the
1.8.x branch once it is branched, since move tracking doesn't provide
any benefit if moves cannot be updated properly. I don't think we can
get this done before 1.9, and we'd just be holding up a bunch of other
nice features which are already stable (automatic merge, inheritable
props, serf (once the crashes are fixed), etc...)
I'd rather release something that's done right than rushing an
incomplete solution out the door...
Received on 2012-11-12 15:44:55 CET