Darcs should keep the old patch.

Thanks a lot for this report. This sounds a bit disturbing, are you actually 
experiencing data loss or is it "merely" the patch to be amended that gets 
unrecorded? Or something else, perhaps? Searching the bug tracker briefly, http://bugs.darcs.net/issue332 seems to be about a similar situation with darcs 
record.

Could you supply some additional details, please? An actual transcript of a 
session that demonstrates the problem would be a good start. A transcript that 
demonstrates the problem starting from a fresh repository would be even better. 
And best of all would be a test case that demonstrates the problem.

Thanks and best regards
Thorkil

No data is lost: its just that all the changes have to be selected again.

Ex. with xmonad repo, make a change that passes the test.
darcs record (selecting those changes)

Then make some changes that would cause the test to fail (ex some subtle
documentation changes that cause the haddock test to fail)

darcs amend-record (selecting those most recent changes)

After the test fails, all the changes that were made are still in the repo, but
the first patch made in this process is nowhere to be found and has to be
recorded again.

I hope that that's clearer.

Regards,
Adam

I can't seem to reduce this to a case on a fresh repository, but attached is a
repo that will unrecord the most recent patch if you try to amend-record it (the
change causes haddock to fail).

Attachments

• xmc.tar.bz2

Hi Adam,

As a means of reproducing this, have you tried setting the test to "exit 1"?
This sounds like it's just a superficial bug on the level of the amend-record
command (Darcs.Commands.AmendRecord).  I'll bet it's easy to fix.  And I think I
do agree with the point of view that a failing amend-record --test should
basically be a no-op.

I'm assuming that this is reproducible, and marking this need-volunteer for
somebody to write up a small test case showing the behaviour we would want.

Thanks!

I'm not so sure that it is that easy because darcs does the right thing to a
fresh repo. In the attached repo, all you have to do is:
>  darcs amend-record
and add only change (removing a line), and that patch is unrecorded when the
test fails (either the actual test, or exit 1). There's something different in
the attached repo that I can't isolate.

On Sat, Mar 28, 2009 at 15:19:00 -0000, Adam Vogt wrote:
> I'm not so sure that it is that easy because darcs does the right thing to a
> fresh repo. In the attached repo, all you have to do is:
> >  darcs amend-record
> and add only change (removing a line), and that patch is unrecorded when the
> test fails (either the actual test, or exit 1). There's something different in
> the attached repo that I can't isolate.

I can confirm that this is reproducible.  I deleted an import from
XMonad/Layout/Mosaic.hs with

  sed -e '35,36d' XMonad/Layout/Mosaic.hs > XMonad/Layout/Mosaic.hs.tmp 
  mv XMonad/Layout/Mosaic.hs.tmp XMonad/Layout/Mosaic.hs

and sure enough, the patch unrecorded itself as soon the as the test failed.

I also have a nugget of potentially useful information for anybody wanting
to fix this - this does not appear to affect hashed repositories (hence
Adam not being able to reproduce this).  When I darcs get --hashed and do
the same thing, it does the right thing.  If I darcs get --old-fashioned
a copy, the wrong thing happens.

Adam, with this in mind, any chance you'd be willing to give the minimal
test case another go?

Thanks!

Here are the contents of darcs show repo:
          Type: darcs
        Format: darcs-1.0
          Root: /tmp/XMonadContrib
      Pristine: PlainPristine "_darcs/pristine"
         Cache: thisrepo:/tmp/XMonadContrib, cache:/home/eykk10/.darcs/cache
     test Pref: runhaskell Setup.lhs configure --disable-optimization --user -f testing && runhaskell Setup.lhs build && runhaskell Setup.lhs haddock
        Author: Adam Vogt <vogt.adam@gmail.com>
Default Remote: http://code.haskell.org/XMonadContrib
   Num Patches: 1813

Thanks kowey, this is definitely just an issue with the old repository format as
you suggested. I have attached a crude script that checks whether an
amend-record that fails a test can cause previously recorded changes to be
unrecorded.

Attachments

• checkbug.sh

Excellent!  If you could just tidy that test up a bit, add it to the bugs/
directory as something like bugs/issue1406-amend-record-test.sh and darcs send
it our way, it would be great.

See http://wiki.darcs.net/index.html/RegressionTests for more details.

I think the resulting script will be much simpler, because the darcs test
harness will by default run each test thrice (passing it one of --old-fashioned,
--hashed and --darcs-2 on each run).

(Or if you're already sick of us always asking for just a tiny bit more, feel
free to say "argh, stop!")

Just adding Kamil to the bug-tracker on this as he has started work on
this.

Turned out I was way off about this being ProbablyEasy.

Kamil has attempted a fix for this, but it turned out to be hairier than expected.
- http://wiki.darcs.net/Review/issue1406
- http://lists.osuosl.org/pipermail/darcs-users/2009-September/021175.html

We've decided that the proposed fix would be too risky.  So we're setting this
aside since it's really a relatively obscure case (relatively) and
only affects old-fashioned repositories anyway.  If anybody wants to take a
look, then we will welcome patches.

Meanwhile, many thanks, Kamil!  We got some nice tests out of it, it looks.