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

Reply via email to