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

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

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 18 Apr 2008 15:24:20 +0100

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.

- 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

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.