Return-Path: X-Original-To: apmail-subversion-users-archive@minotaur.apache.org Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5F4B817401 for ; Wed, 20 May 2015 10:52:51 +0000 (UTC) Received: (qmail 57746 invoked by uid 500); 20 May 2015 10:52:45 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 57714 invoked by uid 500); 20 May 2015 10:52:45 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 57698 invoked by uid 99); 20 May 2015 10:52:45 -0000 Received: from Unknown (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 May 2015 10:52:45 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id CC1BC1A3787 for ; Wed, 20 May 2015 10:52:44 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=6.31 tests=[UNPARSEABLE_RELAY=0.001] autolearn=disabled Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id 1e6H6bardpQi for ; Wed, 20 May 2015 10:52:41 +0000 (UTC) Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id AE84324BB6 for ; Wed, 20 May 2015 10:52:40 +0000 (UTC) X-Envelope-From: stsp@elego.de Received: from jim.stsp.name (jim.stsp.name [217.197.84.42]) (authenticated bits=0) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-4) with ESMTP id t4KAqak9030475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 May 2015 12:52:37 +0200 Received: from localhost (jim.stsp.name [local]) by jim.stsp.name (OpenSMTPD) with ESMTPA id 67a868c6; Wed, 20 May 2015 12:52:35 +0200 (CEST) Date: Wed, 20 May 2015 12:52:35 +0200 From: Stefan Sperling To: Warren Block Cc: users@subversion.apache.org Subject: Re: local dir edit, incoming dir delete upon update Message-ID: <20150520105235.GE4388@jim.stsp.name> Mail-Followup-To: Warren Block , users@subversion.apache.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) On Mon, Apr 06, 2015 at 08:54:20AM -0600, Warren Block wrote: > May I humbly request improvements for this error message? > > local dir edit, incoming dir delete upon update > > The ambiguity of "edit" and "delete" (whether adjectives or verbs) is > confusing every time. > > Could it be: > > local dir has been modified, but dir has been deleted in repository > > Or something like that. > > Thanks! Hi Warren, Are you simply asking for the wording to change? Or are you asking for a more precise description of how the tree conflict came about? The degree of ambiguity goes much further than one might expect. Most tree conflict messages are very terse and usually fail to describe the actual conflict situation in an adequate fashion. Currently it's up to the user to figure out what really happened. The message provides a small hint based on the information available to the client at the time the conflict was recorded. More often than not it lacks sufficient detail. 'edit' was chosen to describe local changes that occurred somewhere at or within a directory. These changes may be "local" to a branch (in case of merge) or a working copy (in case of merge or update). The client does not always know what the local changes are. E.g. in case changes happened in the history of a branch it currently does not know much about them, since conflict recording does not take history of the merge target into account. Only the tree configuration resulting from the local changes is known. Perhaps 'modification' would be a better term than 'edit'. But I don't see how such a small change in wording alone provides a huge improvement. As I see it, the situation as a whole could be vastly improved by providing more information to the client, or trying to make the client get at more information, so the conflict can be described to the user in more detail. FWIW, Subversion 1.9 describes your tree conflict as follows, hinting at the possibility that the incoming delete could also be an incoming move (perhaps causing more confusion for users, or perhaps not :-) > local dir edit, incoming dir delete or move upon update I think that, ideally, SVN should show something like this (I'm making up a conflict description and some possible resolution options -- there could be other options users might want): Tree conflict while merging r4242 from '^/trunk' into '^/branches/5.4.x@5100' with common ancestor '^/trunk@4180': 'harry' removed directory '^/trunk/foo' in r4242 'sally' edited '^/branches/5.4.x/foo/README.txt' in r5003 'bob' edited '^/branches/5.4.x/foo/src/common.c' in r5010 'alice' edited svn:ignore on '^/branches/5.4.x/foo' in r5013 More local changes present but not shown. To see all local changes, use: svn log -r 4180:4242 ^/branches/5.4.x/foo@5100 Select: (p) postpone, (q) quit resolution, (h) help, (k) keep local directory 'foo' as-is (d) accept the deletion directory 'foo' discarding all local changes (m) move 'branches/5.4.x/foo' to a different path Some of these improvements could already be made today. But we've been waiting for advances in server-side move tracking before making additional changes to the conflict menu and the underlying APIs which support it. Server-side move tracking is being researched but there is no solution ready to be part of a future release yet. Note how an incoming move would affect our idealized conflict description and set of resolution options: 'harry' moved directory '^/trunk/foo' to '^/trunk/bar' in r4242 'sally' edited '^/branches/5.4.x/foo/README.txt' in r5003 'bob' edited '^/branches/5.4.x/foo/src/common.c' in r5010 'alice' edited svn:ignore on '^/branches/5.4.x/foo' in r5013 More local changes present but not shown. To see all local changes, run: svn log -r 4180:4242 ^/branches/5.4.x/foo@5100 Select: (p) postpone, (q) quit resolution, (h) help, (k) keep local directory 'foo' as-is (m) rename local foo to bar and merge any outstanding differences between incoming bar and local bar