Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <5550FB76.805@reser.org>
Date: Mon, 11 May 2015 11:56:54 -0700
From: Ben Reser <ben@reser.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
 rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Evgeny Kotkov <evgeny.kotkov@visualsvn.com>,
 Subversion Development <dev@subversion.apache.org>
Subject: Re: Issue 4579 / svnmucc fails to process certain deletes
References: 
 <CAP_GPNhwDYg5RP9pUQctkuJLYpJvdeQ516uQBqrJDMPsyWi1hw@mail.gmail.com>
In-Reply-To: 
 <CAP_GPNhwDYg5RP9pUQctkuJLYpJvdeQ516uQBqrJDMPsyWi1hw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

On 5/11/15 11:41 AM, Evgeny Kotkov wrote:
> I raised an issue because I think that we care about compatibility and about
> *not* breaking user scripts and tools that happen to use 'svnmucc'.  Other
> possible examples that work in 1.8.13, but fail in 1.9.0 RC1 include:
> 
>   svnmucc rm /A/mu rm /A
> 
>   svnmucc cp HEAD /iota /A/iota rm /A
> 
> If this behavior change isn't a regression, I am fine with closing the issue.

The first example seems like a much better example, because that probably
should be allowed, even though it's redundant.

But the second one is still an example of where I think the user is poorly
served by us allowing it because we're throwing a change the user desired to be
applied.

The cp example here isn't such a huge issue because /iota is still there, but
the put examples are potentially a situation of data loss if the source file
they are putting is destroyed.

If the cost of helping users avoid inadvertent mistakes is disallowing the rm
example above and breaking some scripts then I'm on the side of some slight
incompatibility here.

While we certainly have endeavored to avoid gratuitous changes in command line
behavior we have made changes in the past with good reason.  I don't know if
this behavior change was deliberate or not.  But in my opinion it's probably
for the best.