GSoC2007 work

[Blair Zajac]

Mark Grimes wrote:
> 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.

Yes, that's true, but for this type of work, I don't see very often 
merging on the file level.  Maybe that's a limitation of the tool, but I 
typically see merges at the directory level and of complete revisions.

> 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 think you're being a little dismissive here.  For 90% of the merging 
people do, merging complete revisions and at a top level directory is 
sufficient.

We're not talking about the big project here for MacPorts.  We use 
svnmerge.py in the Subversion project itself on feature branches.  Here, 
most of the time you want to just merge changes from trunk into the 
feature branch en-masse to keep the branch up to date and not have to 
keep track of what you have already merged over.  When the branch work 
is ready, you merge it by hand back into trunk.

I don't see this being much different for a MacPorts feature branch.  So 
svnmerge.py works fine here.

> 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

I use svk also, but more for having a copy of a repository on my laptop 
and being able to do commits then for its merge tracking.

We use branches at work all the time.  Each developer gets their own 
branch and we use trunk to track what's in production web site (Java, 
HTML code).  So we do svnmerge.py merges from trunk into each developers 
branch when they want to, and also use svnmerge.py for merge from the 
developer's branch back into trunk for when new code is being deployed.

In this case, svnmerge.py does all we need.

Does svk support more fine grained branch management where the branches 
live on the server and not in ~/.svk?

Regards,
Blair