codebase itself with the 1.4 API, rather than
having to tell everyone to download the 1.4.0 headers and change their
include path. There are a couple other reasons why I like the idea, but
pinning a project to a given API is the big one.
-Dani Church
big fan of having to mangle the header files
before they're usable-- I'd rather be able to point my GCC include path
straight at my working copy.
-Dani Church
N_API_UNTIL_1
svn_error_t *
svn_client_update([...]);
This has the benefit of being directly in line with the @since and
@deprecated tags in the Doxygen comments.
Anyway, that's probably more than enough for this email, I think. Is it
any surprise that I don't have any issue with verbose header files? :)
-Dani Church
This patch is a fix for some of the @deprecated tags in the Doxygen
comments. It standardizes them so that the phrasing "Provided for
backward compatibility with the 1.x API" refers to the LAST version for
which the function was valid rather than the first.
[[[
* subversion/include/svn_fs.h,
probably a bit large to attach to an email. What should I do with
them?
-Dani Church
On Fri, 24 Sep 2010, Greg Stein wrote:
On Fri, Sep 24, 2010 at 15:04, Dani Church wrote:
I wanted to suggest using a preprocessor directive to target a
codebase to a specific API version, something like the following:
#define USE_SVN_API 105
#include
I figure that could have two effects
nity.
[1] http://gcc.gnu.org/onlinedocs/cpp/Pragmas.html
-Dani Church
7 matches
Mail list logo
