Re: [PROPOSAL] Allow plaintext passwords again.

[Mark Phippard]

On Fri, Jan 21, 2022 at 7:22 PM Karl Fogel  wrote:
>
> On 21 Jan 2022, Mark Phippard wrote:
> >One aspect of the previous thread that came up is that someone
> >demonstrated a simple script to create a cached password (as a
> >workaround for current users). That is what led to the idea of
> >formalizing this using the svn auth command to create this file.
> >
> >I am the only one calling this a backdoor. I am saying that if I
> >am an
> >admin that does not want plaintext passwords being cached and you
> >then
> >create a simple way to do exactly that, then that is a backdoor
> >around
> >the policy I wanted. Maybe it is not the right term to use
> >here. I am
> >just saying if we are going to make someone compile their own
> >binaries
> >we might as well at least give them what they want.
> >
> >I return to my "two camps" argument. The people that do not want
> >plaintext passwords to be cached ... do not want them being
> >cached.
>
> I see what you mean.
>
> If svn is compiled to not cache passwords, but a legacy cached
> password exists on disk for a given repository, should svn not
> only not read it but actually warn the user that the cached
> password exists?

IMO, it is not necessary and if a compiler option disables the code
then I would envision we do not even have any code running that is
looking for those files to give the warning.

That said, I do not have a strong opinion on this one.

Mark

Re: [PROPOSAL] Allow plaintext passwords again.

[Karl Fogel]

On 21 Jan 2022, Mark Phippard wrote:

One aspect of the previous thread that came up is that someone
demonstrated a simple script to create a cached password (as a
workaround for current users). That is what led to the idea of
formalizing this using the svn auth command to create this file.

I am the only one calling this a backdoor. I am saying that if I 
am an
admin that does not want plaintext passwords being cached and you 
then
create a simple way to do exactly that, then that is a backdoor 
around
the policy I wanted. Maybe it is not the right term to use 
here. I am
just saying if we are going to make someone compile their own 
binaries

we might as well at least give them what they want.

I return to my "two camps" argument. The people that do not want
plaintext passwords to be cached ... do not want them being 
cached.


I see what you mean.

If svn is compiled to not cache passwords, but a legacy cached 
password exists on disk for a given repository, should svn not 
only not read it but actually warn the user that the cached 
password exists?


Best regards,
-Karl

Re: [PROPOSAL] Allow plaintext passwords again.

[Mark Phippard]

On Fri, Jan 21, 2022 at 6:39 PM Karl Fogel  wrote:

> >2) If we have to add a new compile option, then I suggest we go
> >all
> >the way and also close the backdoor that exists. IOW, if svn is
> >compiled without plaintext support then it also should not be
> >able to
> >read an existing stored plaintext credential.
>
> That was a deliberate compatibility move, and I'm not sure we
> should change it.  Can you describe the harm that would come from
> keeping that behavior vs changing it as you describe above?  I
> guess I don't see how it's a "backdoor".

One aspect of the previous thread that came up is that someone
demonstrated a simple script to create a cached password (as a
workaround for current users). That is what led to the idea of
formalizing this using the svn auth command to create this file.

I am the only one calling this a backdoor. I am saying that if I am an
admin that does not want plaintext passwords being cached and you then
create a simple way to do exactly that, then that is a backdoor around
the policy I wanted. Maybe it is not the right term to use here. I am
just saying if we are going to make someone compile their own binaries
we might as well at least give them what they want.

I return to my "two camps" argument. The people that do not want
plaintext passwords to be cached ... do not want them being cached.

Mark

Re: [PROPOSAL] Allow plaintext passwords again.

[Karl Fogel]

On 21 Jan 2022, Mark Phippard wrote:
In terms of what needs to be done, maybe I am wrong, but I did 
not
think we had any mechanism in place where someone could choose 
not to
compile in support for this feature. So that is new code that 
would

need to be added.


