Re: Crazy idea: changes in WC should share an API with changes in repository

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_at_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.)

Unify.

* 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