You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@codematters.co.uk> on 2005/04/07 14:39:35 UTC
Re: svn commit: r14002 - in trunk/subversion: include
libsvn_fs_base libsvn_fs_fs tests/libsvn_fs_base tests/libsvn_repos
maxb@tigris.org writes:
> Author: maxb
> Date: Wed Apr 6 18:51:35 2005
> New Revision: 14002
>
> Modified:
> trunk/subversion/include/svn_error_codes.h
> trunk/subversion/libsvn_fs_base/tree.c
> trunk/subversion/libsvn_fs_fs/fs_fs.c
> trunk/subversion/libsvn_fs_fs/tree.c
> trunk/subversion/tests/libsvn_fs_base/fs-test.c
> trunk/subversion/tests/libsvn_repos/repos-test.c
> Log:
> * subversion/include/svn_error_codes.h: Remove unused #include "svn_props.h".
HACKING refers to http://apr.apache.org/versioning.html which states:
We define "source compatible" to mean that an application will
continue to build without error, and that the semantics will remain
unchanged.
Applications that write against a particular version will remain
source-compatible against later versions, until the major number
changes.
Removing an unsed #include from the public header files means the new
version is not "source compatible" with the old, if we follow the
rules strictly then this change needs to wait until 2.0.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r14002 - in trunk/subversion: include libsvn_fs_base
libsvn_fs_fs tests/libsvn_fs_base tests/libsvn_repos
Posted by Julian Foad <ju...@btopenworld.com>.
Max Bowsher wrote:
> Philip Martin wrote:
>> maxb@tigris.org writes:
>>> * subversion/include/svn_error_codes.h: Remove unused #include
>>> "svn_props.h".
>>
>> Removing an unsed #include from the public header files means the new
>> version is not "source compatible" with the old, if we follow the
>> rules strictly then this change needs to wait until 2.0.
Yes.
> /me would rather say "naughty source, #include what you need, don't be
> lazy", but given what we've promised, it seems I need to go revert r14002.
It is a bit naughty of the C files, but not unreasonable, so yes you do.
Note that it would be perfectly good and proper to re-commit the other parts of
your r14002, i.e. adding "#include svn_props.h" to C files that were previously
relying on it being included through svn_error_codes.h.
Note also that this is just one of many unused #includes within our public
headers. I have the attached patch sitting around, waiting for version 2,
which removes a whole bunch of them. It will need re-checking of course, and
the C files will need updating, when that time comes.
I was thinking about whether we should mark the unused #includes in some way.
I don't think a comment like "only for source compatibilty" would be easily
maintainable, because a future version of the header could start to use
something from the included header or stop using anything from a different
included header, and there would be no easy way of noticing that the comments
are then wrong. We could instead enclose them in something like "#if
SOURCE_COMPATIBILITY", or, in practice,
#ifndef LOSE_SOURCE_COMPATIBILTY
#include "svn_props.h"
#endif
which would allow a maintainer occasionally to build with
"LOSE_SOURCE_COMPATIBILTY" defined to check that all the C files are looking
after their own needs, but there still isn't a way of checking that that "#if"
has been placed on all the #includes that it should have.
So I don't think it's worth trying to track the set of unused #include
statements, because the set may change (though very little) over time, and it
would be just something else to maintain.
We just need to do this as part of the API overhaul when v2 comes.
- Julian
Re: svn commit: r14002 - in trunk/subversion: include libsvn_fs_base libsvn_fs_fs tests/libsvn_fs_base tests/libsvn_repos
Posted by Max Bowsher <ma...@ukf.net>.
Philip Martin wrote:
> maxb@tigris.org writes:
>
>> Author: maxb
>> Date: Wed Apr 6 18:51:35 2005
>> New Revision: 14002
>>
>> Modified:
>> trunk/subversion/include/svn_error_codes.h
>> trunk/subversion/libsvn_fs_base/tree.c
>> trunk/subversion/libsvn_fs_fs/fs_fs.c
>> trunk/subversion/libsvn_fs_fs/tree.c
>> trunk/subversion/tests/libsvn_fs_base/fs-test.c
>> trunk/subversion/tests/libsvn_repos/repos-test.c
>> Log:
>> * subversion/include/svn_error_codes.h: Remove unused #include
>> "svn_props.h".
>
> HACKING refers to http://apr.apache.org/versioning.html which states:
>
> We define "source compatible" to mean that an application will
> continue to build without error, and that the semantics will remain
> unchanged.
>
> Applications that write against a particular version will remain
> source-compatible against later versions, until the major number
> changes.
>
> Removing an unsed #include from the public header files means the new
> version is not "source compatible" with the old, if we follow the
> rules strictly then this change needs to wait until 2.0.
/me would rather say "naughty source, #include what you need, don't be
lazy", but given what we've promised, it seems I need to go revert r14002.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org