Well:

  
 r1845377 | brane | 2018-10-31 14:40:21 -0500 (Wed, 31 Oct 2018) 
 | 6 lines Changed paths: 
M /subversion/trunk/configure.ac 
  
 Disable plaintext password storage by default. It can still be 
 enabled at configure time.   * configure.ac: Invert the default 
 of the plaintext-password-storage 
option and update its help text. 
  
 


:-)

1) I think there should be an easy way to know if the support 
exists
or not. I am thinking "svn --version" maybe prints out if 
plaintext is

available? So an admin could run this command and would look to
confirm they do NOT see that in the output? Maybe this already 
exists?


As Nathan Hartman pointed out in his reply, we already do this (I 
wasn't aware of it either until Nathan's mail, by the way!).


2) If we have to add a new compile option, then I suggest we go 
all

the way and also close the backdoor that exists. IOW, if svn is
compiled without plaintext support then it also should not be 
able to

read an existing stored plaintext credential.


That was a deliberate compatibility move, and I'm not sure we 
should change it.  Can you describe the harm that would come from 
keeping that behavior vs changing it as you describe above?  I 
guess I don't see how it's a "backdoor".


Best regards,
-Karl

Re: A two-part vision for Subversion and large binary objects.

[Karl Fogel]

On 21 Jan 2022, Julian Foad wrote:

Only for commands that need them, but, as mentioned above,
pesimistically for every file that the command *possibly* 
pertains to.

I'll follow up on that.


*nod*  Will look for that, thanks.

It will not fetch for 'commit' once I commit Evgeny's tiny patch 
to make

it so.


Great.


The only case in which [that] might be unsatisfactory is [...]
   - there is a subset of files on which the user needs to 
   work [...]
often enough that fetching their pristines "on demand" is a 
problem;

[...]
It is not one of the cases driving this [...]


Well, that case is almost exactly our use case at my company 
:-),

except that I think fetching pristines on demand will be fine.


Well, that's the crucial difference: in your case, fetching some
pristines on demand sometimes is not a problem, so this solution 
works.


Yep, agreed!

Best regards,
-Karl

Re: A two-part vision for Subversion and large binary objects.

[Karl Fogel]

On 21 Jan 2022, Johan Corveleyn wrote:
I like where this is going. Thanks to all involved for pushing it 
forward :-).


You're welcome!  Thanks for the use-case example, too.

Any chance your company would want to join the consortium that is 
funding this work?  Please follow up with my privately if so (or 
introduce me to the right person if needed).


We have a few companies in the consortium already, but I'm always 
keeping an eye on budget and scope -- the more we pool our 
resources, the less it costs for each member and the more 
risk-resilient this overall effort becomes.


(I have a great deal of faith in the implementors, who are skilled 
and who know Subversion well.  But anyone who's managed projects 
will do whatever they reasonably can to reduce risk! :-) )


Best regards,
-Karl

Just as another data point, at my company we have a slightly 
different

use case where this feature would be great (I think), and where a
simple per-WC-yes/no switch would work fine. In this case, we'd
probably also want a "system-wide runtime config area default".

The use case: we have a couple of build machines for "official 
full
builds" (for test, staging, production, ... different stages) of 
our
major applications. To save time, for most big applications, we 
keep

re-using the large checked-out working copies (update, build, and
switch to the next release branch if there is a next release). We 
also
use those same working copies for backporting cherrypick merges 
to our
release branches (it's all part of our release process, supported 
by

build scripts and procedures to do these things).

So, currently, our largest build server has 400 such working 
copies on
disk, and they remain there "dormant" until someone updates, 
builds,
cherrypick-merges, commits-a-tag-from-WC, ... Totalling around 
450 GB
at the moment. Not an absolute killer, but this is a growing 
number,

