Ross Golder <ross@golder.org> writes:
> For example, I am releasing *some* code from our project's trunk branch
> to a live branch. There are two developers, me and Mr X. Mr X has made
> lots of changes and all are tested and ready to go live. I have been
> made some drastic modifications but haven't been able to test them fully
> yet. Our manager wants Mr X's code released now, but I want to exclude
> my code from the release (for safety).
>
> I have 'svn copy'ed the previous live branch to a new one, and used 'svn
> merge' to merge in all the changes to trunk since the last release was
> cut (from trunk), so I have a base to apply the relevant patches.
>
> My feature request is for a kind of 'filter' that, at this point, would
> allow me to only merge patches in the given range that were applied by a
> given developer, or (for larger projects, perhaps with a rogue
> developer), the ability to exclude patches from a certain developer
> (both ways would work equally well in my two-developer case!).
>
> As it happens, in this case, I have just merged all the changes to trunk
> since the last release, and reverted the ones I made before the commit.
> But, if we had both been working on the same files that wouldn't be
> possible, and I'd have need to manually work out which patch
> numbers/ranges in the range were Mr X's and apply them by hand with
> multiple 'svn merge's.
>
> Just a thought ;)
Whew :-). Yeah, that would be nice. Right now such a filter would
have to depend on consistently formatted log messages, because
Subversion doesn't have "real" merge tracking. I'm assuming when you
talk about filtering out changes from developer X, you're not just
talking about commits made by developer X, but also patches made by X
but committed by Y.
Some notes about what would constitute real merge tracking are being
haphazardly gathered, for starters see:
http://svn.collab.net/repos/svn/trunk/notes/merge-tracking.txt
http://svn.collab.net/repos/svn/trunk/notes/repeated-merging
http://svn.collab.net/repos/svn/trunk/notes/EuroOSCON-2005-vc-bof.txt
(The middle one is probably the least relevant in this context.)
A thought: if the data you need can be gotten from the svn:author
revprop and from log messages, a script could be written to do what
you describe, rather than building it into Subversion.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 17 19:32:46 2005