Re: [Monotone-devel] commit date patch

[Nathaniel Smith]

On Sat, Apr 16, 2005 at 08:29:16PM +0200, Markus Schiltknecht wrote:
> 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.

Cool.  cvs_import and cvssync are very good at what they do (when they
don't have bugs :-)), but you're right that this approach is more
general.

> 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?

It doesn't seem so bad to me.  I've merged your patch (with some
modifications), as well as a similar --author option (which we've been
needing anyway).

> 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?

Ah, this keeps coming up; I've just added a FAQ entry on it.  The
short answer is -- you probably don't want to :-).

> 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?)

Monotone is slow because it is unoptimized, and because it does
careful safety checking on all data it handles.  It is already much,
much faster than it was a month or two ago when we started optimizing
in earnest.  The slowness has basically nothing to do with the
database backend.

Atomic operations are a rather nice feature in a VCS, we think, and
monotone uses SQLite's transaction support extensively.  There
are ways to design file-based backend that aren't too dangerous,
though, for instance by designing it to be "write-once", like
subversion's fsfs, or git.

> 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.)

Is it still true that "drop file" fails if "file" has already been
deleted?  If so that's definitely a bug, and a fixable one.

I don't think t_delete_dir is something you want to wade in on right
now, though; I've sorta been thinking we'd just wait until graydon got
back and we got around to the directory support overhaul that we
realized was needed just before he left... of course, if you feel up
to it, by all means :-), it's just that it's about as intrusive a
change as you'll find anywhere...

I'd just work around it by deleting files, instead of directories.

-- Nathaniel

-- 
Sentience can be such a burden.