unfortunately the repo contains sensitive data, so i can't send it.

i'm trying to convert a branched project to darcs2, but both branches 
evolved, so i need to create a repo with all the patches. this repo is 
such a try, although pulling all patches is exponential... but the point 
is that it has loads of conflicting patches, up to the limit still 
pullable in a darcs1 repo.

then i've converted that repo to darcs2. then i darcs get it to unpull 
patches to form the darcs2 repo of one of the branches.



alendvai@ed101:~/Desktop/conversion$ darcs --version                      
2.4 (release)
alendvai@ed101:~/Desktop/conversion$ darcs get merge.without-deadly-
conflicts.darcs2/ delme
Copying patches, to get lazy repository hit ctrl-C...
Finished getting.                                             
alendvai@ed101:~/Desktop/conversion$ cd delme/                
alendvai@ed101:~/Desktop/conversion/delme$ darcs check --complete
The repository is consistent!                                                   
alendvai@ed101:~/Desktop/conversion/delme$ darcs unpull                         
Wed Jan 13 11:22:37 CET 2010  levente.meszaros@gmail.com
  * Refactor www according to new structure.
Shall I unpull this patch? (1/86)  [ynWvplxdaqjk], or ? for help: a
Really unpull all undecided patches? y
Finished unpulling.
alendvai@ed101:~/Desktop/conversion/delme$ darcs check --complete
The repository is consistent!                                                   
Hash mismatch(es)!
notes
    index: 
c60e6dbbc670805cac905cbf336ba403cbf8399b5d57047e4acc61a77c0b47f6
  working: 
5fb6151cb223d4857a38635ed0bc369366bb07af0d99aaa595770f3c75aa39a0

Bad index.
alendvai@ed101:~/Desktop/conversion/delme$ darcs repair
The repository is already consistent, no changes made.                          
Hash mismatch(es)!
notes
    index: 
c60e6dbbc670805cac905cbf336ba403cbf8399b5d57047e4acc61a77c0b47f6
  working: 
5fb6151cb223d4857a38635ed0bc369366bb07af0d99aaa595770f3c75aa39a0

Bad index discarded.
alendvai@ed101:~/Desktop/conversion/delme$ darcs check --complete               
The repository is consistent!                                                   
alendvai@ed101:~/Desktop/conversion/delme$

I think we should aim for a 2.4.1 bugfix release if possible.

The good news is that we can reproduce it systematically
(so Attila, if you would be so kind as to tarball that somewhere you can
pull it up, and maybe even write yourself a shell script so we can check
back with you later, that'd be great).

The bad news is that we don't have a minimal test case.  We have a
semi-formal boil-down procedure for reducing complicated repositories
with bugs to minimal ones with the same bugs, but it takes a lot of
patience!

If you have the time to devote to this, Attila, it would be a help! 
http://wiki.darcs.net/Forensics
... but I'm not counting on it because it really is super-involved, and
you basically have to dedicate yourself to it for at least a few hours.

Meanwhile, we need to come up with some way of turning this into a test
case. :-(

err, hrm.

i see another one of this, but as far as i remember i have not unpulled 
anything from this repo. i did probably a few amend, though...

still on darcs 2.4

attaching a file that contains the "darcs changes -s" up to the point i 
have unpulled when the index corruption happened.

Attachments

• changes.txt

Bingo, reproduced. Luckily, this is a silly bug that's not related to 
either the darcs-2 format or conflicts. Still urgent and something to be 
fixed in 2.4.1, but not a mass-panic material.

20:40:09 | morn@twi:/tmp/x -> darcs init
20:40:12 | morn@twi:/tmp/x -> l
_darcs/
20:40:12 | morn@twi:/tmp/x -> mkdir a b
20:40:16 | morn@twi:/tmp/x -> echo x > a/x
20:40:21 | morn@twi:/tmp/x -> echo y > b/y
20:40:25 | morn@twi:/tmp/x -> darcs rec -lam initial
Finished recording patch 'initial'
20:40:28 | morn@twi:/tmp/x -> darcs wh
No changes!
20:40:30 | morn@twi:/tmp/x -> darcs check
The repository is consistent!
20:40:33 | morn@twi:/tmp/x -> darcs mv a/x b/
20:40:38 | morn@twi:/tmp/x -> darcs check    
The repository is consistent!
Hash mismatch(es)!
a
    index: 
4e36eace85956d1aeb6749c5e889a88697535133ef507be5365d2303ad7ae9f7
  working: 
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Bad index.

RAAH!! :-)

Please make a test case of that...

Hi Petr, I think this should get fixed for 2.4.1 if at all possible. 
Agreed?

(I'm just trying to sift through the remaining Target-2.4 bugs to give
Reinier a hand for 2.4.1)

(I still don't have a fix for this. I'll look into it.)

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

* Resolve issue1756: new h-s handles file removals correctly in Index. 
Ignore-this: bbedaa58cc6630492efed346332ee21d

I'd like to re-open this and recommend that we put together a regression
test based on msg10114

See also
http://lists.osuosl.org/pipermail/darcs-users/2010-March/023476.html

No cutting corners :-)

Doh, there was a test after all; I just got confused.  Also, Petr
reports that the email linked is unrelated.  OK let's resolve this again.

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

* resolve issue1756: bump hashed-storage dependency to 0.4.10 
Ignore-this: c59e8582416191a8d55b72ae511f70b3

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

* resolve issue1756: bump hashed-storage dependency to 0.4.10 
Ignore-this: c59e8582416191a8d55b72ae511f70b3

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

* Resolve issue1756: new h-s handles file removals correctly in Index. 
Ignore-this: bbedaa58cc6630492efed346332ee21d