[Monotone-devel] Re: Proposal for human readable revision IDs

[Wim Oudshoorn]

Chad Walstrom <address@hidden> writes:

> Practically speaking, I think the suggestion to add spacing every 5
> (common w/the crypto crowd) or 4/8 characters (more "natural" for
> representing hex) seems most reasonable and global.  I personally like
> 4 characters/space pattern.  Using a small group of characters creates
> a mnemonic device (memory aid) through rhythm, making it easier to
> recall.

I have one small doubt on adding spaces, how does copy paste
on the command line work,  considering that most shells see
the space character as argument delimeters?

Personally I don't mind the current format, mostly because
the tools I use:

1 - a custom scripts that generates the revision tree 
    with the dot program.
    (somewhat like monotone-viz, but not interactive).
2 - my own emacs mode for monotone

both show revision id shortened to the shortest unique sequence
currently in the database.   So most of the time I just have
to remember and  type 3 or 4 characters.

Oh I know this does not cover all the use cases that came up in this
thread but I agree with the following:

>  Selectors are probably one of the more under-used features of
> monotone.

And I think it is better to perfect selectors
for the use case people want and teach people about them.

> INI-style output is and old-reliable with support across most
> programming/scripting languages, and it's readable to boot. 

I am not really a fan of the INI-style files, because I find them
slightly cumbersome to parse in a scripting language.  But he, that
could just be my lack  of experience with them.

Also I find the it rather terse, in your examples:

>
>     % monotone status PATH
>     [Proposed Manifest]
>     m:0687 5a5d 40a9 6f6b c5bf 6af9 4456 573e 00a6 9c6a
>     
>     [Last Revision]
>     r:9bed b716 44a5 6862 640e 036e fc32 1fdf 7318 52be
>     m:0687 5a5d 40a9 6f6b c5bf 6af9 4456 573e 00a6 9c6a
>
> ....
>
>     % monotone log PATH
>     -----------------------------------------------------------------
>     [Ancestor]
>     r:
>
>     [Current]
>     r:9bed b716 44a5 6862 640e 036e fc32 1fdf 7318 52be
>     a:address@hidden
>     d:2005-09-01T05:44:38
>     b:branch.name
>     t:tag1
>     t:tag2
>
>     [Added files]
>     FILE1 FILE2 FILE3
>
>     [ChangeLog]
>     Example changelog entry.
>     -----------------------------------------------------------------

You should now that, a: means author, b: means branch m: means manifest etc.
Also remember that a revision can have multiple ChangeLog certificates. 
But that are just details.   I think it is nice if you have some copy
paste mechanism, but something like:

Author:
  a:address@hidden
Branch:
  b:branch.name

would suite me better.

Wim Oudshoorn.