Issue 1796 broken patch in leksah repo from old darcs, can't repair

Title broken patch in leksah repo from old darcs, can't repair
Priority bug Status given-up
Milestone Resolved in
Superseder Nosy List darcs-devel, dmitry.kurochkin, hamish.k.mackenzie, kowey, mornfall, tux_rocker
Assigned To

Created on 2010-03-26.22:50:33 by kowey, last changed 2011-10-13.13:00:57 by markstos.

msg10535 (view) Author: kowey Date: 2010-03-26.22:50:31
I'm filing this request on Petr's request.

Hamish Mackenzie noticed that darcs check on the leksah repo fails:

We discussed it on IRC

It turns out upon further analysis by Petr that the error comes a broken patch
generated a couple of years ago that Darcs up to 2.3 simply do not detect.

You can reproduce this fairly easily by just grabbing

  darcs init
  darcs pull -p "restruct little" http://code.haskell.org/leksah-head/leksah
  darcs check

You should get an error message like this: darcs failed:  Error
renaming: destination AnchoredPath [Name "src",Name "Ghf",Name "GUI"] exists.

The problem seems to be this sequence of two patches

Sun Jul  8 13:28:27 CEST 2007  jnf@arcor.de
  * restructure

    A ./src/GHF/GUI/
     ./src/GHF -> ./src/Ghf

Mon Jul  9 16:31:55 CEST 2007  jnf@arcor.de
  * restruct little little

     ./src/Ghf/gui -> ./src/Ghf/GUI

If I could boil that down, we do
 add GHF/GUI
 mv  GHF     -> Ghf
 mv  Ghf/gui -> Ghf/GUI
In other words, we create a patch which would clobber a GUI directory by moving
on to it.

It's not entirely clear how this came to pass.  Because of the case renaming,
my first guess was that it might have been due to a rename on a case
insensitive filesystem with old-fashioned repository.  Petr believes it's more
likely to be some kind of pending patch bug.

In any case, this is going to be a problem in the future because Darcs 2.5 will
be much more stringent about applying patches.  It looks like we need to offer
some sort of workaround for the leksah guys.

What are our options?

1. we could use the new darcs rebase feature (but it's experimental)
2. we could extend darcs repair somehow (so that if it's clobbering an
   empty directory, it slips in a rmdir shim?)
3. we could hope this is a one-time problem and offer some sort of
   recipe based on editing patch bundles?
4. other solution?

We should probably consider that there may be other broken repos out there
that we're only going to notice now.  This may need some discussion before
we release Darcs 2.5 :-(

Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
msg10536 (view) Author: kowey Date: 2010-03-26.22:57:54
This is a really hard one to triage.  How can we turn this bug into some
sort of useful action?

My first guess is that we have a choice of (a) thinking up a workaround
(b) talking about this more on darcs-users.  

It doesn't sound like we have the information we'd need to figure out
why this patch was generated in the first place.  Perhaps it would be a
good idea to try to re-create this situation using a ca 2007 Darcs.
msg11405 (view) Author: tux_rocker Date: 2010-06-14.06:43:26
It looks like we're not going to make this before darcs 2.5.
msg14755 (view) Author: markstos Date: 2011-10-13.13:00:56
I'm moving this to "given-up" status. If no one has had any ideas about 
to solve this in a year and a half, I don't have much hope for the future 
of it.
Date User Action Args
2010-03-26 22:50:33koweycreate
2010-03-26 22:57:56koweysetpriority: bug
status: unknown -> needs-reproduction
topic: + Target-2.5
messages: + msg10536
2010-06-14 06:43:28tux_rockersettopic: + Target-2.6, - Target-2.5
nosy: + tux_rocker
messages: + msg11405
2010-06-15 21:07:56adminsettopic: - Target-2.6
2010-06-15 21:07:57adminsetmilestone: 2.8.0
2011-10-13 13:00:57markstossetstatus: needs-reproduction -> given-up
messages: + msg14755
milestone: 2.8.0 ->