and our sysadmins would be quite happy to see that number be +/-
divided by 2 :-). Besides, these build servers are located in our 
data
centers, "right next to" the SVN server, i.e. having a 1 Gb or 10 
Gb
connection to the repository. A perfect fit for "I don't need 
99.9% of
those pristines most of the time, and it's blazingly fast to get 
them

when needed".

Ideally, after pristines-on-demand become possible, I'd do the 
following:
- Set a system-wide flag to make pristines-on-demand the default 
for new WC's.

- Run a script to "convert" all existing working copies to
pristines-on-demand (setting the per-WC flag).
- Run a script to "vacuum-pristines" those converted working 
copies.
- Receive chocolates from our sysadmins (probably not, but I can 
try).


(BTW: a lot of those working copies are similar, so a feature to 
have
a "shared pristine store" would also help, but that's another 
feature

altogether, and perhaps much more difficult to get right -- both
features would solve the wasted-disk-storage problem here, so I'm
happy either way)

Kind regards,

Re: A strong WTF on compiling out plaintext password support by default?!

[Karl Fogel]

On 21 Jan 2022, Bernard Boudet wrote:
- There should be a single option in the repository config to 
define
 whether that repo permits client-side plaintext password 
 storage (or

 perhaps define which are the permitted/denied caching methods).


Hmm.  A design principle that I think is generally solid but is 
especially important in free software: since the server by 
definition cannot reliably dictate policy about matters that can't 
affect the server -- matters that the server cannot in fact even 
discern -- the server should to try to in the first place.


It's like a chat app that obeys a server-sent signal to destroy a 
local copy of a message.  That app is ultimately not serving the 
needs of the user whose hands are holding the device.


There is a better way to achieve what you want: by distributing 
recommended run-time configurations to users (perhaps even by 
keeping those configurations under version control and 
distributing them that way!).  This is a purely client-side issue, 
and client-side run-time config controls the client.  If 
organizations want to influence client behavior, that run-time 
config is where to do it.  If the organization wants to monitor 
the users' computers to see if that config is ever changed, well, 
I wouldn't want to work there, but they can do that -- it's common 
enough for organizations to monitor work-owned machines.


Let me be very clear: if Subversion had this "feature", I would 
definitely be compiling my client to disobey the signal and lie to 
the server :-).


Best regards,
-Karl

Re: A strong WTF on compiling out plaintext password support by default?!

[Bernard Boudet]

Hi all,

The current situation makes certain work-flows, unworkable.  It also
encourages the use of a modified or out-dated client, to "get the job
done", which then itself becomes a security risk more generally.

Reverting to the "old way" and adding a compile-time option is viable,
IMHO, only as a temporary solution in the absence of something better.

Common pre-built distribution binaries benefit the user with
convenience *and* security.  From what I have read, it seems that a
compile-time option will not be the final word on the matter.

As for "auth add", as I understand it, this leaves open some security
concerns, so would not be the final word on the matter either.

