[darcs-users] When patches are modified?

[Petr Rockai]

"Pekka Pessi" <ppessi at gmail.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^{-1}B pair as a single entity, ie. you can
commute B^{-1}BA to AB^{-1}B, but not to B^{-1}A'B' (if i got this
right). However, this commutation is only valid, as long as B^{-1}B
"stay together". So at that point, you cannot unpull B^{-1} without
unpulling B, which is probably something you do not want. This is
basically equivalent to obliterating both B and B^{-1}, 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^{-1}A^{-1}, or even XB^{-1}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