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

Re: Help on 1.6-blocker #3334 - tree conflicts in update

From: Mark Phippard <markphip_at_gmail.com>
Date: Mon, 2 Feb 2009 11:20:13 -0500

On Mon, Feb 2, 2009 at 11:15 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:

>> Another thought, the ideal behavior probably depends a lot on if the
>> incoming delete is part of a move or not. If it is solely a delete,
>> having the context of entire subtree in addition to our local mods
>> makes a lot of sense no?
> Yes.
>> OTOH if the delete is part of a move, then
>> *maybe* having only the modified portions of the deleted subtree makes
>> sense.
> Maybe.
>> Also, the nature of the local mods matters. At one extreme consider a
>> modification that consists solely of a text change to an immediate
>> file child of a large the deleted subtree. Scheduling the entire
>> subtree for addition does seem a bit excessive.
> Excessive? It's not as if we're adding stuff that wasn't there. It was
> all there in the WC just before you ran "update". Why is it excessive if
> the update says "Hold on, the incoming change wants to delete this huge
> tree but I'm not going to do that to you just yet, I'll wait until you
> tell me to resolve as theirs."

The fact that there is no obvious answer we can agree on tells me
let's go with what we have and see where that leads under real world

Julian, the only part that is kind of excessive is the user recovery
process. If a user wants to preserve that single file in a deep tree
how many commands do they have to run to unschedule all the other
files and clean up their WC?

I tend to think we cannot win no matter what we do so I like the idea
of going with what we have now and see if it hits the mark for users
or creates new problems.

Mark Phippard
Received on 2009-02-02 17:20:36 CET

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.