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