On Oct 3, 2009, at 12:10 PM, Benson Margulies wrote:
On Sat, Oct 3, 2009 at 11:19 AM, Grant Ingersoll
<[email protected]>wrote:
On Oct 3, 2009, at 10:11 AM, Benson Margulies wrote:
There is one further level of fun available here.
Step 1: committer makes svn branch.
Step 2: verify/arrange that branch is included in git clone.
Step 3: set up served git clone of that branch at your place with
gitosis
or
whatever. Note that git svn doesn't do 'bare', but it doesn't turn
out to
interfere.
Step 4: students actually commit to that clone.
Step 5: committer pushes that up to ASF svn on the branch with light
supervision.
I'm not sure the ASF treats branches any differently from trunk
when it
comes to the supervision involved.
Let me clarify. Anything that goes into the real ASF repo has to
come from
someone with an iCLA, and a committer has at least to be confident
that
there isn't someone else's IP involved. Beyond that, we're in the
territory
of the particular's community's taste in patch control. Piling up a
bunch of
contributions in a branch is, in my view, just another alternative to
stacking them up in JIRAs.
Patches can be updated individually and managed individually. If a
branch gets to far out of whack, even in Git, it becomes harder and
harder to merge back in and will require a massive merge unless it is
done frequently, in which case you might as well use patch.
I don't know why the whole patch thing is viewed as so complex:
Steps:
Make changes in code
In the checked out dir: svn diff > ../MAHOUT-XXX.patch
Upload to JIRA.
Application:
Download patch
patch -p 0 -i ./MAHOUT-XXX.patch (do a --dry-run first)
Review changes.
Besides the fact, that JIRA should still be used extensively b/c that
is how we track changes for releases.
