[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] m7 rises from the dead... reborn with new non-irrit
Re: [Monotone-devel] m7 rises from the dead... reborn with new non-irritating behavior!
Tue, 7 Nov 2006 11:19:12 +0100
Great. This is the functionality that I was looking for some time
ago, to automate building automake packages for my software.
I wrote a small perl script some time ago, that upon execution, tagged
the current revision with a monotonically incrementing version number,
next builds an automake package (using 'make dist'), whose name
depends on the package name, and on the current version number and the
current branch name. This works using ako keyword expansion on
selected files. Fi. a package with name 'heccer' can have branches
'passive' and 'active', and the consequent releases would be called
and so on.
This automates building releases, and avoids human errors. The
release number is saved in a small database, currently included in the
project, such that a next release number can be generated from the
database. The downside is that this database is committed with the
project and that a tag is set on the previous revision, after
incrementing the version number. Both these operations can possibly
fail and leave the system in an inconsistent state, because the
repository is kind of ahead of the released package. This is just a
minor issue, but it makes me feel uncomfortable.
So far the script works without problems. I am just wondering about
the relationship between what you have done and what I have done ?
Can I use your versioning method in combination with my keyword
expander and build automake packages for heccer and neurospaces
automatically ? Can I use m7 and monotone interchangebly for monotone
functions ? I.e. I only have to call m7 to get the version number ?
On 11/6/06, Larry Hastings <address@hidden> wrote:
Howdy folks! Today I announce a new version of m7. In case you forgot, m7
is a proof-of-concept Python script that adds simple "local revision
numbers" to monotone. These local revision numbers are simple monotonically
increasing numbers affixed to revisions, and you can use them anywhere you
specify a revision on the command-line. To ensure it's unambiguous, you
need to prefix the revision number with a colon. So, if revision
"818b9c9604efad446e5729d82a707714fea92cde" was local
revision number 5, these commands are equivalent:
m7 cat --revision=:5 foo.cpp
When I announced m7 over a year ago I didn't know what to expect. Reactions
were mixed, from negative like "I would never use this, and I hope no one
else does either", to positive like "I would never use this, but it's kind
of neat"*. The original objection to m7 was its use of tags to track local
revision numbers. Later I changed to custom certs, but that was little
improvement. Since these tags & certs become part of your database, they
would be sync'd to external users, even though they were primarily intended
for local use. Correspondents on the monotone mailing list felt these certs
would clutter up their databases and network traffic.
However! Some senior monotone fella, surely either Graydon or Nathaniel,
suggested an approach that doesn't need these certs―and is both faster and
less error-prone to boot. It relies on a slightly-obscure feature of
SQLite: every table has an indexed unique auto-incrementing integer column,
whether or not it specifies one explicitly in its schema (see
http://www.sqlite.org/autoinc.html ). So each entry in the
revision table already has a locally-unique "revision number", ready-made
and just waiting to be exposed to the monotone user. This even works,
automatically, for external revisions you get from a network sync―a feature
the old m7 never had, and never would! The only downside to this approach
is a descent into "mtn db execute" territory, but it's a quick trip.
I am therefore pleased to announce m7 version 0.8, which does not create
extra tags or certs. Its only overhead is three "database variables" for
local configuration which do not get propogated via netsync. You should
feel free to download it and play around with it, secure in the knowledge
that it will not "infect" your repositories with extraneous certs. m7 is
written in Python, and requires version 2.3 or higher.
Apart from the exposed local revision numbers, m7's other main feature is a
more readable form of annotate. I tinkered with this a little too; now by
default it prints a legend of the relevant revisions at the top before the
In case you're an existing m7 user, you can remove all the old m7 cruft by
running "m7 unpopulate" from your work directory. (And you could give me
the shock of my life by letting me know you were actually using m7.)
You can read more about m7, and download a copy, here:
* This is exaggerated for comedic effect, though I do believe I have zero
active users of m7. But let it be said that the monotone developers were
always supportive of my experimenting with monotone's UI.
Monotone-devel mailing list
Hugo Cornelis Ph.D.
Research Imaging Center
University of Texas Health Science Center at San Antonio
7703 Floyd Curl Drive
San Antonio, TX 78284-6240
Phone: 210 567 8112
Fax: 210 567 8152