On 12 Jan 2022, Julian Foad wrote:
No reason to upgrade an old WC until someone actually wants an
optional pristine.
In principle, an what we ideally desire, agreed. Here I was just
saying
what this branch does as it is now, before being combined with
the
multi-wc-format work, which we're told is needed to accommodate
what we
desire. (I'll be looking into exactly what this means and
whether
avoiding WC database changes and using on-disk pristine presence
alone
is a feasible (perhaps even superior) alternative, as I
mentioned.)
Gotcha -- understood.
Also, the point of this feature is not to remove pristines for
all
unmodified files. It's to make it possible for users to
specific
certain circumstances (generally involving large file size!) in
which the pristine should be omitted *for certain files*.
Understood. That ability (to pick and choose which files it
applies to,
by some client-side config) will need to be added. I'll be
looking into it.
Cool.
Here's an example use case, in case it helps:
At our company, we have a separate repository for large binary
assets, which we call our "bigdata" repository. However, not
everything in that repository is a giant multi-gigabyte blob --
there are also some README files, etc. For those small files, one
naturally wants the pristines, because 'svn diff' is useful
locally on them. But generally no one wants pristines for the
large binary blob files.
So if we have client-side configuration that can specify "no
pristine" based on some combination of one or more of...
- file size
- repository of origin
- path and/or basename
- svn:mime-type property (if present)
- some custom property
...then any developer will be able to get whatever behavior they
need given their local storage constraints.
Different people may make different choices based on available
local storage. A developer with a lot of local disk space might
set her no-pristine size threshold to, say, 5 GB, and thus at
least preserve 'svn revert' ability for those files (I don't think
'svn diff' would be useful for any of the files, though there
might be exceptions even to that). Meanwhile, another developer
with less disk space might choose 100 MB as the limit.
This is why I feel so strongly that the UI needs to be entirely
client side -- only the client side has the information needed to
make the appropriate decision.
By the way, I'll give some more details about our setup, since it
involves a nice trick: our bigdata repository tree is a sparse
mirror of our regular internal corporate repository tree, which is
also in SVN because Subversion's path-based authz is so great when
you have different clients / contractors / employees / partners
all having access to different things. (Note that our source code
is in public Git repositories -- it's all open source. The stuff
I'm talking about here is not source code, though that doesn't
matter for this discussion.)
Having the two SVN repositories be parallel means that we can use
the same authn file and authz file for both :-). So if a person
has access to customer Foo's area in the regular repository, then
by default they also have access to the bigdata assets for Foo as
well. (In the few cases where different access is needed, we just
create an extra subdirectory and update the authz spec
accordingly.)
Most people never need the binary assets, and so they don't pay
those checkout or storage costs -- they never fetch from bigdata.
But a few people *do* need access to the bigdata, and for some of
it the checkout totals can run to hundreds of gigabytes, so
avoiding pristines is not just a nice benefit but rather usually a
necessity.
All this is just our use case, of course. I don't mean that it is
more
important than other use cases others may present. I just wanted
to
give some concreteness to the discussions. I hope others will
post with
their scenarios.
Best regards,
-Karl
