[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: Branko Čibej <brane_at_apache.org>
Date: Thu, 14 Sep 2017 14:55:28 +0200

On 14.09.2017 14:46, C. Michael Pilato wrote:
> 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?

Indeed, however the wcroot struct is not part of any context or baton
that gets passed around; it's created on demand by functions within
libsvn_wc. It would take moderately drastic surgery to change that.

One possibly sane change would be to take the format _out_ of
svn_wc__db_wcroot_t and put it into svn_wc__db_t, with appropriate
getters and setters; that one's part of svn_wc_context_t. If I do that,
the answer to my first question would be set in concrete, more or less.

> 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)?

Yes. That in fact already done; it was the easy part. :)

The multiple-format support feature would be a lot less usable if users
couldn't create new working copies in a not-latest format, for
compatibility with other tools.

> Will 'svn upgrade' someday be able to upgrade to anything other than the
> most-current supported format?

It can already do so on the branch. Of course there aren't that many
formats to choose from right now.

-- Brane
Received on 2017-09-14 14:55:34 CEST

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