Re: When patches are modified?

"Pekka Pessi" <ppessigmail.com> writes:
> Why adding stuff  to patch (merger things) or modifying
it (the hunk
> line numbers) does not change the date/hash of the
patch? I mean, it
> is not the same patch anymore, so why pretend it is?
>
> Is this bug or a feature?
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.

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

> Most importantly, how I can get rid of the mergers? It
is bloody
> annoying when rollback does not and pulling
"same" patches through
> different repos result in different results. Also,
darcs check
> --complete does not complain when patch and its
rollback are
> different.
This is a different problem, or so i believe. Rolling back
two
dependant patches has the problem that:

There is patch B that depends on A. When you roll back B,
you get a
new patch B^-1, which is rollback of B, and obviously
depends on B
(ie, you cannot commute the undo to come before the thing
it
undoes). This means that now you have B^-1 depends on B
depends on
A. 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

Now, you can use diff/patch and/or a little manual action
(for
renames, tokreplace), to move the changes between repo and
repo-rollback to repo and record the almost-inverse patch
manually. (Now, darcs won't know about the fact the patch is
inverse
of some other patch, however it will have the same
commutation
properties (as far as i can see) and i do not know of
anything where
darcs could leverage this information, other than user
interface).

These observations are from what i have read and observed
and i do not
have any deeper understanding of darcs. Therefore, please
correct me
if i am wrong on any of the points.

Yours, Peter.

PS: I *think*, that for systematic solution of
"rollback dependant
patches", you would need to use the information that
B^-1B amounts to
Nil and commute the B^B pair as a single entity, ie. you
can
commute B^BA to AB^B, but not to B^A'B' (if i
got this
right). However, this commutation is only valid, as long as
B^B
"stay together". So at that point, you cannot
unpull B^ without
unpulling B, which is probably something you do not want.
This is
basically equivalent to obliterating both B and B^, or
replacing
them with an explicit Nil patch, either of which is a sorta
history-trashing operation. Go figure. Although this
probably more
properly belongs to -devel. (I also think, that
"proper" solution
could be to allow rollback of interdependent patch groups,
say XBA
where X is same as B^A^, or even XB^BA where X
undoes the
whole group; this also starts to look a bit like merges and
i am
starting to feel like running in circles and/or babbling
nonsense, so
i stop here).

-- 
Peter Rockai | me()mornfall!net | prockai()redhat!com
 http://blog.mornfall.net
| http://web.mornfall.net

"In My Egotistical Opinion, most people's C programs
should be
 indented six feet downward and covered with dirt."
     -- Blair P. Houghton on the subject of C program
indentation
_______________________________________________
darcs-users mailing list
darcs-usersdarcs.net

http://lists.osuosl.org/mailman/listinfo/darcs-users

Thanks for answering,

2007/10/15, Petr Rockai <memornfall.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
_______________________________________________
darcs-users mailing list
darcs-usersdarcs.net

http://lists.osuosl.org/mailman/listinfo/darcs-users