cvs2hg emit .hgeol?

[Tom Udale]

Dear Greg,

> Hahaha. Nice try.

:)  I had a feeling that it was a supremely optimistic attempt.


> The good news is that cvs2{svn,hg} is written in a very extensible
> style, so it's not too hard to add your own behaviour. Three cheers
> for the cvs2svn developers: it's a great piece of software. I suggest
> you sneak in a synthetic revision 0 that adds the .hgeol you want.
> That way, it's *always there* no matter what old changeset you update
> to.
>
> (The docs for eol are unclear, but from peeking at the code it looks
> like it reads .hgeol from the working dir. So if you add .hgeol
> *after* your CVS conversion, then people working at tip are fine and
> benefit from eol. But if someone updates to an old pre-conversion
> changeset, there is no .hgeol file and thus I'm not sure what eol will
> do.)
>
> I did a similar trick to add .hgignore to our Mercurial repo before
> any changesets converted from CVS. Worked great, although it does look
> a bit weird having rev 0 from 2010 and rev 1 from 1998. ;-)

Indeed this synthetic add is exactly the goal.  It does address the 
issue you mention (and which Martin confirmed for eol), namely that if 
you simply add .hgeol (or .hgignore for that matter) to a converted 
repository, you are ok going into the future, but you are hosed the 
moment you check out before the conversion time.

I figured out, with the help of the forum, how to do this with clone and 
convert splicemap.  It would obviously be ideal if cvs2hg could add 
these sorts of files as part of its routine, particularly since it can 
gather the requisite information from the CVS repository and .cvsignore 
files.

Unfortunately, I am probably not the person to do this.  I am in a 
Windows C++ shop so not only do I not know a damn thing about Python, I 
don't have a Python tool chain set up that would let me poke at it.  I 
would be starting literally from zero.

Indeed, I have been using turtlehg which seems to provide its own python 
and mercurial does not appear to play well with a normal 
python/mercurial install.  I cannot even run cvs2hg on my windows 
machine (it cannot fine the hg api, probably because it is running on 
the normal python install and the hg api is bound up in the turtle 
supplied one) and had to have someone set up a virtual linux box for me 
to run it on.

So there is a bit of a learning curve here.  Sigh.

At any rate, I am not sure it is a particularly trivial problem.  In 
general, any file with any extension can have any binary/text setting 
including both.

That is, a *.xxx can be text or binary depending on whatever tool is 
using.  Indeed, I don't see any reason that within a single repository a 
given *.xxx file could not be both, perhaps split up by directory (i.e. 
*.xxx is a binary file for one tool and a text file for a separate one).

So I am pretty sure that you would need to keep track of all the files 
you saw and their binary/text status, and then do some sort of analysis 
at the end to determine the optimal .hgeol file.

I am assuming of course that you don't want to simply list every file in 
the repo in the .hgeol file, but rather would like to make *.c=native, 
*.jpg=binary etc, and only use explicit references for oddball files (or 
those without extension like readme, or makefile).



So I think I will struggle along with my manual (well, shell script) 
approach.


I promise once I get this sorted (have a team waiting on it) I will 
spend a little time and try to at least get to where I can set a break 
point in some .py file in some debugger :)


Thanks for your help and
best regards,


Tom