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
