monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Monotone support for tailor.py


From: Markus Schiltknecht
Subject: Re: [Monotone-devel] Monotone support for tailor.py
Date: Tue, 19 Apr 2005 12:15:30 +0200

Hello Nathaniel,

On Mon, 2005-04-18 at 19:56 -0700, Nathaniel Smith wrote: 
> > FYI, Markus sent me his work that is now integrated in the tool. Many
> > thanks again, Markus.
> > 
> > Tailor can now be used as a gateway between {svn,cvs,darcs}->monotone,
> > and can easily be extended to go the other way around too.
> 
> Awesome, thanks to both of you.  I've put a link to Tailor at
>    http://www.venge.net/monotone/tools.html

Cool, but keep in mind that Tailor doesn't really work well together
with monotone, yet. I should write something in the Tailor wiki...

There are problems when you have deleted directories (i.e. deleted all
files in a directory, cvs removes the directory). Other problems I
couldn't track yet.

Then, string_to_datetime doesn't seem to accept date strings as they
appear in CVS anymore (i.e. "1996-09-19 20:17:48"). I wanted to correct,
did monotone update first but it didn't compile:

commands.cc: In function `boost::posix_time::ptime
commands::string_to_datetime(const std::string&)':

I've investigated and found out: "This was a problem in the 1_31 release
-- the constructor was accidently droped.  The file has been fixed in
CVS.  You can patch your 1_31 release by getting the
latest /boost/date_time/posix_time/ptime.hpp"

I'm updating to boost 1_32, being quite sure that got fixed. Maybe you
want to add a hint stating 1_31 as buggy. I tried to circumvent the
problem, but I didn't manage to see through the complicated boost c++
headers...

On Sat, 2005-04-16 at 19:08 -0700, Nathaniel Smith wrote: 
> 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.

Well, that's the point: it didn't work for me :-(

I tried converting the PostgreSQL repository and got the following error:

$ monotone --db=pgsql.db cvs_import ../fullrep/cvsrepo/pgsql 
--branch=org.postgresql
monotone: [branches: 20] [versions: 97526]
monotone: phase 1 (version import) complete
monotone: [branches: 20] [finished branches: 7] [finished edges: 1516] 
[versionsmonotone: fatal: std::logic_error: change_set.cc:2550: invariant 
'I(b.rearrangement.deleted_files.empty())' violated
monotone:
monotone: this is almost certainly a bug in monotone.
monotone: please send this error message, the output of 'monotone 
--full-version',
monotone: and a description of what you were doing to address@hidden: 
discarding debug log (maybe you want --debug or --dump?)

I've reproduced that yesterday, with monotone's head version. I didn't inspect 
further. Any hints?

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

Thank you for clarification. Now there is only one reason left: I like
PostgreSQL and trust it more than SQLite. :-)

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

I've discovered the MT/inodeprints setting. That makes monotone even
faster than subversion or cvs (at least for status and diffs, which is
what I'm most concerned about). What are the dangers, why isn't that
active by default?

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

No, I don't think so. But I have to cope with complete directories getting 
deleted by Tailor/CVS...

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

What exactly do you mean by 'directory support'? I thought of just
removing the files that were deleted anyway from the manifest...
especially if there was a 'monotone drop $DIRECTORY' command issued
first.

I'm currently doing that by hand: as soon as tailor/monotone gets stuck,
I'm moving back the files that were already deleted by CVS, dropping
them in monotone, commit for monotone and then remove the files again
(cvs update).

Markus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]