Re: [merge-tracking] replicating commits

On Thu, 13 Jul 2006, Giovanni Bajo wrote:
...
> I believe the main functional problem I have with the way svnmerge.py operates
> is that merges appear as totally different commits. Say I merge r10-20 from
> branch to trunk. The merge will appear as a single commit (r100 for instance),
> which totally hides the history of r10-20. For instance, neither "svn log" nor
> "svn blame" will show any significant information for that merge: the whole
> modification will appear as being done by the author of the merge.
>
> This is especially bad for long-living large dev branches. When they are merged
> into the trunk, the whole history of the branch is basically lost, "svn blame"
> becomes less useful, ecc.
>
> The idea I used to have with svnmerge.py was to replicate the commits.
> Basically, svnmerge.py could be taught to apply the merge with different
> commits, one for each revision being merged, and then tweak the revprops so
> that the log/author/date would match those of the original commit. This would
> bring meaningful svn log history, and perfect svn blame output. Technically
> speaking, this method of replicating commits would have problems with conflicts
> in merges, but you get the idea.
>
> Did you already consider this problem? Do you have any possible solution in
> mind? If you keep merge-tracking history in revprop, so that r100 has a revprop
> saying "I'm a merge of r10-20" (which is what you are doing, IIRC), would it be
> possible to tweak svn log/svn blame so that they follow these "merge links" and
> display information based on the original revisions?

While this topic came up during CollabNet's Merge Tracking Summit
<http://subversion.tigris.org/merge-tracking/summit.html>, the focus
was on how the author of the commit was displayed. Attendees were
interested in a transitive display for 'blame', with 'log' showing
both the original author and actual committer (if different). This is
described briefly in the "Auditing" section of the use case document
<http://subversion.tigris.org/merge-tracking/requirements.html#auditing>.

Personally, I find the idea of "transitive log messages" much more
useful! Do you see this as an optional behavior? Would it be the
default?

One problem use case: A change must be heavily modified (manually) to
the point where any description of specific code changes from the
original log message is nonsensical (e.g. 'merge --record-only',
manually apply some changes to a branch which has drifted FAR apart
from the merge source, commit). Seems like we'd want to have the
ability to provide an alternate log message here (preferably avoiding
a subsequent 'propedit svn:log').

Giovanni, would you mind adding this idea of "transitive log messages"
to the use case/requirements document?

Thanks, Dan