On Tue, Feb 15, 2022 at 2:22 PM Karl Fogel <kfo...@red-bean.com> wrote: > As a command-line option for per-WC behavior, it might be > something like this on checkout: > > --local-base=no > > When the option is not provided, the default would be "yes" of > course (in a sense, it's been defaulting to "yes" for decades :-) > ). > > As a configuration option, it would be something like this:
Possibly bikeshedding a bit, but this seems to return to the idea of "turning on" what we are (tentatively) calling "local base"... IMHO it would be better if it were reversed to "--remote-base=yes" to convey that this is non-default and opt-in. (Or possibly allow both.) Alternatively... As a command line switch, how about: "svn checkout --base=local $REPO $WC" or "svn checkout --base=remote $REPO $WC" The default of "--base=local" would be, as Karl points out, the same behavior as in past releases, unless the user configures otherwise. When checking out, it would only be necessary to specify "--base=local" or "--base=remote" if that differs from the configured (or implied) default. A possible future way to change pristine storage in an existing working copy: "svn update --set-base=local" or "svn update --set-base=remote" That conceptually mirrors the current "svn checkout --depth=xxx" and "svn update --set-depth=xxx", (modulo the fact that --depth=xxx has another meaning for operations beside checkout). Hopefully this doesn't cause confusion with, e.g., "--accept=base". No opinion yet regarding configuration option naming. Cheers, Nathan
