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.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 15:14:17 CEST