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-04 12:02:09 CET