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

Re: [RFC] An element-based 'svn merge'

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

I (Julian Foad) wrote:
> Work needed:
>
> 1. A UI and data structure to input the user-specified matchings.
> (Straightforward.)
>
> 2. A routine that assigns EIDs to the three trees based on the
> user-specified matchings and path matching. (Straightforward.)
> trees
>
> 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).

I've started working on this (2. and 3.) -- in the
assign_eids_to_trees() function. I think I will in fact use diffs,
because otherwise it would be hugely expensive which would make a bad
first impression, and anyway it seems to be just as easy to get the
info from diffs as from full tree walks.

> 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.

Anyone willing to help write one of the other parts?

- Julian
Received on 2015-12-17 20:01:39 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.