[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Change tracking

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-05-06 13:57:14 CEST

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:


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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.