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 AA633F90D for ; Sat, 24 Aug 2013 19:05:21 +0000 (UTC) Received: (qmail 88746 invoked by uid 500); 24 Aug 2013 19:05:20 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 88640 invoked by uid 500); 24 Aug 2013 19:05:20 -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 88633 invoked by uid 99); 24 Aug 2013 19:05:19 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 24 Aug 2013 19:05:19 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [192.109.42.8] (HELO einhorn.in-berlin.de) (192.109.42.8) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 24 Aug 2013 19:05:11 +0000 X-Envelope-From: stsp@stsp.name Received: from ted.stsp.name (ted.stsp.name [217.197.84.34]) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id r7OJ4mVo031697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 24 Aug 2013 21:04:49 +0200 Received: from ted.stsp.name (localhost [127.0.0.1]) by ted.stsp.name (8.14.7/8.14.3) with ESMTP id r7OJ4mEU002414; Sat, 24 Aug 2013 21:04:48 +0200 (CEST) Received: (from stsp@localhost) by ted.stsp.name (8.14.7/8.14.7/Submit) id r7OJ4mS5009564; Sat, 24 Aug 2013 21:04:48 +0200 (CEST) Date: Sat, 24 Aug 2013 21:04:48 +0200 From: Stefan Sperling To: Les Mikesell Cc: Ryan Schmidt , Branko =?utf-8?B?xIxpYmVq?= , Subversion Subject: Re: Switching Message-ID: <20130824190447.GB8910@ted.stsp.name> Mail-Followup-To: Les Mikesell , Ryan Schmidt , Branko =?utf-8?B?xIxpYmVq?= , Subversion References: <910250F21FAA2A4E8F72DD21EA7807660906CFD5@VMJudi.corp.rotair.com> <521665CF.7050807@gmx.us> <81E45292CF3BC5478E88DF55E216AD2F03B46E5E@FLONIDANPOST.flonidan.net> <52178B18.9050007@gmx.us> <5217A562.3020202@gmx.us> <54C87FD8-9CBD-41A3-9D6B-F7C1C787BB60@ryandesign.com> <5218656B.6020302@wandisco.com> <9DEB2347-7103-49A2-AC8C-51C8223C3069@ryandesign.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 X-Virus-Checked: Checked by ClamAV on apache.org On Sat, Aug 24, 2013 at 10:22:41AM -0500, Les Mikesell wrote: > Don't forget that it was subversion, not the user, that created the > directory and abandoned it in the first place. If a previously versioned directory is left behind unversioned, that means there are unversioned (aka obstructing) nodes within the directory, such as files created during a build. Those files could not have been created by svn. I hope that we will eventually extend tree conflict handling to the point where it makes these kinds of situations trivial to resolve, even for novice users. svn should interactively offer a set of reasonable courses of action, such as removing the unversioned nodes, or moving them to a special lost+found area, or something else that allows incoming versioned nodes to be created in their place.