[Monotone-devel] 1st class branches support in Monotone and usability issues (WAS: cairo, git and mercurial)

[Zakirov, Salikh]

Hi,

SZ> From the usability point of view, "first class" branches in Monotone
SZ> has a disadvantage of being completely equal in rights. 
SZ> You can't just pull from remote repository and start browsing the
code,
SZ> you will also need to find out which branch is the "main" one.

Emile Snyder wrote:
> This is true.  I can think of two things that might ease this pain
> 1. Extend the netsync protocol so that you can easily ask the server
> what branches it's serving.
> 2. Also extend it so that it can show you "branch groups", where a
> branch group is the set of branches which are attached to a single
> connected DAG of revisions.  This would let you quickly see when there
> were multiple projects (ie. no overlapping code) in one repository.

> Would these changes make the co-equal first class branches more
> appealing to you?

IMHO, the usability problems of browsing a Monotone database can be
solved
in easier ways, without changing internal algorithms:

1) Allow users to specify the host address with branch name as one
entity,
instead of two. E.g. use "mtn://venge.net/monotone" instead 
of "branch net.venge.monotone, which is being served at venge.net".

2) Somehow encourage users to have separate databases for separate
projects,
so that the problem of repository browsing will not appear. 

I have learnt not to put unrelated projects on the same database, 
when I noticed that I spend way too much time on deciding what branch
I need to check out, or which branch I need to diff with. This happened
just after 'monotone ls branches' became too long to fit into one screen
:)

However, this learning process would have not been necessary, if the 
Monotone had the default behaviour of creating a separate database for
each new working directory.

Below are my thoughts on what in particular can be done in Monotone UI
to solve usability issues I've encountered in my practice. This is 
completely subjective, so it might or might not make sense to other
Monotone users.

$ monotone setup myproject      
        - current behaviour
        monotone: misuse: need --branch argument for setup
        
        + more usable behaviour: default branch name to directory name,
like
        monotone init myproject -b myproject

$ monotone setup myproject -b myproject
        - current behaviour
        monotone: misuse: no database specified
        
        + more usable behaviour: create empty database in MT/
        monotone -d myproject.mtn db init
        monotone -d myproject.mtn setup -b myproject myproject
        mv myproject.mtn myproject/MT # and fix myproject/MT/options

* initial checkout from remote repository

        - currently done in 3 commands
        monotone -d monotone.mtn db init
        monotone -d monotone.mtn pull venge.net net.venge.monotone
        monotone -d monotone.mtn checkout -b net.venge.monotone monotone

        (and I always do then
                mv monotone.mtn MT/
                vi MT/options           # to fix the path to the
database
        )

        + more usable way
        monotone checkout mtn://venge.net/monotone
        # which would have done the sequence of commands described
above.