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.)
Yes.
> 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