Hi Julian,
thanks for the explanation. I'll make a note on our recorded issue here
and will see to update our scripts/workflow to cope for this updated
information on how --record-only behaves.
Regards,
Stefan
> Bert forwarded to dev@ from Stefan Hett:
>> Bert wrote:
>>> I haven’t looked at the full details, but actual merges only store mergeinfo
>>> of what is actually merged (includes unaffected tree filtering, filtering
>>> what is already merged, etc.). A record only merge is a tool to just
>>> register as merged the affected target without further processing. It is
>>> primarily used to block further merges, or unblock something that wasn’t
>>> really merged.
>>>
>>> So totally different mergeinfo is fully expected.
>>>
>>> Does this answer your question, or did either of your operations record
>>> wrong mergeinfo?
>> thanks. That mostly does explain the current behavior to me.
>> From a user's point of view I however find this difference in recorded
>> mergeinfos quite problematic. While certainly both cases represent the
>> same logical merge structure:
>>
>> case 1:
>> svn:mergeinfo for /B: /A:2-5
>> case 2:
>> svn:mergeinfo for /B: /A:2-5
>> svn:mergeinfo for /B/test.txt /A/test.txt:3
>>
>> The redundant? mergeinfo of /B/test.txt is causing quite some issues for
>> us. It's true, that when I directly reintegrate B back into A, A would
>> not record the "redundant" mergeinfo for A/test.txt. But if I create
>> another branch from B (let's say C) and reintegrate this back into A, the
>> mergeinfo (assuming, didn't test!) will be kept in /A/test.txt - ending
>> up with mergeinfos on a file.
>>
>> When I never reintegrate B back into A, this mergeinfo in test.txt wil
>> stay forever, having an accumulating effect on the number of files
>> containing mergeinfos over the time...
>> [...]
>> Using TortoiseSVN as our main client, this makes a lot of cases quite
>> inconvenient:
>> - showing the overview when committing merged changes, is hard, because
>> this brings up a list of hundreds of files with the actual changed
>> files being somewhere in-between
>> - logs are cluttered with mergeinfo changes, so it's quite hard to find
>> the actual changes in a revision
>> - committing changes is unnecessarily slowed-down because all mergeinfo
>> changes are transferred one-by-one
>> - I guess other SVN-operations are slowed-down as well, because the
>> mergeinfos are not stored only in one single mergeinfo-property...
>>
>> Do u have any suggestion for us to improve our workflow? Wouldn't it be
>> reasonable to change the behavior of the --record-only merge, so that it
>> does not store these "redundant" mergeinfos in the first place?
>
> I think it would be sensible if --record-only did exactly what a normal merge does, except not record the final mergeinfo. However, that is not completely possible. When a merge adds a file or directory, it may add subtree mergeinfo on that file/dir (in other words, mergeinfo that differs from the mergeinfo it would otherwise inherit). In a record-only merge, the file/dir would not be added, and so there is nowhere to add the corresponding mergeinfo. That is a limitation of our mergeinfo storage design.
>
> I am thinking about a future redesign of mergeinfo, mainly to support move tracking. Rather than try to improve the current design and implementation further, I will bear this in mind as one of the properties the new merge tracking should have.
>
> - Julian
>
Received on 2015-03-05 10:13:36 CET