I just tried to use 'darcs get' to make a local copy of the
ghc repo and was surprised to see it fail, as I was sure that
this used to work (on windows locally only, of course). And 
indeed:

$ export PATH=`echo $PATH | sed 's/d\/darcs/d\/darcs1/'`

$ darcs --version
1.0.9 (release)

$ darcs get c:/fptools/ghc
Copying patch 19412 of 19412... done.
Finished getting.

$ mv ghc/ ghc1

$ ls
ghc1/

$ export PATH=`echo $PATH | sed 's/d\/darcs1/d\/darcs/'`

$ darcs --version
2.0.2 (+ 76 patches)

$ darcs get c:/fptools/ghc
Unapplicable patch:
Thu Jan 11 14:26:13 GMT Standard Time 1996  partain
  * [project @ 1996-01-11 14:06:51 by partain]

darcs failed:  File './ghc/includes/RtsTypes.lh' already exists!

$ uname -a
CYGWIN_NT-5.1 cr3-lt 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin

There doesn't seem to be a 'darcs info' to get format information
on a repo, but I haven't changed the default format, if that helps.

I haven't timed it, but darcs2 also seems slower and proceeding
in short sprints while darcs1 seems to make continuous progress.

On the way, I also noticed that 'darcs2 check' fails with the
same message, but that has already been reported, it seems
(http://bugs.darcs.net/issue971). That also happens with darcs1,
surprisingly (I seem to recall running 'darcs1 check' on a full
ghc repo in the past; but now, I get the same unapplicable patch).

Claus

Hi,

On Mon, Sep 08, 2008 at 23:35:17 -0000, Claus Reinke wrote:
> $ darcs get c:/fptools/ghc
> Unapplicable patch:
> Thu Jan 11 14:26:13 GMT Standard Time 1996  partain
>   * [project @ 1996-01-11 14:06:51 by partain]

I think you will have better luck with darcs get --hashed, which has
better handling of case insensitive file systems.  We'll need to work
out later why darcs 1 succeeds in this case.

> There doesn't seem to be a 'darcs info' to get format information
> on a repo, but I haven't changed the default format, if that helps.

darcs show repo

> On the way, I also noticed that 'darcs2 check' fails with the
> same message, but that has already been reported, it seems
> (http://bugs.darcs.net/issue971). That also happens with darcs1,
> surprisingly (I seem to recall running 'darcs1 check' on a full
> ghc repo in the past; but now, I get the same unapplicable patch).

Yes.  Petr's latest patches make darcs repair work, but will need to be
refactored to extend the new coverage to darcs check

Thanks!

|I think you will have better luck with darcs get --hashed, which has
|better handling of case insensitive file systems.  

You mean because it encrypts file names in pristine? I never
liked that idea, I must say - if the hashes are useful, why not
store them out of the way? Having a real pristine copy of the
repo in place was a big point in favour of darcs1: (a) it is unlikely
that it would screw up both copies at once, (b) it allows for easy
scripting and tool access bypassing darcs.

Anyway, I thought I'd give it a try but, geez, that is slow! 20
minutes wall clock time before it even starts "writing inventory"?
Hogging all my memory and then some? No thanks. I'm not sure 
I'm going to wait around to see it finish.

> There doesn't seem to be a 'darcs info' to get format information
> on a repo, but I haven't changed the default format, if that helps.

|darcs show repo

Since darcs1 worked on it, the answer was probably obvious
anyway, but

$ darcs show repo --repodir=ghc
          Type: darcs
        Format: darcs-1.0
          Root: c:/fptools/ghc
      Pristine: PlainPristine "_darcs/pristine"
         Cache: thisrepo:c:/fptools/ghc
boringfile Pref: .darcs-boring
        Author: claus.reinke
Default Remote: http://darcs.haskell.org/ghc
   Num Patches: 19412

Claus

Summarising:
1. darcs get fails because of case insensitivity on an old fashioned repository
2. getting a hashed copy of this works fine [I've tried]
3. surprisingly, darcs 1.0.9 succeeds in this case

Since hashed repositories work, I don't think it would be a good investment of
our time trying to make the old-fashioned repositories work better.  

On the other hand, I do need a volunteer to investigate the following:  Why does
darcs 1.0.9 succeed here and 2.x fail?  One path could be that 1.0.9 applies
from the checkpoint and 2.x (presumably) tries to apply all patches.  Why does
it do this?  Once we know the answer to this, I think we can close the bug.

Interestingly, getting from hashed copy of the GHC repository is much faster
because it allows for lazy fetching of patches (this is like partial
repositories but a good deal more robust), and also lets you take advantage of
the global cache.  

There should perhaps be a hashed mirror of the GHC repository on
darcs.haskell.org.  Things can be set up so that the hashed and old-fashioned
repositories push to each other.

[1] http://darcs.net/manual/node6.html#SECTION00640000000000000000
[2] http://wiki.darcs.net/index.html/DarcsTwo

Eric Kow wrote:
> Eric Kow <kowey@darcs.net> added the comment:
> 
> Hi,
> 
> On Mon, Sep 08, 2008 at 23:35:17 -0000, Claus Reinke wrote:
>> $ darcs get c:/fptools/ghc
>> Unapplicable patch:
>> Thu Jan 11 14:26:13 GMT Standard Time 1996  partain
>>   * [project @ 1996-01-11 14:06:51 by partain]
> 
> I think you will have better luck with darcs get --hashed, which has
> better handling of case insensitive file systems.  We'll need to work
> out later why darcs 1 succeeds in this case.

For some reason darcs2 wants to apply all the patches to reconstruct the 
working copy when doing a local get of a darcs1 repo, whereas darcs1 took a 
shortcut and copied the pristine (I'm guessing).

This is why darcs2 get doesn't work even for local GHC repos on Windows, 
whereas darcs1 used to.

Cheers,
	Simon

So I believe this is a duplicate of http://bugs.darcs.net/issue971 .