Karl Fogel wrote:
>>> So if we have client-side configuration that can specify "no
>>> pristine" based on some combination of one or more of...
> [... size, properties, etc. ...]
> with a general mechanism for combining conditions, then things
> will be in a good position for future improvement.
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.)
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.
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.
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.
