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
