[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Progress of extract and merge non-reflective changes from a reflective rev

From: Daniel Rall <dlr_at_collab.net>
Date: 2007-12-07 18:22:08 CET

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.