darcs: bug in darcs!
fromJust errorsrc/Darcs/Commands/Send.lhs:187 compiled Feb 14 2008 16:39:37 at
src/Darcs/Commands/Send.lhs:187 compiled Feb 14 2008 16:39:37
You can check to see if this bug is already known at http://bugs.darcs.net/
If it is not, please report this to bugs@darcs.net
If possible include the output of 'darcs --exact-version'.

-------

darcs compiled on Feb 14 2008, at 16:40:08
# configured Thu Feb 14 16:37:26 GMT 2008
./configure /usr/local/share/config.site /usr/local/etc/config.site

Context:

[Delegate building to makefile (cabal).
Eric Kow <E.Y.Kow@brighton.ac.uk>**20080214160146] 

[Bump version number in Cabal file.
Eric Kow <E.Y.Kow@brighton.ac.uk>**20080214155247] 

[Add Cabal files (not feature complete).
Eric Kow <eric.kow@loria.fr>**20070407104406
 
 This gives you a not-quite-complete Cabalisation of darcs.  It does not
 replace the makefile (yet).  Indeed, with this patch alone, you should
 still consider the makefile as the prefered compilation method.  At present,
 using the Cabal method means:
 
  autoconf
  runhaskell Setup.lhs configure
  make src/Context.hs
  runhaskell Setup.lhs build
 
 It would be good if somebody worked out a way to get rid of the make src/Context.hs
 step.  Note also that this version of the cabal file does not support git or
 wxdarcs.
 
] 

[Add a 'show authors' command.
Eric Kow <E.Y.Kow@brighton.ac.uk>**20080214100825] 

[Fix c2w import in FastPackedString.
Eric Kow <E.Y.Kow@brighton.ac.uk>**20080213181316] 

[add has_n_newlines (untested!) for ByteString.
David Roundy <droundy@darcs.net>**20080212220213] 

[make debug message more specific.
David Roundy <droundy@darcs.net>**20080212212234] 

