You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Ross Golder <ro...@golder.org> on 2005/11/14 03:54:05 UTC
[Enhancement request] Ability to merge patches with developer
filter
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 ;)
--
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [Enhancement request] Ability to merge patches with developer filter
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Nov 18, 2005, at 17:38, Ross Golder wrote:
> So, it seems there may be two feature requests uncovered:
>
> - The ability to filter in/out merges based on 'svn:author'
> - The ability to filter in/out merges based on the login of the
> committer
>
> Are both feasible and worthy of consideration?
I think it would only be possible to work with the identity of the
person doing the commit, which is the svn:author property of that new
revision. If Bob makes a change in revision 3, then the svn:author
property of revision 3 is Bob. But if Fred then merges Bob's changes
into a branch and commits that as revision 9, the svn:author property
of revision 9 will be Fred, and Subversion will have absolutely no
idea that Fred did not write these changes himself, and that Bob was
the original author. To Subversion, all changes look the same. As
soon as you do the merge and apply it to your working copy,
Subversion forgets that it ever came from anywhere other than your
own editing commands.
This might possibly get better when Subversion has real merge
tracking; I don't know.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [Enhancement request] Ability to merge patches with developer
filter
Posted by Ross Golder <ro...@golder.org>.
On ศ., 2005-11-18 at 14:57 +0100, Ryan Schmidt wrote:
> On Nov 18, 2005, at 08:53, Ross Golder wrote:
>
> >> 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.
>
>
> There are both properties, which apply to files and directories and
> are versioned, and there are revision properties ("revprops"), which
> apply to revisions and are therefore unversioned. svn:author and
> svn:log are revision properties, since revisions are the things that
> people create and write commit messages for. It doesn't make sense to
> refer to the author of a file, since a file most likely has had many
> authors over its lifetime, each of whom have written different lines.
> (You can see this by running svn blame on a file.)
>
Ah, I see. Thanks for explaining that. Now you mention it, I do vaguely
recall reading about 'revprops' in the documentation when I first
started using subversion (a year or so ago!). I can see it being useful
in some cases, but it's not something we've had the need to use in any
projects I've been involved in so far.
So, it seems there may be two feature requests uncovered:
- The ability to filter in/out merges based on 'svn:author'
- The ability to filter in/out merges based on the login of the
committer
Are both feasible and worthy of consideration?
--
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [Enhancement request] Ability to merge patches with developer filter
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Nov 18, 2005, at 08:53, Ross Golder wrote:
>> 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.
There are both properties, which apply to files and directories and
are versioned, and there are revision properties ("revprops"), which
apply to revisions and are therefore unversioned. svn:author and
svn:log are revision properties, since revisions are the things that
people create and write commit messages for. It doesn't make sense to
refer to the author of a file, since a file most likely has had many
authors over its lifetime, each of whom have written different lines.
(You can see this by running svn blame on a file.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [Enhancement request] Ability to merge patches with developer
filter
Posted by Ross Golder <ro...@golder.org>.
On พฤ., 2005-11-17 at 11:05 -0600, kfogel@collab.net wrote:
> Ross Golder <ro...@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
Re: [Enhancement request] Ability to merge patches with developer filter
Posted by kf...@collab.net.
Ross Golder <ro...@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