Stefan Sperling wrote on Tue, Aug 10, 2010 at 13:06:43 +0200: > 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).
And as a work-around, you could apply the patches to trunk (without creating mergeinfo) and then merge --record-only them to the branch. Daniel (who just asked on IRC after realizing he accidentally committed to the atomic-revprops branch something that should have gone to trunk) > 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