monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] monotone update overwrites local changes


From: Nathaniel Smith
Subject: Re: [Monotone-devel] monotone update overwrites local changes
Date: Sun, 15 May 2005 11:11:16 -0700
User-agent: Mutt/1.5.9i

On Sat, May 14, 2005 at 10:21:32PM -0600, Derek Scherger wrote:
> Nathaniel Smith wrote:
> > On Wed, May 11, 2005 at 08:47:56PM -0600, Derek Scherger wrote:
> >>How about just skip the file and keep going, perhaps with a warning like
> >>"preserving existing file ...".
> > 
> > This violates "refuse the temptation to guess".
> > 
> > I suggest, check for such files; if they exist, tell the user what's
               ^^^^^^^^^^^^^^^^^^^^
> > up and refuse to go on.  Then the user can investigate and take
> 
> at which point half of my tree has been updated. I now have an old value
> in MT/revision, no idea what changes have been applied and no record of
> what revision those changes came from.

Yeah, we have to check before we irrevocably commit to modifying
things.  Shouldn't be any harder than checking after we do that;
probably is easier, even.

> I'm not sure I agree with the "refuse the temptation to guess" assesment
> either. if I've set a hook to say, don't update pre-existing files but
> don't quit either, then there's no guessing involved.

No, there isn't; there're separate questions of "what the default is",
and "what other options could the user could override that with".
"refuse the temptation to guess" only speaks to the first question,
but I think it's pretty compelling there.

So, configurability... we should generally remember that just because
we _can_ make something configurable, doesn't mean we _should_ :-).  I
don't really see the point of having a "clobber existing files" mode;
you would never want to make it the default, and in any case where you
actually wanted it, it would be just as easy to delete the existing
files as to signal your intent some other way (modify a hook, etc.).
Maybe for the preservation mode it would be useful to have some sort
of support, but again, whenever this case comes up, you want to do
some manual inspection to figure out what's going on anyway, so having
the non-configurable default be to basically tell the user "hey, you
need to do something manual here", still seems fine.  Maybe a
subcommand option on update to preserve existing files would be good?

Implementing "fail before clobber" is clearly an incremental win over
our current behavior, and the subcommand thing could be a separate
change, after that was working.

-- Nathaniel

-- 
So let us espouse a less contested notion of truth and falsehood, even
if it is philosophically debatable (if we listen to philosophers, we
must debate everything, and there would be no end to the discussion).
  -- Serendipities, Umberto Eco




reply via email to

[Prev in Thread] Current Thread [Next in Thread]