Mark Grimes wrote:
On 6/4/2007, "Blair Zajac" <[EMAIL PROTECTED]> wrote:
Mark Grimes wrote:
On 6/4/2007, "Jordan K. Hubbard" <[EMAIL PROTECTED]> 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.
<[EMAIL PROTECTED]>
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
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
