Regarding the disk space savings, I haven't tested against pristineless, but
the savings are also close to 50% on a repo with lots of large binary files:
The large SVN repo we use at work is a 1.6TB fresh checkout on disk, with this
change that drops to 865GB (on Windows+ReFS). A huge saving due to the large
number of art assets in our repository!
I ran some tests with and without the patch, the ~10% slowdown is from losing
the streamy checkout benefits and instead having to do extra system calls.
1.16: 1588.22 GB 169 mins
1.16-CoW: 864.76 GB 202 mins
volatile svn_atomic_t svn_wc__test_writer_copy_source_count = 0;
I agree this extern debug atomic for at est is awkward, I didn't really see any
way around it if we want a test that checks the reflink path is actually being
taken. Adding platform native methods for checking if a file is reflinked for
testing reasons is not practical, given it's also not a simple to work out via
the filesystem anyway. However, we could discuss reworking or removing the test
to avoid this weird variable. I'm not sure about the warning you are seeing, I
don't think I saw that when I built for windows/linux.
This means that, for example, a Subversion working copy, where most
files havesvn:eol-style=native, would see no improvement, correct?
No they would see no benefit, which is why this saves slightly less space than
pristineless. But in our large repo 95% of the disk usage comes from large
binary blob files which can benefit. I realise this isn't the case for
everyone, but if you have a repo with only code files withsvn:eol-style=native
it's probably not large enough to be a disk space concern in the first place.
How does this interact with the pristines-on-demand feature? How is this
tested?
There isn't a test for this but the "pristines-on-demand" takes precedence over
reflinking, they shouldn't interfere with each other.
If clients that do not support CoW use the same working copy as a client
that does, how do they interact?
Yes! That's the best part, there's no working copy format change. The
filesystem handles the reflinked files transparently once they've been set up.
If you did a checkout on a CoW supporting drive (ReFS) and got the disk usage
benefits of CoW you would still be able to copy your svn checkout folder to
another drive with no CoW support (NTFS), it would transparently expand to its
full size on the new drive, but otherwise would be fully functional.
Does this happen on every invocation? Concretely: if I'm on Windows with
NTFS, I'll get two file open attempts instead of one, every time?
There are details on this in the op but no, there is a 1 time check at the start of a
checkout/update operation to see if the current filesystem supports CoW. If not all files
will use the current "streamy-checkout" path avoiding any extra system calls.
Not that this is indicative of patch quality in general. But I'd have
preferred to see some discussion on dev@ before being presented with
160k of patch. It's basically unreviewable, I don't even know where to
start.
I was originally working on this feature for myself and work colleagues. It was initially
a hacky, Windows-only implementation. Then I added linux, polished it a bit and ended up
fleshing it out a lot more. It got to the point were I figured I might as well bring it
all together into a patch and share it here to get people's thoughts on it. I do realise
it's a huge patch, and in the "Notes" section of the op I laid out how it could
be split into several parts. But I didn't want to do the work to split it before gauging
general interest in the feature.
On Fri, 5 Jun 2026 at 19:50, Sean McBride<[email protected]> wrote:
On 4 Jun 2026, at 7:31, Jordan Peck via dev wrote:
This patch saves disk space on supported filesystems for byte-identical file
installation by utilising filesystem clone APIs.
FWIW, just the other week, I've used this tool:
https://github.com/ttkb-oss/dedup
on my Mac, and several others in our office, to deduplicate files in our svn
(1.14) working copies. It detected identical files not only in our /branches vs
/trunk but also among the pristine copies, and it deduplicated them using APFS'
cloning feature.
It didn't cause svn to freak out, so that bodes well.
Sean
