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

Reply via email to