On Thu, Sep 14, 2017 at 6:01 AM, Branko Čibej <brane_at_apache.org> 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. There's an overview in the branch readme file, but the
> basic idea is this:
>
> * the client will support more than one WC format
> * when working copies are created or upgraded, the default is always
> the latest supported format
> * 'svn checkout' and 'svn upgrade' accept a --compatible-version
> option that says which format of WC to create/upgrade to (the option
> name and semantics are the same as svnadmin's)
> * when update/switch create new externals working copies, they will
> use the parent's format.
Woohoo! Those are huge steps forward IMHO (both "multiple wc formats"
and "compressed pristines"). I hope these features might still make it
into 1.10 :-).
I remember asking for supporting "older wc formats" before [1], and I
very much look forward to this extra flexibility. For example it makes
it much easier to organize the upgrade of an svn client on a big build
server with hundreds of working copies; or to get your users to
upgrade their clients without jumping through too many hoops at the
same time. Excellent!
(BTW: in that old mailthread I also asked about a "downgrading"
possibility (which used to be possible with a python script in /tools
[2] before 1.7) -- could be handy in case of accidental or premature
upgrades -- but I'm guessing that's out-of-scope for your current
work).
Also, it will be great to finally see compressed pristines become a
reality :-). That buildserver with hundreds of working copies,
totalling 200 GB's of diskspace, will be very glad I think :-).
> The implementation of 'svn upgrade' is fairly straight-forward, but I've
> still run into a bit of a conundrum; the question is this: since 'svn
> upgrade' can theoretically be performed on an external WC, should we
> support working copies with different formats in the top level and the
> externals? I haven't checked if we currently do, though obviously, as
> things stand now, upgrading only a subtree doesn't make much sense,
> since the top-level format would still not be supported.
My opinion: don't allow upgrading individual externals-sub-wc's. It's
all or nothing IMHO.
Wasn't there some vague plan to, one day, migrate away from "dir
externals are embedded wc's loosely integrated into the parent wc" to
"dir externals are fully managed by the root wc (no embedded wc with
sugar on top)"? In that case it might be important to view the
"embedded wc technique" as an implementation detail of directory
externals ...
(maybe Bert has some idea about the long-term vision if there ever was one?)
> 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.
Sorry, can't comment on that ...
[1] https://svn.haxx.se/dev/archive-2012-04/0468.shtml
[2] http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/change-svn-wc-format.py
--
Johan
Received on 2017-09-14 11:48:48 CEST