On พฤ., 2005-11-17 at 11:05 -0600, kfogel@collab.net wrote:
> 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.
>
Actually, I was just talking about filtering out (or in) commits made by
developer X during a merge. We commit our own patches around here ;)
> 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.
>
I might be misunderstanding the way svn properties work, but I thought
such properties were associated with the file, not with the
commits/patches. I would assume that the 'svn:author' property refers to
the author of the file. But I guess if each commit/patch had properties,
it would work, assuming that the committer made use of the property.
--
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 18 08:57:09 2005