Greg Stein <gst...@gmail.com> writes:
> On Thu, May 5, 2011 at 15:16, Bert Huijben <b...@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
