Karl Fogel wrote on Mon, Jan 24, 2022 at 10:50:14 -0600:
> On 24 Jan 2022, Daniel Shahaf wrote:
> > 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.)
Sure! And a script for running «hydrate» automatically could be called
"submerge". :)
And I guess we'll want `svn info` to grow a "Last watered at:" line.
> > - 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.
Agreed, but perhaps have a --offline-only option to let people say
"Error out if you can't complete the operation without contacting the
server". That might be useful for «revert», «diff», etc., as well.
Use-case: to request "fail fast" behaviour rather than commence
a (known to the user to be) long/expensive network retrieval.
> > - «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.
I figured «svn commit --keep-pristines» could be used not only after
manually hydrating but also after implicit hydrating (e.g., after
«echo foo >> iota && svn diff iota»).
As to explicit hydrations:
- After «svn hydrate», should a revert dehydrate (by default)?
I'm not sure. Someone might revert a patch they'd started writing in
order to re-do it; and someone might revert a patch they'd started
writing because they're abandoning it.
«revert» means "discard my local changes". It doesn't mean "throw away
my ability to diff/revert cheaply". So, I guess revert _shouldn't_
dehydrate an explicitly-hydrated file…?
For that matter, perhaps «svn revert iota» shouldn't dehydrate iota, but
leave iota.svn-base behind to be dehydrated by the _next_ svn operation…?
This could help if the revert is followed by further edits to iota.
- After «svn hydrate», should a commit dehydrate (by default)?
I guess so.
- After «svn hydrate», should an explicit «svn dehydrate» be an error if
the file is locally modified?
Dehydrating _unmodified_ files should be a rare situation: it will only
be able to happen after «commit --keep-pristines» or «revert --keep-pristines».
Dehydrating a locally-modified file means that:
+ A subsequent revert will hit the network
+ If the file is deltifiable, subsequent commit won't be able to
deltify against BASE
But then again, perhaps the file isn't deltifiable (whether or not it's
diffable) and the user knows they intend to commit it and not revert it.
I think I'm leaning towards not making this an error. Unix doesn't try
to protect users from themselves, and besides, we can always make this
an error down the road.
Cheers,
Daniel
