Re: Rename tracking for merges
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 1 May 2012 17:04:51 +0100 (BST)
Overall comment: yes, I think something like this could form the basis of a data storage for tracking renames.
We should think a bit more about how we would expect this to be used initially -- whether we make 'svn copy' and/or 'svn move' populate this data, or provide some other UI, initially.
Stefan Fuhrmann wrote:
> * Info in svn:mergehints is non-authoritative.
> * Use the following format
The rationale makes sense. It's useful to see this format written down as a basis for discussion,
1. Are the paths mentioned in these hints full path-within-repository, or are they path-within-branch? If the latter, then we need to define a way of identifying branch roots, don't we?
2. This is one-way info (like our copy history in the
> * "continue" from-path[@peg] [ from-rev ] to-path
OK, this is fine. Minor nit: I'd simplify the from-rev specification to:
* "continue" from-path@[from-rev] to-path
> * "ignore" path [[from-rev:]to-rev]
I think this "ignore" feature needs higher level design.
> Semantics in a merge from path A to path B:
> * If A and B are unrelated (no YCA exists), "continue"
If A and B are unrelated (no YCA exists), we don't support automatic merging (that is, merge tracking), so the case is rather uninteresting and probably out of scope. But I don't see why we should deliberately ignore the rename info on the source branch for that kind of merge. It would still be useful for seeing where a node has been renamed during its lifetime in the source branch. We wouldn't look at rename info on the target branch because we wouldn't be looking at a series of changes along the target branch. But if, as I say, this case is out of scope, we don't need to discuss it.
> * "continue" and "ignore" do not affect the merge of
[As I wrote on IRC...]
Not sure what you mean by not affecting the merge of tree changes.
I think "continue" should be used to track the renames of every path, files and directories, to find which path in the source branch corresponds to which path in the target branch. If the path in the source branch then gets deleted or renamed, the merge should do the same to the corresponding path (that it, the one matched by following the "continue" info) in the target branch. In that sense, it should apply to tree changes. Is there some specific kind of change or scenario where we'd want to deliberately ignore "continue" info?
If a path (say X/foo) is added in branch A, then that new path (X/foo) won't have any "follow" info, and no connection to a path in branch B. The merge should add a path with name "foo" inside the path in B that corresponds to X in A: so, tracking the "follow" info that leads to "X" in A, that same info leads to a path in B that might be "X2", so we create "X2/foo".
My overall thinking is shaped by the idea that we should treat a file and a directory the same way. That is, a file has properties and text-content, and when we merge a change into a file we merge a text-change and a properties-change into it. A directory has properties and a set of children, and so when we merge a change into a directory we merge a children-change (that is, we do any adds and deletes and moves, and we recurse into all the subdirectories) and a property-change.
So I think it's helpful to define an algorithm in a recursive way (recursing into directories, that is).
In terms of execution, that might be implemented as: first go through the whole tree noting what changes are needed, then go through the whole tree again making the tree-changes, then go through the tree again making the text-changes (on files) and property-changes (on any node kind). Or it could be implemented as: go through the whole tree just once, making all the changes to one node before processing the next node.
The point is, regardless of how it's implemented, if the behavioural description treats "a change to a node" as a single concept that applies equally to a file or a directory, I find that easier to understand and accept.
> * Starting from the YCA, the "continue" information
> * "ignore" is then applied to reduce the entries in
Don't know; see above.
> * Finally, all text changes get applied to their
And property changes and tree changes, I assume; or do you think those need to happen at some other point?
> * The design allows for N:1, 1:N and N:M merges
OK, I get what you mean. We should explain that more fully, but it's advanced usage, so not too important, but I like it.
> Technically, we can use that feature to model changes
What does that mean?
This is an archived mail posted to the Subversion Dev mailing list.