The issue manifests itself at the client side.  I will suggest it can
be solved looking at the server side.  This is my RFC (and bearing in
mind I'm just an interested user/admin rather than a dev):

- There should be a single option in the repository config to define
  whether that repo permits client-side plaintext password storage (or
  perhaps define which are the permitted/denied caching methods).

- The configuration option should apply to the entire repository, that
  is it should be path independent.

- The configuration option should apply regardless of client username.

- The configuration option should apply regardless of read/write
  request.

- The configuration may differ per repository, if the server instance
  serves multiple repos.

- So I think it belongs in svnserve.conf.

Then, either:

- during authentication the client shall signal to the server the
  password storage method in use and the server shall deny auth if it
  cares

- and/or the client shall have means to query the server as to
  permitted storage methods and determine its own behaviour
  accordingly

- in any case, the user's work-flow should be unchanged from that as
  it has ever been.

Default behaviours:

- The default unconfigured behaviour should be that the server signals
  to the client that plaintext password storage is prohibited.

- There should be no compile-time option in either the server or
  client to alter this behaviour.

- There should be no run-time option in the client to alter this
  behaviour (obviously).

Backwards compatibility:

- When accessing an older server, the new client behaviour should be
  as it is currently.  That is the user has no way to enable plaintext
  password storage.

- For older version clients, the behaviour should be whatever it is
  currently for that version.

- If that is unacceptable, the server could deny auth to prior version
  clients, with a separate run-time option to control this.  In any
  case, if it's a problem, it's also one which is unaddressed by the
  current situation.

- In case of an already stored plaintext password, use of this will be
  permitted only if the repository enables it.

Benefits:

- No change to client UI, documentation, or work-flow.

- It is a simple matter for the admin to allow plaintext password
  storage for clients of their repository.

- It provides for multiple repo's running from a single svnserve
  instance to dictate differing security models.

- It provides for the user to access multiple repo's from their same
  client software, intentionally mixing password caching methods, and
  without fear of leaking important credentials.

- Enforcement is at the central admin's discretion, as must be
  expected from an "Enterprise Class" solution.

Flaws:

- The scheme is dependent upon client software honouring the rules and
  can be defeated with hacked/rebuilt/ported client software, as is
  the case currently.

- There are many authentication schemes.  I don't know, but this could
  entail a lot of work.

- Probably some things I haven't thought of.

Sorry for rambling on. ;) I hope it may be of use, even if for now the
"old way" is resumed.

Bernard.

Re: [PROPOSAL] Allow plaintext passwords again. (was: Re: A strong WTF on compiling out plaintext password support by default?!)

[Nathan Hartman]

On Fri, Jan 21, 2022 at 7:35 AM Mark Phippard  wrote:

> On Thu, Jan 20, 2022 at 11:50 PM Karl Fogel  wrote:
> >
> Putting the hat on of someone that wants to turn off plaintext passwords
> ...
>
> 1) I think there should be an easy way to know if the support exists
> or not. I am thinking "svn --version" maybe prints out if plaintext is
> available? So an admin could run this command and would look to
> confirm they do NOT see that in the output? Maybe this already exists?



Yes, svn --version does print this information. See near the end:

[[[
$ svn --version
svn, version 1.15.0-dev (under development)
   compiled Apr 12 2021, 15:50:36 on x86_64-pc-linux-gnu

Copyright (C) 2021 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/

WARNING: Plaintext password storage is enabled!

The following repository access (RA) modules are available:

* ra_svn : Module for accessing a repository using the svn network protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using
serf.
  - using serf 1.3.9 (compiled with 1.3.9)
  - handles 'http' scheme
  - handles 'https' scheme

The following authentication credential caches are available:

* Plaintext cache in /home/nate/.subversion
* Gnome Keyring
* GPG-Agent
* KWallet (KDE)
]]]

Cheers,
Nathan

Re: A two-part vision for Subversion and large binary objects.

[Julian Foad]

Vincent Lefevre wrote:
> Do you mean that "svn diff" at the root will fetch everything
> even if no files are modified?

No, only the pristines for files that are modified.

Re: A two-part vision for Subversion and large binary objects.

[Vincent Lefevre]

On 2022-01-21 11:15:04 +, Julian Foad wrote:
> Premature Hydrating
> 
> The present implementation "hydrates" (fetches missing pristines) every
> file within the whole subtree the operation targets. This is done by
> every major client operation calling svn_client__textbase_sync() before
> and afterwards.
> 
> That is pessimistic: the operation may not actually touch all these
> files if limited in any way such as by
> 
>   - depth filtering
>   - other filtering (changelist, properties-only, ...)
>   - terminating early (e.g. output piped to 'head')
> 
> That introduces all the fetching overhead for the given subtree as a
> latency before the operation shows its results, which for something
> small at the root of the tree such as "svn diff --depth=empty
> --properties-only ./" may make a significant usability impact.

