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

[graydon hoare]

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

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.

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
--nostd           -n
--output          -o
--quiet           -q
--rcfile          -r
--url             -u
--verbose         -v
--version         -V

huh, look at that! not even a short-option name conflict. neat. well,
this will complicate the option processing code a bit, but on the
other hand I really like the way those commands read. they make it
much more clear what they're doing. anyone disapprove of this change?
it'll affect the syntax of pretty much every command.

-graydon