cvs2hg emit .hgeol?

[Tom Udale]

Hi Martin,

Actually, there is some hoseage (if you will).  The CVS repo we had was 
running on linux.  Everything was checked out on Windows.  For whatever 
reason (my understanding is that the CVS internal eol format, at least 
on unix, is unix style) everything in the hg repo is unix style eol. 
Thus they currently get checked out on my Windows machine this way.

This is not actually a problem for most files because the editors and 
compilers can handle either style eol.  The most notable exceptions are 
notepad (the default windows editor) which is only a problem in the 
sense of "it would be nice to work", and the resource compiler, which is 
not optional.  It completely barfs on RC files with the wrong ending style.

Therefore without eol, we cannot compile at all.  Thus to go back to any 
point in history and actually compile, I have to check out and then to 
add the eol files hereby making a branch way way back.

This is the main reason I am trying to sort it all out.

It is complicated by the fact that this CVS repo was _huge_ and we are 
trying (perhaps foolishly) to break it up into several smaller 
sub-repos.  Thus the same thing needs to be done on something like ~10 
subrepos.


Actually, now that I think about it, there is something that I don't 
understand about your suggested solution.

I could, in principal, check out very early in the repo and run an eol 
search and replace on all the RC files, converting them from unix to dos 
style.  But when I commit them, that basically would just create a branch.

What I would want though is to have that change suddenly appear in the 
RC files going forward in the tree from that point.  Otherwise, if I 
checked out just one change set into the future, I would be right back 
where I was, right?

So I don't understand how to merge this change in such that it would 
appear in the files in the future, which I think is what you are 
suggesting is possible with this bit:

 > To me, that sounds like a rare problem. If you encounter it, then just
 > copy in a good .hgeol file and fix the offending files with a new
 > commit.

This would only fix the offending files at that point in time right, not 
into the future?


Best regards,

Tom




> Tom Udale<tom at ionoptix.com>  writes:
>
>> 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.
>
> Well, since the history is already written, you're not really "hosed".
> The only problem you could get, is if you update back to an old
> revision, add a file with the wrong newline format and then commit it.
>
> To me, that sounds like a rare problem. If you encounter it, then just
> copy in a good .hgeol file and fix the offending files with a new
> commit.
>
> There is more value in having a good .hgignore file in all changesets so
> that your build products wont show up in 'hg status' when you update
> back and build an old release.
>


-- 
Tom Udale
--------------------------
IonOptix LLC
309 Hillside St.
Milton, MA 02186
(617) 696-7335
--------------------------
tom at ionoptix.com