Am 24.04.2012 22:27, schrieb Daniel Shahaf:
> Stefan Fuhrmann wrote on Tue, Apr 24, 2012 at 22:20:52 +0200:
>> (2) Modified merges.
>> In case of textual conflicts, users will usually resolve them
>> before committing the merge result. Depending on policies,
>> a user may even need to modify textually successful merges
>> to e.g. fix a broken build before the merge may be committed.
>>
>> The problem is that SVN will not record the difference between
>> the merge result and the combined change that eventually
>> get committed. This information is not lost because the system
>> could redo the merge and diff the result against the committed
>> change. But it is expensive to get that information.
> I think there are two separate things that aren't recorded:
>
> - Changes done after the merge but before the commit
>
> - Which parts of the mergeinfo delta were physically merged, and which
> were added to the mergeinfo as part of merging a merge revision.
> (That is: 'svn merge -c 80 ^/trunk', where r80 changed svn:mergeinfo
> on ^/trunk.)
>
Agreed. There are several use-cases where the
semantics of our merge implementation (i.e.
whatever the algorithm decides to do based
upon the recorded data) and the user's intend
may not match. Or where that difference can
not be expressed formally.
Another such case that I ran into recently is
with reverse-merging changes. Those "un-merged"
revisions seem not to re-appear on the "eligible
for merge" list. Don't remember the specifics, though.
-- Stefan^2.
Received on 2012-04-29 20:23:08 CEST