I looked into the multi-wc-format branch today. Brane wrote previously:
> This basically needs the following:
>
> * a huge sync with trunk;
Done.
> * a way to pass the requested WC format from the command-line into the
WC library when creating a working copy (I never found a nice, clean
way to do that);
Your branch code passes the requested format down from libsvn_client to
libsvn_wc by calling svn_wc__ensure_adm(... format ...). Maybe it's not
nice and clean but I am not sure whether and what could be better. It
doesn't seem qualitatively worse than other interations with libsvn_wc.
> * an actual test for WC compatibility.
There doesn't seem very much to test: the "compatibility" we're speaking
of here is just whether the client accepts the format number as one that
it can work with, and if not then it errors out with the "client too
old" error, doesn't it? I'll see if I can think of any useful smoke test.
Now I'm considering what would be the pros and cons of using
'multi-wc-format', compared with if it's possible to modify the
pristines-on-demand implementation to work with no format bump but just
an on-disk variation of the current WC format. (We haven't proved it's
possible nor that it's impossible.)
How would it work with 'multi-wc-format' branch included?
=========================================================
The 'multi-wc-format' branch allows the client to accept a WC declared
as an older format, and not insist on upgrading it. It does not provide any
special mechanism (such as feature flags) for making the client
behaviour compatible with different versions that it claims to support;
the client must provide that.
Outcome:
- old client, old-format WC
- fine
- old client, new-format WC (pristines-on-demand)
- errors out (cleanly)
> svn diff
> svn: E155021: This client is too old to work with the working copy at
'/.../wc' (format 32). You need to get a newer [...]
- new client, old-format WC
- works like the older version did
- leaves the WC in the old format
- optionally upgrades the WC to new format on request
- new client, new-format WC (pristines-on-demand)
- works like pristines-on-demand
- [OPTIONAL] a way to downgrade WC format, restoring all pristines
How it could work without a WC format bump and DB change?
=========================================================
We would make a variant of the old WC format, keeping the same format
number, and changing something else, something that makes old clients error
out as cleanly as possible.
- Example: Keep ".svn" and its files so still recognized as a WC, but rename
e.g. "pristine" to "pristines-on-demand" so any operation involving
pristines errors out early. (Keeping the existing directory name and just
omitting certain pristine files would be worse: that would lead to an
operation succeeding on some files and then failing part way through when
it reaches a file whose pristine is missing.)
Outcome:
- old client, WC with all pristines present
- works as it always did
- old client, WC with missing pristines
- errors out on some operations
> svn diff
> svn: E000002: Can't open file
'/.../wc/.svn/pristine/03/03xxxx..xxxx.svn-base': No such file or directory
- [CHECK] Are there any scenarios that could involve data loss?
- new client, WC with all pristines present:
- works with WC as-is
- doesn't change WC in any way that would affect old clients, UNTIL
- if user chooses to start omitting pristines, then removes them
- new client, WC with missing pristines
- works like pristines-on-demand
- [OPTIONAL] a way to change back to all-pristines-stay-present
Differences
===========
Essentially not much. In both cases an old client can work with an old
WC but would error out on a pristines-on-demand WC. In both cases a
newer client could work with both WCs without forcing upgrade.
Differences in the error message don't seem significant. Is there
anything I'm missing?
- Julian
