[Monotone-devel] Workflow with Monotone

[Willem Rein Oudshoorn]

Introduction
------------

We are thinking of changing from CVS to monotone.
This will impact our way of working and I am 
trying to figure out what the best way is of
utilizing monotone.

Thinking about is led to a short wishlist 
for monotone.  If you are only interested in
the wishlist, just jump to the section 'Wishlist'.
The rest of this long post gives some context to
the wishlist

So let me start with describing:

Current situation with CVS
--------------------------

Currently when a developer finishes some piece of
work he takes, what we call, the "lock" and commits
his changes to the repository.  
After that he starts the build script on a dedicated
build machine.  

This script does roughly the following:
[1] Delete all traces of a previous build
[2] Fetch from CVS a big part of the development environment
[3] Install the development environment
[4] Fetch from CVS the sources of the project
[5] Update the version number
[6] Tag the sources with the updated version number
[7] Build the sources, which result in an installer
[8] Log the build result

Now when the build script is done the automated tester running 
on a different machine, kicks in.  This automated tester does the following:

[9] Clean up the previous tested version
[10] Fetches the just build installer and installs it
[11] Run tests
[12] Log the test results.

This works very well, CVS is well suited for that except
for the following minor points:

[A] We split of branches near a release, and 
    it is tricky to merge between the release
    and main branch.  
    Furthermore, the branch hierarchy becomes
    not very intuitive when you have 
    1.0, 1.1, 1.2, 1.0.1,
    
[B] We want to work disconnected.

[C] We want to be able to test changes
    before merging them in the mainline,
    however branching and merging is
    time consuming and error prone.  So 
    when trying out some new code you  are 
    not really encouraged to create a branch.
    Also, it is not easy to retroactively 
    change to a branch in CVS.


Workflow with monotone
----------------------

So I would like to change to monotone and update
our way of working as well.

With respect to the build procedure we 
keep it roughly equivalent.  

We will have a branches
        
        project  (the main development branch)
        project.1.0 (a release branch)

Also each developer will have its own collectin
of branches, so for example:

        project.wim

So the idea is that:

        projects              projects.wim

   .....  A 
        \ | \________________    B (empty commit)
          C                      | do work
          | \                    D
          |  \_______________    |
          |                   \  |
          |                      E  merge mainline
          |  _________________/
          | /
          F

and we make sure that nobody commits to the main branch
between C and F.

So this is simple enough.  

Now we plan using certificates heavily, for example:

Version:  1.2.0.3
Build:    machine xxx: passed|failed
Build arguments:  special compiler flags used
Smoketest: ... passed| failed
Regressiontest: ... passed | failed
Bug fix implemented: bug nr
Devepment environment:  rev id of development environment used

and a few others.

I especially like the "bug fix implemented" certificate,
it will allow us to easily track which fixes are merged in 
which branch.  



Wishlist
--------

[A] commit a revision without making changes
[B] mark a head as a non-head for a branch


Use case I - Discard work
.........................

I have developed on my own branch project.wim
But I have been out of the loop for a while, so I want to start 
again.
          project        project.wim

           A  
            \_______________  B (empty commit)
                              | did work
                              C
          .
          .
          .
          X
            \______________  Y  


Y will be in the same branch, but I do not want C to show
up.  So I would like to mark "C" as a non-head on the branch project.wim


Use case II - Discard work
..........................

A made a change I which is a mistake

           A
           |
           B

B is a mistake, so I want to do:

          A          
          | \
         *B* C (empty commit)

and continue to work on C.  Just mark
B as a non-head and I am happy.
If I later decide to continue on B, I just
have to explicitly checkout revision B
and commit again to create

          A
          | \
         *B*  C
          |
          X (empty commit)



Use case II - Retroactive branching
...................................
I started making changes and commited them
in branch project.wim, but I suddenly decide that
they should NOT be in project.wim but in 
project.wim.experiment

So I have

         A [project.wim]
         |
         B [project.wim]


And I want B to be in project.wim.experiment.  What I
do is:
(1) add branch certifacet project.wim.experiment to B
(2) mark B as a non head for project.wim



        A [project.wim]
        |
        B [*project.wim*]
          [project.wim.experiment]

         

Use case III - adding other metadata
....................................
If we want to make a new build with a different version
number, it would be nice to just do an empty commit
and attach the new compiler flags and version number
to the new revision.



Finer points of wishes
----------------------
[A] commit a revision without changes.  
        default behaviour should be to refuse to commit,
        I prefer a command line flag like --force 
        is needed

[B] it really is necessary to make the "not head for branch"
    to take the branch into account.  Otherwise 
    it is not very usefull when a revision is 
    in multiple branches.
    
    Also, it should only apply for selecting heads
    and only apply to the specific revision.
    
    So the algorithm for heads is rougly:
     * look at heads for a particular branch.
     * filter out all the revisions that have
       the, "you are not head for this branch"
       certificate.


Work
----
If these wishes are appropriate, I am willing to take a stab 
at implementing them.  

Unfortuntaly, my only computer available right now is a
333 Mhz machine with 64Mb of memory, and that is a tad
slow for compiling monotone.  


Wim Oudshoorn.

P.S.: My machine spec is also the reason that I haven't 
written the lcad test case yet.