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
usage.
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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1091281
Received on 2009-02-02 17:20:36 CET