From: Mark Mielke <mark@mark.mielke.cc>
To: Markus Wanner <markus@bluegap.ch>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: Ron Mayer <rm_pg@cheapcomplexdevices.com>
Cc: Marko Kreen <markokr@gmail.com>
Cc: Greg Stark <stark@enterprisedb.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Aidan Van Dyk <aidan@highrise.ca>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Magnus Hagander <magnus@hagander.net>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: PostgreSQL Developer meeting minutes up
Date: Mon, 08 Jun 2009 08:36:05 -0400
Message-ID: <4A2D05B5.7030804@mark.mielke.cc> (raw)
In-Reply-To: <20090608104557.67011lcu43khli2t@mail.bluegap.ch>
References: <20090526144812.GC15213@yugib.highrise.ca>
<20090602162333.369974jcc3jpn3dx@mail.bluegap.ch>
<e51f66da0906020834q7e6e3401jf77f40f9924bbace@mail.gmail.com>
<20090602180702.15986cp384yo3l7q@mail.bluegap.ch>
<e51f66da0906020917m274debd5u3288d6d56b62daf7@mail.gmail.com>
<20090603131004.12934iyrr4f7rlsc@mail.bluegap.ch>
<4136ffa0906030508i2971790dk54a8203ee03ed196@mail.gmail.com>
<4A266A56.2020703@anarazel.de>
<4136ffa0906030701x200bf0e4o4c77fa3239062ca5@mail.gmail.com>
<e51f66da0906030720u33d72d05y14ea5ce002cbaf1e@mail.gmail.com>
<20090604114610.808217tbogts0noi@mail.bluegap.ch>
<4A283A8D.8030600@cheapcomplexdevices.com>
<20090605090514.11712ntlvhi2deay@mail.bluegap.ch>
<2871.1244209112@sss.pgh.pa.us>
<4A2922E8.1090505@dunslane.net>
<4A2A8E16.2090703@bluegap.ch>
<4A2A9FB8.4050405@dunslane.net>
<11701.1244308956@sss.pgh.pa.us>
<4A2AAD96.1030603@mark.mielke.cc>
<12326.1244311188@sss.pgh.pa.us>
<4A2B15EA.4080107@mark.mielke.cc>
<20090608104557.67011lcu43khli2t@mail.blueg ap.ch>
Markus Wanner wrote:
> Quoting "Mark Mielke" <mark@mark.mielke.cc>:
>> 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.
>
> Than makes me wondering why you are speaking against merges, where
> there are common ancestors. I'd argue that in theory (and generally) a
> merge yields better results than cherry-picking (where there is no
> common ancestor, thus less information). Especially for back-branches,
> where there obviously is a common ancestor.
Nope - definitely not speaking against merges. Automatic merges = best.
Automatic cherry picking = second best if the work flow doesn't allow
for merges. Doing things by hand = bad but sometimes necessary.
Automatic merges or automatic cherry picking with some manual tweaking
(hopefully possible from kdiff3) = necessary at times but still better
than doing things by hand completely. I think you and I are in
agreement. (Even Tom and I are in agreement on many things - I just
didn't respond to his well thought out great posts, like the one that
describes why back patching is often better than forward patching when
having multiple parallel releases open at the same time)
>> 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.
> Well, I guess it can be frustrating for both sides. However, I think
> these discussions are worthwhile (and necessary) none the less.
>
> As not even those who highly appreciate merge algorithms (you and me,
> for example) are in agreement on how to use them (cherry-picking vs.
> merging) it doesn't surprise me that others are generally skeptic.
We're in agreement on the merge algorithms I think. :-)
That said, it is a large domain, and there is room for disagreement even
between those with experience, and you are right that it shouldn't be
surprising that others are generally sceptic.
Cheers,
mark
--
Mark Mielke <mark@mielke.cc>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: mark@mark.mielke.cc, markus@bluegap.ch, tgl@sss.pgh.pa.us, andrew@dunslane.net, rm_pg@cheapcomplexdevices.com, markokr@gmail.com, stark@enterprisedb.com, andres@anarazel.de, aidan@highrise.ca, heikki.linnakangas@enterprisedb.com, magnus@hagander.net
Subject: Re: PostgreSQL Developer meeting minutes up
In-Reply-To: <4A2D05B5.7030804@mark.mielke.cc>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox