Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 268802004F2 for ; Sat, 26 Aug 2017 15:39:15 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 250F0165E32; Sat, 26 Aug 2017 13:39:15 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 6C250165E05 for ; Sat, 26 Aug 2017 15:39:14 +0200 (CEST) Received: (qmail 50485 invoked by uid 500); 26 Aug 2017 13:39:07 -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 50475 invoked by uid 99); 26 Aug 2017 13:39:07 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 26 Aug 2017 13:39:07 +0000 Received: from zulu.23.e-reka.si (89-233-126-4.dynamic.t-2.net [89.233.126.4]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id C562F1A00A2 for ; Sat, 26 Aug 2017 13:39:06 +0000 (UTC) Subject: Re: Towards a Shelving MVP To: dev@subversion.apache.org References: From: =?UTF-8?Q?Branko_=c4=8cibej?= Organization: The Apache Software Foundation Message-ID: <3624b193-10f3-8e30-8d38-bc9d845c12db@apache.org> Date: Sat, 26 Aug 2017 15:39:03 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-GB archived-at: Sat, 26 Aug 2017 13:39:15 -0000 On 25.08.2017 18:23, Julian Foad wrote: > It seems Shelving in the current form is working out quite nicely. I'm > thinking about what more we need so that any of us or our friends would > be comfortable testing it on non-trivial data and calling the feature > set a "minimum viable product". I thought of: > > > Hardening before being safe to use: > > * Help text should contain a short introduction to how to use; set the > user's expectations; state the limitations (see "Extensions / Not > Supported Initially" section [1] in design doc.). > > * Output should be verbose and clear about what is happening. > > * The prototype should not delete patch files when unshelving, in case > it goes wrong; instead rename/move them. On the topic of storing patches, I'd like to propose an alternative implementation. Instead of saving a set of patches, save two sets of (untranslated pristine) files: * All currently modified files * Their pristine, unmodified versions (these are of course already in the pristine store and would only need an extra reference in the WC DB so that 'svn cleanup' doesn't delete them). The idea is that 'unshelve' could, instead of applying patches to the current working copy, invoke our built-in diff3 algorithm with whole (untranslated!) files. This is likely to produce much better results and saner conflict info than applying patches, which have limited context information. Additionally, the existing pristine store can be used to track the files. -- Brane