<p>ⓒ Richard Levitte</p>
http://journal.richard.levitte.org/tags/monotone/Richard Levitte's journalikiwiki2011-04-19T07:55:22Zcommit-patchhttp://journal.richard.levitte.org/entries/commit-patch/2011-04-19T07:55:22Z2011-04-19T07:55:22Z
<p><a href="http://www.porkrind.org/commit-patch/">commit-patch</a>
is a cool little tool, if you want to quickly commit a patch even
though the affected files are filled with other changes that you
don't want to undo or commit at the time.</p>
<p>I recall that some people have asked if there might be some
build in support for partial commits in <a href=
"http://www.monotone.ca/">monotone</a>... there isn't. However, a
cool little tool like <a href=
"http://www.porkrind.org/commit-patch/">commit-patch</a> fits the
job perfectly.</p>
<p>There is just one little problem, it doesn't have monotone
support. Yet. I've added a small change that implements this and
sent it to the author. If there are no issues with it, I'm guessing
we'll soon see a tool that can help with partial commits with
monotone.</p>
monotone 1.0 is out!http://journal.richard.levitte.org/entries/monotone.1.0/2011-03-26T12:12:56Z2011-03-26T12:12:56Z
<p><a href=
"http://journal.richard.levitte.org/tags/monotone/../../images/openclipart/balloons-aj-small.png"><img src=
"http://journal.richard.levitte.org/tags/monotone/../../images/openclipart/balloons-aj-small.png" width="183"
height="200" class="img" align="right" /></a> Finally, it's
released. Shiny and new, I hope this will be a good one.</p>
<p>Have a look at <a href="http://www.monotone.ca/NEWS">the
NEWS</a>... hell, have a look at <a href=
"http://www.monotone.ca">the whole site</a>!</p>
<p>Next down the line for me is to have a Debian release out and to
play with usher. But now, <strong>Party!</strong></p>
monotone 1.0 is coming soonhttp://journal.richard.levitte.org/entries/monotone-1.0-coming-soon/2011-03-20T18:00:52Z2011-03-20T18:00:52Z
<p>We talked about releasing monotnoe 1.0 in Q1 2011, and we're
currently doing what we can to make sure we release something good.
Actually, as I write this, not much is happening, and I find that
oddly calming, it's not like there are some last minute show
stoppers (oh, <em>that's</em> a challenge ;-)). So, unless
something big happens, I expect to see a release fairly soon.</p>
<p>On a related note, I've promissed <a href=
"http://www.stacken.kth.se">Stacken</a> a lecture on March 31
(that's the last day in Q1, which I find oddly amusing). Time to
prepare, I think.</p>
Monotone branch renaming revisitedhttp://journal.richard.levitte.org/entries/monotone-branch-renaming/2011-02-28T10:51:41Z2011-02-28T07:40:35Z
<p>Up until now, <a href=
"http://wiki.monotone.ca/BranchRenaming/">branch renaming</a> has
been a tricky issue with <a href=
"http://www.monotone.ca/">monotone</a>... and for good reasons.
What makes it tricky is that as soon as a branch has left the
building (in this case, your own database) out into the world
(basically, any other database), you're stuck with what there is
unless you track down every damn database where it has ended up and
convince every last owner of those databases to do the same change
you did. That might be hard work.</p>
<p>So far, it has been recommended to think of what globally unique
name you should use for your branch from the start, since you can't
undo it later.</p>
<p>My question is, though, is that really true any more? After all,
since that time, <a href="http://www.monotone.ca/">monotone</a> has
evolved further, new features have been added, and they might help
us in this case.</p>
<p>Let me introduce you to this little command:</p>
<pre>
mtn suspend
</pre>
<p>This little command, which has been around since version 0.41
(September 2008), allows anyone to mark a revision as suspended,
discontinued. If all heads of a branch are suspended, that branch
will not be displayed any more. It will become invisible.</p>
<pre>
$ ########################################
$ # Preparations
$ #
$ mtn -d foo.mtn db init
$ mtn -d foo.mtn setup workspace -b foo -k richard@levitte.org
$ cd workspace
$ echo a > a; mtn add a; mtn ci -m "initial commit"
mtn: adding a to workspace manifest
mtn: beginning commit on branch 'foo'
mtn: committed revision bb0a1222004d13502ff27be2c92fbe6cb3f7ebf2
$ ########################################
$ # Done with the preparations
$ #
$ mtn ls branch
foo
$ mtn suspend w:
mtn: expanding selection 'w:'
mtn: expanded to 'bb0a1222004d13502ff27be2c92fbe6cb3f7ebf2'
$ mtn ls branch
$
</pre>
<p>Now, if you commit a new revision on a branch where the head is
suspended, that branch will reappear.</p>
<pre>
$ echo b > b; mtn add b; mtn ci -m 'b' b
mtn: adding b to workspace manifest
mtn: beginning commit on branch 'foo'
mtn: committed revision fc6c73dc99a8f71350507a5369bdd0fa93664b41
$ mtn ls branch
foo
$
</pre>
<p>However, if you commit that same new revision with a new branch
name, the old branch (whose head is the parent of the newly
committed revision) will remain invisible, while the new one
appears, with a history that goes back into the old (now invisible)
branch.</p>
<pre>
$ # This example is instead of the previous commit
$ echo b > b; mtn add b; mtn ci -b bar -m 'b' b
mtn: adding b to workspace manifest
mtn: beginning commit on branch 'bar'
mtn: committed revision fc6c73dc99a8f71350507a5369bdd0fa93664b41
$ mtn ls branch
bar
$ mtn log --no-graph
----------------------------------------------------------------------
Revision: fc6c73dc99a8f71350507a5369bdd0fa93664b41
Parent: bb0a1222004d13502ff27be2c92fbe6cb3f7ebf2
Author: Richard Levitte <richard@levitte.ord>
Date: 02/28/11 08:32:41
Branch: bar
Changelog:
b
Changes against parent bb0a1222004d13502ff27be2c92fbe6cb3f7ebf2
added b
----------------------------------------------------------------------
Revision: bb0a1222004d13502ff27be2c92fbe6cb3f7ebf2
Author: Richard Levitte <richard@levitte.ord>
Date: 02/28/11 08:31:19
Branch: foo
Changelog:
initial commit
Changes
added
added a
$
</pre>
<p>Another way to achieve the same effect without committing
something new is, of course, to simply add another branch cert to
the revision you just suspended.</p>
<pre>
$ # This example is instead of any of the two previous commits
$ mtn cert bb0a1222004d13502ff27be2c92fbe6cb3f7ebf2 branch "bar"
$ mtn ls branch
bar
$ mtn log --no-graph
----------------------------------------------------------------------
Revision: bb0a1222004d13502ff27be2c92fbe6cb3f7ebf2
Author: Richard Levitte <richard@levitte.ord>
Date: 02/28/11 08:31:19
Branch: bar
Branch: foo
Changelog:
initial commit
Changes
added
added a
$
</pre>
<p>So, this isn't reeeally branch <strong>renaming</strong> per se,
but it has the same effect in practice, <em>and</em> it comes with
the benefit that this is entirely supported by monotone, there's no
need to remove a whole bunch of branch certs and add the same
number of new ones, there's no need to chase down every damn
database this might have spread to. There's no need for
trickery.</p>
Done packaging usherhttp://journal.richard.levitte.org/entries/usher-done/2010-12-02T22:27:17Z2010-12-02T22:27:17Z
<p>I've finished packaging usher... at least the upcoming 1.0
<em>(which comes as <a href=
"https://code.monotone.ca/p/contrib/source/tree/1d4ef14f99fbafcc9071db37de41cfa4138dbb8d/">
1.0~dev</a> for now)</em>. Some have asked me if I can backport it
to usher <a href=
"https://code.monotone.ca/p/contrib/source/tree/t:usher-0.99/">0.99</a>,
and sure, I certainly can. There are two ways to do that, one is to
have the tool <tt>usherctl</tt> <em>(which is part of 1.0~dev but
not 0.99)</em> be part of the debian package, or do things a bit
differently <em>(and quite hard-coded, I might add. Still, it's
quite possible to do)</em>. Choices, choices, both are ugly, just
from different points of view, but may be worth it.</p>
<p>I've updated <a href=
"http://journal.richard.levitte.org/tags/monotone/../../entries/things-to-do-for-monotone-1.0/">my list of things to
do</a>.</p>
Monotone tip of the day: using usher as drop in replacementhttp://journal.richard.levitte.org/entries/transparent-usher/2010-11-25T13:48:19Z2010-11-25T13:36:00Z
<p>I've started fiddling with <a href=
"http://code.monotone.ca/p/contrib/source/tree/h:net.venge.monotone.contrib.usher/">
usher</a> on Debian and trying to figure out a good way to have it
replace a bare monotone server (the way it's currently done with
the Debian package <a href=
"http://packages.debian.org/sid/monotone-server">monotone-server</a>),
and the big question was how to have a smooth and transparent
transition.</p>
<p>Of course, it's a matter of configuration, and the result I came
with was to have a catch all usher server stanza in the usher
configuration file:</p>
<pre>
server ".catchall."
pattern ""
local "--confdir=/etc/monotone"
"--db=/var/lib/monotone/default.mtn"
"--no-standard-rcfiles" "--rcfile=/etc/monotone/hooks.lua"
"--keydir=/var/lib/monotone/keys"
</pre>
<p>(The parameters following <tt>local</tt> are the same given to
the server process in <a href=
"http://packages.debian.org/sid/monotone-server">monotone-server</a>)</p>
<p>The crucial part here is to have that empty pattern prefix, it
will really catch anything that's sent to usher with the following
form:</p>
<pre>
mtn pull 'mtn://{host}:{port}?{branch1};{branch2}'
</pre>
<p>Calls that include a server name, such as the following, will
match the stanza with the correspoding server name or will return
an error of there is none:</p>
<pre>
mtn pull 'mtn://{host}:{port}/{server}?{branch1};{branch2}'
</pre>
<p><em>Note: if your really doing this to replace Debian's
monotone-server process, make sure the usher process is run by the
user <tt>monotone</tt> user. It should really not be too difficult
to copy <tt>/etc/init.d/monotone</tt> and change it to work with
usher. I might post an usher-specific init script in another blog
entry...</em></p>
Things to do for monotone v1.0http://journal.richard.levitte.org/entries/things-to-do-for-monotone-1.0/2010-12-02T22:35:26Z2010-11-18T15:18:32Z
<p>For monotone v1.0, it would be nice if we actually released
something that felt fairly complete. The question is, what should
be included?</p>
<p>Right this moment, I'm looking through the <a href=
"https://code.monotone.ca/p/monotone/source/tree/h:net.venge.monotone/contrib">
contributed scripts that are packaged in the source
distribution</a>, making sure they work properly with <a href=
"https://code.monotone.ca/p/monotone/source/tree/t:monotone-0.99.1/">
the latest release</a>, that they use up to date technology (let me
tell you, monotone has had some cool additions lately!), things
like that. Just now, I reworked the <a href=
"https://code.monotone.ca/p/monotone/source/tree/h:net.venge.monotone/contrib/monotone.bash_completion">
old bash completion script</a> into a <a href=
"https://code.monotone.ca/p/monotone/source/tree/h:net.venge.monotone/contrib/monotone.bash_completion2">
new version</a> that <a href=
"https://code.monotone.ca/p/monotone/source/tree/h:net.venge.monotone/contrib/monotone_gen_bash_completion_table.pl">
gets its data directly from the current man page</a>.</p>
<p>What else have I been thinking of? Well, a few things
actually:</p>
<ul>
<li>having newer versions of <a href=
"http://buildbot.net/">buildbot</a> work with monotone... sadly
enough, it seems like the build in support is not up to date, and
it seems like it's been removed from version 0.8. Since we're using
buildbot for tests, we do need to have this working. <strong>this
is actually pretty high priority</strong></li>
<li>packaging <a href=
"https://code.monotone.ca/p/contrib/source/tree/h:net.venge.monotone.contrib.usher/">
usher</a> for Debian. <a href=
"https://code.monotone.ca/p/debian-mtn/source/tree/h:org.debian.usher/">
I've started on the program itself</a>, I still need to add the
information for a server package around usher (I plan to call it
monotone-server-usher).<br />
<strong>DONE</strong></li>
<li>Keep working on the scripts in the <a href=
"https://code.monotone.ca/p/monotone/source/tree/h:net.venge.monotone/contrib">
<tt>contrib/</tt> directory</a> with the intention to try to see
what could become supported stuff.</li>
<li>Finish up the <a href=
"https://code.monotone.ca/p/monotone/source/changes/h:net.venge.monotone.bugfest-2010.28805-rlevitte/">
bugfix</a> I worked on during the last <a href=
"http://colabti.org/irclogger/irclogger_log/monotone?date=2010-05-08">
bug</a><a href=
"http://colabti.org/irclogger/irclogger_log/monotone?date=2010-05-09">fe</a><a href="http://colabti.org/irclogger/irclogger_log/monotone?date=2010-05-10">st</a>.</li>
</ul>
<p>The list could probably be made longer. Any ideas or wishes?
Please email me.</p>
<p><strong>Update 2010-12-03</strong> (<a href="http://journal.richard.levitte.org/tags/monotone/#fn:iso" id=
"fnref:iso" class="footnote" name="fnref:iso">1</a>): I've now done
what's needed to package usher 1.0~dev. Well, ok, except there's
still no manpage for <tt>usherctl</tt>, but that's a relatively
small thing...</p>
<div class="footnotes">
<hr />
<ol>
<li id="fn:iso">
<p>That's december 3rd 2010 <img src="http://journal.richard.levitte.org/tags/monotone/../../smileys/smile4.png"
alt=";-)" /><a href="http://journal.richard.levitte.org/tags/monotone/#fnref:iso" class=
"reversefootnote"> ↩</a></p>
</li>
</ol>
</div>
Cool things with monotone 0.99http://journal.richard.levitte.org/entries/monotone-coolness/2010-11-11T13:45:33Z2010-11-11T13:45:33Z
<p>If you follow what's happening with <a href=
"http://monotone.ca/">monotone</a>, you've probably seen that
there's been some major development lately, and that we're getting
much closer to a version 1.0. As a matter of fact, 0.99 is more or
less to be seen as a pre-release, or RC1, or something like
that.</p>
<p>It's full of nice little tricks that you can do to make yoru
life easier. For example, to do some on-the-side processing, it's
often not at all necvessary to pull a mirror of the database, as
there is a mechanism to do runt remote commands (that are performed
by the server, with the output being sent back to you). Mail
notification scripts and other things like that have been updated
to use these new features.</p>
<p>Just among the little cool things that weren't possible before,
copying branches from one database into another, with full control
over revision, the revision graph and all that, is done as simply
as this:</p>
<pre>
<code>mtn -d /PATH/TO/MY/db.mtn pull file:///PATH/TO/OTHER/database.mtn '*'
</code>
</pre>
<p>Actually, if you use monotone regularly, I urge you to try 0.99
today. It's been thoroughly tested, among other by being used live
on the <a href="http://code.monotone.ca/">monotone server</a>, and
is a good way to get to know the new and changed features without
having to wait until 1.0.</p>
<p>When is 1.0 coming out? I don't really know, but there's a
desire to get it out before the end of the year. I jokingly said on
the developers mailing list that we could make a Christmas
release... and maybe that's a joke that'll be reality, eh <a href=
"http://www.thomaskeller.biz/blog/">Thomas</a> (<a href=
"http://journal.richard.levitte.org/tags/monotone/#fn:release" id="fnref:release" class="footnote" name=
"fnref:release">1</a>)? <img src="http://journal.richard.levitte.org/tags/monotone/../../smileys/smile4.png" alt=
";-)" /></p>
<div class="footnotes">
<hr />
<ol>
<li id="fn:release">
<p>Thomas has been our release manager for the last
releases.<a href="http://journal.richard.levitte.org/tags/monotone/#fnref:release" class=
"reversefootnote"> ↩</a></p>
</li>
</ol>
</div>
Monotone moving onhttp://journal.richard.levitte.org/entries/monotone-moving-on/2010-11-02T14:52:43Z2010-11-02T14:52:43Z
<p>Not long ago, after having been served by my server for a few
years, the monotone repository has moved to another server,
integrated in a project infrastructure powered by <a href=
"http://indefero.net">indefero</a>.</p>
<p>Please see us at <a href=
"http://code.monotone.ca">http://code.monotone.ca/</a>.</p>
<p>Not all services are up yet, it seems like <a href=
"http://buildbot.net/">buildbot</a>'s support for monotone is
seriously lacking, it even seems to be removed in version 0.8,
which is a bit of a pain... we're working on it, though.</p>
<p>More news, including a aggregation of known blogs, can be found
on the <a href="http://monotone.ca/">main page</a>.</p>
How monotone changes your views and your wayshttp://journal.richard.levitte.org/entries/monotone-changes-your-view/2010-11-02T14:56:27Z2006-03-18T19:02:46Z
<p>I've noticed how much <a href=
"http://monotone.ca/"><tt>monotone</tt></a> has changed my habits
and views on version control. From being a fairly mature <a href=
"http://www.cvshome.org">CVS</a> user and <a href=
"http://www.catb.org/jargon/html/H/hacker.html">hacker</a>, I've
now fully moved to use <a href=
"http://monotone.ca/"><tt>monotone</tt></a> as much as I can. It
was most noticable a couple of days ago, when I worked on some
project that's still versioned using <a href=
"http://www.cvshome.org">CVS</a>, and wondered why so many files
were missing, until I realised I had forgotten to update with
<code>-dP</code>... Those flags used to be second nature!</p>
<p>The thing that attracted me the most about <a href=
"http://monotone.ca/"><tt>monotone</tt></a> was its off-line
capabilities and the way it keeps track of history, which is
essential to get merging working the way I want (contrary to the
way I have to do it with <a href="http://www.cvshome.org">CVS</a>,
with all the dealing with tags and all). I've also come to realise
that the way it works leads to a different approach to work
flow:</p>
<dl>
<dt><b>Maintainance branches</b>:</dt>
<dd>many large projects that use <a href=
"http://www.cvshome.org">CVS</a>, for example <a href=
"http://www.openbsd.org">OpenBSD</a> and <a href=
"http://www.openssl.org">OpenSSL</a>, use separate branches to
maintain one or two "current" versions of the product while still
being about to do "bleeding edge" development in the trunk. When
you want to make a change (a bug fix), you might need to do it in a
maintainance branch and then merge the results into the main trunk,
which leads to the typical merge hassle with <a href=
"http://www.cvshome.org">CVS</a>. With <a href=
"http://monotone.ca/"><tt>monotone</tt></a>, it's a bit of a
different story. First of all, you don't really have to deal with
separate maintainance branches. Since a branch can have multiple
heads, all you need to do it is to update to the latest release,
make your change and commit, then tag it. If you want to merge the
change with the other (or all the other) head(s), you simply merge.
Of course, it might be more practical to have a separate branch for
maintainance, but at least there is the option! There is no such
option with <a href="http://www.cvshome.org">CVS</a>.</dd>
<dt><b>Looking at it as things to follow up on</b>:</dt>
<dd>Just an hour or two ago, someone said there was a bit of an
error in <tt>Makefile.am</tt> in the <a href=
"http://monotone.ca/"><tt>monotone</tt></a> source. I decided to
take it on, and decided to do it in a slightly different way.
Instead of just update to the head and make the change there, I
updated to the revision where the error was introduced, made the
correction, committed, which of course created a second head, and
finally merged While being something of an experiment, it taught me
another way to look at source development, as responses to very
specific events. Basically, I treated this particular event as an
email to follow up on, which creates a link between the other
emailer (committer) and me, and a thread of emails (revisions) to
follow. Kind of a different view, much more like people responding
to each other than people dealing with a big blob called the source
and whatever "magically" happens in it. A kind of social
interaction between developers, maybe far away from each
other.</dd>
</dl>