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.gm19...@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
