[Monotone-devel] [ANNOUNCE] monotone 0.18

[Nathaniel Smith]

I am pleased to announce that monotone 0.18 has been released, and is
available from the monotone web site:
    http://venge.net/monotone/

This release adds a number of new features, usability improvements,
bug fixes, and performance improvements; the full NEWS file is
attached below.

Many will be particularly interested in the performance improvements.
The checking done by an initial 'pull' has been sped up by a factor of
very roughly 2 (this will vary a great deal depending on the size of
your tree, etc.).  Additionally, performance on large trees has been
improved.  For instance:

$ tar xjf linux-2.6.11.tar.bz2                                                  
                                   
$ cd linux-2.6.11 
$ monotone --db ../test.db setup .    
$ time ../../0.18/monotone add . 2>/dev/null
monotone add . 2> /dev/null 10.12s user 0.32s system 93% cpu 11.147 total
$ time ../../0.18/monotone commit --branch=org.example.kerntest --message=test 
monotone: beginning commit on branch 'org.example.kerntest'
enter passphrase for key ID [test]: 
monotone: committed revision f57d9b5a2a22dda8fb62c0dafd280242e6a89e06
monotone commit --branch=org.example.kerntest --message=test  144.05s user 
9.06s system 77% cpu 3:18.04 total
$ time ../../0.18/monotone diff                                               
# 
# no changes
# 
monotone diff 16.86s user 1.21s system 73% cpu 24.506 total

That last measurement can be improved somewhat by the new
"inodeprint" support.  Previously (and still by default), monotone
detects changes in a working copy by simply hashing all files in the
working copy.  On large trees, this takes several seconds of CPU, and
can take several minutes of IO.  The new functionality is that you can
request that monotone keep a cache of some quickly computed metadata
about each file in the tree (mtime, size, etc.), and assume that any
files whose metadata has not changed have their contents unchanged as
well.  There is no documentation or UI for this yet; for now, "touch
MT/inodeprints" to turn it on, and then do a "commit", "update", or
"revert" to trigger a cache regeneration.  (The best time to do it is
right after running "monotone setup".)  These 3 operations are
somewhat slowed down (though this can be optimized somewhat in the
future), and it will _not_ give you sub-second diff calculation, but
it does give a reasonable speedup in all cases and a huge speedup on a
cold cache.  Rerunning the last command above with a working copy in
inodeprints mode gives:

$ time monotone diff
#
# no changes
# 
monotone diff 11.78s user 0.15s system 99% cpu 12.029 total

The remaining 12 seconds are almost entirely taken by monotone's
sanity checking of the generated changeset -- verifying that you
don't have "rename foo bar" and "add bar" together, you don't have two
files named "foo/bar" and "foo", or two different files with names
"foo/./bar" and "foo/bar", or any file named
"../../.ssh/authorized_keys", etc., etc.  This should be highly
susceptible to further optimization -- 10-20% of the time is taken by
malloc locking/unlocking mutexes (in a single-threaded program), it
seems likely that the filename parser we use from Boost could be sped
up, etc.  More profiling and optimizations welcome.

-- Nathaniel

-- 
"Lull'd in the countless chambers of the brain,
Our thoughts are link'd by many a hidden chain:
Awake but one, and lo! what myriads rise!
Each stamps its image as the other flies"
  -- Ann Ward Radcliffe, The Mysteries of Udolpho

NEWS
Description: Text document