You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Campbell, Matthew A" <Ma...@Relizon.com> on 2004/07/02 19:45:55 UTC
Merge & blame
In our repository, there are two access groups; admins and developers.
Production code (/trunk) is readable to all, but only writable to admins.
Most (if not all) development changes are actually executed in /branches by
people in the developers group.
Using svn merge to integrate changes into the trunk is the obvious method,
however:
1) All incremental commits to the branch are lost
2) "blame" ownership gets changed to the person doing the merge - the admin
user
Is there any way around this? "switch" looked promising, until I watched it
delete some newly-created files. :(
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.
TIA...
--------------------------------------------------------
Matt Campbell, Programmer Analyst
The Relizon Company (Timonium, MD)
Tel: 410-308-7059 Fax: 410-561-8237
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merge & blame
Posted by Max Bowsher <ma...@ukf.net>.
Campbell, Matthew A wrote:
> In our repository, there are two access groups; admins and developers.
> Production code (/trunk) is readable to all, but only writable to admins.
> Most (if not all) development changes are actually executed in /branches by
> people in the developers group.
>
> Using svn merge to integrate changes into the trunk is the obvious method,
> however:
> 1) All incremental commits to the branch are lost
> 2) "blame" ownership gets changed to the person doing the merge - the admin
> user
>
> Is there any way around this? "switch" looked promising, until I watched it
> delete some newly-created files. :(
Some scripting might provide a way around this.
For each individual revision to be merged:
Merge to trunk (probably with modified log message, giving info on the merge)
Reset the svn:author property to the author of the original commit.
> 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.
It's not been scheduled. Lots of people agree its important, but the current major feature on the drawing board is locking. Locking
will probably end up in 1.2, and its likely that serious thoughts about merge tracking will then happen. However, until the design
is mostly done, its impossible to give a reasonable estimate of how long the coding will take.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merge & blame
Posted by Mark <em...@gmail.com>.
On 02 Jul 2004 20:48:38 -0500, kfogel@collab.net <kf...@collab.net> wrote:
> Mark <em...@gmail.com> writes:
> > 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.
>
> Well, if we had that, we'd have merge tracking... :-)
>
Cool, I had thought that merge tracking simply allowed the multiple
merges from one branch to another w/o needing to use something like
tags, like in cvs, to mark the last merge point, because the tool
remembers for you. But if merge tracking also means being able to use
annotate or blame to locate the real person who changed a given line,
even across branches, that is great!
--
===========================//
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
Re: Merge & blame
Posted by kf...@collab.net.
Mark <em...@gmail.com> writes:
> 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.
Well, if we had that, we'd have merge tracking... :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Merge & blame
Posted by Mark <em...@gmail.com>.
On 02 Jul 2004 16:14:42 -0500, kfogel@collab.net <kf...@collab.net> wrote:
> "Campbell, Matthew A" <Ma...@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
Re: Merge & blame
Posted by kf...@collab.net.
"Campbell, Matthew A" <Ma...@Relizon.com> writes:
> Using svn merge to integrate changes into the trunk is the obvious method,
> however:
> 1) All incremental commits to the branch are lost
> 2) "blame" ownership gets changed to the person doing the merge - the admin
> user
>
> Is there any way around this? "switch" looked promising, until I watched it
> delete some newly-created files. :(
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.)
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org