[Monotone-devel] Re: CvsImport

[Markus Schiltknecht]

Hi Thomas,

Thomas Lotterer wrote:
> this is a reply to http://www.venge.net/mtn-wiki/CvsImport

I'm CC'ing this to the monotone mailing list. Hope that's okay for you.

> You don't know me, but let me tell you that my colleagues know me as a person who tends to see lots of challenges for problems they classify being easy to solve This time I wonder whether I'm the guy who sees an easier approach :-) 

If there is an easier way, I'd be glad to hear. But so far, the graph 
based approach seems to be the easiest way, which still gives correct 
results.

> I also want to note that we at OpenPKG know CVS from the inside out, using it 
> to the fullest possible extend and beyond. I mean we even patched in new 
> functionality published as OSSP shiela [1] access control and logging.

Wow..

> We use branching and branch off from branches

That should be no problem. Unnamed branches are a little trickier.

> and at openpkg.COM we operate a private repository which is bidirectionally 
> synced manually with openpkg.ORG - an effort simply too much for CVS and the 
> root cause of my hunt for a replacement.

Hehe... sounds like netsync is just exactly what you need. ;-)

> Back to the topic.
>
> Do you know CVStrac [2]?

Yup, seen it.

> It is written by D. Richard Hipp, the fellow who also created SQLite which I'm sure a 
> Monotone developer knows very well.  CVStrac is a web interface used to browse a CVS 
> repository. It has an interesting feature called "timeline" which shows the 
> history of the CVS by Check-in's.

Nice, but I'm pretty sure he's not using anything more fancy than 
looking at timestamps. That's simply not enough in many cases.

> Yes, not per file commits, but patch sets.  For a quick look watch the timeline 
> of CVStrac development [3] itself. I know from our usage at OpenPKG that 
> CVStrac combines commits with close time proximity and common log message and 
> it understands branches.It reads the CVS history file to grab that information 
> and guess where it is stored: in a SQLite database. Maybe it is enough to 
> extract the information from that DB and most of your CvsImport job is done.

Take a look at the story of cvs2svn. There's a reason why they are 
moving towards cvs2svn 2.0, with pretty much the same graph based algorithm.

> Anyway, independent from CVStrac there is another interesting tool called CVSps [4], 
> "a program for generating 'patchset' information from a CVS repository".  May 
> also help to avoid reinventing the wheel.

I know that one as well, and have tested it on old and large 
repositories. But again, that tool fails miserably on certain CVS 
repositories - where a graph based algorithm can certainly do better.

The only thing I'm asking myself sometimes is, why not write a better 
cvsps, based on the monotone code?

Anyway, thanks for you inputs.

Regards

Markus