cvs2hg emit .hgeol?

[Tom Udale]

Hi Martin,


> Okay, I see. I naively assumed that your existing files in CVS had the
> right newline formats :-)

Well, you could be forgiven.  Indeed, I am having trouble understanding 
how things have gotten so inconsistent.  We are a 100% Windows shop on 
the dev side.  The only linux machine in the whole building was the CVS 
server.  So I have a difficult time reconstructing how we would have 
gotten inconsistent line endings on the client side to begin with, let 
alone into the CVS server.

Indeed, I think it should be impossible because of the design of CVS. My 
understanding is that the canonical CVS repository style is Unix (so 
claim the cvs2svn docs at least).  There is no option in our CVS client 
to muck with that.  A file is either binary or text.  So I would think 
therefore that the CVS client, based on the host OS, simply translates 
everything it sees from the repository Unix EOL into the host EOL and 
similarly in the reverse direction.

Considering the local machine->repository direction and taking into 
account feeding the CVS client "unexpected" endings I still cannot think 
of any approach that would not result in a file ending up with unix EOL 
in the repository.

If the client is well coded, it would consider all possible endings and 
correctly convert them to the repo style.

If it was _not_ well coded and simply assumed that every line ending was 
CRLF on a Win host, I think the repository should _still_ end up all 
unix.  A file with 100% unix endings would pass untouched.  One with 
mixed unix and dos endings would still get the dos bits translated and 
end up unix.

So I have a difficult time seeing how the CVS repo could be anything but 
unix (ignoring the old mac LF possibility).  And I would assume 
therefore that cvs2hg would simply translate that directly into a 100% 
unix style hg repo.

So my expectation was that when I checked out everything with no .hgeol 
file, everything would be unix.

But it is not.  Indeed most of the files came across in DOS style.

If I add the .hgeol and start my **.c = native, etc patterns, the files 
that were in unix usually change as expected.

But I just did one of my subrepos and there are some files that 
stubbornly refuse to get their correct eols even though they are in the 
patterns (thankfully it does not matter in this case and is simply 
academic).

So I am a little baffled.  Am I confused about how CVS works?  Am I 
confused about cvs2hg or the eol extension?  Is there a bug somewhere?






> I'm glad to see you've found a way to inject a .hgeol file in the 0th
> revision with the --existing-hgrepos flag for cvs2hg. That sounds like a
> good way to achieve what you want.

So far it seems like a pretty clean way to meet the ends.




All the best,

Tom