:) On Thu, Jun 10, 2010 at 6:41 PM, Michael Busch <[email protected]> wrote: > OK cool. I'll start the new realtime branch soon! > > Michael > > On 6/10/10 9:30 AM, [email protected] wrote: >> >> I technically can't vote, but if I could I would say +1 to option 2 as >> well. >> Karl >> >> -----Original Message----- >> From: ext Mark Miller [mailto:[email protected]] >> Sent: Thursday, June 10, 2010 12:16 PM >> To: [email protected] >> Subject: Re: Branches for large patches? >> >> +1 to option 2 - I like feature branches more than than an issue/patch >> branch approach - large features often span many issues/patches. >> >> Option 2 can also really be a superset of option 1. >> >> - Mark >> >> http://www.lucidimagination.com (mobile) >> >> On Jun 10, 2010, at 8:17 AM, Michael Busch<[email protected]> wrote: >> >> >>> >>> Hi All, >>> >>> When working on large patches, such as LUCENE-2324, I find it always >>> troublesome to use patch files only to track progress. Since >>> branching in svn works fine now (since 1.5) I'd like to create a >>> branch for 2324. The big advantage is that everyone can track >>> progress much more easily because we get a full history on that >>> branch. And people who commit patches to trunk can help merging, >>> because it's sometimes very difficult if you haven't followed that >>> other change closely. >>> >>> I talked about this with Robert, Uwe and Simon in Berlin, and they >>> all like this proposal. >>> >>> So two different approaches come to my mind: >>> 1) branches/patches/LUCENE-2324/ >>> 2) branches/lucene-realtime/ >>> >>> >>> 1) We would have a dedicated place for branches that are used for >>> individual patches. Every committer who thinks it makes sense for a >>> certain patch to create a branch can do in the branches/patches >>> location. >>> >>> 2) Like with flexible indexing we create a branch for bigger >>> features. E.g. for realtime search there are several open issues in >>> JIRA and we could just use this single branch for all of them until >>> we're ready to merge a stable realtime version to trunk. >>> >>> I like both 1) and 2) and don't have a strong preference. What do >>> others think? >>> >>> Michael >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
