Folker Schamel wrote:
> Hi Mark!
>
>> On Dec 6, 2007 4:27 AM, Folker Schamel <schamel23@spinor.com> wrote:
>>
>>> Basically all the time you try to work around the fundamental problem
>>> that your current mergeinfo scheme has not enough information
>>> about the merge history.
>>
>> Folker, I have been thinking a lot about these comments (you've made
>> them a dozen times now).
>
> Yes; sorry if my comments have been annoying.
>
> (Due to lack of response, my assumption was that people
> didn't understand my comments, so I tried to make them more clear
> and apply them to particular issues people are working on.)
>
> > I am not sure that our scheme is as
>> different from what you propose as you think it is. I get the
>> impression you are looking at what you see in the svn:mergeinfo
>> property and basing your comments entirely on that. The information
>> that we have stored in the repository is different (or at least
>> richer).
>>
>> My understanding of your proposal in regards to mergeinfo is that we
>> should only record the explicit revisions that are merged by a given
>> merge. We can follow the history within the repository to get any
>> additional information we need.
>
> Exactly.
>
> > So let me make a few comments.
>>
>> 1) I suspect you are already aware of this, but as of a week or two
>> ago we no longer create mergeinfo for any operation but merge. Using
>> copy to create a branch used to create mergeinfo but no longer does.
>>
>> 2) When you do a merge, we create explicit mergeinfo that describes
>> the revisions you merged, but we also will merge in other differences
>> in the mergeinfo property. I think this is the crux of your
>> objection. I believe in the original design this additional
>> information was viewed as a benefit as it act as a bit of a local
>> cache. I think we agree that the information on these other merges is
>> needed, it is just that you think that information should be obtained
>> when needed by following the merge graph.
>>
>> So basically it boils down to that we are recording more mergeinfo
>> than you think we should. This can result in three scenarios:
>>
>> 1) The extra mergeinfo is harmless and provides no benefit. If this
>> is the case, we can optimize it away in a future version.
>>
>> 2) The extra mergeinfo is harmless and provides some marginal extra
>> benefit. Perhaps one or two local operations can benefit by having
>> the information in the WC. It remains to be seen if this true. It
>> seems like we always need to return to the repository when dealing
>> with mergeinfo.
>>
>> 3) The extra mergeinfo is harmful because it makes it impossible to
>> look at the mergeinfo and understand the explicit revisions that were
>> merged in a given change.
>>
>> You seem to believe this is option 3.
>
> Exactly.
>
> > I suspect you are right, but
>> that we can "easily" turn this into one of the other two options. The
>> branch that Kamesh is working on for issue-2897 essentially does this
>> (if I understand his proposal correctly). What his branch does is add
>> an extra SQLite table that records the explicit revisions that were
>> merged for a given commit. He has then been working on the algorithms
>> to use this extra information to properly drive the reflective merges.
> >
>> It seems like there has been a movement to defer Kamesh's work until
>> after 1.5. Perhaps we should ask Kamesh to create a new branch where
>> he makes his scheme change and puts the code in place to populate the
>> table properly. We can deal with using this information in other
>> branches. I suspect the change he made could co-exist and be
>> coordinated with the other SQLite optimizations that David Glasser has
>> made. I would also think that this extra information that Kamesh has
>> been recording does not have the same deep copy/move problem that
>> David Glasser has found with our other info. I do not see why this
>> information needs to be copied. The point is to record for a given
>> commit (revision) what revisions were explicitly merged and from what
>> paths. That seems like a point in time entry that never needs to
>> change or propogate.
>>
>> Anyway, Folker, perhaps you should look more closely at some of what
>> Kamesh has been proposing. I suspect it is a lot closer to your
>> proposal that you realize.
>
> Yes, maybe. Honestly, I don't understand what Kamesh is working on.
> However, the point is:
>
> As long as the meaning of mergeinfo does not change,
> I think I should not have to care about Kamesh's work,
> because i think mergeinfo should contain *all* information,
> and SQLite tables should be only an optimization detail
> containing only *redundant* information of mergeinfo.
> Don't you agree?
>
> Do I understand you correctly that my assumption is wrong,
> and that Kamesh's new SQLite table contains "extra information"
> which *cannot* be reconstructed from the mergeinfo property?
> What about svnadmin load then?
> What about users or 3rd-party-tools who want to inspect that
> "extra information" using an svn client?
>
issue-2897 branch does not record any extra information it rather
records relevant information to make the lookup faster. It just records
the merged_ranges_for_this_commit, /source, /target, commit_rev to
mergeinfo_changed table.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 6 16:18:33 2007