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

Re: Supporting multiple WC formats

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Thu, 14 Sep 2017 08:46:52 -0400

On 09/14/2017 12:01 AM, Branko Čibej wrote:
> As you may have noticed, I started implementing support for multiple WC
> formats on the better-pristines branch, as a prelude to adding support
> for compressed pristines without forcing users to upgrade all their
> working copies.

Sweet!

> The other question that's popped up is more technical: how to
> communicate the WC format down the library stack (for creating externals
> working copies) during checkout/upgrade/switch. The only structure that
> currently holds the format number is svn_wc__wcroot_t, which is strictly
> private to libsvn_wc and not exposed anywhere else. The obvious solution
> of recording the format in svn_wc_context_t seems like a bit of a
> layering violation to me, but on the other hand it's the only bit of
> context that's available to libsvn_client.

(Small correction: I _think_ you mean svn_wc__db_wcroot_t, not
svn_wc__wcroot_t.)

Maybe I'm missing something (like, oh, most of the technical context
required to answer this in detail, plus any degree of Subversion
development momentum), but that which is private can be made effectively
not so with public getter/setter functions, right?

Some other questions (partly out of curiousity, partly out of a hope
that by thinking through them your path becomes more clear):

Are you looking to expose mechanisms all the way up in the client binary
for declaring the version compatibility of a newly checked out working
copy (rather like the way 'svnadmin create' allows for the repository
flavor of this same idea)?

Will 'svn upgrade' someday be able to upgrade to anything other than the
most-current supported format?
Received on 2017-09-14 14:47:18 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.