[Monotone-devel] commit date patch

[Markus Schiltknecht]

Hello monotone hackers,

because I wanted to convert not only CVS repositories but also
subversion ones to monotone, I hacked tailor.py to support monotone
partly. My final intention is to replay a whole repository history. To
convert between SCMs the tailor.py approach seems more universally
usable than cvs_import. tailor.py uses the original tool to checkout a
revision, get information about the next changes, apply a single
changeset and then uses 'normal' monotone or subversion or darcs or ...
commands to commit into the destination repository. It's even possible
to keep two different kinds of repositories in sync with each other (as
long as there are no conflicts, I guess). Of course replaying a whole
repository might take longer than cvs_import, but since you normally do
that only once I don't mind to much.

To be able to replay a repository including original dates I needed an
option to the monotone commit command to be able to backdate a commit.
The attached patch adds a '--date' flag so commits can be given any
date. Currently there's absolutely no error checking, you can give it
any date you want. I guess it's not clever (at least not user-friendly)
to keep that option as it is, but repository replaying absolutely needs
such an option. What's the proper way to offer such an option? Maybe as
an automation command?

What I (as a database interested programmer) really like about monotone
is that it saves its data in as database and queries it via SQL. I
thought I could try to code a PostgreSQL backend for monotone. Anybody
already working on that? Hints on where to start with?

Also the disconnected operation impressed me (compared to subversion,
with it's central repository). But what's hard to understand is: why is
monotone so slow? In (my) theory a database backend should be optimal,
even better than a filesystem based approach (like git :-)  BTW an
approach I don't completely understand. Aren't things like atomic
operations quite an important features of databases that a SCM can or
should make use of? Or what are the ideas behind git which make it
fast?)

The repository I want to replay currently also has deleted files and
even directories. Because the files and directories to be removed are
already gone when monotone gets the drop command that still fails. I
would like to implement (or have it implemented :-) the t_delete_dir
test. Thought I don't understand the comments in t_delete_dir.at,
currently. I'll have to reread it... (..and stop writing mails, but
write code.)

I'd be glad to contribute to the monotone development and thankfull for
every help in understanding it's internals.

Regards

Markus

monotone.date.patch
Description: Text Data