(I'm using separate Subject lines for my replies to your two points.) Stefan Fuhrmann wrote:
> (1) Renamed / moved nodes. > [...] even *with* move support in the back-end, > we could not rely on the mv command being used accurately > and consistently [...] And there is lots of gray area where > semantics don't match well, e.g. file X superseding file Y but > can't and should not be merged. Still, the user wants to record > their semantic relationship ... > > I'm all for recording moves as such but we will always have > to have a way identify moves after the respective changes > have already been committed. The good news is that >90% > of these cases can be identified programmatically it is just > somewhat expensive to do. I agree. 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@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. - Julian
