On 24 Jan 2022, Daniel Shahaf wrote:
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.
As long as we alias 'svn mop' for 'svn cleanup', it's fine with me
:-).
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.
Yep.
Use-case: to request "fail fast" behaviour rather than commence
a (known to the user to be) long/expensive network retrieval.
Indeed, other tools implement that option, for that exact purpose.
I think it's quite reasonable.
> - «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»).
Before implementing these options (which obviously won't happen in
the first iteration anyway), we should think carefully about
naming and about how much of the underlying implementation detail
we want to expose.
And there are broader UI/UX questions:
Maybe once someone starts working on a (large) file, they are
likely to continue working on it. In which case, we should keep
the pristine until told to drop it. Then 'svn cleanup' could have
an additional behavior: "remove pristine for any unmodified file
that would *normally* not have a pristine (except that the user
manually caused it to have a pristine due to some special action
or circumstance)".
This is a bit different from the current '--vacuum-pristines'
option of 'svn cleanup', by the way, though maybe there should be
some connection.
And maybe a --interactive option would be good, so the user can
interactively choose which pristines to drop and which not!
I'm partly just thinking out loud here, to stimulate us all to
think. None of this affects the initial, whole-WC implementation,
and of course let's keep in mind that the *main* use case will be
already well-served by that initial implementation. These further
improvements are for the future, and perhaps we shouldn't even
make them until we've all had some experience with the initial
simple UI.
Best regards,
-Karl
