On Fri, 07 Dec 2007, Mark Phippard wrote:
> On Dec 6, 2007 8:13 PM, Daniel Rall <dlr@collab.net> wrote:
>
> > On Thu, 06 Dec 2007, Mark Phippard wrote:
>
> > When we get the whole-branch-merge branch, and/or Mike's work, into a
> > state that handles the "safely merge back into trunk, handling mergeinfo"
> > use case, the priority of issue #2897 drops to the point where it is no
> > longer a 1.5 blocker. That said, it doesn't mean that we can't include
> > the fix for issue #2897 in 1.5 if it's completed in time.
>
> What about the idea of asking Kamesh to put the schema change and the
> code to populate it into a separate branch? I think we should
> consider including this in 1.5 even if we do not have any code that
> uses it as the information that it captures would probably be
> expensive to recreate later.
This sounds good to me, since it reduces schema churn, but like I said,
it means that we need to also deal with issue #3037, "SQLite index does not
stay up to date (copy/move/delete unhandled)". glasser's sqlite-deep-copies
branch is a setup in this direction, but using and the incoming schema
changes requires that the incoming schema changes be re-written with respect
to that branch.
--
Daniel Rall
- application/pgp-signature attachment: stored
Received on Fri Dec 7 17:26:33 2007