On Thu, Mar 4, 2010 at 19:36, Neels J Hofmeyr <ne...@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
