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 <cmpil...@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 <cmpil...@collab.net> > CollabNet <> www.collab.net <> Distributed Development On Demand > >
