From dev-return-38654-archive-asf-public=cust-asf.ponee.io@subversion.apache.org Mon Dec 3 19:22:06 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 420B0180645 for ; Mon, 3 Dec 2018 19:22:06 +0100 (CET) Received: (qmail 48431 invoked by uid 500); 3 Dec 2018 18:22:05 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Received: (qmail 48421 invoked by uid 99); 3 Dec 2018 18:22:05 -0000 Received: from mail-relay.apache.org (HELO mailrelay1-lw-us.apache.org) (207.244.88.152) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Dec 2018 18:22:05 +0000 Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 696F83C39 for ; Mon, 3 Dec 2018 18:22:04 +0000 (UTC) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailauth.nyi.internal (Postfix) with ESMTP id C9A3D21673 for ; Mon, 3 Dec 2018 13:22:03 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute7.internal (MEProxy); Mon, 03 Dec 2018 13:22:03 -0500 X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 3990E9E593; Mon, 3 Dec 2018 13:22:03 -0500 (EST) Message-Id: <1543861323.1082735.1597389160.0956A86B@webmail.messagingengine.com> From: Julian Foad To: dev@subversion.apache.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-3449945b In-Reply-To: <1541783843.273397.1571559192.3AAB5520@webmail.messagingengine.com> Subject: Re: Crazy idea: changes in WC should share an API with changes in repository Date: Mon, 03 Dec 2018 18:22:03 +0000 References: <1541760972.3265847.1571178128.7660FB8E@webmail.messagingengine.com> <1541783843.273397.1571559192.3AAB5520@webmail.messagingengine.com> 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.) 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