monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] current to-do items


From: Nathaniel Smith
Subject: Re: [Monotone-devel] current to-do items
Date: Thu, 11 Sep 2003 16:15:13 -0700
User-agent: Mutt/1.5.4i

On Thu, Sep 11, 2003 at 05:40:25PM -0400, graydon hoare wrote:
> Nathaniel Smith <address@hidden> writes:
> 
> > Do you mean that monotone should be like CVS in always putting
> > checkouts into a subdirectory (controllable in CVS with the -d
> > switch, defaulting to the module name -- maybe monotone could default
> > to the branch name?)?  Or are you complaining about all source
> > monotone files living in the root of the project directory instead of
> > in src/ or something?  Both of these seem like things worth fixing,
> > but I'm not quite following you :-)
> 
> I think njs has spotted this one correctly: the problem is not with
> keeping MT in the directory with lots of files, but with the behavior
> of checkout. even if there's a lot of crap at the top level of your
> manifest, checkout shouldn't scatter a bunch of files in cwd. how
> about expanding the command syntax to handle three cases:
> 
> 2 args: monotone checkout <id> <dirname>
>   create dirname, cd to it, checkout <id>
> 
> 1 arg: monotone checkout <id> 
>   checkout <id> in current directory

This makes it awfully easy to get junk scattered all over the place if
you forget to put a second argument.  Much better to not have this
form at all, and let people who want this behaviour type a "." at the
end.

> 0 args: monotone --branch=foo checkout 
>   create directory foo, checkout head (if it exists) of branch foo
> 
> I'd be ok with this, I think, though it's getting a bit cumbersome.
> perhaps tromey is right in that we ought not use positional parameters
> at all. I haven't tried sitting down and working out whether each
> command could be done entirely based on cmd name + positionless
> options. maybe it can..
> 
> monotone genkey address@hidden
> monotone pubkey address@hidden --output=mykey.txt
> monotone mdelta --mid=<id> --mid=<id>
> monotone commit --branch=bleh --logmsg="happy commit day"
> monotone commit --branch=bleh --input=commitmsg.txt
> monotone checkout --mid=<id> --output=somedir
> monotone read --infile=packets.txt
> monotone post --url=http://www.foo.com --group=bleh
> monotone cat --fid=<id>
> monotone update --sort=quality
> monotone propagage --branch=classpath --branch=gcj
> monotone diff --fid=<id1> --fid=<id2>
> monotone diff --mid=<id1> --mid=<id2>
> monotone add --file=foo.c
> monotone drop --file=foo.c
> 
> hm. the last two there look fishy. perhaps a slightly different rule
> of thumb?  say "first positional is always command, all remaining
> positionals are always files, all other parameters are --options?"
> that at least plays well with globbing. you probably want a way to
> support globs. also, the cases where you're operating on *two* things
> (diff, propagate) I think continue to need to be at least sensitive to
> relative order (left-to-right), as would things like specifying
> --rcfile more than once produces successive reads in the left-to-right
> order specified.

Erm.  I dunno.

I generally agree with the guidelines and rationale at
http://optik.sourceforge.net/tao.html ; what if we stick to those?
In particular, options should be optional and order should mostly only
matter for positional arguments.  (I can see the point with --rcfile,
but not diff... speaking of diff, can the syntax just be "diff
(MID MID | FID FID)"?  It's not like a given id is ambiguous.)

I'm actually perfectly happy with cvs's two-option-string-tango, for
that matter, but maybe I'm just weird that way.  (It helps that zsh is
clever enough to know how to complete options on both sides of the
command, and even explain what they mean.)

Another thing to consider is whether monotone will continue to acquire
new options in the future; cvs does probably overdo things a bit, but
most of those options actually are needed at times...

Oh, and I don't understand what you're saying about globbing at all
:-)

> in general, I'm pleasantly surprised with how well those commands
> read.  they're pretty explanatory and not as verbose as I'd
> feared. how about short options?
> 
> --branch          -b
> --db              -d
> --fid             -f
> --group           -g
> --help            -h
> --input           -i
> --key             -k
> --mid             -m

What about --logmsg?

> --nostd           -n
> --output          -o
> --quiet           -q
> --rcfile          -r
> --url             -u
> --verbose         -v
> --version         -V

And --sort doesn't get a short option I suppose.

-- Nathaniel

-- 
The Universe may  /  Be as large as they say
But it wouldn't be missed  /  If it didn't exist.
  -- Piet Hein




reply via email to

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