On May 6, 2005, at 6:01 AM, Russ Brown wrote:
>
> Alternatively, if Subversion were capable of merge tracking, it could
> potentially trace back the the original change before all of the
> merges happened, which would solve the problem. However, I understand
> that Subversion does not at present have this functionality.
>
> Could anybody comment on the problem and potentially suggest a
> workaround. Also, does anybody else have the same problem and consider
> that a change to rectify would be a very nice to have in the future?
> Are there any plans to make the system work more like this in the
> future?
>
Yes, this is one of the things we'd like to see happen when we start
implementing 'merge tracking' features, already listed in part B of our
brainstorm document:
http://svn.collab.net/repos/svn/trunk/notes/merge-tracking.txt
I can't think of a workaround, other than to have each branch-author do
their own merge to trunk. Or, ... oh wait! Have the release manager
do the integration as usual, but after he commits the merge of a branch
to trunk, have him go back and retroactively change the 'svn:author'
revision-property attached to the revision he just committed.
In other words, if the release manager merge's bob's branch to trunk,
and commits that merge as r150, he would then run
svn propset --revprop -r150 svn:author bob
Now it *looks* like bob committed r150.
Of course, for security's sake, I would jigger your pre-revprop-change
hook script such that only the release manager would have this power.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 6 13:59:11 2005