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.
> 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 think Kamesh is capturing the information you think we need to. So
confirm that is true, and help him refine the algorithm we need to use
that information. I have also asked him to take a closer look at what
you have already posted.
--
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:17:50 2007