Re: Behaviour of "update" vs. "merge" w.r.t. tree changes (and tree conflicts)

Julian Foad wrote:
> Er... did you read my following paragraph? It said:
>
>> I would like to convert this case to a tree conflict. Is there any
>> serious benefit to not doing so, and keeping this special case?

Sorry. What I did was read your mail, then Andreas', then responded to your
mail. I got my threads crossed somewhere in the middle.

> In other words, yes I agree that making the opposite assumption (that it
> should be scheduled for delete) would be equally wrong. We can't know
> what the user wanted, so we should ask the user what to do.

By calling that scenario a tree conflict (which would make
delete-atop-schedule-deleted and delete-atop-missing the same thing), aren't
you already assuming that missing files were intended for deletion?

We can never know what the user intended to do, tree conflicts or not.
We've chosen to make the user explicitly schedule a file's removal from
version control.

Now, if our goal is to punt on every unsure situation, and a missing file is
defined as an unsure situation, then 'svn update' should croak well before
even contacting the server for the new bits. During the state report crawl
when it finds missing items, it should just bail right there. The ambiguity
of the situation doesn't appear because the server sent a delete-this-file
command -- it appears because the working file is missing. Right?

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand