eol with hg 1.4.x?

[Martin Geisler]

Mark Hammond <mhammond at skippinet.com.au> writes:

> On 7/01/2010 12:04 AM, Martin Geisler wrote:
>
>> But please look at the tests. That is really where the best
>> specification is right now.
>
> Without trying to be pedantic, I expect the tests do indeed cover most
> of the desired functionality, which we seem to agree is in roughly the
> right place. What the tests obviously do *not* capture are places
> where things don't work quite correctly in practice - as you yourself
> found in the followups.

Yeah, that is strange. I just tried inserting some sleep calls into
test-eol-add to see if the problem is that I am slower than the script
when I execute the commands myself. That didn't make the script fail.

Can anybody else reproduce the problem? Take test-eol-add and execute
the commands one by one in a terminal where you set $1=CRLF (on Unix) in
the dotest function:

  http://bitbucket.org/mg/hg-eol/src/tip/tests/test-eol-add

I then end up with

  % hg tip -p
  ændring:     1:749181de51ea
  mærkat:      tip
  bruger:      Martin Geisler <mg at lazybytes.net>
  dato:        Thu Jan 01 00:03:20 1970 +0000
  uddrag:      Added .hgeol file

  diff --git a/.hgeol b/.hgeol
  new file mode 100644
  --- /dev/null
  +++ b/.hgeol
  @@ -0,0 +1,5 @@
  +[patterns]
  +**.txt = native
  +
  +[repository]
  +native = CRLF

which is wrong since the preceding 'hg status' showed that a.txt would
be recoded from LF to CRLF. Notice how the test gives different output:

  http://bitbucket.org/mg/hg-eol/changeset/21e1cf9860a8/#chg-tests/test-eol-add.out_newline60

> It is for this reason I was suggesting that nominating a date for
> conversion is premature.

Yeah, I think we should wait until some more people report back that the
extension works for them.

>> Clone the repository and run
>>
>>    make test-eol-clone TESTFLAGS=--debug
>>
>> to see how a session looks like. Similarly for the other tests:
>>
>>    http://bitbucket.org/mg/hg-eol/src/tip/tests/
>
> The tests don't seem to run on Windows with my tools. I've cygwin, so
> which hg' results in cygwin style paths being specified to Python,
> which doesn't understand such paths.
>
> eg:
>
> % make test-eol-clone TESTFLAGS=--debug
> cd tests && python run-tests.py --with-hg=`which hg` --debug test-eol-clone
> Usage: run-tests.py [options] [tests]
>
> run-tests.py: error: --with-hg must specify an executable hg script
> make: *** [test-eol-clone] Error 2
>
> % which hg
> /cygdrive/o/utils/mercurial/hg
>
> I suspect that Python attempts to check the validity of
> /cygdrive/o/utils/mercurial/hg', which it fails to do.  Or maybe it is
> upset the hg it found isn't a source version?

Hmm, strange... The run-tests.py script simply requires an executable.

> Either way, trying to move around this I tried executing the
> command-line manually.  Now the output I see is:
>
> Skipped test-eol-clone: shell script
> # Ran 1 tests, 1 skipped, 0 failed.

I just looked in run-tests.py and I can see that it will only execute
.py and .bat files when os.name == 'nt'. So that suggests that we can
write some .bat files to test eol. I think those should run outside of
Cygwin -- run-tests.py will invoke them as "cmd /c call test-foo".

> FWIW, I've similar problems with the rest of the hg tests - when I
> submitted a patch to win32text a year or so ago, I was forced to boot
> up a linux box just for the purpose of adjusting and running tests.

Yeah, the test suite is very Unix-centric. Patrick is running part of it
on Windows,but I don't know the details. The wiki has some information:

  http://mercurial.selenic.com/wiki/WindowsTestingPlan

>> I feel you should be motivated by your *need* for this feature. If
>> you or anybody else want it, then join in and help us make it work.
>> Again and again I feel like I'm trying to develop a feature that
>> people say is important, but nobody is really that much interested
>> anyway.
>
> It is just another chicken-and-egg problem.  Trying to use this
> extension is fairly intrusive in normal work-flows.  I need to make
> new clones of repositories and work inside them.  If I find a problem
> and decide to get some work done without the extension, I'm forced to
> abandon the entire clone, and manually move the work I had done back
> to another copy.  Combine this with the difficulties in testing on
> Windows and the fact noone truly *needs* this anyway (in the same way
> you don't *need* to have your local files in \n format), the barriers
> to providing useful contributions are fairly high.

I hadn't thought of the problem with running the tests on Windows, but I
now see why it's even more work to try it out.

However, simple manual testing in a scratch repository would also be
helpful. Such testing would help us build confidence that the extension
gets the simple things right. When you (or someone else) can no longer
break it by hand, then perhaps you'll want to try it for real on a
bigger repository.

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.