[darcs-users] When patches are modified?

[Pekka Pessi]

Thanks for answering,

2007/10/15, Petr Rockai <me at mornfall.net>:
> This is a design decision. The files in _darcs/patches are patch
> representations, which are definitely not unique. First, darcs needs
> to commute patches, second, commutation often changes representation
> of a patch (eg. true of commuting hunk patches for a single file, or
> rename vs content changes). So yes, it still is the same patch, and it
> can be commuted back to its original representation if ever
> neccessary. This also means, that its hash must not change this way.

You are right - if I remove conflicting patches, the mergers disappear.

> What i do not know, if merger patches may come out of commutation of
> non-merger patches (though i somewhat doubt it).

Looks like a patch and its inverse do this magically. It seems to me
that a conflict is considered resolved, if darcs finds an inverse to
one of the conflicting patches, even if the inverse has no other
conflicting patch in its context.

> [...] However, you cannot roll back A, since there are patches depending
> on it (namely B, and, transitively B^-1). I have no idea about plans
> for fixing this problem, what you can currently do is undo the patches
> manually, eg:

> darcs get repo repo-rollback
> cd repo-rollback
> darcs unpull # select the offending patches

This has the problem that A^-1 (rollback of A) now conflicts with B:
if I push the rollback of A to original repo, it conflicts with B.
There are three patches involved in conflict, B, its rollback and
rollback of A. However the conflict is already considered resolved
because the repo has rollback of B, so the rollback of A has no
effect.

The situation is even worse if the A and B have more than one atomic
patch. The the B^-1 B pair only cancels those parts of rollback A
where B depends on A. So "undo A" now undoes those parts of A on which
B does not depend but the parts of A on which B depends are left in
repo.

-- 
Pekka.Pessi mail at nokia.com