blair at orcaware.com
Mon Jun 4 16:08:34 PDT 2007
Mark Grimes wrote:
> On 6/4/2007, "Jordan K. Hubbard" <jkh at brierdr.com> 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 svnmerge.py, 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 svnmerge.py 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 orcaware.com>
Subversion training, consulting and support
More information about the macports-dev