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). 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. 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. 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.
--
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
Received on Thu Dec 6 16:24:06 2007