|Do you get this using darcs 2? We would appreciate a bug report!
Well, okay, I'd like to switch to darcs 2 (forgot that Simon had
already convinced me earlier..). But according to darcs.net:
- the latest stable release is 2.0.2
- the latest windows binary bundles are 2.0.0
- there is a binary-only add-on from Simon (2.0.1rc2), with
comment that one needs to use a different wrapper to use
cygwin's ssh (which I'd prefer)
So, as far as I can tell, windows releases are all in pieces, none
up to date, and it isn't immediately clear how to get there, either.
Building from the latest stable source, presumably, but obviously
that is neither trivial (is there even one right way to build? what
about those bytestring fixes in Simon's executable? what about those
discussions on the darcs lists about neither 6.8.2 nor 6.8.3 being
quite the right compiler to build darcs? what about other little
things, like mmap apparently affecting darcs functionality on
windows, #443/#320, but it only being disabled in unstable?
are there other issues I should avoid when building darcs stable
on windows?), or there would be an updated binary bundle already.
I'd like to be able to take stable sources and just build them,
with the default configuration doing the right thing for windows,
and warning me if I use a compiler version that is know to create
darcs bugs (well, actually, I'd like an uptodate binary bundle;-).
$ grep ^Warning mystuff/darcs-all.log
Warning: ./packages-0: renameFile: permission denied (Permission denied)
How can that be a "warning" when it leads to the repo ending
up in a state it shouldn't be in?
|We would need to be able to reproduce this to give you a definitive
|answer. My guess is that the permission denied error is due to a darcs
|bug under Windows, while emitting a warning and moving on is a feature.
You will generally find it difficult to reproduce darcs bugs on
ghc repos - most people don't build ghc for fun, but because
they need a working ghc head for something entirely different.
If they have to build ghc from source, they are already far from
where they want to be.
So if anything goes wrong even further down the tool chain, the
order of the day is to get rid of the issue by all means, not to
reproduce it (at least for me, but you seem to have the same
problem with other ghc repo reports).
If darcs developers are serious about addressing those issues,
there's no way around them having their own ghc head repo,
pulling perhaps weekly to see what goes wrong, and reproducing
any incoming bugs by synching their repo to the reporter's (at
least, you don't have to build ghc, just pull it, and imagine that
you have your own important source changes in working).
|Particularly, darcs will exit if it has trouble applying the patch to
|its internal pristine cache... but if it is having trouble applying a
|patch to the working directory, it tries to do the most robust thing by
|emitting a warning and moving on.
Having skimmed over the ticket relating to "moving on", that
seems to have been a shortcut/workaround, rather than a feature
(#434, where the suggested fix was to make darcs actions atomic:
either they succeed or not, but nothing in between).
In particular, darcs should be able to recognize that it has taken
that shortcut, which means recording a flag "pristine and working
out of sync because <warnings here>", and repeating the warnings
for every darcs command until the user addresses the issues and
resets the flag. Currently, darcs doesn't distinguish between its
own messing up and the user editing working, which isn't good,
especially if there are real unrecorded user changes in working.
|Darcs 2 fixes the small things above regardless of the repository format
|you use.
That is good to know, thanks. So I really need a darcs 2 for windows.
And thanks for keeping darcs afloat,
Claus
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
