[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: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Sat, 19 Dec 2015 10:36:01 +0000

Julian Foad wrote on Thu, Dec 17, 2015 at 10:10:12 +0000:
> 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

This seems like an arbitrary restriction: supposing I have
a mixed-revision ${SRC} tree with local mods, and I do a wc-URL cp into
a ${SRC′} tree, what is the difference between using ${SRC} or ${SRC′}
as my merge source? _Should_ there be any difference?

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

What does 'bail out' mean? It sounds like "discard all the work
computed in memory and return an error". Is there a way to avoid doing
work and then discarding it? (I assume the "temporary result" is
expensive to compute)

> * 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.
> (Straightforward.)
>
> 2. A routine that assigns EIDs to the three trees based on the
> user-specified matchings and path matching. (Straightforward.)
>

I wonder how straightforward computing the mapping would be with
directory moves. It sounds like nested moves would require some
op_depth-like state?

Example: Consider merging a commit that was created by 'svnmucc -m "r2"
rm A cp 1 A/D/H A mkdir A/D cp 1 A A/D/H rm A/D/H/D/H'. This commit
consists of one mkdir and many renames, without any "node bifurcation"
operations. Is this commit situation something the branch is attempting
to handle? How would it be specified in terms of the data structure
from step (1)?

Cheers,

Daniel
(The ′ character is entered in Vim as <Ctrl+K><1><'>.)
Received on 2015-12-19 11:36:11 CET

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