Hello,
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?
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 13 01:17:04 2006