Re: Change tracking

On 5/6/05, Ben Collins-Sussman <sussman@collab.net> wrote:
>
> On May 6, 2005, at 6:01 AM, Russ Brown wrote:
>
> 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.
>
>

(Apologies for sending you this again Ben, I forgot to reply to the list.)

Very interesting! I hadn't realised you could do that. Thanks for the tip.

This handles the situation where a branch being merged was worked on
by one person, so in those cases it solves our problem. However, we do
have some projects that are worked on by more than one developer, so
in these cases this won't work.

It also doesn't work in the case of the merge from release to trunk,
since the changes involved in that merge will be a mixture of project
branches. Therefore, our trunk would still tend to appear like the
release manager was responsible for all changes. The only workaround
to that is to merge from individual branches to trunk instead of from
the release branch. Possible, but we'd lose the 'safety' factor of
knowing that we're merging exactly what we've just tested (on the
release branch). I suppose we could do the merge from branches to
trunk and then diff the trunk against the release to check, but that's
starting to make the process a little too involved.

Is there any indication as to when merge tracking is planned to be
implemented? I note in the document you link to that locking is
considered a higher priority, but the imminent release of 1.2 almost
takes locking out of the way. Is merge tracking next, or are there
other issues to take care of first?

Well, in the end I expected the answer of 'nothing doing right now',
so I've actually got more than I expected.

Thanks very much!

-- 
Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org