Bruce Momjian <br...@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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
