GSoC2007 work

[Mark Grimes]

On 6/4/2007, "Blair Zajac" <blair at orcaware.com> wrote:

>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:
>
>http://www.orcaware.com/svn/wiki/Svnmerge.py
>
>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.
>
>Regards,
>Blair
>
>--
>Blair Zajac, Ph.D.
><blair at orcaware.com>
>Subversion training, consulting and support
>http://www.orcaware.com/svn/

Maybe I'm missing something when I evaluated the tool prior to switching
to svk, but my understanding is that it's better then nothing but far
from a merge tracking solution as it only works at the directory level
which makes microbranches a tough sell (can cause double merging). From
what I've researched the consensus seems to be that you cannot merge a
single file and unless you only merge from project's root every time
you're stuck with manual merge tracking.

I would imagine the last mile is being handled by subversion's roadmap,
but I would tend to think that in large multi-developer project's
something that coarse grain wouldn't be ideal.

I didn't mean to slant this discussion into battle of the tools -- but
what I've researched (granted opted out of) doesn't chalk svnmerge.py
as a complete solution in the slightest.

I'm more inclined to believe someone like yourself that has used it, but
I'm pretty scared off about there being a "manual merge tracking"
path at all when it comes to making decisions about being quick to
branch or not. I've always been quick to branch because svk does a very
nice job of this whilest keeping my sanity entact, but my scorecard only
shows 2 committers using svk thus far, so I wanted to bring up
subversion's work-in-progress on the technical slant. Noone needs the
headache of branching if the technical merging is not up to par with
what people envision they can do. You don't find that many subversion
projects that are branch happy, but I'm not necessarily convinced it is
because of JKH's reasons as much as it is an implementation pitfall and
known weakness on the Subversion side that are currently being
milestoned (http://subversion.tigris.org/merge-tracking/)

-Mark