[Monotone-devel] Re: Monotone - A couple quick notes

[Thomas Keller]

Am 23.02.11 18:41, schrieb John B Thiel:
> Hello, I was just taking a quick look at Monotone, which looks very
> well-designed and excellent, with some great features (I especially
> like the single file repository, xdelta, and robust design).  A couple
> "first 5 minutes" feedbacks:

Hi John!

Many thanks for your feedback! I hope its ok that I share it with the
others... I'll answer item for item.

> * Allow 'help' at End of line
> 
> The builtin 'help' is great, but it should allow saying help at the
> END of a command sequence (complete or partial).  The current design
> requires shuttling back and forth to the beginning of commands you are
> building up to keep inserting and removing the word 'help' - very
> annoying.

Saying `mtn help <cmd>` is just one way, another is the `--help` (or
short `-h`) option which can be put anywhere, also at the end of the
command sequence. `--help` and `help` are aliases in some way, just that
you can give additional options to the help command like displaying
hidden (debug) commands, but all visible and general purpose commands
can just be queried with `--help` alone.

> One of the nicest designs for this kind of command-tree
> interface is a dynamic readline that offers listing and
> auto-completion of the available commands depending on what node you
> are at so far,  and quick help at that node by typing '?' (or 'help'),
> then you type the next parameter, etc.    Until Monotone might acquire
> such a readline, supporting 'help' at the end would at least allow
> more efficient use of shell recall.  (also, if the command is
> incomplete when entered, it could list the valid options at that
> point).

We leave command completion up to the shells and have actually improved
the bash completion script for the upcoming version 1.0 quite a bit
(amongst many things its source data are dynamically built from the
command tree, so it automatically knows all the available completions).
There is also a zsh completion script in our tree, but this just needs a
little more love and might be slightly outdated.

> * Globally unique branch names
> 
> The part in the manual 1.7.2 about requiring globally unique branch
> names is highly disconcerting and does not fit the generally robust
> presentation and positioning of Monotone.  I did not even want to
> bother with a branch name at all on an initial trial setup, but it was
> apparently required, and then to find they have to be globally unique,
> extralong strings linked to some other random construct  (DNS?? what
> does that have to do with my project files?) 

monotone is all about global identity and it wants you to ensure that
you put your contents (files and revisions) in a namespace that cannot
be accidentially confused by somebody else and that you can always
recognize wherever it is put. monotone can, by design, host many
different projects in one single repository and without a clear branch
naming it would be impossible to distinguish these different projects
from each other.

You are of course free to choose whatever branch you like for your
project, monotone won't hinder you to use "master" or "develop" or
anything else. It is just a little pickier recently about certain
characters allowed in the branch, for the reason that some of them might
otherwise conflict with special characters used in branch patterns or
monotone URIs. Be aware though that whenever your repository contains
two different projects with the same branch name, that you'll have a
hard time selecting and thus for example querying, logging, committing
and merging revisions.

> Also, the manual cannot
> just nonchalantly throw out passages like "bad things can happen".  I
> hope this is an area that can be reworked -- why should the user have
> to explicitly name branches in the first place, and requiring global
> uniqueness is not reasonable, and if pushing this burden to the users,
> the manual should at least detail exactly what kind of "bad things"
> will happen and how to recover from them.

Thanks for that - we're looking into the documentation and try to
improve that.

> * I could not get unregister_workspace to remove a  workspace (from an
> auto-managed db).  It just silently does nothing. This is on Windows7.
>  Any tips on the syntax?  I tried full pathname with both fwd and
> backslash, exact capitalization, and also tried a '~' reference.  If I
> remove/rename the _MTN dir and do cleanup_workspace_list, then it goes
> away (as reported by list db).

mtn unregister_workspace can work with and without a given workspace
path (if none is given, the current workspace is used). I don't know of
problems with this particular command, but then, on the other hand,
we're currently low on Windows build bots. Would you mind and send us
the output of the command with an appended -v?

> Thanks for the excellent work on Monotone!

Thank you for your feedback!

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature