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

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.

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.

This would not be the first time I was wrong about something either.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org