fs-atomic-renames: move_plus_copy_test problem

[Garrett Rooney <ro...@electricjellyfish.net>]

So last week I added an XFAIL test on the atomic renames branch, and
today I've been digging around trying to figure out why it's failing. 
The test does the following:

1) Create the greek tree.

2) Copy /A to /Z.

3) Move /A/D to /Z/d.

4) Copy /Z to /Q.

5) Modify /Q/d/gamma and /Z/d/gamma in one transaction.

At that point we get an error trying to create a successor id for
/Z/d, since /Z/d and /Q/d are two instances of the same node that had
been moved, and thus has a move id tacked on to it, so both try to use
the same old id when generating the successor id.

My current thinking is that this is a manifestation of one of the
items on the atomic renames todo list, the one about figuring out what
to do with the saved up copy id when a moved node (or its parent) is
later copied.  I haven't confirmed this yet, but I suspect if we could
keep from using the stored up move id on /Q/d then we'd be able to
avoid the problem.  That means either removing the move id annotation
when we make a copy (which we can't do without killing performance and
throwing out our "copies are cheap" feature), or later on recognizing
that this part of the tree was created via a copy and thus ignoring
the move id.

Does this make sense?  If so, all I need to do is figure out how we
detect that we've been copied, which seems like it should be
possible...

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org