Re: Lessons from commit fest - Mailing list pgsql-hackers

From Chris Browne
Subject Re: Lessons from commit fest
Date
Msg-id 60od89sbrg.fsf@dba2.int.libertyrms.com
Whole thread Raw
In response to Re: Lessons from commit fest  (Chris Browne <cbbrowne@acm.org>)
Responses Re: Lessons from commit fest  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
bruce@momjian.us (Bruce Momjian) writes:
> Chris Browne wrote:
>> >> Would it be a terrible idea to...
>> >> 
>> >> - Draw the indent code from NetBSD into src/tools/pgindent
>> >> - Build it _in place_ inside the code tree (e.g. - don't assume 
>> >>   it will get installed in /usr/local/bin)
>> >> - Thus have the ability to run it in place?
>> >
>> > Yes, but it bloats our code and people still need to generate the
>> > typedefs and follow the instructions.  The other problem is if they run
>> > it on a file they have modified, it is going to adjust places they
>> > didn't touch, thereby making the patch harder to review.
>> 
>> The bloat is 154K, on a project with something around 260MB of code.
>> I don't think this is a particlarly material degree of bloat.
>
> You mean 37kb vs 13MB, right?  That is the tarball sizes I see.

Hmm.  I was apparently badly counting the size of the sources.  I ran
a find | wc command that seemed to report 260MB of code.  A "du" on a
"make distclean" tree gives me 104MB.  At any rate, that's only out by
a bit more than a binary order of magnitude ;-).

I was thinking about the 154K of source code sitting in CVS, not the
(yes, lower) cost of it in a tarball.

Seems immaterial either way...

>> If we ran pgindent really frequently, there would admittedly be the
>> difference that there would be a lot of little cases of
>> changes-from-pgindent being committed along the way, but [1] might it
>> not be cheaper to accept that cost, with the concomittant benefit that
>> you could tell patchers "Hey, run pgindent before submitting that
>> patch, and that'll clean up a number of of the issues."  Yes, it
>> doesn't address code changes like typedef generation, but that never
>> was an argument against running pgindent...
>
> That is much a more radical use of pgindent than it has had in the past
> but it is certainly possible.

Well, supposing you're cleaning up a patch after someone has generated
it in bad style, it would seem like rather less work to use pgindent
to impose style policy right away rather than simulating its effects
manually.

I'm not proposing anything *really* radical, like migrating away from
CVS, after all!  ;-)
-- 
let name="cbbrowne" and tld="linuxfinances.info" in String.concat "@" [name;tld];;
http://linuxfinances.info/info/lisp.html
There was a young lady of Crewe
Whose limericks stopped at line two. 


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout