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

[Thomas Keller]

Am 24.02.2011 03:35, schrieb John B Thiel:
> On Wed, Feb 23, 2011 at 2:34 PM, Thomas Keller <address@hidden> wrote:
>> 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.
> 
> 
> Ah, very good!  -h at the end of the line solves just what I meant.
> 
> Another thing that might be helpful is grouping/highlighting the basic
> subset of most frequently used commands.  Generally with these systems
> you use the same basic 5-10 commands 80+% of the time, with the rest
> for special cases, but it's always some work to initially find those
> 10.

What would you propose here? I could only think of printing "often" used
commands in bold (or somehow colored) in the output of `mtn help`. We
started a "colorization" branch some time ago for the purpose of making
the output of diff, log and friends easier to grasp, but I fear this
won't get ready until 1.1, because Windows support for this is still
largely lacking.

>> 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.
> 
> This is a script/alias that one loads into the bash shell?  A good
> approach; where do I find it?

For the current version these are the files
monotone.{bash,zsh}_completion here:

<https://code.monotone.ca/p/monotone/source/tree/t:monotone-0.99.1/contrib>

The new magic one however is only available in the trunk and needs to be
built from source to work properly:

<https://code.monotone.ca/p/monotone/source/tree/h:net.venge.monotone/extra/shell>

Give us some more time - we plan to release 1.0 which ships with the new
one by default by the end of March.

>>> * Globally unique branch names
>>> [...]
> So can the top-level branch just start out as a word, like
> "Wondermatic", and then a release branch can be "Wondermatic-1.0".
> Or should one preferably use tags, or revision ids to track releases?
> I am not sure yet how branches, tags, and revisions fit together.

If you start out with "Wondermatic" in your private development, then
this is just fine. Be careful though that whenever you go public with
that, that there is the chance that the branch name is not unique and
lead to confusion. While it is possible to "rename" the branch in a
complete private history later on, its still a bit harder than for
example in git, because every single revision needs to loose its old
branch certificate and gets a new one attached.

The hierarchical setup is actually quite nice for a couple of other use
cases, like pushing or pulling changes to and from somewhere. For
example, if you happen to have the branches

Wondermatic
Wondermatic-1.0
Wondermatic-1.1
Wondermatic-Website

and you now only want to sync the trunk and stable branches, you have to
--exclude Wondermatic-Website specifically. If you however choose to
name them

Wondermatic
Wondermatic.releases.1.0
Wondermatic.releases.1.1
Wondermatic-Website

the include pattern would simply be "Wondermatic{,.*}". Of course this
works with any other separator than "." as well, as long as it is not
some reserved character.

> Is it fine if the branch and workspace directory have the same name?

This is fine - but you can also use a completly different name. This
doesn't matter actually much nowadays, because `mtn list databases` will
always print you what workspaces have what branch currently set up. If
you happen to work with many branches and switch between branches very
often, its probably more fitting to just name the workspace after the
name of the project or the common (hierarchical) branch name.

> Surely it can't matter
> if Frank in Kalamazoo *also* has a "Wondermatic" branch like me ?
> unless I ever started working with him, I guess?  And tried to put his
> project in my same repository?  Then what? can't he or I just somehow
> rename colliding branches at that point ?   Or I just make a new --db
> repository to hold that project separate from my others ?

Picking the colliding branches once they are in the same database is
quite hard, because the way revisions are selected depends very much on
the certificates that are tacked on them and especially for the netsync
/ network use case you can only select revisions by branch name, not by
author, date, changelog or anything else.

Please keep also in mind that distributed systems are bad at purging
unwanted data, so even if you or he is locally renaming his project tree
to another name - once he has synced his changes somewhere already, the
old certificates are likely to come back when he syncs again somewhere
else. This is actually an unresolved problem with all the distributed
version control systems out there. Unless _all_ people purge the data in
_all_ of the distributed copies, the changes can come back at any time.
We're working quite some time now on a solution for that, named "policy
branches", which should solve this and other issues.

> What/where is the looming disaster, that the manual so urgently
> recommends those deep hierarchy branch names?   None such, really
> (right?), so the manual should just point out the issue/risk with a
> mild suggestion, and explain what to do if branch names collide.

We're somewhat conservative in everything we do, and we're often find
ourselves trying to hinder our users doing things they'll certainly
regret in the future. But yes, the section in the manual can and should
be expanded to hint you more at the specific problems. We're at it :)


I'm splitting off the reply for the register_workspace issue into a
separate mail, because I have to have a detailed look at the source at
first and won't have time for that until tonight.

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