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

Re: request to make svn_wc__prop_list_recursive a public API

From: Greg Stein <gstein_at_gmail.com>
Date: Fri, 18 Feb 2011 06:09:53 -0500

I concur with all of Mike's statements here. I see no reason to
believe that we'll *ever* see any intention of pluggable working copy
libraries.

On Thu, Feb 17, 2011 at 09:22, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> On 02/17/2011 08:17 AM, Branko Čibej wrote:
>> On 17.02.2011 14:12, Stefan Sperling wrote:
>>> On Thu, Feb 17, 2011 at 01:52:44PM +0100, Branko Čibej wrote:
>>>> On 17.02.2011 13:39, Julian Foad wrote:
>>>>> Let me point out the background, in case you weren't aware.  There has
>>>>> been a general feeling (especially during the WC re-write) that the WC
>>>>> API wasn't well suited to being maintained as a public API and that we
>>>>> should move in the direction of providing a better client-layer public
>>>>> API instead.
>
> +`wc -c subversion/include/svn_wc.h | cut -d ' ' -f 1`!
>
> I'm one of those folks who thinks the client/wc distinction was foolhardy.
> I've come around to being alright with the modularization we have today with
> the two libraries.  But I strongly believe that there should never have been
> a *public* svn_wc.h, and that what lives there now should never, ever be
> revised again save for mass deprecation.
>
>> s/client/repos/g
>> s/WC/fs/g
>> s/working copy/versioned filesystem/g
>> repeat
>
> This isn't a fair comparision.  The FS API does something completely
> meaningful, independent of the larger Subversion version control system.
> Actually, depending on how you look at it, it could be said that the FS API
> and library *are* Subversion.  Everything else is just tooling to help
> mortals use the FS.
>
>> With a sane, useful public WC API you can at least think about plugging
>> different WC backends ... someday. Same goes for the repos/fs separation.
>
> We have no reason to believe that anyone would want to write a new WC
> storage layer, but that's not so important.  I see two other matters that
> are, though.
>
> First, it's not the lack of a *public* WC API that would be a blocker to
> implementing a new WC storage layer.  The lack of a WC API, sure, but it's
> publicity is disinteresting.
>
> Secondly, it's *extremely* unlikely that someone would want to use the
> Subversion WC library independently of Subversion itself.  Using the terms
> you have above, there's independent value in having a "versioned
> filesystem"; not so much in a "working copy".
>
> --
> C. Michael Pilato <cmpilato_at_collab.net>
> CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
>
>
Received on 2011-02-18 12:10:33 CET

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.