[Chandler-dev] Branching for recurrence/table view interactions?

Andi Vajda vajda at osafoundation.org
Tue Nov 28 11:56:50 PST 2006

On Tue, 28 Nov 2006, Jeffrey Harris wrote:

> Hi Folks,
> I'm not crystal clear on whether this requires any group process, but I
> figure it's better to discuss branching, at least briefly, so people
> don't get surprised by it.
> I knew my table/recurrence work was going to slow things down, but
> apparently it also caused a few test failures that weren't just timeout
> related, so I backed out my changes.  Since it seems like the impact of
> those changes is likely to be mitigated by work Grant's doing, Grant and
> I have been discussing working together on a recurrence branch.

I was going to suggest the same thing.

> Grant would put his per-attribute-modifications work (which is mostly
> working except for indexes) onto the branch, and I'd put in my
> modifications-in-the-dashboard work.  This would give me a chance to
> A) consolidate triageStatus modifications, which should limit the
> performance hit from my work, and
> B) change the export/share code to ignore triageStatus-only
> modifications, avoiding sharing pollution my change was likely to cause
> Anyone have objections or concerns with this plan?  Historically it
> seems like merging branches back in has been fairly difficult, so I
> think it would be naive to assume this time around we won't have
> problems.  Still, I think this would be the right move.

If you merge the trunk into the branch daily, it shouldn't be that bad.


More information about the chandler-dev mailing list