On Tue, Aug 10, 2010 at 12:56:19PM +0200, Stefan Sperling wrote:
> On Mon, Aug 09, 2010 at 09:45:18PM +0300, Daniel Shahaf wrote:
> > Also, this isn't really related to performance; it belongs on /trunk. Next
> > time, you could send this with a [PATCH] marker in the subject line, and
> > a full committer could +1 you to commit that to directly to /trunk.
>
> Yes, please send patches if you have a change that isn't direclty
> related to your performance improvements work.
>
> The scope of the branch is not "stefan2 makes all of his commits there",
> it's "this branch is for stefan2's performance-related work".
Oh, and there is a technical reason for this:
Subversion is bad at dealing with cyclic merges (a.k.a. reflective
merges). Because of this, it really matters where a change enters the tree.
See the ASCII graph at the end of this post for an example where things
go wrong because a change is made on a branch first and not on trunk:
http://mail-archives.apache.org/mod_mbox/subversion-dev/201004.mbox/%3C20100406152724.GM19641@noel.stsp.name%3E
(This example may not apply to our situation, but other examples can
be contrived.)
So, ideally, changes we may want to cherry-pick to other branches such
as 1.6.x should enter our tree via trunk, and be merged to other
branches from there -- it will enter your performance branch during a
sync with trunk, and the 1.6.x branch via a cherry picking merge.
Stefan
Received on 2010-08-10 13:07:59 CEST