On 08 Mar 2022, Daniel Shahaf wrote:
Sure. I was asking whether by "once the user has a local
pristine" you
meant a pristine — as in, a file under .svn/pristine/ that
.svn/wc.db
knows about and uses — or Alice making a local copy of the
contents of
file@BASE somewhere libsvn doesn't know about.
Well, depending on the context, I may be using the word "pristine"
flexibly. Sometimes I mean a literal integrated-into-wc-metadata
pristine, and sometimes I just mean "an extra copy of the file,
that the user has made locally".
(It's possible that the degree of precision you would like in this
sub-discussion is not one I'm willing to adhere to consistently
:-). I can't always predict what will matter to a given
interlocutor. But I'll try to be sufficiently precise in my
responses below at least.)
A manual copy of the BASE revision would "serve for local diffs
and
reverts", indeed, but I would hestitate to recommend this,
because diff
and revert are both core operations. If users need to reinvent
these
two wheels, then:
- All the advantages of having just that one well-known «svn
revert»
button that all the users' GUI clients and scripts can press
are lost
- The local disk storage cost will be paid, but without all the
benefits: e.g., commit will use a self-delta rather than a
delta
against BASE even if the file format does lend itself to binary
diffs;
ra_serf's ability to not download a file if the wc has another
file
with the same sha1 won't be used; the keyword-contraction and
diff-ignore-content-type features of «svn diff» will need to be
reimplemented; etc.
- We might leave a bad impression on potential users
As an MVP alternative, some sort of command to hydrate a single
file,
perhaps, as you have proposed? CLI-wise, I'll just say we might
want to
mark such a command as experimental (name it "x-foo" and document
it has
reduced forward compatibility promises). Backend-wise, we'll
want to
ensure a manually-hydrated file doesn't get dehydrated too soon.
What's "too soon"? Until the user explicitly requests or permits
dehydration. If hydration was manual, so should dehydration be.
Makes sense?
Yes, thanks for the suggestion, and I agree. I would love for MVP
or MVP+1 to have an explicit "rehydrate" UI. I think there
*might* be some value to shipping MVP without such a feature, in
order to first get some real-world experience with how people use
pristine-less working copies, before we make long-lasting UI
decisions.
But anyway, +1 to the general idea.
The context of all this is whether 'update' should fetch
pristines for
modified files. I guess it should not do so by default (there's
no
reason to incur the costs, and the user has opted in to
pristines-on-demand),
but I don't think we should tell users to keep pristines _and not
tell
libsvn_wc about them_. The cost of implementing «svn x-hydrate»
(however named) is smaller than the cost of asking users to
reimplement
core version control functionality.
Users can already copy files behind Subversion's back, of course.
I'm worried that implementing 'svn x-hydrate' commands now would
be premature -- we don't know enough about real-world usage yet.
I'd feel more comfortable putting out one release (of
x-hydrate-less MVP) to get feedback on pristine-less working
copies. We could even say that we're considering adding x-hydrate
commands but that we're waiting until the next release so we can
make sure our UI ideas match people's actual needs.
Anyone else have thoughts on this?
If we think there are use-cases in which users will want to have
a pristine for a modified file, whether those use-cases involve
«commit»
or «diff» or «revert» or whatever else, then that pristine
shouldn't be
just the user's private copy of BASE; it should be a real
pristine, live
in .svn/pristine/ and be known to wc.db, and used for all svn
operations,
not just those the user has reimplemented.
I understand the motivation. There are reasonable arguments both
ways for shipping MVP with/without x-hydrate functionality.
What do others think?
This way, by default «commit» will send self-deltas, but if the
user
wants a pristine for diffs or reverts, then reverts, diffs, and
commits
will all use the pristine. There shouldn't be any need for the
user to
reimplement their own pristine store and their own diff and
revert
operations.
And yes, commit might not want to use pristines this way, but
that's
actually a separate feature request: a request to change the
"When
committing a change to a pristineful file, send a delta against
BASE or
a self-delta, whichever is smaller" logic, which IIRC works by
computing
a delta against BASE and comparing its length to the
repository-normal
filesize, to something that doesn't compute a delta against BASE
in the
first place.
Yes, that's a good point (in that last paragraph there), and we
should take it into account when (re)implementing commit logic.
Best regards,
-Karl
