Karl Fogel wrote on Mon, Jan 24, 2022 at 12:35:10 -0600:
> On 24 Jan 2022, Daniel Shahaf wrote:
> > > > - «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.
+1; I thought so too, just didn't say so explicitly.
> 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.
Let's disentangle this.
In 1.14, «svn cleanup --vacuum-pristines» is used to garbage collect
(GC) unreferenced pristines. The need to run it manually has been
documented as a bug since
https://subversion.apache.org/docs/release-notes/1.7#wc-pristines
(10 years ago).
In pristines-on-demand (as it stands / as currently envisioned)
a pristine may be either absent altogether, present because the file
_had been_ locally modified ("implicitly hydrated"), or present because
the user advised us that the file is _about to become_ locally modified
("explicitly hydrated").
All three cases fall under "Return to the state just after a fresh
checkout". However, as you say, removing implicitly-downloaded
pristines is closer to GC'ing pristines, because both of these cases
dehydrate pristines that had been hydrated by the library's logic,
whereas removal of an explicitly-downloaded pristine undoes an explicit
user action.
As to UI…
- The GC case has no downsides unless the user downdates or switches the
wc, in which case the unreferenced pristines might be used.
[Remind me: is this reuse possible over all RA layers?]
- In the other two cases, the user is making an informed choice to
dehydrate. That is similar to «revert» in that an accidental use may
have non-trivial costs, so we can consider some of «revert»'s
behaviour of defaulting to --depth=empty and not using
svn_opt_push_implicit_dot_target(),
particularly if the file in question has local mods.
I don't immediately see a reason to distinguish between explicitly-
and implicitly-downloaded files at the UI level in this context.
However, right now the question is whether we should be make this
distinction at the library implementation level. (For instance, the
"keep the pristine until told to drop it" scenario implies being able
to make such a distinction.)
More precisely, the question is whether our design permits us to add
this functionality to the library if and when a UI need for it will
want to be implemented.
I think it does. Suppose we release 1.15 without library support for
distinguishing implicitly/explicitly-hydrated pristines, and then want
to add such support in 1.16. I think 1.16 will be able to implement
this without a format bump if it adds to the PRISTINE table a column
declared as «manually_hydrated INTEGER NOT NULL DEFAULT ( 0 )»,
provided 1.16 will handle the possibility that an old, 1.15 client
will dehydrate the pristine in spite of the user's instruction. (The
DEFAULT constraint on column definitions is supported by the oldest
SQLite version supported by 1.14.)
So, unrolling the chain of logic, I think we'll be able to teach the
backend to distinguish explicitly/implicitly hydrated pristines if and
when the UI requires this.
>
Aside: Can we have two working copies share _only_ their pristine
stores? That is, continue to have separate wc.db files, but use the
same on-disk pristine store? That might be easier to implement than
shared wc.db's, and would be useful if multiple wc's need the same file
hydrated.
(Or sharing could happen at a lower level, as with
http://scord.sourceforge.net/, mentioned on issue #525 — although this
particular solution doesn't support wc-ng (≥1.7).)
> And maybe a --interactive option would be good, so the user can
> interactively choose which pristines to drop and which not!
Perhaps; but for now, we can let people write scripts around svn to
achieve this, like how svn-bisect(1) and backport.pl are external.
That's one reason for adding a line to `svn info`.
> 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.
+1 to every single sentence of this paragraph.
Also:
> 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.
We _could_ make them in a way that doesn't require us to provide
compatibility for them forever, such as by releasing them as
"experimental" (cf.
https://subversion.apache.org/docs/release-notes/1.10#shelving),
by releasing an alpha or a nightly and soliciting feedback for
that, or by prototyping in Python what can be so prototyped.
Cheers,
Daniel
(Aside: "explicitly-hydrated" is a bit of a mouthful. I considered just
referring to these as "somatic" and "autonomous" pristines…)
