GSoC2007 work

Blair Zajac blair at
Mon Jun 4 16:08:34 PDT 2007

Mark Grimes wrote:
> On 6/4/2007, "Jordan K. Hubbard" <jkh at> wrote:
>> On Jun 1, 2007, at 11:43 AM, Juan Manuel Palacios wrote:
>>> 	Again, many reasons to move GSoC work to branches and very little
>>> to have it happen right on trunk, in my opinion. I'll make the move
>>> if no one presents a case against it, so please speak up if you feel
>>> you have valid arguments against moving to branches. Thanks!
>> I object.  I'm completely in agreement with James - the SoC
>> contributors shouldn't be treated any differently than other
>> contributors (lest we create 2nd class citizens in what is otherwise
>> supposed to be an open project, regardless of how someone gets
>> here).   A branch also isn't a quarantine mechanism to be arbitrarily
>> placed on a contributor* - it's an organizational tool to be used in
>> certain situations which depend ENTIRELY on the types of changes in
>> question.   That should be left to the discretion of the contributor.
>> Artificially constraining things to branches is also generally the
>> first step in ensuring their decay and eventual death.  That's a
>> fairly strong argument against.
>> - Jordan
>> * Yes, I'm also familiar with the "untrustworthy contributor"
>> scenario, but the solution there still isn't a branch, it's a
>> committer proxy.)
> Subversion does not currently support merge tracking (without svk), so
> this makes cherry picking a micromanagement burden and probably weighs
> in somewhat on the branching stigma as well.  

Not true.  There is, which makes this very easy:

It supports cherry picking and already has most of the feature set that 
1.5 will have.

I would recommend using to manage feature branches and it's 
easy to keep development on a branch that may break trunk.  We use it 
all the time at work.


Blair Zajac, Ph.D.
<blair at>
Subversion training, consulting and support

More information about the macports-dev mailing list