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

[RFC] An element-based 'svn merge'

From: Julian Foad <julianfoad_at_apache.org>
Date: Thu, 17 Dec 2015 10:10:12 +0000

For the first practical application of element-based move tracking and
merging, I propose to write an element-based alternative to 'svn
merge'. This version of 'svn merge':

  * matches tree elements by path, like today...
  * ... except where the user specifies a different matching (aka a 'move')
  * uses the element-based merge algorithm (which handles moves)

This is like the implementation in 'svnmover' except it operates on a
real repository and WC, and has to be given the matching data

Most of the required pieces are in place now, in svnmover.

The benefits are:

  * a merge involving moves will Just Work, without the moves causing
any conflicts to be reported.

The initial implementation will work like this, as a minimum, with the
following limitations:

  * input: a requested merge from known, single-revision source trees,
    either discovered by 'automatic merge' or specified by user
  * input: a set of user-specified element matchings, each of the form
    (src-left-path, src-right-path, target-path)
  * assign EIDs (in memory) to the source-left, source-right and target trees
  * perform a tree merge, creating a temporary result (in memory)
  * check for (new style) conflicts in the result; if any, bail out
  * convert the result to a series of WC edits and apply those to the WC
  * forget all the EID metadata

Work needed:

1. A UI and data structure to input the user-specified matchings.

2. A routine that assigns EIDs to the three trees based on the
user-specified matchings and path matching. (Straightforward.)

3. Fetching the contents of the source-side trees -- easiest would be
to fetch each tree separately in its entirety. A big performance
improvement would be to fetch src_left and diff(src_left:src_right),
and construct src_right from those. Better still, also construct
src_left from target and diff(target, src_left).

4. Conversion of the element-based result to a series of WC edits. The
code in branch_compat.c doesn't quite do this, as it assumes an Ev1
output (with only a 'copy' operation) whereas the WC API has a 'move'
operation that we probably need to use. In general it will need to
insert temporary moves e.g. to swap X and Y it may need to start by
moving X to temporary name Z. Unless the WC API moves can also be set
up using just 'copy' operations, in which case the approach in
branch_compat.c is on the right track although it is currently buggy.

Items 1 and 2 are straightforward, and 3 can also be straightforward
for an initial, crude implementation, and 4 is probably the hardest

- Julian
Received on 2015-12-17 11:10:37 CET

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.