Hi Daniel!
> On Thu, 06 Dec 2007, Kamesh Jayachandran wrote:
>> Folker Schamel wrote:
>>>> 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.
>
> It's not that our mergeinfo doesn't contain enough information; rather,
> it's that the information isn't broken out into a format that is
> supportive of fast queries needed for cyclic cherry-picking merges.
By "mergeinfo" I mean the data in the mergeinfo property only,
which alone definitely contains not enough information.
>
>>>> 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.
>
> Yeah, it has been getting a bit tedious. That said, you have demonstated that
> you have a good handle on the issues involved in Merge Tracking.
>
> It'd be quite helpful if you'd take the time to understand the work that
> Mike Pilato just merged to the trunk, the whole-branch-merge branch that
> Dave, Karl and I have been working on this week, and the issue-2897 branch
> that Kamesh is working on. Some good discussion around how to meet the
> needs of the various use cases you've brought up with those branches would
> be great! Mike, for instance, seems to have followed the spirit of some of
> your suggestions for calculating merginfo for 2-URL merges.
>
>>> (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.)
>
> Or maybe we've been busy writing code, and reviewing each other's changes?
>
> ...
>>>> 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.
>
> Wouldn't this make transitive mergeinfo -- that is, mergeinfo introduced by
> merges of merges -- much more difficult and expensive to determine?
There are two separated aspects:
a) What information must be stored for solving merge-tracking problems
(or at least to be future-safe for solving these problems)?
The answer to this question should be very clear and simple.
And I strongly advocate exposing that information via the svnmerge property.
b) How should this information stored internally so that the required
access to this information is not expensive?
This may get arbitrary complex, for example using various
SQLite indices containing redundant data.
Your point adresses b), while I am addressing a).
> ...
>>>> 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.
> ...
>>> 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?
>
> As Mark said, we can reconstruct this information (as required by 'svnadmin
> load', and other use cases); but, we want it in a more easily query-able
> form.
>
> ...
>> 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.
>
> Trying to describe this at a higher level, we need to be able to quickly
> determine not only the mergeinfo for a path at a given revision, but also
> the changes in mergeinfo on a path -- with history tracing -- over a revision
> range.
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:47:27 2007