[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Workflow with Monotone
From: |
Willem Rein Oudshoorn |
Subject: |
[Monotone-devel] Workflow with Monotone |
Date: |
04 Jun 2005 22:08:56 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 |
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.
- [Monotone-devel] Workflow with Monotone,
Willem Rein Oudshoorn <=