subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Foad <>
Subject Re: Crazy idea: changes in WC should share an API with changes in repository
Date Mon, 03 Dec 2018 18:22:03 GMT
Julian Foad wrote on 2018-11-09:
> > Implementation of the "WC delta editor" is in progress.
> Currently factoring out our "copy dir from repos to WC" implementation 

Some more notes on progress.

The way we handle "copy" into the WC is a beast. Untangling this is by far the most complex
part of the whole exercise.

* Copy via Checkout

Copying a directory tree from the same repository into the WC is currently handled by performing
a new checkout into a temporary WC, then running a WC-to-WC-copy from there to the target
location, then deleting the remnants of that temporary WC. Ugh.

The essential purpose of the WC-to-WC-copy step is putting down a layer in the WC 'working'
table to represent the pristine version (aka 'revert-base') of this copy.

The temporary WC, ugly though it is, is a fairly well hidden implementation detail and so
not too worrying.

What is ugly is the way this procedure calls back to the RA layer using a full-blown 'checkout'
procedure, scanning the WC, setting up a reporter, and using it to drive a new 'update' edit.

Instead, at this level in our WC editor, we already know there's an empty spot in the WC where
the result is going to go, and we know the 'report' is of the trivial 'give me the whole subtree
URL@REV' variety. We should be able to make a callback that doesn't require access to the
WC nor the repository but just to whatever datastore the caller has available.  The driver
of this WC edit might be some shelving storage or might be another WC.

Requiring a callback to the RA layer connecting to The Repository might be a workable initial
version, even though ultimately we would certainly not want to require repository access for
shelving or unshelving or WC-to-WC copying.

* Single-file vs. Directory

Need to unify. Handling these two cases separately is the cause of a lot of complexity duplication
and resulting bugs.

Potential solution: Some form of the old "anchor-and-target" idea. Create a generic editor
wrapper that transforms a request for an editor rooted at a file (or a maybe-file) into a
request for an editor rooted at its parent directory with operations performed on a single
target entry.

* Foreign-repo copies:

Currently a separate code path. (Currently the only one that calls the new WC editor.)


* Externals

r1847834: "Unify how 'copy' processes externals with and without pinning. ... Remove the optional
'externals' processing from inside the copy APIs, as there was already support for doing it
outside. Previously, externals were fetched outside the 'copy' API if and only if some externals
were to be pinned. Now we always use that code path. As a side effect, this makes the notifications
consistent between the two cases."

* Mergeinfo

Mergeinfo is deleted when we are copying from a foreign repo. (Inconsistency bug found and
fixed: SVN-4792.)

This should be re-implemented as a wrapper editor that just performs mergeinfo stripping.

- Julian

View raw message