C. Michael Pilato wrote:
> Hyrum K. Wright wrote:
>> cmpilato@tigris.org wrote:
>>> Author: cmpilato
>>> Date: Tue Nov 6 12:54:33 2007
>>> New Revision: 27633
>>>
>>> Log:
>>> Split libsvn_ra_neon/fetch.c into 5 different files, four of which
>>> service one RA API each, the other (fetch.c) which continues to hold
>>> all the rest of the stuff it used it. This required *no* code
>>> changes -- only intra-file motion.
>>>
>>> * subversion/libsvn_ra_neon/get_locks.c
>>> New, copied from fetch.c, but with only the code supporting
>>> svn_ra_neon__get_locks() left.
>>>
>>> * subversion/libsvn_ra_neon/get_location_segments.c
>>> New, copied from fetch.c, but with only the code supporting
>>> svn_ra_neon__get_location_segments() left.
>>>
>>> * subversion/libsvn_ra_neon/get_locations.c
>>> New, copied from fetch.c, but with only the code supporting
>>> svn_ra_neon__get_locations() left.
>>>
>>> * subversion/libsvn_ra_neon/get_dated_rev.c
>>> New, copied from fetch.c, but with only the code supporting
>>> svn_ra_neon__get_dated_rev() left.
>>>
>>> * subversion/libsvn_ra_neon/fetch.c
>>> (drev_report_elements, getlocks_report_elements, drev_baton_t,
>>> drev_start_element, drev_end_element, svn_ra_neon__get_dated_revision,
>>> get_locations_baton_t, gloc_report_elements, gloc_start_element,
>>> svn_ra_neon__get_locations, gls_report_elements, gls_start_element,
>>> get_location_segments_baton_t, svn_ra_neon__get_location_segments,
>>> get_locks_baton_t, getlocks_start_element, getlocks_cdata_handler,
>>> getlocks_end_element, svn_ra_neon__get_locks): Remove all the stuff
>>> now present in the other four files.
>>>
>>> Added:
>>> trunk/subversion/libsvn_ra_neon/get_dated_rev.c
>>> - copied, changed from r27617, /trunk/subversion/libsvn_ra_neon/fetch.c
>>> trunk/subversion/libsvn_ra_neon/get_location_segments.c
>>> - copied, changed from r27617, /trunk/subversion/libsvn_ra_neon/fetch.c
>>> trunk/subversion/libsvn_ra_neon/get_locations.c
>>> - copied, changed from r27617, /trunk/subversion/libsvn_ra_neon/fetch.c
>>> trunk/subversion/libsvn_ra_neon/get_locks.c
>>> - copied, changed from r27617, /trunk/subversion/libsvn_ra_neon/fetch.c
>>> Modified:
>>> trunk/subversion/libsvn_ra_neon/fetch.c
>> This commit, combined with the recent spate of consistification within
>> our code got me thinking about file naming conventions. Currently, we
>> use both - and _ in place of a space in the code tree:
>>
>> hwright@spock:~/dev/svn-trunk$ find . -name '*-*.c' | wc -l
>> 91
>> hwright@spock:~/dev/svn-trunk$ find . -name '*_*.c' | wc -l
>> 61
>>
>> I know this is pretty bikesheddy, but would it be worth it to
>> consistently use one version over the other?
>
> You get nothing but +1s from me, even though my preferred choice (hyphens)
> is not a viable option because our public header files all use underscore.
I agree that underscores should be used for header files and folder
names, but I also like the hyphen for .c files.
(And with Ben's new copy-on-update stuff, such a change won't hose over
people who have local mods...oh, wait, that requires a 1.5 server.
Never mind. :( )
-Hyrum
Received on Thu Nov 8 14:17:09 2007