On 19 December 2015 at 10:36, Daniel Shahaf <d...@daniel.shahaf.name> wrote:
> 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?
It is an unnecessary restriction, intended only to simplify the
initial implementation and to match the existing "svn merge SRC-LEFT
SRC-RIGHT wc" interface. There should be no reason in principle not to
support mixed-revision trees as inputs, except that we'll then have to
delve into exactly what "mixed-revision tree" means in the element
model and how it translates to existing Subversion. That's for later.
>> * 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)
Correct. Later, we can work on storing the partial result, with
conflicts. In fact, I talked with Philip yesterday afternoon and he's
already thinking about that.
>> * 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)?
Yes, it will handle this sort of situation, which we might say
involves "arbitrary moves" or "complex moves".
The UI input data structure from step 1 could represent the
transformation that I think you have in mind with your 'svnmucc'
example as:
{ 1: ("A/D/H", "A"), 2: (nil, "A/D"), 3: ("A", "A/D/H") }
a Python dictionary of (EID : (initial path, final path)).
- Julian
