[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: inconsistency between mergeinfo records

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 4 Mar 2015 11:01:19 +0000

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

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