On 24 Jan 2022, Daniel Shahaf wrote:
[...] To be clear, I'm not trying to pick nits; I'm trying to
make sure that we don't make unwarranted assumptions. We might
get a lightbulb moment from that. (E.g., that's basically how we
realized we should deprecate --reintegrate, IIRC.)
Agreed. I found Julian's initial analysis very helpful, and still
think it's overall reasonable & correct -- but now is definitely
the time to probe our assumptions carefully, so your questions are
good to ask.
Which brings me to a less contrived / more general point: What if
the user _knows in advance_ they'll need a pristine? Shouldn't
there be: — - a way to say "I'm about to change a large,
diffable file; detranslate
it into the pristine store before I touch it"? Perhaps even
make files read-only at the OS level (as with svn:needs-lock)
so the user doesn't modify the file accidentally until its
pristine has been set aside?
'svn hydrate'? (I can't even tell if I'm joking.)
- a way to say "I've modified a large, diffable file and I'm
about to go
offline; download a pristine for this file now"?
Same command, I think?
That is: the goal is to get a local pristine copy. We already
know the checksum(s) for the pristine and the clean working file
(normally they'll be the same, unless there was keyword
translation). If we can detranslate the working file to get the
pristine, then we do that; next option is to try fetching the
pristine from the repository.
- «svn commit --keep-pristines», in case Alice has two logical
changes
that she'd like to make in separate commits?
Maybe, or maybe one just uses 'svn dehydrate' ('svn hydrate
--dehydrate' :-) ) when one is done working on the file.
+1 to starting with a per-WC knob. However, all else being
equal, we should try to design this in a way that allows future
extensions, including extensions that set pristinefulness on a
finer granularity than per-WC. (That's similar to what I said
earlier in this thread in [1]).
Completely agree. I assume this is what Julian had in mind all
along. Identifying those knobs now is a good idea, though, in
case they have any design implications.
Best regards,
-Karl
