On 02 Jul 2004 16:14:42 -0500, kfogel@collab.net <kfogel@collab.net> wrote:
> "Campbell, Matthew A" <Matthew.Campbell@Relizon.com> writes:
> > 1) All incremental commits to the branch are lost
That's the way I've seen version control tools do it. You could always
merge each incremental commit, thus sending each one to the trunk, but
until subversion gets a way to track merges (which i'm hoping comes
sooner rather than later), that would not be easy.
> > 2) "blame" ownership gets changed to the person doing the merge - the admin
> > user
> When the integrator does the merge, they can set the svn:author
> revision property to at least use the original author. They can
> either propset by hand, or use svn --username, or whatever works.
> (This is a clumsy workaround, I'm aware.)
This would only be good if one person worked on the branch or if
incremental commits on the branch where merged individually. I would
be very surprised if any version control tools could track "blame"
over merges and not attribute the changes to the person doing the
merge. Whoever you set the merged version to, will be blamed for all
changes from the branch in the merge.
> > Is this related to the lack of "merge tracking" I'm reading about in other
> > threads? If so, then I'm encouraged by the fact that it's on the to-do
> > list, and am curious as to which version of SVN for which this is likely to
> > be implemented.
>
> Yup, it's very much related. Solution Not Yet Scheduled, sorry.
Since merge tracking is not scheduled, maybe subversion can address
this "blame" situation. If a file version is a result of a merge,
maybe "blame" or "annotate" can somehow show that in the place of the
author in the output. Instead of "user123" changing line 43, maybe
something like "user123 merge r1456" changing line 43. That is not
ideal, but better that the merger erroneously getting full credit for
everyones changes on that file.
I think that my be a more fair "blame". The output would show the
"user123" changed line 43, but did so as a result of a merge from
r1456. That way, the true source of the change can be tracked, over
multiple branches if needed. Also, if that change isn't found on the
branch, user123 has some explaining to do... (for me, the merge
version should only contain the results of the merge, or massaged
results needed to compile, work correctly, resolve conflicts, etc....)
Don't know if this is possible or if enough people who matter like the
idea, but it would greatly increase the accuracy of tracking line
changes across branches. Merge tracking (repeat merges) a factor in
our future decision to upgrade from CVS at work, blame or no blame...
:)
Later,
--
===========================//
Mark (email2mark at
O'Brien gmail dot com)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 3 03:14:19 2004