On Wed, Jan 12, 2022 at 4:07 PM Julian Foad <julianf...@apache.org> wrote: > > 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.
This sounds quite sensible to me, especially for the command line client. I suppose 3rd party tools, e.g., GUIs, could implement some "smart" behaviors as long as APIs exist that make it possible, but I agree we should not mess with user expectations of being able to work offline by default. (It's a Good Thing that this is stated explicitly.) More inline, below... > > 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. Simplicity is a good argument. I'm good with that. More below... > > 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) +1 to the above points. > * we choose, now, the simple config setting shall be just a size > threshold alone (likely good enough); Will it complicate things too much to provide the possibility of a particular wc being no-pristines? E.g., a user could supply some switch to 'svn checkout'. If this is possible, it handles the 2nd example use case I mentioned, where a project may contain a very large number of files, not necessarily large binaries, and the user desires to exclude pristines for all of them. Perhaps the network is very fast, or repo and wc are on the same machine, and/or wc is on a ramdrive... This could be quite beneficial in a number of different ways and opens up some interesting future directions like repo-in-wc. > * 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. +1. Cheers, Nathan
