Hi, Very nice timing, since we're pushing for 2.0.3
On Sun, Sep 07, 2008 at 10:56:24 +0200, Petr Rockai wrote: > 1) pull.sh, apparently due to a path handling issue > > darcs failed: Not a repository: /cygdrive/c/Documents and > Settings/buildslave/windows-darcs2/zooko allmydata > virtual2/build/tests-shell-old-fashioned.dir/temp1 (/cygdrive/c/Documents and > Settings/buildslave/windows-darcs2/zooko allmydata > virtual2/build/tests-shell-old-fashioned.dir/temp1/_darcs/inventory: > openBinaryFile: does not exist (No such file or directory)) > > 2) mv-formerly-pl.sh, again, with what seems a path handling problem to me: > > darcs mv "$REPO_ABS/abs_path.t" abs_path_new.t > Ignoring non-repository paths: /cygdrive/c/Documents and > Settings/buildslave/windows-darcs2/zooko allmydata > virtual2/build/tests-shell-old-fashioned.dir/temp/abs_path.t > darcs.exe: Cannot rename a file or directory onto itself! I think the first two are problems with the test suite. Darcs is a native Windows program and does not use the Cygwin library. Therefore, it does not understand the absolute paths that Cygwin tries to feed it, i.e. those that start with /cygdrive/c There is this cygpath program that converts paths like that into Windows ones. Maybe we could work out a way for the test scripts to use it. I've filed http://bugs.darcs.net/issue1063 > 3) amend-cancelling.sh failing like this: > > darcs.exe: setCooked: failed (failed to set buffering) That's interesting. I've filed http://bugs.darcs.net/issue1062 so we don't lose track of this > Obviously, it didn't get around to run the tests on hashed repos, but these > three don't look *too* bad to me -- apparently at least fixable. Although it > might make sense to revisit Eric's (and mine, sort of) proposal to try using > System.FilePath in darcs. In the above two cases, I don't think I see how System.FilePath would have helped. That said, maybe Neil would be interested in something like System.FilePath.Cygwin, a sort of weird fusion of the two pre-existing modules with the /cygdrive/c stuff on top. Or maybe we would work out some means for darcs to optionally become a Cygwin program [Note that this would also involve stretching out our manpower a bit]. This could be an interesting research task for any Windows based Haskellers. What is the best way to deal with Cygwin? Finally, quoting Juliusz on darcs Cygwin support <http://bugs.darcs.net/issue29>. On 2006-07-13, Juliusz Chroboczek said: > Taking the risk of reopening a long-dormant flamewar, I'm marking this > bug as wont-fix. > > Writing software for Unix is difficult. Writing software for Windows is > difficult. Writing software that's portable between Windows and Unix > even more so. > > Writing software that works on a nondeterministic Windows/Unix hybrid > such as Cygwin is beyond what we can afford. Thus, I would argue that > unless somebody volunteers for maintaining Darcs on Cygwin, we should > make no concessions for Cygwin users. > > Please reopen this bug if you disagree and are willing to do the work > and willing to make sure it doesn't break in the foreseeable future. This was in 2006, so maybe you can argue that our circumstances may have changed. But he does make some interesting points. Summing up: * short term: issue1063, testsuite/cygpath problem, needs workaround * short term: issue1062, possible bug, worth looking into * long term: what the heck should we do about Cygwin? Thanks! P.S. There are some test cases floating around, which we have "fixed" by disabling them on Cygwin. I don't think this is the best solution, and that by darcs 2.2 we should audit these and get them working the right way. -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9
pgpDhFPmbtRZM.pgp
Description: PGP signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
