Re: Merge-relevant information that is hard to come by -- Renamed / moved nodes
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 25 Apr 2012 09:32:55 +0100 (BST)
(I'm using separate Subject lines for my replies to your two points.)
Stefan Fuhrmann wrote:
> (1) Renamed / moved nodes.
If we had originally designed Subversion such that renames are tracked only if the user identifies them at commit time, I would feel that was a good design for its time. But coming to the issue now, I think we have to do better than that, by having the ability to tweak the history to say "that was a rename, so start following it now".
Retroactive marking of renames (or merges) does make the semantics of the system more complex, so we need to specify it with care. For example, if we have a subroutine that traces a node (PATH1_at_REV1) forward through any renames up to revision REV3, and then we decide to call that subroutine twice on the two subranges (REV1->REV2) followed by (REV2->REV3), what rename-tracking info does it use for the (REV1->REV2) calculation? If it uses the rename-tracking info is versioned and it uses the version that was present at REV2, then it will find a different result than if it used the REV3 version of the info.
We have exactly this issue today with mergeinfo: a user can edit the mergeinfo to say that a particular merge was or was not done, but that updated info is only recorded on revisions from 'now' onward; the original mergeinfo where the merge was performed is not changed. So any algorithm traversing the repository and following mergeinfo will get different results depending on which mergeinfo it reads. I don't know if that is a cause of the sometimes unexpected behaviour of "svn log -g", for example, but I suspect it may well be a factor.
As far as I'm aware, we haven't formalized this issue (for mergeinfo) in the sense of having a description of how a mergeinfo-sensitive operation should behave when it needs to interpret old as well as current mergeinfo.
This is an archived mail posted to the Subversion Dev mailing list.