Re: PostgreSQL Developer meeting minutes up

Tom Lane wrote:
>> Any revision control system should be able to do better than diff/patch
>> as these systems have more information available to them. Normal GIT
>> uses the relatively common 3-way merge based upon the most recent common
>> ancestor algorithm. Assuming there is a most recent common ancestor that
>> isn't "file creation", it will have a better chance of doing the right
>> thing.
>>
> And I still haven't seen any actual evidence. Could we have fewer
> undocumented assertions and more experimental evidence? Take Andrew's
> plperl patches and see if git does any better with them than plain patch
> does. (If it's not successful with that patch, it's pointless to try it
> on any bigger cases, I fear.)
>

This comes to the theory vs profiling I suppose. I am a theory person -
I run things in my head. To me, the concept of having more context to
make the right decision, and an algorithm that takes advantage of this
context to make the right decision, is simple and compelling on its own.
Knowing the algorithms that are in use, including how it selects the
most recent common ancestor gives me confidence. You have the
capabilities to test things for yourself. If you have any questions, try
it out. No amount of discussions where others say "it works great" and
you say "I don't believe you until you provide me with output" is going
to get anywhere. I could set up a few scenarios or grab actual patches
and show you particular success cases and particular failure cases, but
will you really believe it? Because you shouldn't. For all you know, I
picked the cases I knew would work and put them up against the cases I
knew would fail.

I've used ClearCase for around 10 years now, and with the exception of
"cherry picking", it has very strong and mature merge support. We rely
on merges being safe while managing many projects much larger than
PostgreSQL. Many of the projects have hundreds of users working on them
at the same time. CVS is *unusable* in these environments. Recently,
however, in spite of investments into ClearCase, we are looking at GIT
as providing *stronger* merge capabilities than ClearCase, specifically
with regard to propagating changes from one release to another. I'm not
going to pull up the last ten years of history and make it available to you.

Nothing is going to prove this to you other than trying it out for
yourself. People need to be burned by unreliable merge algorithms before
they respect the value of a reliable merge algorithm. People need to
experience reliable merging before they buy the product.

If the theory doesn't work for you, you really are going to have to try
it out for yourself.

Or not.

It doesn't matter to me. :-)

In any case - you raised the question - I explained how it works - and
you shot me done without any evidence of your own. I explained how it
works. It's up to you to try it out for yourself and decide if you are a
believer.

Cheers,
mark

P.S. I'm only a bit insulted by these threads. There are a lot of
sceptical people in the crowd who until now have raised questions which
only make it clear that these people have not ever worked with a capable
SCM system on a major project before. I really shouldn't hold this
against you, which is why I continue to try and provide the theory and
background, so that when you do give it a chance, it will all start to
make sense. You'll try it out - find it works great - and wonder "how
does it do that?" Then, hopefully you can go back to my post (or the
many others who have tried to help out) and read how it works and say
"ah hah! excellent!"

--
Mark Mielke <mark(at)mielke(dot)cc>