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. 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): - The first place is svn_client__get_revision_number() with a revision of svn_opt_revision_working or _base. This function returns a (much overloaded) revision number, which is derived from the parent in some added-cases. In above case (switched-away parent from a locally added child), deriving from the parent is not possible anymore. Regardless, we do not want to look up parents at all. ... But chances are good that we can eliminate this case by refactoring a few callers, properly defining svn_opt_revision_*'s meaning for added nodes to be SVN_INVALID_REVNUM, and coining it an API error, or something. - The second place is tree-conflict info. (This is a slightly odd concept, but it makes sense:) If a tree-conflict happened on a locally added node, 'svn info' would like to tell the user at which u...@rev this added node was *known to not exist*. We can get the URL easily, today. But the revision is missing. That's why 'info' currently just prints "(none)" in that case. I'm loosely thinking of an "added-at-rev" column in the NG-WORKING table, which is derived from the parent during 'svn add', and is updated during 'svn update' and 'svn switch' (here --depth=infinity). But frankly, this info output is not that pressing really. Just noting this to indicate that this particular useful information is currently not available in the schema. (There is another situation that is related -- saying this here because it illustrates how "real code" can just "cheat" around not having an added-onto-revision. Philosophical experiment: If we had this data of 'revision-onto-which-node-is-added', a locally added node may, hypothetically, *be detected to be out-of-date* in the same way that locally modified nodes are; that would force an 'svn up', which would cause a tree-conflict if this path has also been added in the repos. Currently, we don't detect that, try to commit, which fails with an error and *not* a tree-conflict. In reality, this can simply be fixed by saying 'out-of-date' instead of erroring when we hit a local-add vs. repos-add during commit; it obviously doesn't really need the revision.) 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? ;) ~Neels
signature.asc
Description: OpenPGP digital signature
