Re: [Monotone-devel] cvs_import failure

[hendrik]

On Wed, Dec 23, 2009 at 09:01:04AM +0100, Markus Wanner wrote:
> Hi,
> 
> address@hidden wrote:
> >I'd like to look at this, possibly next January.  If anyone else would, 
> >please do also.
> 
> Cool!
> 
> Which one was that again, git to monotone converter?

DOn't care all that much.

I have an existing CVS repository, still in active use, to convert to 
monotone.  Ideally under the constraint that people still working on 
branches in CVS will be able to finish their work and check stuff in and 
have the updates converted as they trickle in -- so that new stuff can 
be started in monotone and old stuff finished in CVS.

> 
> >The more the merrier, at least during design discovery 
> >stage.  What languages are all these *2* programs written in?
> 
> cvs2svn and its derivates are written in python.

python is easier to debug than C++.

One option is to replace the svn-output stuff with uses of monotone 
automate.

with all these cvs2* programs around, it might be useful to 
isolate their common core (the cvs part and the 2 part) from the * part.
Incresed modularity.  ANy chance that such factoring would spread to the 
others and overall maintenance costs?

I also have a CVS updater (CVSup) that updates slave CVS repositories 
from a master repository (CVSup). It's written in Modula 3, another 
language that's easy to debug in and the advantage that it's statically 
typed.  CVSup will interface with remote CVSs over the net, but lacks 
the analysis that cvs2svn does to figure out the structure.

> 
> >IN case I have to tear one apart, are any written in secure, statically 
> >typed languages (whose programs I find easiest to read and debug).
> 
> The existing cvs_import and git_export commands are certainly written in 
> C++. Something like git_import would be very welcome, IMO.

Ideally mtn sync would detect the system used at the other end and use 
the appropriate conversion tool automatically.  But this is probably 
just pie in the sky for now.  Especially syncing with systems that don't 
maintain information monotone uses.

-- hendrik