Do you mean that "svn diff" at the root will fetch everything
even if no files are modified?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [PROPOSAL] Allow plaintext passwords again. (was: Re: A strong WTF on compiling out plaintext password support by default?!)

[Mark Phippard]

On Thu, Jan 20, 2022 at 11:50 PM Karl Fogel  wrote:
>
> On 20 Jan 2022, Mark Phippard wrote:
> >I have made the suggestion before and I want to say there was
> >agreement from anyone that responded. So if nothing else anyone
> >that
> >objects to this is not speaking up. I think the main issue is
> >that no
> >one has wanted to step forward and make the change.
> >
> >I think we all know there are people who legitimately want the
> >additional security. They are either not reading any of this or
> >have
> >decided they can accept having a compile time option and just
> >want to
> >wait and see what happens. Most likely it is the former.
> >
> >Making the change can at least make them come forward again.
>
> I've changed the Subject line to reflect that I'm concretely
> proposing now that we do this.  I'll volunteer to do it, though am
> happy for anyone else to as well.
>
> I think it's just a matter of reverting r1845377, right?  (And
> updating CHANGES, etc.)
>
> If someone knows a reason why it's more complex than what I've
> described above, please speak up.

First off, thanks for volunteering.

In terms of what needs to be done, maybe I am wrong, but I did not
think we had any mechanism in place where someone could choose not to
compile in support for this feature. So that is new code that would
need to be added.

Putting the hat on of someone that wants to turn off plaintext passwords ...

1) I think there should be an easy way to know if the support exists
or not. I am thinking "svn --version" maybe prints out if plaintext is
available? So an admin could run this command and would look to
confirm they do NOT see that in the output? Maybe this already exists?

2) If we have to add a new compile option, then I suggest we go all
the way and also close the backdoor that exists. IOW, if svn is
compiled without plaintext support then it also should not be able to
read an existing stored plaintext credential.

I think closing the backdoor would be a nice addition to help soften
any wounds this change creates.

Mark

Re: A two-part vision for Subversion and large binary objects.

[Julian Foad]

I have been studying when this implementation fetches pristines. Two
concerns about performance in the current implementation:

1. scanning the whole subtree, calling 'stat' on every file

2. premature hydrating


Scanning with 'stat'

I'm concerned about the implementation scanning the whole subtree,
calling 'stat' on every file to determine whether the file is "changed"
(locally modified). This is done in svn_wc__textbase_sync() with its 
textbase_walk_cb().

It does this scan on every sync, which is twice on every syncing
operation such as diff.

Don't we already have an optimised scan for local modifications
implemented in the "status" code? Could we re-use this?


Premature Hydrating

The present implementation "hydrates" (fetches missing pristines) every
file within the whole subtree the operation targets. This is done by
every major client operation calling svn_client__textbase_sync() before
and afterwards.

That is pessimistic: the operation may not actually touch all these
files if limited in any way such as by

  - depth filtering
  - other filtering (changelist, properties-only, ...)
  - terminating early (e.g. output piped to 'head')

That introduces all the fetching overhead for the given subtree as a
latency before the operation shows its results, which for something
small at the root of the tree such as "svn diff --depth=empty
--properties-only ./" may make a significant usability impact.

Presumably we could add the depth and some other kinds of filtering to
the tree walk. But that will always leave terminating early, and
possibly other cases, sub-optimal.

I would prefer a solution that defers the hydrating until closer to the
moment of demand.


Evgeny, have you looked into these possibilities at all? What are your
thoughts about these?

- Julian

Re: A two-part vision for Subversion and large binary objects.

[Julian Foad]

Replying to the last three posts (Nathan, Karl, Johan).

Nathan wrote:
> The pristine for a given file is not fetched until the file is
> modified and an
> operation pertaining to it requires the pristine.

That's basically how the 'pristines-on-demand' branch is working.
However, the present implementation fetches ('hydrates') pristines for
every file within the whole subtree the operation targets. That is
pessimistic: the operation may not actually touch all these files if
limited in any way such as by depth filtering. I'll follow up with a
separate report on that.

