On Mon, 2009-02-02 at 11:20 -0500, Mark Phippard wrote:
> 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?
Yes. I don't know which scenarios will be more common, and this one
didn't seem likely to me. But I was just going through your other mail
and basically concluding that yes, this scenario (re-create single file
with parents in deep tree) is real, as well as the other scenarios. And
it doesn't have such easy commands to achieve. A "revert recursively all
schedule-added files except added-and-modified files" is the sort of
command that would help, but we don't have it.
> 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.
Received on 2009-02-02 17:27:22 CET