[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r27633 - trunk/subversion/libsvn_ra_neon

From: Daniel Rall <dlr_at_collab.net>
Date: 2007-11-08 19:44:18 CET

On Thu, 08 Nov 2007, 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.

Ditto. And for the record, I'm fine with pattern of the source files
using dashes, and the headers files using underscores.

  • application/pgp-signature attachment: stored
Received on Thu Nov 8 20:47:06 2007

This is an archived mail posted to the Subversion Dev mailing list.