[darcs-users] [issue1067] darcs 2.0.2 (+ 76 patches) fails where darcs 1.0.9(release) succeeds (windows, ghc repo, get)

Claus Reinke claus.reinke at talk21.com
Tue Sep 9 23:24:14 UTC 2008


> > 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.
> 
> Please have a look at http://bugs.darcs.net/issue230 for background
> to this decision.
> 
> (1) files which are introduced by third party tools are ignored
>     because they do not appear in the index
> (2) modifications to pristine files can be detected through hash failure 

Neither of these depend on changing the file names, just on a 
second index to check against for presence and contents.

> (3) relying on darcs-internal filenames avoids the case
> sensitivity issue as well as http://bugs.darcs.net/issue53

This is the only reason where encoding the file names could make a
difference. But pristine is only a copy of a version of working, so you
don't avoid the trouble at all. Unless you adopt a system that applies
the same (and user-readable) renaming to working and pristine, warning
about non-portable naming sounds like the best option (actually, I'd
like that to be on by default - better safe than sorry and all that).

> In the meantime, there are various ways to retrieve the pristine version
> of a file, either by use of darcs diff (--diff-command "cat %1") or via
> the 'show contents' commands.

Yes, it would simply be a question of concrete vs abstract interface,
but for: (a) the encoding of file names addresses none of the issues
you listed and (b) being able to bypass darcs improves the chances
of survival when darcs screws up, thereby improving confidence (that
applies for all darcs ops, eg, some issues would be devastating if one
couldn't bypass darcs and remove bogus pending files, left-over locks,
etc.).

> > 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.
> 
> You may be interested in http://bugs.darcs.net/issue973
> 
> On non-Windows machine, Petr Rockai have identified the slowness as
> being due to a library bug in GHC 6.8.2 (since fixed in 6.8.3).  The
> workaround is to compile darcs with GHC 6.8.3.  That said, these
> findings apparantly do not translate to Windows.  If we had more
> Windows-based developers, it would be useful to to have one of them
> investigate the cause of this.

$ darcs +RTS --info
 [("GHC RTS", "Yes")
 ,("GHC version", "6.8.3")
 ,("RTS way", "rts_thr")
 ,("Host platform", "i386-unknown-mingw32")
 ,("Build platform", "i386-unknown-mingw32")
 ,("Target platform", "i386-unknown-mingw32")
 ,("Compiler unregisterised", "NO")
 ,("Tables next to code", "YES")
 ]

My first bet would be memory usage. I have only 1Gb, so once there
are 1.5Gb in use, someone is going to suffer.

Claus




More information about the darcs-users mailing list