On 6/4/2007, "Blair Zajac" <blair@orcaware.com> wrote:
Mark Grimes wrote:
On 6/4/2007, "Jordan K. Hubbard" <jkh@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@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