On 10 Mar 2022, Lorenz wrote:
Daniel Sahlberg wrote:
Den tis 8 mars 2022 kl 14:17 skrev Daniel Shahaf
<d...@daniel.shahaf.name>:
An alternative is to require the user to let svn know before
they're
starting to edit a file, so we can create a pristine off the
on-disk
file. This way we won't have pristineless modified files in
the first
place.
Not "require". It might be an interesting for some use-case to
have "svn
create-pristine-from-wc" as a manual step, but not adding this
as part of
the normal workflow. I have some wc's that might benefit from
being
pristine-less, but I'm not prepared to pay the extra cost
(time-wise) of an
svn:needs-locking-like step for every file I need to modify. I
don't think
this new command (or option) is MVP.
maybe something like svn:needs-prestine-for-edit similar to
svn:needs-lock?
Or, when finally get a file specific configuration for prestine
handling, that case could be included there?
There's one principle I'm pretty firmly convinced about (I mean,
of course everything is open for discussion here, I'm just saying
where I'm starting from):
Everything to do with pristines is a matter of *local
configuration* ("configuration" interpreted broadly -- it includes
local run-time options, as well as stuff in config files).
In other words, it would be a mistake to create new svn:foo
properties that indicate what the local pristine behavior should
be, because the user's needs are inherently local and specific to
that user's situation (how fast is their network, how much disk
space do they have). In other words, those needs are *not* about
the file itself, but rather are solely about the constraints of
the local (client-side) environment.
Now, local configuration could look at *existing* svn:foo
properties that serve other purposes (e.g., svn:mime-type), in
order to make decisions about pristines, the same way local config
can look at file size to make such decisions. And if some
organization wants to set their own custom non-svn:foo properties
and have local config look at those custom properties for
guidance, that's fine -- that's their business.
But SVN should not be building in such things itself. Pristines
are a purely local phenomenon. An svn:foo property whose purpose
is to give guidance about pristines would be a directional
mistake, IMHO.
Best regards,
-Karl