C. Michael Pilato wrote:
> 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?
Ah, yes, so I am. I am confusing "conflicts" (conflicting version-controlled or
scheduled changes) with inconsistent WC state.
> 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?
Yes, you're right. At present the code for detecting these WC inconsistencies
is in the same place as that for detecting conflicts, which is making it a bit
awkward to keep the two concepts separate. I'm not intending to move it to the
state-report crawl, but in principle that might make sense.
(Such WC inconsistencies often consist of a node on disk that's unexpected or
the wrong type, and then they are called "obstructions". A node missing from
disk when it's expected to be there is another type.)
I have been wondering whether tree-conflicts work should include detecting WC
inconsistencies and even flagging them as a (distinguishable) type of conflict.
Now that you've pointed out that we should be able to detect them much earlier,
I'm seeing that that's a bad idea.
I'll just try to keep the two concepts logically separate for now, and not
bother about obstructions/inconsistencies yet.
Thanks.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-18 16:24:49 CEST