[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: C. Michael Pilato <cmpilato_at_collab.net>
Date: Thu, 17 Feb 2011 09:22:09 -0500

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-17 15:22:57 CET

This is an archived mail posted to the Subversion Dev mailing list.