cvs2hg emit .hgeol?

[Tom Udale]

Hi again Martin,

I have been looking at the July 13 eol.py trying to understand the 
behavior I described in my previous email (also below).  I just don't 
get how it all works.

I see the

self._eolfile = self.loadeol([None, 'tip'])

called in _hgcleardirstate at the end of reposetup.

That looks to me what would result in a default .hgeol pulled from the 
tip and would explain why I am seeing the most recent .hgeol when I 
update, regardless of the cset I update to.

What does not make sense is that it looks as if that .hgeol gets 
overridden in the preupdate hook via repo.loadeol to be the .hgeol of 
the parent of the current changeset.  That _is_ consistent with what I 
see when doing a hg status, but it is unclear to me how preupdate would 
be associated with hg status but not with hg update.

So basically I just don't get it.

I think that what I would try to do to fix what I am seeing is to load 
an empty .hgeol in _hgcleardirstate (to handle cases where you are 
working before the .hgeol file was added) and then override it for 
status, commit, update, etc by calling repo.loadeol with the appropriate 
parent changeset in a sensible hook function.

But there are many things to learn before I could do that.  I don't see 
how hooks are called in general (searches of the codebase for preupdate 
do not seem to point to either a call site in the hg framework or to a 
redirection to some function that is called).  I also don't understand 
enough about the hg structure to be able to map hooks and callbacks to 
top level hg commands.  Cxts seem important, but plausibly too low level.

Lastly, it looks to me as if there is code in there to detect when an 
.hgeol file has changed (the stuff around line 307 in _hgcleardirstate), 
but I don't get how that is subsequently used and if or if not it could 
be used to prevent having to update through null to get the correct eols.


Any pointers as I am poking along at it would be most appreciated.


Best regards,

Tom




> With that out of the way, let me get on to the unexpected behavior of
>  eol. The biggest confusion I was having was that then I updated to a
>  time before the .hgeol file existed in my repo, I was not seeing
> 100% unix files as I expected. This is what made me think my CVS repo
> was screwed up (or there was a bug in cvs2hg).
>
> It turns out that if I do a clean conversion of my CVS repo using
> cvs2hg with no .hgeol file at all, I get the expected 100% unix line
> endings.
>
> The cause of this confusion is that it appears that eol _always_ uses
>  the most recent .hgeol file to update. Thus if you start with a 100%
>  unix working directory and add an .hgeol file to it that converts
> everything to DOS, if you check out any revision before the one that
>  adds the .hgeol file, you still get the DOS versions.
>
> It is actually more confusing that that however. It appears that when
>  testing for dirty files in the working directory, eol uses the
> "correct" .hgeol file, if one exists.
>
> Here is an example: you start with a repo at cset 0 with no .hgeol,
> working directory is in state 0.
>
> Now you add a .hgeol, creating cset 1 with working directory state
> 1.
>
> Now you edit the .hgeol, adding new conversions, hereby creating cset
> 2 and working directory state 2.
>
> Now hg update null; hg update 0 (not going through null is even more
>  confused but I think "by design").
>
> You would expect that you would be at working directory state 0. You
> are not. You are at state 2. If you do a hg status (well, tortiosehg
>  refresh), you will find there is nothing to commit.
>
> If you now hg update null update 1, you are still at working
> directory state 2. However, if you hg status, you get as modified all
> the files added to .hgeol in cset 2. This implies that the status is
> working against the .hgeol in cset 1 (as expected).
>
> Let me say that again. It checks out using the cset2 .hgeol settings,
>  but statuses those files against the repo using the cset1 .hgeol
> settings.
>
> My interpretation of what happens at cset0 is that when it goes to
> status, it cannot find a .hgeol at cset0 and simply uses the cset2
> version - and then diffs to an empty set against the working
> directory which was also checked out with the cset2 .hgeol file.
>
> And then there is the extra complication of what happens when you
> don't hg update null when crossing csets that changed .hgeol. In my
> observation, it appears that going backwards, only the .hgeol file is
>  changed and no changes occur to the working directory. However it
> does appear that when going forward, files in the working directory
> do get updated.
>
> Now, I am doing all this via tortiosehg, so it is possible that it is
>  the source of the confusion here rather than the eol extension.
>
> For me, once I get my .hgeol files in from the very beginning, this
> will not be a problem. But it does seem like a problem for the
> utility in general. Because it appears that even if you always update
> via null, you still get odd behavior.
>
> I am trying to figure out how eol works to see if maybe I can find
> where this is happening. I have not managed yet.
>
>
>
> Best regards,
>
> Tom
>