LS.,

with darcs 2.4.1 (installed via 'cabal install darcs'), on macosx  
10.5, with ghc 6.10.2, I get an inconsistent repo after:

darcs get --partial http://darcs.haskell.org/cabal/
cd cabal
darcs check

with output:

Replaying patch 468 done, 1165 queued. Sat Feb 12 20:40:12 CET 2005   
ijones@synt
Replaying patch 896 done, 737 queued. Wed Jan 10 15:27:56 CET 2007   
Ian Lynagh <
Replaying patch 1531 done, 102 queued. Mon Jan 26 02:09:18 CET 2009   
Duncan Cout
Looks like we have a difference...
Difference:  hunk ./tests/test-cabal-install-user 1
-#!/bin/sh
-
-darcs get --partial http://darcs.haskell.org/packages/Cabal/ && \
-cd Cabal/cabal-install && \
-make install-user && \
-cabal-install update && \
-cabal-install install --prefix=/tmp --user hnop && \

[deleted]

-darcs get --partial http://darcs.haskell.org/packages/Cabal/ && \
-cd Cabal/cabal-install && \
-make install-user && \
-cabal-install update && \
-cabal-install install --prefix=/tmp --user hnop && \
-ls -l /tmp/bin/hnop
rmfile ./tests/test-cabal-install-user
rmdir ./tests

Inconsistent repository!


With darcs 2.3.1 the problem does not occur.
With an other repo (cabal-install) the problem also does occur.

regards,

                 - Atze -

Atze Dijkstra, Department of Information and Computing Sciences. /|\
Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \
Tel.: +31-30-2534118/1454 | WWW  : http://www.cs.uu.nl/~atze . /--|  \
Fax : +31-30-2513971 .... | Email: atze@cs.uu.nl ............ /   |___\

Thanks for the report!

I have confirmed these symptoms on the Cabal repository on Linux, both
that it reports this error with darcs >= 2.4.1 (actually darcs HEAD -
noslurps), and that a repository fetched with darcs-2.3.1 checks fine
(under HEAD darcs).

More investigation needed.  Darcs hackers are trying to work out what
exactly has gone wrong.  Fingers crossed that it's actually a minor
error / false alarm.

Atze: it looks like a good workaround for now is to do darcs repair
followed by darcs check again.

Darcs Team: useful debugging technique might be to get an old fashioned
repo (check etc), and see if we can reproduce the same thing with just
local get.  Could be a lot faster and save some frustration.

I can confirm that get --partial makes all the difference (with the
wxhaskell repository)

Looks like we just need a minimal test case.

Atze, would you be able to help us out by sending a regression testing
script for this bug?  It's really easy.

See http://wiki.darcs.net/Development/RegressionTests

Don't worry if not; I just like to farm out as much of the work as I can
so that we can be efficient.

Meanwhile, I think Petr has an idea what's going on and will be fixing
this for 2.4.2 (for which thanks)

On  6 May, 2010, at 15:26 , Eric Kow wrote:

>
> Eric Kow <kowey@darcs.net> added the comment:
>
> Looks like we just need a minimal test case.
>
> Atze, would you be able to help us out by sending a regression testing
> script for this bug?  It's really easy.
>
> See http://wiki.darcs.net/Development/RegressionTests
>


I am not sure it will be a minimal test case, that is, the original  
problem occurred on the cabal package, which takes some time to  
download. I have tried to find a small package requiring less  
downloading times, but I cannot get darcs (2.4.1) to download them. E.g.

darcs get --partial http://code.haskell.org/hexpat-iteratee/

just stalls.

regards,

                - Atze -

Atze Dijkstra, Department of Information and Computing Sciences. /|\
Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \
Tel.: +31-30-2534118/1454 | WWW  : http://www.cs.uu.nl/~atze . /--|  \
Fax : +31-30-2513971 .... | Email: atze@cs.uu.nl ............ /   |___\

On Thu, May 06, 2010 at 14:50:29 +0000, Atze Dijkstra wrote:
> I am not sure it will be a minimal test case, that is, the original  
> problem occurred on the cabal package, which takes some time to  
> download. I have tried to find a small package requiring less  
> downloading times, but I cannot get darcs (2.4.1) to download them. E.g.

Right, so I was hoping that you would be able to reproduce this by
creating some sort of almost empty repo with darcs init --old-fashioned
and darcs get.  It'll be a help if you could.  Otherwise, we'll take
care of it.

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

Atze Dijkstra <atzedijkstra@gmail.com> writes:

>> Right, so I was hoping that you would be able to reproduce this by
>> creating some sort of almost empty repo with darcs init --old-
>> fashioned
>> and darcs get.  It'll be a help if you could.  Otherwise, we'll take
>> care of it.
>
> Currently the only way I know to reproduce the problem is to execute the
> commands in the bug report. I am aware it makes a bad regression  test, but I
> am afraid I'll have to leave it up to you to minimise the  example and search

I have managed to reproduce this locally, but it needs a repo tarball,
since darcs HEAD (or 2.4 for that matter) cannot create checkpoints.

The recipe:

mkdir R
cd R
darcs init --old-fashioned
echo a > a
darcs rec -lam "a"
darcs tag -m "bla"
darcs-2.3 optimize --checkpoint
cd ..
darcs get --partial R S
cd S
darcs check

... the obvious alternative is

tar xvzf darcs1-repo-with-checkpoint.tar.gz
darcs get --partial R S
cd S
darcs check

Yours,
   Petr.

PS: In other news, there's a patch pending (patch236) that fixes the
bug. But I'd still like to have a regression test for it. With above, it
should be quite easy to produce, too. Volunteers very welcome.

The following patch updated the status of issue1837 to be resolved:

* Resolve issue1837: Add readWorking and use it in pristineFromWorking. 
Ignore-this: 6feec15528cc3ad225160889a50d2328

The following patch updated the status of issue1837 to be resolved-in-stable:

* Resolve issue1837: Add readWorking and use it in pristineFromWorking. 
Ignore-this: 6feec15528cc3ad225160889a50d2328