subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fuhrmann <stefan.fuhrm...@wandisco.com>
Subject Re: svn commit: r1464763 [1/2] - in /subversion/trunk/subversion: include/svn_ra_svn.h libsvn_ra_svn/client.c libsvn_ra_svn/editorp.c libsvn_ra_svn/marshal.c svnserve/serve.c
Date Fri, 05 Apr 2013 11:37:29 GMT
On Fri, Apr 5, 2013 at 12:40 PM, Bert Huijben <bert@qqmail.nl> wrote:

> I think we should still move this to a private header.****
>
> ** **
>
> Originally (around Subversion 1.0) we determined that our libraries should
> only use public apis from our other libraries. And in this case svnserve
> could only use libsvn_ra_svn in this way.****
>
> ** **
>
> We started the private subdirectory for library communication much later.*
> ***
>
> ** **
>
> In Subversion 1.7 we even started deprecating libsvn_wc public apis
> without adding public replacements, while libsvn_client still uses them.
>

O.k. Then there is a precedent and if no one subjects by Monday
morning (UTC), I will commit the following:

* move 1.8 ra_svn functions to a private header
* rename them to svn_ra_svn__*
* provide svn_ra_svn__* copies of the remaining API
  and use that in our code
* deprecate all existing ra_svn API and make its
  implementation forward to the private API

****
>
> If a client really needs to connect this deep it should maintain a strict
> 1-on-1 version compatibility to Subversion, like we do as it has to
> understand the svnserve protocol. In this it probably already uses private
> apis anyway.
>
I don't think people using the current API directly will have a hard
time doing a global search&replace followed by a recompile. My
objection was solely on the grounds of compatibility rules.

-- Stefan^2.

>
>
> *From:* Stefan Fuhrmann [mailto:stefan.fuhrmann@wandisco.com]
> *Sent:* vrijdag 5 april 2013 12:09
> *To:* Bert Huijben
> *Cc:* commits@subversion.apache.org; dev@subversion.apache.org
> *Subject:* Re: svn commit: r1464763 [1/2] - in
> /subversion/trunk/subversion: include/svn_ra_svn.h libsvn_ra_svn/client.c
> libsvn_ra_svn/editorp.c libsvn_ra_svn/marshal.c svnserve/serve.c****
>
> ** **
>
> On Fri, Apr 5, 2013 at 12:38 AM, Bert Huijben <bert@qqmail.nl> wrote:
>
> Can we keep these in a private header?
>
>
>
> Hi Bert,
>
> Thanks for the review!
>
> Technically, nothing prevents us from moving them to a private header.
>
> However, the now deprecated svn_ra_svn_write_cmd is public and so
> are a lot of low-level ra_svn functions.
>
> I guess the mistake of releasing low-level ra_svn functions as public
> has already been made and it will be breach of compatibility to make
> them private again. Moving only the new cmd functions to the private
>
> realm will not improve things or add any protection.
>
>
>
> -- Stefan^2.
>


-- 
*Join one of our free daily demo sessions on* *Scaling Subversion for the
Enterprise <http://www.wandisco.com/training/webinars>*
*

*

Mime
View raw message