Hi Mark!
> On Dec 6, 2007 9:55 AM, Folker Schamel <schamel23@spinor.com> 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.
>>> 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 think the comments have been walking a fine line between helpful and
> noise. I think you have some good points, but you are also being
> fairly dismissive of the current approach and not very constructive in
> reaching a solution. We are not going to scrap everything because of
> a drive-by proposal.
>
>>> 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?
>
> This is an example of what I am referring to. It really is not helpful.
>
> To answer your question ... no I do not really agree. I think of it
> more as the "repository" should contain the information and be able to
> answer queries. And yes the SQLite tables are an optimization the
> repository can use.
>
>> 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?
>
> Dump/Load will always be a "set in concrete" requirement that it has
> to work. When you load a repository the transactions are replayed and
> the information would be reconstructed as part of that process. Any
> solution would absolutely have to work and support this.
>
>> What about users or 3rd-party-tools who want to inspect that
>> "extra information" using an svn client?
>
> I do not think there should be any guarantee that these clients ought
> to be able to inspect a property and just use its contents. There
> should be formal API that gives answers to the questions that clients
> want to ask.
Of course, this is a valid design approach, but - if I am not totally
wrong - this is different from the (originally) planned design,
where SQLite contained just redundant information.
And if you are right and that design has changed,
then I am wondering why such a (fundamental) design aspect
may change silently.
And if I understand Kamesh's latest email correctly, even you
developers seem to have a different understanding of it.
(You and Kamesh's last email gives me even more the impression
that you developers don't have a clear common understanding
and vision of the issue, but of course I may be wrong.)
>
>> 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.
>
> I think we have, or can have, all the information that we need using
> the current fundamental design (branches included). It is entirely
> possible we are storing more information than it turns out we need.
> Recent optimizations have been removing that and we can continue to do
> so. You and Kamesh seem to have arrived at the same conclusion that
> there was a bit of information we were not accurately recording.
> Kamesh's branch is seeking to rectify that.
>
> I just want to be sure that people are listening to your suggestions.
> That being said, if you want them to do that you need to invest a
> little more effort, and respect, into understanding the work that is
> going on and try to incorporate your suggestions into that work.
> Telling us we have it all wrong and we need to start over just isn't
> going to get anywhere and your insights are going to be lost. No one
> is going to benefit if that happens.
I understand your point, but I think it is not completely fair.
My first main point is that I wanted to point to problems
with the mergeinfo scheme.
I think it *is* constructive to point to a problem,
even if I haven't an solution which is acceptable for you.
As soon as someone of you developers had said one sentence
"Yes, we are aware of that problem", then I would have been
quiet immediately, even if I don't understand your approach at all.
However, this did not happen, and so my impression was that
I didn't explain it well enough, so I tried to explain it better.
Furthermore, maybe as non-developer I have no right to do that at all,
and usually I am very reluctant to give tips from outside without
really helping in the dirty implementation work.
But in this case I was quite sure that I have a valid point.
The second aspect is that I made suggestions of how solving it,
exactly because I wanted to not stop at describing the problem.
I wanted to point out that there exist solutions.
Of course you have the right to reject my proposal because
it is too far away from your current approach.
But at least I *tried* to be constructive.
And honestly, I am still not sure if the problem can be solved
at all by just minor changes of your current approach.
So my impression is that you expect something from me
which I myself just don't see yet how this is possible at all.
I hope I am wrong...
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 17:35:43 2007