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

On Fri, 07 Dec 2007, Mark Phippard wrote:

> On Dec 7, 2007 12:22 PM, Daniel Rall <dlr@collab.net> wrote:
> >
> > 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.
>
> My understanding of what Kamesh needs to do is record somewhere the
> exact revisions/path that was merged for a given transaction. The
> mergeinfo itself might contain additional information that came from
> the merge itself. It seems to me like this information would be
> static, like any piece of "history". It would not need to be copied
> or deleted as the repository is changed in the future.
 
That's right. But because mergeinfo is inherited, it's not so simple
(anymore) for copies/moves.

> Which is not to say that the patch does not take into account this
> other work, just that it does not seem particular difficult or related
> to that issue you mention.

All I'm saying is that it's additional work that would be required if
going with a solution based on a code fork like Kamesh's patch (or the
sqlite-deep-copies branch?), rather than on glasser's original
sqlite-mergeinfo-without-mergeinfo branch. And regardless, it's not so
much work.