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
