On 14.09.2017 11:48, Johan Corveleyn wrote:
> 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).
Very much out of scope, though not impossible, given how I've decided to
go about supporting multiple formats. Downgrading for small changes
should be easy ... not so much for large ones, but it's really just a
matter of throwing enough code at the problem.
> 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 :-).
Some of the necessary code has been in place for years ... but the
addition of LZ4 compression finally pushed me towards doing something
about it. I have a nasty suspicion that using gzip compression would
have been disappointing in terms of performance. It's just a hunch, however.
>> 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.
That's the way I'm leaning, too. I do have to figure out if the code for
that is already in place, or whether I need some more wc-fu to invent it. :)
> 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 ...
There was such a vague plan. And, hehe, this is the kind of WC format
change that I would not want to write downgrade code for.
-- Brane
Received on 2017-09-14 14:47:30 CEST