Re: Patch: Native filesystem CopyOnWrite support for working copy and pristine files

On Mon, Jun 15, 2026 at 11:15 AM Branko Čibej <[email protected]> wrote:
> [...]
>
> Thoughts on creating a branch for this? It may be easier to work through
> actual working code, as well as test interaction with other working copy
> changes.
>
> Downside is that the code may just bitrot on a branch that's not
> actively maintained.
>
> I don't think it needs its own branch, it would be easy to add a
> global toggle via a pre-processor define since it's already gated
> around the reflink support probing.
>
>
>
> I'm well aware that we can #ifdef our way around any new code, but this change as it stands now is much too big and intrusive for that. I would not support committing it directly to trunk in its current state, even if disabled by default. This isn't a comment about your patch specifically, I'd say the same about any other large, intrusive change, no matter the source. We do develop some significant new features on trunk (e.g., FSX, svnxx, svnbrowse), but they're well isolated from the rest of the code – and also never finished, eh. What can go directly to trunk and what should be developed on a branch is a bit of a judgement call. I think my opinion on the matter is consistent.
>
> -- Brane


I haven't had a chance to actually study the patch(es) yet, but the
discussion has been interesting.

If Jordan and/or others are interested in developing this feature
further, I would urge to consider doing so on a branch, NOT in trunk.
My rationale for this is substantially the same as Brane's.

Cheers,
Nathan