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

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

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Fri, 5 Apr 2013 13:37:29 +0200

On Fri, Apr 5, 2013 at 12:40 PM, Bert Huijben <bert_at_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_at_wandisco.com]
> *Sent:* vrijdag 5 april 2013 12:09
> *To:* Bert Huijben
> *Cc:* commits_at_subversion.apache.org; dev_at_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_at_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>*
*
*
Received on 2013-04-05 13:38:02 CEST

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.