[don't bother packing patch bundle into an email on darcs push.
David Roundy <droundy@darcs.net>**20080212212115
 This is a workaround for an unknown parsing bug affecting email-formatted
 darcs patch bundles.  :(
] 

[define catLinesPS and uncatLinesPS when ByteString is present.
David Roundy <droundy@darcs.net>**20080212195025] 

[add new "chunk" patch format (currently only used in darcs-2 repositories).
David Roundy <droundy@darcs.net>**20080212194456] 

[make ColourPrinter able to deal nicely with userchunks that contain newlines.
David Roundy <droundy@darcs.net>**20080212192220] 

[fix miscounting of changes in interactive prompting.
David Roundy <droundy@darcs.net>**20080212190602]

I think the send bug was caused by a bad patch (attached), which has a rmfile
but no actual content removal.

I'm not sure how I managed to produce this patch.  I think it involved some
combination of amend-record, record, and unrecord.

For what it's worth, the file "removal" was just me trying to change this file
=====8<================== [old]
#!/usr/bin/env runhaskell

> import Distribution.Simple
> main = defaultMainWithHooks defaultUserHooks
=========================

Into this one
=====8<================== [new]
#!/usr/bin/env runhaskell

> import Distribution.Make
> main = defaultMain
==========================

I think the sequence was something like (1) change the contents (2) record (3)
decide I actually didn't need the file (4) amend-record (5) decide I did indeed
need it [with the new content] (6) rewrite the file (7) amend-record. 
Unfortunately, it's not very clear in my head how this happened.

It would be good if we could work out how to make a test case out of this.

Attachments

• weird-rmfile-patch

Merging in issue815.  Please view issue815 to see more details about this issue.

Okay, here is something that I don't understand.  If I do a "darcs get
--old-fashioned-inventory", I end up with a repository that has *four* patches
in _darcs/patches that touch misc/hatch-eggs.py.  Their names are:

0000000142-8a9a56b2d267a619e1931053128a1edc6db2da2fd9545ef33dfa789ce71c261e
20080423204156-92b7f-5394de71307adec2c71c22deada9d78e4f9130e3.gz
20080114235354-80e44-815e1b522e531af40ca35c0ad2f4ff51b923c1b3.gz
5caf603466d9e3295af3886398f589b38e8ebec0

The first two have nearly identical contents except that the second one (the one
that ends with .gz) has a trailing carriage return character, i.e. the last few
bytes of the first one are "67 67 73 2e 70 79" in hex a.k.a. "ggs.py" and the
last few bytes of the second one are "67 67 73 2e 70 79 0a" a.k.a. "ggs.py\n"
and they are otherwise identical.  Similarly, the only difference between the
3rd and the 4th patch is that the 3rd has a trailing \n.  Is this normal?

Okay, I removed the two that have names that don't start with "2008", and "darcs
check" still passes.

So I guess one question is why did "darcs get --old-fashioned-inventory" copy
those two patches into my _darcs/patches dir.

Okay, per Lele Gaifax's suggestion, I converted my repository to old-fashioned
format, removed the two weird patches as mentioned earlier, edited the incorrect
patch by inserting a hunk which removed all the lines, and verified that the
resulting repository is now fixed.

Now I am trying to convert from this old-fashioned repository format to
hashed-format and seeing if my fixed-by-hand patch will be treated as "the same
patch" by darcs as the incorrect patches which exist in dozens of hashed-format
repositories in my project now...

Okay, I installed my fixed-by-hand patch into our web site and now the source
code browser works again!  So this at least demonstrates that the suggested
"repair" in http://bugs.darcs.net/msg4359 can work! :-)

Oh!  I see that David already committed patches to darcs to detect and repair
this sort of corruption:

http://allmydata.org/trac/darcs-2/changeset/5585
http://allmydata.org/trac/darcs-2/changeset/5588
http://allmydata.org/trac/darcs-2/changeset/5589

If I had noticed those improvements I would have tried them instead of repairing
the patch by hand yesterday.

I will try those patches out on my repo at some point...

Thanks, David!

Hm.  I tried it, and while it detected the problem, it did not correct the
problem on "darcs repair".  I guess [5589] is not used in "darcs repair" yet, or
else it does not work, or else I misunderstand something:

http://allmydata.org/trac/darcs-2/changeset/5589

HACK wonwin-mcbrootles-computer:~/playground/allmydata/tahoe/trunk$ darcs --version
2.0.0 (+ 121 patches)
HACK wonwin-mcbrootles-computer:~/playground/allmydata/tahoe/trunk$ darcs check
WARNING: Cannot remove non-empty file ./src/allmydata/Crypto/PublicKey/__init__.py
WARNING: Cannot remove non-empty file ./misc/hatch-eggs.py
The repository is consistent!
HACK wonwin-mcbrootles-computer:~/playground/allmydata/tahoe/trunk$ time darcs
repair
WARNING: Cannot remove non-empty file ./src/allmydata/Crypto/PublicKey/__init__.py
WARNING: Cannot remove non-empty file ./misc/hatch-eggs.py
The repository is already consistent, no changes made.

real    0m12.670s
user    0m6.993s
sys     0m4.038s
HACK wonwin-mcbrootles-computer:~/playground/allmydata/tahoe/trunk$ darcs check
WARNING: Cannot remove non-empty file ./src/allmydata/Crypto/PublicKey/__init__.py
WARNING: Cannot remove non-empty file ./misc/hatch-eggs.py                   
The repository is consistent!                                                



It would be good to have a unit test that exercises this code to repair broken
primitive patches...

The code to deal with broken patches hasn't been finished yet.  Or rather, I
just finished it, and was about to test it when I saw your comments here.

I've tested the patch on my repository and it fixes the problem!  Way to go! 
Thank you!

I would like to have an automatic test to ensure that this behavior doesn't
regress.  (This is nothing about you or about this particular patch, it is just
my habit nowadays not to rely upon behavior which isn't automatically tested.) 
If I make a test in shell which creates a patch like this (lacking a hunk-remove
but having an rmfile) and asserts that darcs check detects it and that darcs
repair fixes it, would you accept this test?  Thanks again!

Hm, actually there is still a user interface glitch here -- the part where it
says "The repository is already consistent, no changes made.":

source@org:~/darcs/tahoe/trunk-hashedformat$ time darcs check
Unapplicable patch:                                                          
Fri Nov  9 16:21:12 PST 2007  zooko@zooko.com
  * remove parts of pycrypto that we are no longer going to use: SHA256 and RSA

darcs failed:  Cannot remove non-empty file
./src/allmydata/Crypto/PublicKey/__init__.py
                                                                             
real    0m8.129s
user    0m3.064s
sys     0m0.992s
source@org:~/darcs/tahoe/trunk-hashedformat$ time darcs whatsnew
timNo changes!

real    0m0.489s
user    0m0.436s
sys     0m0.052s
source@org:~/darcs/tahoe/trunk-hashedformat$ time darcs repair
WARNING: Fixing removal of non-empty file
./src/allmydata/Crypto/PublicKey/__init__.py
The repository is already consistent, no changes made.                        
                       
real    0m24.999s
user    0m14.761s
sys     0m4.988s
source@org:~/darcs/tahoe/trunk-hashedformat$ time darcs check
The repository is consistent!                                                
                        
real    0m12.138s
user    0m9.545s
sys     0m1.540s
source@org:~/darcs/tahoe/trunk-hashedformat$ time darcs repair
The repository is already consistent, no changes made.                        
                        
real    0m20.677s
user    0m14.493s
sys     0m4.864s

Oh, whoops, also it doesn't appear to work on old-fashioned-repository format:

source@org:~/darcs/tahoe/trunk-get-hashedformat$ cd ../trunk
source@org:~/darcs/tahoe/trunk$ time darcs check
The repository is consistent!                                             
                                                                      
real    0m3.326s
user    0m2.100s
sys     0m0.468s
source@org:~/darcs/tahoe/trunk$ time darcs repair
The repository is already consistent, no changes made.                         
                                                                       
real    0m11.016s
user    0m9.501s
sys     0m0.912s
source@org:~/darcs/tahoe/trunk$ cd ..
source@org:~/darcs/tahoe$ time darcs get trunk
Directory '/home/source/darcs/tahoe/trunk' already exists, creating repository
as '/home/source/darcs/tahoe/trunk_0'
Unapplicable patch:                                                       
Fri Nov  9 16:21:12 PST 2007  zooko@zooko.com
  * remove parts of pycrypto that we are no longer going to use: SHA256 and RSA

darcs failed:  Cannot remove non-empty file
./src/allmydata/Crypto/PublicKey/__init__.py
                                                                          
real    0m4.316s
user    0m3.276s
sys     0m0.908s

I worked-around it by doing a "darcs get --old-fashioned-inventory" on the fixed
(hashed-format) repository to get a 1.0-format repository.

Oh, wait, now it *does* correctly fix another darcs-1.0 repository:

source@org:~/darcs/tahoe/prod$ darcs check
Unapplicable patch:                                                          
Fri Nov  9 16:21:12 PST 2007  zooko@zooko.com
  * remove parts of pycrypto that we are no longer going to use: SHA256 and RSA

darcs failed:  Cannot remove non-empty file
./src/allmydata/Crypto/PublicKey/__init__.py
source@org:~/darcs/tahoe/prod$ darcs repair
WARNING: Fixing removal of non-empty file
./src/allmydata/Crypto/PublicKey/__init__.py
The repository is already consistent, no changes made.                        
source@org:~/darcs/tahoe/prod$ darcs check
The repository is consistent!                                                
source@org:~/darcs/tahoe/prod$ darcs repair                                  
The repository is already consistent, no changes made.                        
source@org:~/darcs/tahoe/prod$ cat _darcs/format 
darcs-1.0

Here's a summary of this bug:

 * David made it so that "darcs check" detects this problem in current patches
and "darcs repair" fixes it.  Hooray!  These fixes are in darcs-2.0.2.

 * It incorrectly prints out "The repository is already consistent, no changes
made." during the darcs repair, see http://bugs.darcs.net/msg4580

 * We don't know how the ill-formed patches get created in the first place.

 * It seemed to fail on one of my old darcs-1 repositories, but not on another
one (msg4581, msg4622).  Since these are only darcs-1 repositories I'm inclined
to forget about it.

So we should either close this as fixed and open a new ticket saying that the
"repository is already consistent" message is wrong, or else we should fix that
message and then close this ticket.

It is great that you can resolve this by check and repair, but the bug remains,
so I don't agree it should be closed. It is causing problems for me in
particular when mirroring other projects with a tailor script. Manual
intervention is really bad in this usecase.

I am not sure you had identified the problem, so I attach a sure way to do it.
Use the attached tailor script, and you will see the problem: darcs failed: 
Cannot remove non-empty file ./output.lisp
But the patch both consists of a hunk that removes the contents of the file,
followed by a rmfile. So why does darcs say it is non-empty?

Instructions:
Put config.tailor in a new empty directory.
mkdir originalgit
tailor config.tailor

If I first create a darcs2 repo like this:
mkdir salza2;cd salza2; darcs init --darcs-2

It fails in a similar, but not exactly the same way.
Yikes! Pending has conflicts. And if I do darcs check
the rmfile problem is there as an "Unapplicable patch".

Attachments

• config.tailor

Sorry, I forgot this:
tailor --version
0.9.35 (the latest)
darcs --version
2.0.2 (+ 24 patches) (almost the latest...)

Thank you very much for a script that produces this bug!  If you could boil it
down to a shell script or perl script to include in the darcs test suite then
that would be perfect -- it would be automatically tested on all the builders:
http://buildbot.darcs.net/waterfall

About making a shell script of the tailor script: I don't think this is best way
to do it, it would require a bundled tailor.py script, and a local copy of the
remote darcs repo. Instead, I intended the tailor config file for the guy that
can solve this bug. He can use it to reproduce it, and when he understands what
the core of the real problem is he can probably make a unit test for it that is
more on the spot, faster and more maintainable (than using my tailor config file).

hankhero: Thanks very much for the reproducible example.

Lele, may I assign this to you to reproduce?  Perhaps you could help us produce
a minimal test case?

On Mon, 11 Aug 2008 09:51:04 -0000
Eric Kow <bugs@darcs.net> wrote:

> 
> Eric Kow <eric.kow@gmail.com> added the comment:
> 
> hankhero: Thanks very much for the reproducible example.
> 
> Lele, may I assign this to you to reproduce?  Perhaps you could help
> us produce a minimal test case?

Well, AFAICT, if the only way you can trigger this is by using tailor,
than it's a tailor bug I hit myself very recently, not one of darcs2.

If you cannot reproduce this using *only* the darcs2 command line, I
think this bug was properly fixed by David. Nevertheless, thanks for
the additional recipe: I'll try to focus on a possible solution (one
of my tailorized products is blocked by that, so that should happen
relatively soon ;-)

ciao, lele.
-- 
nickname: Lele Gaifax    | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas    | comincerò ad aver paura di chi mi copia.
lele@nautilus.homeip.net |                 -- Fortunato Depero, 1929.

Thanks for looking into this, Lele!

Any thoughts as to why it might be tailor-specific?

Just my $.02, which haven't been validated through repeatable experiments yet,
but... I have hit this bug, or something like it, using only darcs, and moreover
have hit the same problem "one level up", where an rmdir was generated without
actually deleting a file inside it.  I have the broken repository for the latter
and will sift through it on a rainy day.

If it helps, the aforementioned broken repository produces clones (via "darcs
get") that don't have the not-deleted file, but excising patches and reapplying
to a freshly initted repository did seem to solve the breakage.  If this
provides insight...

Just checking: do you produce this bug with darcs 2 (or has it perhaps been
produced with darcs 1 with you noticing it only now?).

The same goes for hank's repository (I still haven't gotten around to upgrading
my tailor for this script to work, sigh)... does this sort of bad patch get
created with darcs 2?

On Mon, 11 Aug 2008 22:10:33 -0000
Eric Kow <bugs@darcs.net> wrote:

> 
> Eric Kow <eric.kow@gmail.com> added the comment:
> 
> Thanks for looking into this, Lele!
> 
> Any thoughts as to why it might be tailor-specific?

Since .35 Tailor writes out the pending file by itself, without
invoking darcs (http://progetti.arstecnica.it/tailor/changeset/1536):
in this way it is able to migrate tricky cases. It turns out that with
darcs2 it fails on removes: with darcs1, putting a "rmfile foobar" in
the pending file was enough, while darcs2 shout about "file contents
was not removed".

In the general case it will be fixed by "not doing anything" on
removes, letting darcs figure out what happened by its own. This will
reintroduce problems with (some) tricky cases, though :-|

I haven't had the chance to focus on the problem yet, sorry.

ciao, lele.
-- 
nickname: Lele Gaifax    | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas    | comincerò ad aver paura di chi mi copia.
lele@nautilus.homeip.net |                 -- Fortunato Depero, 1929.

On Sat, Aug 16, 2008 at 03:35:01PM -0000, Eric Kow wrote:
> Just checking: do you produce this bug with darcs 2 (or has it perhaps been
> produced with darcs 1 with you noticing it only now?).

The repository in question was produced entirely with 2.0.2 from Debian, and
has been a --darcs-2 repository for its whole life.

--nwf;

I have tested it with darcs 1 and darcs 2 and it fails on both, but not in
exactly the same way (with tailor). (see msg5338).

Unassigning self; how'd I get set as assignee anyway? :)  I'll be happy to keep
looking as time allows, but time is thin these days.

(I have noticed that darcs-2 seems to be able to corrupt its pending to contain
rmfile patches alone, resulting in the mentioned corruption even without use of
tailor. This happened to me with the cabalisation branch. Unfortunately, cannot
really reproduce or gather enough info about how that happened.)

(From reading through the bugtracker, it seems I might have ran into an instance
of issue1021, since unrecording might have been involved. However, I can't recall
getting the error upon re-recording, only later. Not sure what happened, really.)

Yes, it has happened to me without the use of tailor, but (probably) with the
use of amend-record.  It is still bothering me actually -- my partner Brian
experienced this failure using darcs-2.0.2 yesterday:

<warner> sigh, 'darcs get dev:/home/darcs/tahoe/prod' gives me an error: 
<warner> Unapplicable patch: 
<warner> Fri Nov  9 16:21:12 PST 2007  zooko@zooko.com 
<warner>   * remove parts of pycrypto that we are no longer going to use: 
         SHA256 and RSA 
<warner> darcs failed:  Cannot remove non-empty file 
         ./src/allmydata/Crypto/PublicKey/__init__.py 

I think I can work-around this, but this demonstrates that the problem is not
completely fixed.

Zooko: hmm, this is the same patch you reported last time, one that was created
in the darcs 1 days.  Did darcs repair not fix it?

We're still on the lookout for an example of this bug being triggered purely by
using darcs-2 (regardless of repository format).  Everybody seems to agree that
darcs amend-record is involved.

Unfortunately darcs check in the repo in question says it is clean, and darcs
repair does nothing.

Also I can't reproduce this failure myself.  Hm -- maybe Brian has a bad patch
in his local cache?  I thought that Brian didn't use a local cache, but I'm not
sure.

Oh, I can indeed reproduce this failure myself.  (I was looking at the wrong
repository when I said I couldn't earlier.)

On Sat, Aug 30, 2008 at 02:09:30PM -0000, Zooko wrote:
> 
> Zooko <zooko@zooko.com> added the comment:
> 
> Unfortunately darcs check in the repo in question says it is clean, and darcs
> repair does nothing.

Can you please test with a version of darcs with my "make check look both
ways" patch (which I believe I sent to the list) applied?  There's a case
where darcs will not notice repository corruption; I wonder if this is
biting you?

--nwf;

> Also I can't reproduce this failure myself.  Hm -- maybe Brian has a bad patch
> in his local cache?  I thought that Brian didn't use a local cache, but I'm not
> sure.
> 
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue693>
> __________________________________

Okay I've now tried the patch "make check look both ways".  The answer is that
the patch does not make a difference -- with or without the patch the "darcs
check" passes even though the repository is corrupt.  However, when I added "-v"
to darcs check I saw that it said "checking from a checkpoint", and so then when
I added "--complete" then darcs check started correctly detecting the
corruption, both with and without the "make check look both ways" patch.

Zooko: so does darcs repair --complete fix the patch(es)?

I'm sorry -- I seem to have repaired or removed all the copies of this
repository with the bad patch in it.  There may be some other copies lying
around somewhere, but I don't see them.

So I can't test whether "darcs repair --complete" fixes it.  Presumably we can
recreate this situation by having a bad patch covered by a tag.  Maybe this
repository could serve as a test subject:
http://lists.osuosl.org/pipermail/darcs-users/2008-September/013363.html

I believe I've probably fixed this bug with the fix that fixes issue709.

David

I would feel confident about closing this bug if we had a test case in ./tests
that checked for this.

Failing that, I would feel better if someone could verify that the patches David
mentions fixes the problem in his/her repository.

I thought the problem was that there wasn't anyone who could reproduce this bug.

On Tue, Sep 16, 2008 at 7:38 PM, Jason Dagit <bugs@darcs.net> wrote:
> I would feel confident about closing this bug if we had a test case in ./tests
> that checked for this.
>
> Failing that, I would feel better if someone could verify that the patches David
> mentions fixes the problem in his/her repository.

I do think that issue709 and its test case is a way to reproduce it, I also
think  that there is more than one way to do it :)

Excerpts from Darcs Bugs's message of Tue Sep 16 23:15:10 UTC 2008:
> 
> David Roundy <droundy@darcs.net> added the comment:
> 
> I believe I've probably fixed this bug with the fix that fixes issue709.

Great!

As mentioned in issue1155, I just got this error again.  I created a
darcs-2-format repository using darcs-2.2.0 (release) on Mac OS X, and using
tailor v0.9.35 to convert the history of Crypto++ (http://cryptopp.com ) from
subversion (http://cryptopp.svn.sourceforge.net/svnroot/cryptopp ).

Here is the tailor.config file.  If you install tailor and then run "tailor
--config=tailor.config" where "tailor.config" is the following file, then you
will reproduce this issue.

[DEFAULT]
remove-first-log-line = True
verbose = True
patch-name-format = %(firstlogline)s

[project]
target = darcs:target
start-revision = INITIAL
state-file = tailor.state
source = svn:source
subdir = .

[darcs:target]
init-options = --darcs-2

[svn:source]
module = trunk
repository = http://cryptopp.svn.sourceforge.net/svnroot/cryptopp

Okay, I did a couple of more experiments.  If I change the line in the
tailor.config to say "init-options = --old-fashioned" instead of "init-options =
--darcs-2", then tailor stops with an error after it tries to create a darcs
patch and finds the files left in the working directory after they were supposed
to be removed:

2009-06-03 20:02:25     INFO: Changeset #8
2009-06-03 20:02:25     INFO: Upstream revision "12" by weidai, 2002-10-18
19:48:45+00:00
2009-06-03 20:02:25     INFO: Log message: remove Sapphire
2009-06-03 20:02:25     INFO:
/Users/wonwinmcbrootles/playground/pycryptopp/cryptopp/tailored-to-d1f $ svn
update --ignore-externals --revision 12 . 2>&1
2009-06-03 20:02:28     INFO: [Ok]
2009-06-03 20:02:28     INFO:
/Users/wonwinmcbrootles/playground/pycryptopp/cryptopp/tailored-to-d1f $ darcs
record --all --pipe --ignore-times 2>&1
2009-06-03 20:02:28  WARNING: [Status 2]
2009-06-03 20:02:28     INFO:
/Users/wonwinmcbrootles/playground/pycryptopp/cryptopp/tailored-to-d1f $ darcs
repair 2>&1
2009-06-03 20:02:29     INFO: [Ok]
2009-06-03 20:02:29     INFO:
/Users/wonwinmcbrootles/playground/pycryptopp/cryptopp/tailored-to-d1f $ darcs
whatsnew --summary --look-for-add 2>&1
2009-06-03 20:02:29  WARNING: [Status 0]
2009-06-03 20:02:29 CRITICAL: Couldn't replay changeset:
Revision: 12
Date: 2002-10-18 19:48:45+00:00
Author: weidai
Entries: c5/License.txt(UPD)
         c5/Readme.txt(UPD)
         c5/bench.cpp(UPD)
         c5/sapphire.cpp(DEL)
         c5/sapphire.h(DEL)
Log: remove Sapphire

2009-06-03 20:02:29     INFO: 439 pending changesets in state file
2009-06-03 20:02:29 CRITICAL: Upstream change application failed: Changes left
in working dir after commit:
M ./c5/License.txt -1 +1
M ./c5/Readme.txt -4 +4
M ./c5/bench.cpp -1
R ./c5/sapphire.cpp
R ./c5/sapphire.h


(Note that this is only the 8th patch in the Crypto++ SVN repository, so you
won't have to wait very long if you reproduce this yourself.)

If I set the options line to say "init-options = --hashed" then I get the same
behavior as with --darcs-2: it goes ahead and creates the corrupted patches --
*not* leaving behind the files in the working directory and therefore tailor
doesn't notice anything out of the ordinary and doesn't stop, but a subsequent
"darcs check" will identify the corrupted patches.

Hm, from re-reading this, especially msg5556 it sounds like Lele thinks this is
caused by a bug in tailor which is editing the darcs internals directly instead
of using the darcs executable?  Is that right, Lele?  I wonder why tailor and/or
darcs behave differently with --old-fashioned than with --hashed or --darcs-2...

Anyway, I've learned that my repository is still corrupted even after "darcs
repair":

source@org:~/darcs/cryptopp/trunk-darcs2format$ darcs check -v -v -v
Checking that patch names are unique...
Applying patches...
The repository is consistent!
source@org:~/darcs/cryptopp/trunk-darcs2format$ darcs repair -v -v -v
Checking that patch names are unique...
Applying patches...
The repository is already consistent, no changes made.
source@org:~/darcs/cryptopp/trunk-darcs2format$ darcs query contents --quiet
--match "hash 20021004173141-0a92f-c0577d638d82f8a637dccd37c1a419ead9464250.gz"
"tailor.config"
darcs: ./c5/usage.dat: openBinaryFile: does not exist (No such file or directory)

Hi Lele,

I'd like to assign this to you to confirm that this is indeed caused by tailor
editing the pending file directly.  It could make for a nice tailor regression
test, for what it's worth.

If you have some extra time, I'd be curious to here about these tricky cases you
mentioned in msg5556.  I also wonder if there's anything darcs needs to be doing
to be more resistant to this kind of thing. :-)

Ah, it looks like Lele has already documented this -- in
http://progetti.arstecnica.it/tailor/changeset/1536 it says:



    Write directly into the pending file instead of using darcs commands
    This is may be a dirty trick, or simply a clever idea: it allows the
    backend to ignore the fact that the source already has
    moved/deleted/renamed stuff around. It now just takes note of what
    happend, and thus is able to handle difficult cases such as

    $ bzr mv A B
    $ touch A
    $ bzr add A



I'm trying again with that patch obliterated from tailor.  By the way, I think
I've already gone through this process once before with Lele's help but I had
forgotten...  :-)

Okay I obliterated that patch from tailor
(http://progetti.arstecnica.it/tailor/changeset/1536 ) and it required me to
obliterate 13 other patches, now I'm rerunning it with --darcs-2 and it seems to
be working!  It got past the 8th patch without stopping and without creating a
corrupted patch.

Hooray my new trac now works:

http://allmydata.org/trac/cryptopp/browser

Oh, well it times out when you try to do most things, but that's issue1477.

I have skimmed this bug and will note three things:

- we had a bug in tailor which wrote out the pending patch by itself causing
this scenario
- 2008-08-15: Nathaniel (nwf) reported in msg5546 that he was able to do this
sans tailor, but this was before issue709 got resolved 2008-09
- 2008-08-30: Petr (mornfall) reported the same, but thinks he may just have run
into issue1012, which was also resolved 2008-09

I think it's safe for us to close this bug.  If we run into anything similar in
the future we should open a new ticket.

Hi Lele, Could you paste in a ticket from tailor trac about this pending patch
issue?  That will help us for future tracking.  Cheers, E

On Sun, 23 Aug 2009 12:26:20 +0000
Eric Kow <bugs@darcs.net> wrote:

> Could you paste in a ticket from tailor trac about this
> pending patch issue?

http://progetti.arstecnica.it/tailor/ticket/183

ciao, lele.
-- 
nickname: Lele Gaifax    | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas    | comincerò ad aver paura di chi mi copia.
lele@nautilus.homeip.net |                 -- Fortunato Depero, 1929.