On 5. 6. 2026 15:49, Ivan Zhakov wrote:
On Thu, 4 Jun 2026 at 14:57, Jordan Peck via dev
<[email protected]> wrote:
This patch saves disk space on supported filesystems for
byte-identical file installation by utilising filesystem clone APIs.
The main benefit is reduced disk space usage during checkout,
update, and other working-copy file installs on filesystems that
support copy-on-write/block cloning. When the working file is
byte-identical to the pristine file, Subversion can install it by
copying or reflinking from the pristine instead of storing two
independent physical copies of the same bytes.
[..]
Let me know what you think, questions welcome!
Just out of curiosity, was this patch by any chance created with AI/LLM?
I saw some dubious formatting, and this new warning:
subversion/libsvn_wc/working_file_writer.c:69:23: warning: no previous
extern declaration for non-static variable
'svn_wc__test_writer_copy_source_count' [-Wmissing-variable-declarations]
69 | volatile svn_atomic_t svn_wc__test_writer_copy_source_count = 0;
| ^
accompanied by several extern declarations in other source files, even
if they're only tests.
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.
Some questions:
The main benefit is reduced disk space usage during checkout, update,
and other working-copy file installs on filesystems that support
copy-on-write/block cloning. When the working file is byte-identical
to the pristine file, Subversion can install it by copying or
reflinking from the pristine instead of storing two independent
physical copies of the same bytes.
This means that, for example, a Subversion working copy, where most
files have svn:eol-style=native, would see no improvement, correct?
The main affected user-visible operations are checkout/update/switch
style installs of clean, untranslated files. In update_editor.c, when
incoming pristine content is already byte-identical to the working
file representation and the working copy's filesystem supports cheap
block sharing, Subversion now defers working-file creation until after
the pristine is installed, then copy/reflinks from the pristine.
This also affects workqueue file installs in workqueue.c, if a queued
file install does not need translation, it uses the new copy-backed
writer instead of opening a write stream and copying through it manually.
How does this interact with the pristines-on-demand feature? How is this
tested?
If clients that do not support CoW use the same working copy as a client
that does, how do they interact?
Windows: CopyFile2 (with mid-copy cancellation via the progress callback)
Linux: FICLONE / reflink ioctl when supported
macOS: clonefile()
fallback: the portable svn_stream_copy3() read/write loop. On Windows
and macOS the native primitive reports SVN_ERR_UNSUPPORTED_FEATURE and
the dispatcher re-runs svn_io__copy_file_to_temp_portable();
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?
-- Brane
