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
