I really don't mean to create/prolong a debate here. Personally, I find it easier to stay out of downmerge problems with a branch, when there are parallel changes afoot, and I like to have local history of my efforts. However, chacun a son gout.
On Sat, Oct 3, 2009 at 6:28 PM, Grant Ingersoll <[email protected]> wrote: > > 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. >
