Re: PostgreSQL Developer meeting minutes up

Tom Lane wrote:<br /><blockquote cite="mid:12326.1244311188@sss.pgh.pa.us" type="cite"><blockquote type="cite"><pre
wrap="">Anyrevision 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.   </pre></blockquote><pre wrap="">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.) </pre></blockquote><br /> 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
thattakes advantage of this context to make the right decision, is simple and compelling on its own. Knowing the
algorithmsthat are in use, including how it selects the most recent common ancestor gives me confidence. You have the
capabilitiesto 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
couldset up a few scenarios or grab actual patches and show you particular success cases and particular failure cases,
butwill you really believe it? Because you shouldn't. For all you know, I picked the cases I knew would work and put
themup against the cases I knew would fail. <br /><br /> I've used ClearCase for around 10 years now, and with the
exceptionof "cherry picking", it has very strong and mature merge support. We rely on merges being safe while managing
manyprojects much larger than PostgreSQL. Many of the projects have hundreds of users working on them at the same time.
CVSis *unusable* in these environments. Recently, however, in spite of investments into ClearCase, we are looking at
GITas providing *stronger* merge capabilities than ClearCase, specifically with regard to propagating changes from one
releaseto another. I'm not going to pull up the last ten years of history and make it available to you.<br /><br />
Nothingis going to prove this to you other than trying it out for yourself. People need to be burned by unreliable
mergealgorithms before they respect the value of a reliable merge algorithm. People need to experience reliable merging
beforethey buy the product.<br /><br /> If the theory doesn't work for you, you really are going to have to try it out
foryourself.<br /><br /> Or not.<br /><br /> It doesn't matter to me. :-)<br /><br /> 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'sup to you to try it out for yourself and decide if you are a believer.<br /><br /> Cheers,<br /> mark<br /><br />
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
raisedquestions which only make it clear that these people have not ever worked with a capable SCM system on a major
projectbefore. 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
tohelp out) and read how it works and say "ah hah! excellent!"<br /><br /><pre class="moz-signature" cols="72">-- 
 
Mark Mielke <a class="moz-txt-link-rfc2396E" href="mailto:mark@mielke.cc"><mark@mielke.cc></a>
</pre>