Nathan Hartman wrote:
> It sounds like the feature is planned to be opt-in [...]
> but do we want to consider opt-out [...or...] e.g., "smart" [...]?
Opt-in sounds most sensible to me.
Rationale: A default behaviour change that would cause problems for
those who expect certain operations to work offline would be Bad. For
existing users for whom the feature would be useful, it is probably
worth their effort to make a config setting to opt in. For users new to
Subversion, a default to some kind of "smart" choice, whether as trivial
as a fixed size threshold or as complex as calculated taking into
account network throughput -- that would be nice -- defaults are
powerful -- but it would not be wise to do this at the expense of
breaking some existing users' expectations. We can't tell
programatically whether a user has "new user" or "existing user"
expectations -- the creation of "~/.subversion" at install time, for
example, doesn't tell us that.
> Once a pristine is fetched, do we want to delete it automatically or wait
> until the user runs a cleanup operation?
As the rationale for the feature is that network fetches are cheap
relative to storage cost, and favouring simplicity over complexity, it
seems clear to me that Evgeny took the correct approach, maintaining an
invariant that pristines only remain present while needed for the
current operation.
> Also there is the question of how the option is activated: per-file, per-wc,
> per-user, per-system? [...]
>
> Answer(s) to the above questions may have a pretty significant effect
> on the
> scope and design of the feature, both immediate and possible future
> directions, so I think it's important to think about this carefully.
I propose making the low level libraries :
* the WC level decision making be per file, making a call-back to
the client/app level, passing the file's basic metadata (size, details
from 'svn info') and subversion properties;
* (to reduce callback overhead allow querying multiple files per call);
* we implement the callback in 'svn' command-line based on a simple
setting that the user can put in the user config file
(~/.subversion/config on *nix)
* we choose, now, the simple config setting shall be just a size
threshold alone (likely good enough);
* consider possibly allowing it to factor in other
metadata/properties, but that quickly gets complex and I can't imagine
much gain in most cases;
* we make libsvn_client use by default that same callback
implementation so third-party client implementations work the same as
ours, by default;
* a different client (such as a GUI client) may supply its own
callback to libsvn_client to get different control, including for
example the possibility of per-wc differences (by looking at the
svn_info.wc_root metadata) or controlled by a subversion property on the
file or on the wc root, and so on.
How does all that sound?
- Julian
