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.
To verify that I understand you correctly,
I try to rephrase it in my own words.
Can please you acknowledge that I am correct? Thanks!
Subversion stores two kind of merge-information:
a) "exact revisions/path that was merged for a given transaction".
b) "The [current] mergeinfo itself might contain additional
information that came from the merge itself.".
Information a) is currently stored only in SDLite indices, right?
And a) is what I propose to store in the mergeinfo property, right?
Information b) is currently stored both in SQLite indices
*and* in the mergeinfo *property*, right?
And information b) can be reconstructed from a), right?
(Ignoring performance implications at the moment.)
Then, my proposal is the following:
Why not just changing the meaning of the mergeinfo property
so that the mergeinfo property represents a) instead of b)?
The advantages would be:
1. For the client and the users, there will be just one single point
containing *all* merge history information: the mergeinfo property.
(There is no need for adding new interfaces for accessing a).)
2. There is no need to enhance svnadmin store/load,
because the mergeinfo property already handled by svnadmin load
contains all information.
3. This change seems to require no change of the SQLite indices,
so that the merging code developed to far needn't be changed.
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 9 13:51:38 2007