Re: TRUE/FALSE vs true/false - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: TRUE/FALSE vs true/false |
Date | |
Msg-id | CA+TgmoazC912BS_W9=6COMOd9jJxtaeER-vcPUY_26hEy9sYMg@mail.gmail.com Whole thread Raw |
In response to | Re: TRUE/FALSE vs true/false (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: TRUE/FALSE vs true/false
|
List | pgsql-hackers |
On Thu, Aug 23, 2012 at 11:01 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Bruce Momjian <bruce@momjian.us> writes: >> On Mon, Aug 20, 2012 at 03:09:08PM -0400, Robert Haas wrote: >>> I think the thing we need to look at is what percentage of our code >>> churn is coming from stuff like this, versus what percentage of it is >>> coming from other factors. If we change 250,000 lines of code per >>> release cycle and of that this kind of thing accounts for 5,000 lines >>> of deltas, then IMHO it's not really material. If it accounts for >>> 50,000 lines of deltas out of the same base, that's probably more than >>> can really be justified by the benefit we're going to get out of it. > >> The true/false capitalization patch changes 1.2k lines. > > I did a quick look at git diff --stat between recent branches: > > $ git diff --shortstat REL9_0_9 REL9_1_5 > 3186 files changed, 314847 insertions(+), 210452 deletions(-) > $ git diff --shortstat REL9_1_5 REL9_2_BETA4 > 2037 files changed, 290919 insertions(+), 189487 deletions(-) > > However, when you look at things a bit closer, these numbers are > misleading because they include the .po files, which seem to have huge > inter-branch churn --- well in excess of 100000 lines changed per > release, at least in git's simpleminded view. Excluding those, as well > as src/test/isolation/expected/prepared-transactions.out which added > 34843 lines all by itself, I get > 173080 insertions, 70300 deletions for 9.0.9 -> 9.1.5 > 130706 insertions, 55714 deletions for 9.1.5 -> 9.2beta4. > So it looks like we touch order-of-magnitude of 100K lines per release; > which still seems astonishingly high, but then this includes docs and > regression tests not just code. If I restrict the stat to *.[chyl] > files it's about half that: > > $ git diff --numstat REL9_0_9 REL9_1_5 | grep '\.[chyl]$' | awk '{a += $1; b += $2} > END{print a,b}' > 90234 33902 > $ git diff --numstat REL9_1_5 REL9_2_BETA4 | grep '\.[chyl]$' | awk '{a += $1; b += $2} > END{print a,b}' > 90200 42218 > > So a patch of 1K lines would by itself represent about 2% of the typical > inter-branch delta. Maybe that's below our threshold of pain, or maybe > it isn't. I'd be happier about it if there were a more compelling > argument for it, but to me it looks like extremely trivial neatnik-ism. I wouldn't mind a bit if we devoted 2% of our inter-branch deltas to this sort of thing, but I've got to admit that 2% for one patch seems a little on the high side to me. It might not be a bad idea to establish one formulation or the other as the one to be used in all new code, though, to avoid making the problem worse. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
pgsql-hackers by date: