[darcs-users] bug reports for darcs diff

[David Roundy]

Hello.

On Thu, Sep 25, 2003 at 09:26:37PM +0300, Aggelos Economopoulos wrote:
> here are some questions and a few bug reports that were delayed during
> the exams period.
> 
> i) 'darcs diff' produces bogus trailing output. Note that I haven't been
> able to reproduce for trivial repositories so I can't provide a simple
> test case.  Some sample output that demonstrates the problem is attached
> in "bogus_diff".
> 
> ii) darcs passes absolute path names to the diff program, producing very
> long diff header lines; see "bogus_diff". Running it with relative paths
> and _darcs as the current directory would produce much more readable
> output, without revealing the absolute pathname of the repository and
> would probably be more friendly to anyone who tries to apply the patch.

The fix for the first two was the same!  :) The bogus output was caused by
the temporary file used to hold the output of diff, so when I set the
current directory to _darcs, everything is fine.

> iii) Is darcs diff -m 'whatever' supposed to produce a diff to the 'current' 
> tree? Please let me know, so I can submit a documentation patch to 
> DiffCommand.lhs.

Yes.

> iv) from FastPackedString: is map_denywrite honored in OS X? Linux and
> FreeBSD have ignored it for years.

I see.  I imagine it is ignored everywhere.  I saw it on some man page
somewhere and decided to use it.  I've removed it, since I'm not aware of a
system where it works.  The OS X man page doesn't mention it.

> (I assume there isn't an easy way of using the defines in the system
> header files for the constants?)

Actually it's not hard, now that I have a C file for FastPackedString
support functions.  I've coded it up right now (and probably broken win32
compile again).  In the process I noticed why I was getting bus errors, so
now mmap should work considerably better.

I'm still not sure it gives any noticable improvement.  It probably would
be most helpful when reading in the patch files because they can be pretty
large and get held in memory for quite a while, but because they are large
I support compressing them, and haven't implemented code to check if they
are compressed and mmap them if they haven't been compressed.

Thanks for the reports!
-- 
David Roundy
http://www.abridgegame.org