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

Re: svn commit: r24694 - trunk/subversion/libsvn_fs_fs

From: Karl Fogel <kfogel_at_red-bean.com>
Date: 2007-04-21 04:33:29 CEST

kfogel@tigris.org writes:
> Log:
> * subversion/libsvn_fs_fs/tree.c: Include private/svn_mergeinfo_private.h,
> to avoid warning about svn_mergeinfo__to_string being undeclared.

Why do some files in include/private/ end in "_private.h" and some
just in ".h"? The README in there doesn't mention anything about it.

If it's just random, let's pick something and be consistent. I guess
a "_private" suffix is probably a good idea, since that way even if
"private/" were listed in -I<includes>, we'd still avoid name
conflicts. So that would imply these renames under private/:

   ra_svn_sasl.h ==> ra_svn_sasl_private.h
   svn_atomic.h ==> svn_atomic_private.h
   svn_compat.h ==> svn_compat_private.h
   svn_fs_merge_info.h ==> svn_fs_merge_info_private.h
   svn_fs_util.h ==> svn_fs_util_private.h
   svn_client_mergeinfo_private.h === svn_client_mergeinfo_private.h
   svn_mergeinfo_private.h === svn_mergeinfo_private.h
   svn_repos_private.h === svn_repos_private.h
   svn_wc_private.h === svn_wc_private.h

But I'd also be happy with no suffix:

   ra_svn_sasl.h === ra_svn_sasl.h
   svn_atomic.h === svn_atomic.h
   svn_compat.h === svn_compat.h
   svn_fs_merge_info.h === svn_fs_merge_info.h
   svn_fs_util.h === svn_fs_util.h
   svn_client_mergeinfo_private.h ==> svn_client_mergeinfo.h
   svn_mergeinfo_private.h ==> svn_mergeinfo.h
   svn_repos_private.h ==> svn_repos.h
   svn_wc_private.h ==> svn_wc.h

Being consistent is the main thing. The cost of inconsistency is that
people will think that having or not having a "_private" suffix means
something important, and waste time trying to figure out what it is.

(And if there is something important about the suffix, README should
document it.)

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 21 04:33:37 2007

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.