On Wed, Feb 16, 2022 at 9:07 AM Mark Phippard <markp...@gmail.com> wrote:

> > FWIW, I just assumed that this *isn't* the intended entry point to
> > the feature.  That is, it's just how things happen to be on the
> > branch right now, but (presumably) Julian isn't saying that he
> > thinks this is how users should access the feature in real life.
>
> I also assume that to be the case but want to confirm.
>
> My "assumption" is that the 1.15 WC format includes some new database
> indicator(s) that specify whether or not pristines are being stored
> but the default 1.15 format would include pristines. There will be
> some other option that creates the 1.15 format but with the database
> indicator(s) set to indicate that pristines are NOT being stored.
>
> Presumably there will be some new UX as being discussed that
> implicitly creates a 1.15 format WC with these indicators set.
>
> So really the only use case for creating a 1.15 format using this more
> generic syntax is based on some future version of SVN that lets you
> selectively change this setting after a WC is created? Perhaps on a
> file/folder by file/folder basis.

Setting aside the bikeshedding on what we call this new feature ...
this is the behavior I would expect:

$ svn checkout    ==OR==
$ svn checkout --compatible-version=1.14

Creates a 1.14 compatible WC with pristines

$ svn checkout --compatible-version=1.15

Creates a 1.15 compatible WC with pristines ... there is currently no
reason for a user to do this but it leaves open the option for future
commands and options to selectively hydrate/dehydrate on a file by
file basis.

$ svn checkout --bare      ==OR==
$ svn checkout --compatible-version=1.15 --bare

Bikeshedding aside ... this creates a 1.15 compatible WC without pristines

Mark

Reply via email to