[darcs-users] Broken Repo fix problem (left as an exercise to the reader)

[Tommy Pettersson]

On Tue, Sep 27, 2005 at 03:09:53PM -0500, Richard A. Smith wrote:
> darcs choking and leaving the repo in a state that you must use darcs 
> repair on because it can find the file may indeed be a bug.  I'll be 
> happy to zip up copies of the offending repo for test.  It's 100% 
> repeatable.  Or at lease it has been so far.

The bug report (#525) already links to a repo that reproduces
the bug, but more examples can be valuable if the bug is hard
to understand, or if it turns out to be two different bugs
that just looks the same.


> But the source of problem is certainly not darcs.  One of my co-workers 
> pushed a patch that nuked all the files.  But they still exist in my 
> tree so my patches try to modify those files that now don't exist.
> 
> >Well, (pretending there was no failure on darcs' part) I wonder,
> >perhaps this situation is a job for the rollback command? If
> >lucky, just issue 'darcs rollback' and select the offending
> >patch.
> 
> Kind of.  I unpulled things prior to DirRestructure then applied 
> DirRestructure then rolled it it back.  The issue now is that rollback 
> dosen't affect the working directory.

Ah, just 'darcs revert --all'.  The 'rollback' is made to
work just like 'unrecord', but in a "safe" way, in that no
patches are destroyed.

>                                        So one of the following patches
> has a conflict with a file in the ./src/ dirctory but when I go to the 
> working dir to edit the file and fix the conflict the file dosen't exist 
>  anymore.

If you didn't revert earlier you can revert and resolve here.
It should produce the same result, unless you had unrecorded
manual changes.

Hmm, there is a mystery here... There will be conflicts between
the patch that removes the files and the pulled patches that
change these files.  There will also be conflicts between
the rollback patch and these patches.  (If there are many
depending patches things might not work because it looks like
they mergers grow exponentially on the level of dependency.)
But what is strange is, in the presence of the rollback patch
the conflicts appears to be self-resolved.  The "resolution"
is nothing, which means the resulting version will be the
result of the merge.  The result of a merge is that none of
the conflicting changes is applied.  In this case the files
in ./src/ will look like before the DirRestruct.  This is
not very useful, so it seems the rollback was not a good idea
after all. :-(


> I need what ammounts to the union of unpull and rollback.  Or some 
> method of generating and applying a reverse of a patch.

I think there is a feature request for a command that applies
the reverse of a recorded patch to working without changing
anything in pristine (I think that is the same thing as you
describe, but expressed more complicated ;-)


> How would I go about accomplishing whats effectively a rollback but that 
> changes the working dir.

Sometimes it works with:

  darcs diff <clever selection of patch range> | patch -R

Or you can create the rollback patch just like previously,
reverting, and then unrecording the rollback patch.
Now whatsnew should report just the changes you want, and
you can record them in a "normal" patch.

> So again I _think_ that basically I need to apply a patch and right 
> after apply the inverse of that patch so that it neutralizes the changes.
> 
> Then I think the patches after that will all apply.

This is what rollback does, but the handling of conflicts
was a surprise to me.  I have not yet looked into exactly
how darcs commutes patches, and if undo patches (rollbacks)
are handled specially it might work better/differently if
you construct a "normal" patch with the same contents.


> What's a mystery is how did darcs allow a user to remove a file from the 
> repo and then later on record a patch against that file without an add 
> in between?  Thats the only way I can see how this could happen.

Darcs should (and I think does) not, but it should be possible
to pull changes from other repos in any order.  So you can
pull first a patch that removes a file and then a patch
that alters the "same" file.  This results in a conflict.
Conflicts with file/dir adds and removes can sometimes be
hard to see and also understand.


-- 
Tommy Pettersson <ptp at lysator.liu.se>