> Once fetched, the pristine remains present until the file becomes unmodified
> through either 'commit' or 'revert'.

More precisely, the pristine remains until the file is once again
detected to be unmodified, which could happen by any means including
'commit' or 'revert' or being returned to its previous state by the user
outside of Subversion's control.

> [...] it occurred to me that if the file is deleted, the
> pristine (if present) should be deleted as well. (Potential caveat: if
> the file
> is modified, subsequently marked for deletion with '--keep-local', and
> subsequently the user runs 'svn revert', the expected result is to
> restore the original contents as they appear in BASE.)

The expected result for reverting any file marked as "deleted", no
matter whether it is present on disk, modified or not, is to return it
to pristine state.

I suppose your instinct is to not "waste space" once the user has
decided the file is no longer wanted, especially if it's a huge file and
the pristine isn't going to be useful for diffs etc.

That all makes sense once we commit the delete, but until then it's
considered a temporary working state that we might want to revert.

Because this file is in a state of local modification (in the general
sense that includes delete), I think the pristine should be kept, in
line with the simple and general policy that we should keep pristines
around for all files in a locally modified state. I understand we could
treat the "deleted" state specially, but not sure we should.

>From what I understand so far of the current state of implementation, a
delete operation will first "hydrate" the textbase storage by copying
the file from working storage if it's present and unmodified, before
deleting it; and otherwise will mark it as "pristine needed" to be
fetched later on demand.


Karl wrote:
> And it only fetches pristine for commands that absolutely need
> pristine, I assume?  (I think you said earlier that it does not
> fetch for 'commit'.)

Only for commands that need them, but, as mentioned above,
pesimistically for every file that the command *possibly* pertains to.
I'll follow up on that.

It will not fetch for 'commit' once I commit Evgeny's tiny patch to make
it so.

>> The only case in which [that] might be unsatisfactory is [...]
>>- there is a subset of files on which the user needs to work [...]
>> often enough that fetching their pristines "on demand" is a problem;
>> [...]
>> It is not one of the cases driving this [...]
> 
> Well, that case is almost exactly our use case at my company :-),
> except that I think fetching pristines on demand will be fine.

Well, that's the crucial difference: in your case, fetching some
pristines on demand sometimes is not a problem, so this solution works.


Johan wrote:
> Just as another data point, at my company we have a slightly different
> use case where this feature would be great (I think), and where a
> simple per-WC-yes/no switch would work fine. In this case, we'd
> probably also want a "system-wide runtime config area default".
> 
> The use case: [...] "I don't need 99.9% of
> those pristines most of the time, and it's blazingly fast to get them
> when needed".
> 
> Ideally, after pristines-on-demand become possible, I'd do the following:
> - Set a system-wide flag to make pristines-on-demand the default for
> new WC's.

Makes sense.

> - Run a script to "convert" all existing working copies to
> pristines-on-demand (setting the per-WC flag).

Agreed, we need to ensure there is a way to do this.

> - Run a script to "vacuum-pristines" those converted working copies.

Agreed, if the previous step doesn't do it.
(In the current implementation, 'svn upgrade' does this.)

> - Receive chocolates from our sysadmins (probably not, but I can try).

Hehe.

> (BTW: a lot of those working copies are similar, so a feature to have
> a "shared pristine store" would also help [...])

Agreed, that's an alternative with different pros and cons, that would
have approximately the same overall benefit in your case.


- Julian

Re: A two-part vision for Subversion and large binary objects.

[Johan Corveleyn]

