[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Mergeinfo is not per node

From: Thomas Åkesson <thomas_at_akesson.cc>
Date: Sat, 26 Jul 2014 21:50:20 +0200

On 22 jul 2014, at 13:40, Julian Foad <julianfoad_at_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 Å.
Received on 2014-07-26 21:50:56 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.