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?
Regarding 1.5, I am sure that mergeinfo should be defined
in the right way before 1.5.
Then any feature or any hyper-smart merge algorithm
(based on that mergeinfo) can be delayed into future versions
as needed without having compatibility problems.
Cheers,
Folker
---------------------------------------------------------------------
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:17:26 2007