more pedantry -- to recurse or not to recurse?

  there seems to be a nagging inconsistency in knowing whether a
command is going to work recursively or not, and in specifying the
starting directory location for that command.

  in general, you normally expect a set of commands to support options
that reflect two orthogonal choices:

  1) start here (current directory), or specify starting directory
  2) work recursively or not

and the above would most conveniently be represented by
command-independent options; that is, options *before* the actual
command specifier.  to some extent, that's true, since "bk" supports
the options:

  $ bk -R <cmd>               # cd to repo root first
  $ bk -r<dir> <cmd>          # cd to <dir> first

but if you don't specify the <dir> for "-r", then you get the repo
root by default, which seems kind of redundant and wasteful (not
totally, just somewhat).  and, sadly, given that both -r and -R are
now spoken for, there's no obvious option to select recursive as
opposed to non-recursive behaviour (unless all commands are recursive
by default, and you pick a new option ("-l") to mean local, or
something like that).

  i think it's too bad that the global "-r" option was used to select
a directory.  thinking out loud, it might have been more consistent to
use global options like:

  -R		change to repo root first
  -d <dir>	change to <dir> first (*must* have <dir> arg)
		and current directory as default in all cases
  -r		work recursively (if recursion is *not* the default)
  -l		work locally (non-recursively) if recursive *is*
		the default

but the current usage is undoubtedly already cast in stone so, as i
said, just thinking out loud.

rday

p.s.  there is a possible gotcha in the use of "bk -r" since,
according to the docs, if you don't specify a directory arg to "-r",
it defaults to the repo root.  if you look in bk.script, there are
certainly examples of "bk -R", like in _extras():

    bk -R sfiles -x "$@"

and there is at least one example of "-r" with a directory argument in
_unrm():

    bk -r. prs

but there's also a potentially confusing usage in _repair():

    bk -r names

which could cause trouble for folks with a long UNIX history who think
they can put a space between an option and its arg, and actually want
to change to a directory named "names".  this is where letting -r and
-R do the same thing could be confusing.
_______________________________________________
Bitkeeper-users mailing list
[email protected]
http://bitmover.com/mailman/listinfo/bitkeeper-users
To unsubscribe from this list, go to the above URL, follow instruction at the bottom of the web page.