Issue 494 Applying patches leaves unexpected changes in working copy (1.0.9)

Title Applying patches leaves unexpected changes in working copy (1.0.9)
Priority bug Status resolved
Milestone Resolved in
Superseder Nosy List darcs-devel, dmitry.kurochkin, kowey, simonmar, thorkilnaur, tommy
Assigned To
Topics ThePendingPatch

Created on 2007-07-04.12:02:12 by simonmar, last changed 2009-10-23.23:36:38 by admin.

File name Uploaded Type Edit Remove
bug.patch simonmar, 2007-07-04.12:02:11 application/octet-stream
ghc-bug-repo.tar.bz2 simonmar, 2007-07-04.12:11:10 application/octet-stream
msg1794 (view) Author: simonmar Date: 2007-07-04.12:02:11
I have a combination of a GHC tree and a patch bundle that displays the
following behaviour:

~/darcs/ghc-bug > darcs w -s              
No changes!
zsh: 5434 exit 1     darcs w -s
~/darcs/ghc-bug > darcs apply ~/bug.patch 
Finished applying...
~/darcs/ghc-bug > darcs w -s             
 ./compiler/cmm/CmmBrokenBlock.hs -> ./compiler/cmm/CmmCPSData.hs
A ./compiler/cmm/CmmBrokenBlock.hs
R ./compiler/cmm/CmmCPSData.hs

That is, apply the bundle leaves my working copy with changes in it.  There are
no conflicts.

The patch bundle has two patches in it; applying the patches separately avoids
the bug.  It looks like something related to renaming files: one of the patches
has a rename + some changes to the same file.

I've attached the patch bundle, and I'll attach the GHC tree for reproducing the
bug separately.
msg1795 (view) Author: simonmar Date: 2007-07-04.12:11:08
Here's the GHC tree.

Forgot to mention: darcs version 1.0.9, on x86_64-Linux.  Also I should say that
this isn't restricted to apply: pulling the patches from another repo displays
the same behaviour, but you have to pull the two patches together.
msg1957 (view) Author: kowey Date: 2007-08-01.07:00:03
Any ideas, David?  This one looks kind of interesting.  It would be great if we
could boil it down to a minimal test case.

To simplify, first patch adds f1; second patch moves
  f1 -> f2
and modifies f2

And whatsnew shows
  f2 -> f1 (inverse)
  A f2
  R f1

As though Simon had rollback'ed the move and then done it over by hand.

Interestingly, I can't reproduce it with Simon's tarball/patch combo (applies
cleanly), but this is on MacOS X and with darcs 1.0.8.  Will have to check later
if I get the same thing on 1.0.9.  No conflicts or anything weird, as far as I
can see.
msg2053 (view) Author: kowey Date: 2007-08-11.20:20:18
Just for info, I can reproduce this with both 1.0.9 and 1.1.0 (unstable) under
Linux (32 bit).

Sounds pretty serious (and sounds like a regression).  Would be nice if we had a
small test case.
msg2054 (view) Author: kowey Date: 2007-08-11.21:15:04
Ok, now we have a minimal test case!  (Submitted as a patch to darcs-devel). 
Note that (bizarrely enough), the second filename must start with an uppercase
character for the bad things to happen.

mkdir temp1
cd temp1
darcs init
echo abc > a
darcs add a
darcs record --all -m patch1 -A moi
darcs mv a B
echo def > B
darcs record --all -m patch2 -A moi
cd ..

mkdir temp2
cd temp2
darcs init
darcs pull --all ../temp1
darcs whatsnew | grep 'No changes'
msg2055 (view) Author: tommy Date: 2007-08-11.21:32:19
It seems to be the pending patch that haunts us again. A simple
rm _darcs/patches/pending clears the problem.

By the way, the pending file seems to be "correct" in some way,
because a Record (even with extra "real" changes) produces a
valid repo, although with a very strange looking patch.
msg2056 (view) Author: kowey Date: 2007-08-12.13:55:37
Based on Ian's comment on IRC, here is a simplified version of the test.
Capitalisation is not the issue; sorting is.

mkdir temp1
cd temp1
darcs init
echo abc > b
darcs add b
darcs record --all -m patch1 -A moi
darcs mv b a
echo def > a
darcs record --all -m patch2 -A moi
cd ..

mkdir temp2
cd temp2
darcs init
darcs pull --all ../temp1
darcs whatsnew | grep 'No changes'
msg2058 (view) Author: kowey Date: 2007-08-13.17:20:35
Resolved in unstable with David's serendipitous patch:

Wed Aug  8 02:52:51 CEST 2007  David Roundy <droundy@darcs.net>
  * fix bug that revealed itself in optimize --reorder on unstable repo.
Date User Action Args
2007-07-04 12:02:12simonmarcreate
2007-07-04 12:11:54simonmarsetfiles: + ghc-bug-repo.tar.bz2
status: unread -> unknown
messages: + msg1795
2007-08-01 07:00:05koweysetmessages: + msg1957
title: Applying patches leaves changes in working copy -> Applying patches leaves unexpected changes in working copy (1.0.9)
2007-08-11 20:20:19koweysetmessages: + msg2053
2007-08-11 21:15:06koweysetmessages: + msg2054
2007-08-11 21:32:21tommysetmessages: + msg2055
2007-08-12 13:55:38koweysetmessages: + msg2056
2007-08-13 17:20:36koweysetstatus: unknown -> resolved-in-unstable
messages: + msg2058
2008-08-14 06:48:56koweylinkissue911 superseder
2008-09-04 21:31:08adminsetstatus: resolved-in-unstable -> resolved
nosy: + dagit
2008-09-08 15:19:42koweysettopic: + ThePendingPatch
nosy: droundy, tommy, beschmi, kowey, dagit, simonmar
2008-09-13 12:07:39koweylinkissue1034 superseder
2009-08-06 17:35:17adminsetnosy: + markstos, jast, Serware, dmitry.kurochkin, darcs-devel, zooko, mornfall, simon, thorkilnaur, - droundy, simonmar
2009-08-06 20:32:25adminsetnosy: - beschmi
2009-08-10 22:06:00adminsetnosy: + simonmar, - markstos, darcs-devel, zooko, jast, Serware, mornfall
2009-08-11 00:01:26adminsetnosy: - dagit
2009-08-25 17:49:34adminsetnosy: + darcs-devel, - simon
2009-08-27 14:10:30adminsetnosy: tommy, kowey, darcs-devel, simonmar, thorkilnaur, dmitry.kurochkin
2009-10-23 22:38:06adminsetnosy: + marlowsd, - simonmar
2009-10-23 23:36:38adminsetnosy: + simonmar, - marlowsd