On Thu, Mar 4, 2010 at 19:36, Neels J Hofmeyr <neels_at_elego.de> wrote:
> Greg Stein wrote:
>> Oh no no no... the schema is fully set up to record moves properly,
>> without any guesswork. It is just that nobody will invoke the function
>> (in 1.7!) to do the recording.
>>
>> I'm comfortable that the schema will work. Please feel free to analyze
>> it for holes. But you're looking at the 'moved_here' and 'moved_to'
>> columns. You're also going to want to learn about scan_addition() and
>> scan_deletion() in more detail.
>
> I remember someone talking of a hole. It went something like: If a folder is
> copied-here, all its children have locally added status, and I understand
> they refer to the op-root of the add to find out their history, i.e. that
> they are copied. Now what if I replace such a child node with a fresh, new
> node -- it will still think that it's part of the copy-here. Just vague
> memory, haven't verified. This one should be fixed if it turns out to be so.
For an add, yes. The schema doesn't handle this yet. I'm unclear on
how a flag of "added" can't fully handle this. Bert posted something
about it, which I didn't understand. Need to think further on the
scenario.
(and, iirc, props to Philip for discovering this one)
> I also know of another potential "future hole": If I add a node, it
> remembers the URL at which it wants to be added, which is derived from the
> parent during the 'add' operation. If I then even switch the parent away
> --depth=empty, the added child node still remembers its original URL. That
> is pretty cool. But, we have two places where we also may want to know the
> *revision* that the parent had at the time of the 'add' (which should also
> step up when 'svn update's happen):
IMO, that is a bug of wc-1. Today, if you switch the parent, then the
add will go to the new repository location.
Added/copied/moved nodes do not have a repository location (intended
or not) until they are committed. Their target repository location is
identified by the parent.
And all that said, I seem to recall that you are not allowed to switch
a node if there are local changes. Could be wrong, but I do know we
don't "rememeber" the old URL any more.
>...
I'm not sure how your two scenarios apply, since the memory is not present.
>...
> I'm, thirdly, wondering if we can really express all sorts of madly
> cascaded/circular local copies/moves/deletes/replaces from/to subtrees that
> make sense to our users... a proper test suite will tell, right, stsp? ;)
We should be able to. I've thought about a lot of these scenarios...
witness the madhouse docstring of scan_addition and scan_deletion.
Some nasty scenarios.
But that's also why I encourage a review. I certainly missed the
add-within-a-copy/move.
Cheers,
-g
Received on 2010-03-05 22:55:35 CET