On 22 jul 2014, at 13:40, Julian Foad <julianf...@btopenworld.com> wrote:
Hi Julian, I happened to read this post despite not having much focus on merge functionality. We use Subversion for XML-authoring and we don't support branching/merging of trees, just files. This line of thought approaches one of our long-standing struggles; move tracking. The XML contains large amounts of hrefs to other XML files and graphics. Move/rename of individual files are problematic (regardless if the hrefs are relative or absolute). > What I have been calling "mergeinfo" here is only part of the information we > need for merging. We also need a way to map nodes in the source branch to > nodes in the target branch, in order to apply most of the individual per-node > changes in the source branch to the "right places" on the target branch > before falling back to conflicts and user input where this automatic attempt > fails. I am starting to see this mapping as an almost completely separate > problem with its own metadata rather than something that the mergeinfo should > give us for free. I am particularly interested in "a way to map nodes in the source branch to nodes in the target branch". We have been thinking about an alternative to path when identifying a file/node in a repository. It would be interesting if a node received an ID when first appearing in the repository and the ID would be stable across move operations. Copy is debatable, but my current thinking would be that copies get new IDs but might in addition maintain a list of ancestry. This is just some thoughts that we briefly considered but we have not explored further. Regards, Thomas Å.
