On 21 Jan 2022, Johan Corveleyn wrote:
I like where this is going. Thanks to all involved for pushing it
forward :-).
You're welcome! Thanks for the use-case example, too.
Any chance your company would want to join the consortium that is
funding this work? Please follow up with my privately if so (or
introduce me to the right person if needed).
We have a few companies in the consortium already, but I'm always
keeping an eye on budget and scope -- the more we pool our
resources, the less it costs for each member and the more
risk-resilient this overall effort becomes.
(I have a great deal of faith in the implementors, who are skilled
and who know Subversion well. But anyone who's managed projects
will do whatever they reasonably can to reduce risk! :-) )
Best regards,
-Karl
Just as another data point, at my company we have a slightly
different
use case where this feature would be great (I think), and where a
simple per-WC-yes/no switch would work fine. In this case, we'd
probably also want a "system-wide runtime config area default".
The use case: we have a couple of build machines for "official
full
builds" (for test, staging, production, ... different stages) of
our
major applications. To save time, for most big applications, we
keep
re-using the large checked-out working copies (update, build, and
switch to the next release branch if there is a next release). We
also
use those same working copies for backporting cherrypick merges
to our
release branches (it's all part of our release process, supported
by
build scripts and procedures to do these things).
So, currently, our largest build server has 400 such working
copies on
disk, and they remain there "dormant" until someone updates,
builds,
cherrypick-merges, commits-a-tag-from-WC, ... Totalling around
450 GB
at the moment. Not an absolute killer, but this is a growing
number,
and our sysadmins would be quite happy to see that number be +/-
divided by 2 :-). Besides, these build servers are located in our
data
centers, "right next to" the SVN server, i.e. having a 1 Gb or 10
Gb
connection to the repository. A perfect fit for "I don't need
99.9% of
those pristines most of the time, and it's blazingly fast to get
them
when needed".
Ideally, after pristines-on-demand become possible, I'd do the
following:
- Set a system-wide flag to make pristines-on-demand the default
for new WC's.
- Run a script to "convert" all existing working copies to
pristines-on-demand (setting the per-WC flag).
- Run a script to "vacuum-pristines" those converted working
copies.
- Receive chocolates from our sysadmins (probably not, but I can
try).
(BTW: a lot of those working copies are similar, so a feature to
have
a "shared pristine store" would also help, but that's another
feature
altogether, and perhaps much more difficult to get right -- both
features would solve the wasted-disk-storage problem here, so I'm
happy either way)
Kind regards,