On Fri, Jan 21, 2022 at 5:56 AM Karl Fogel  wrote:
>
> On 20 Jan 2022, Julian Foad wrote:
> >The more I think about this, the more I think we are prematurely
> >complicating the requirements in this respect. I'm going to
> >back-track
> >and posit that a simple per-WC switch should suffice for the vast
> >majority of cases, and has the benefit of simplicity. (The user
> >might
> >wish to set this based on the repository location -- local/fast
> >versus remote/slow.)
>
> Personally I'd be very happy to start with this.  We can always
> improve the client-side UI for the feature more in the future.
>
> >I will note that I previously misunderstood the current
> >'pristines-on-demand' implementation as fetching the pristine
> >before a
> >diff (for example) and discarding it afterwards.  In fact it
> >keeps the
> >pristine as long as the file in question remains in a locally
> >modified
> >state, and only discards the pristine when (before or after some
> >client
> >operation) the file is no longer in a modified state. That is to
> >say, it
> >fetches pristines less often than I had thought.
>
> And it only fetches pristine for commands that absolutely need
> pristine, I assume?  (I think you said earlier that it does not
> fetch for 'commit'.)
>
> I like the trick of keeping the pristine, once fetched, for as
> long as the file is locally modified.
>
> >The only case in which a simple per-WC setting might be
> >unsatisfactory
> >is the following combination:
> >
> >  - the repository is "slow" (and/or offline working is
> >  required);
> >
> >  - and, in a single WC:
> >- the WC data set is "huge" (relative to local disk space) in
> >total; and
> >- there is a subset of files on which the user needs to work
> >(requiring diffs, etc.) often enough that fetching their
> >pristines "on
> >demand" is a problem; and
> >- that subset of files is not "huge" in total; and
> >- that subset of files can be distinguished from the rest by
> >metadata.
> >
> >That is certainly a possible case, but we have no suggestion that
> >it is
> >at all common. It is not one of the cases driving this
> >feature. So I
> >think it is not something to design for at this stage.
>
> Well, that case is almost exactly our use case at my company :-),
> except that I think fetching pristines on demand will be fine.
> Thus, we can live with a per-WC setting.
>
> >I'm going to work on getting something more basic (per-WC yes/no)
> >closer
> >to production-ready and then we can re-assess it.
>
> Sounds good!
>
> Best regards,
> -Karl

I like where this is going. Thanks to all involved for pushing it forward :-).

Just as another data point, at my company we have a slightly different
use case where this feature would be great (I think), and where a
simple per-WC-yes/no switch would work fine. In this case, we'd
probably also want a "system-wide runtime config area default".

The use case: we have a couple of build machines for "official full
builds" (for test, staging, production, ... different stages) of our
major applications. To save time, for most big applications, we keep
re-using the large checked-out working copies (update, build, and
switch to the next release branch if there is a next release). We also
use those same working copies for backporting cherrypick merges to our
release branches (it's all part of our release process, supported by
build scripts and procedures to do these things).

So, currently, our largest build server has 400 such working copies on
disk, and they remain there "dormant" until someone updates, builds,
cherrypick-merges, commits-a-tag-from-WC, ... Totalling around 450 GB
at the moment. Not an absolute killer, but this is a growing number,
and our sysadmins would be quite happy to see that number be +/-
divided by 2 :-). Besides, these build servers are located in our data
centers, "right next to" the SVN server, i.e. having a 1 Gb or 10 Gb
connection to the repository. A perfect fit for "I don't need 99.9% of
those pristines most of the time, and it's blazingly fast to get them
when needed".

Ideally, after pristines-on-demand become possible, I'd do the following:
- Set a system-wide flag to make pristines-on-demand the default for new WC's.
- Run a script to "convert" all existing working copies to
pristines-on-demand (setting the per-WC flag).
- Run a script to "vacuum-pristines" those converted working copies.
- Receive chocolates from our sysadmins (probably not, but I can try).

(BTW: a lot of those working copies are similar, so a feature to have
a "shared pristine store" would also help, but that's another feature
altogether, and perhaps much more difficult to get right -- both
features would solve the wasted-disk-storage problem here, so I'm
happy either way)

Kind regards,
-- 
Johan