monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] [PATCH] mtn publish


From: Nathaniel J. Smith
Subject: Re: [Monotone-devel] [PATCH] mtn publish
Date: Fri, 22 Dec 2006 16:08:17 -0800
User-agent: Mutt/1.2.5.1i

On Thu, Dec 21, 2006 at 10:25:35AM -0500, Ben Walton wrote:
> I don't want the clients seeing _MTN/*.

I accept your assertion, but am curious about your reasons :-).  It
seems like _MTN/* takes completely negligible space, and provides
potentially valuable information?

> I realize that this could be done with a script also, so if you feel
> that this is a silly feature, my feelings will not be hurt if the
> patch isn't accepted.

I don't really have any opinion either way -- I've never felt that "rm
-rf _MTN" was particularly onerous, but hey, if abstraction gives
people fuzzies and keeps them warm at night...

General comments on the design follow:

> The semantics are almost identical to checkout, except that it will
> not checkout to the cwd.  It also introduces a --force option to be
> used in the event where the publishing destination directory already
> exists.  If the destination exists and is a file, mtn will abort...I
> felt that this was more dangerous than overriding a directory.  An
> existing directory is backed up and left in place.

I have never seen a good reason to name an option "--force" -- the
name conveys almost nothing about what it actually does, and so people
inevitably end up wanting to pile other a grab bag of behaviors under
the same switch, and users inevitably end up trying it whenever they
see an error, just in case _this_ happens to the error that --force
turns off...

And, of course, there's the always enjoyable question of how to name
backups, and what to do if the name is in use.  Do you actually have a
need for the ability to clobber an existing directory with this
command?  It seems like it would be easier to just tell users to do
their own "rm -rf $FOO", or "[ -e $FOO ] && mv b$FOO $FOO.bak" or
whatever particular policy they like.

-- Nathaniel




reply via email to

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