[darcs-users] Dealing with File Addition Conflicts

[Eric Y. Kow]

> The data doesn't disappear, it's in the merger patch.  zcat the
> patches in _darcs/patches, and you'll see.  How to extract it from
> that patch, I don't know, and it sort of looks like in a Darcs 1 repo,
> Darcs doesn't either.

Well, I've suggested darcs show contents (which may not work if the
version you want to show appears as a merger in your copy of the
repository).  An alternative approach would be to darcs get the branch
you are pulling from and just look at the file there.

None of these are ideal, but as Stephen points out, your data is not
lost.  It's just less convenient to recover than it should be.  Yes, it
is definitely a shortcoming!  (and one that can be fixed by upgrading to
the new darcs 2 format)

>  > I think that makes sense, yes. So basically, no matter what the state
>  > of my working copy, I can always do a mark-conflicts to mark up any
>  > conflicts that do not have a further patch depending on them?
> 
> Not in a Darcs 1 repo in the corner case of conflicting adds, it would
> appear.

To add to Stephen's remark, darcs automatically does a mark-conflicts
when it pulls or applies a patch.  If you revert the changes and do
a mark-conflicts, you'll back to square one (square zero is what happens
in the pristine part of darcs, and also what you get if you revert).

Also: if you fix some of the conflicts, without recording a patch, and
then do mark-conflicts, darcs will probably behave as if you (in
addition to the conflicts it is trying to mark) have some extra
conflicts with the working directory.  The result of this may look a
little strange, but if you don't understand it, you can revert,
mark-conflicts, and return to square one.
 
>  > It's already dropping in an extra copy of the file;
> 
> No, it's leaving it behind.  You put that file there. :-)

More explicitly: The backup mechanism just copies the file in the
working directory before applying any patches to it, so it was
straightforward enough even for me to implement.

Producing a different file for each 'side' of the conflict is something
I would not personally know how to do, as it seems to involve mucking
around in the heart of darcness.  Maybe somebody else like David or
Jason could work on it.  For now, I would suggest just to upgrade to the
darcs-2 format.

It's really a question of pay-off and priorities.  As good as it would
be to fix this, we may be better off focusing on darcs's other problems
instead.

Seeing every side of the conflict
---------------------------------
That said, it may be worth doing if it buys us an improvement for marking up
conflicts in the general case (and not 'just' an amelioration of the ui for
add-conflict handling in old format repositories).

For darcs developers and code watchers, boring implementation details follow.
When I look at this

mangle_unravelled :: [Sealed (FL Prim C(x))] -> Sealed (FL Prim C(x))
mangle_unravelled pss = if only_hunks pss
                        then (:>: NilFL) `mapSeal` mangle_unravelled_hunks pss
                        else head pss

I do not really know how to interpret this, but my guess from skimming the
literate comments is that each member of the list represents a different 'side'
of the conflict -- there can be more than 2 -- and if there are non-hunk
patches involved, darcs just picks the first unravelling.

If this is the case, we could conceivably introduce an additional mangler that
applies each one of the unravellings, taking care to copy the files involved
and systematically appending a suffix to each filename.  Then again, could it
be the case that it a conflict fight, there would be a very great number of
possible sides, and therefore a scary number of files created?  If this was the
case, we could just impose a cut-off, like taking only the first 5 sides of the
conflict.

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20080624/f260b451/attachment.pgp