[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Making delete resolve tree conflicts

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Fri, 06 May 2011 10:12:35 +0100

Greg Stein <gstein_at_gmail.com> writes:

> On Thu, May 5, 2011 at 15:16, Bert Huijben <bert_at_qqmail.nl> wrote:
>>...
>>> wc_db could do this, as long as we put a check for conflicts up in
>>> svn_wc_delete() to look for unresolved conflicts.
>>
>> The easiest place to block  this is probably libsvn_client. It does already
>
> That feels too high level to me. It allows third party code to call
> svn_wc_delete() and wipe out conflict info too easily.

I don't understand this. svn_wc_delete deletes text changes, text
conflicts, property changes, property conflicts and tree changes. Why
should tree conflicts be preserved when all those other things are
deleted? My view is that text changes, which get deleted, are more
valuable than tree conflicts.

>> Is making 'svn rm' fail on conflicts backwards compatible?
>
> I say "no". That just seems the safe way to approach this. That we
> didn't stop the operation before seems like a big mistake. We looked
> for local mods, and I view conflicts in the same boat ("hey! you've
> got something in this subtree").

We check for modifications, including tree conflicts, in the client
layer. The user has to use --force, or --keep-local, to get the delete
to run at all.

-- 
Philip
Received on 2011-05-06 11:13:25 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.