Now, just applying the patch is straightforward, you can apply the forward_change to manipulate data1 to be data2, and manipulate data2 to be data1. However, I've implemented a mechanism to remove a patch; this could be intermediary between numerous patches. Subsequent patches are re-adjusted to reflect the removal of a earlier patch.
To do this, I was hoping that index[0] of forward_change.patch (fp) is the direct opposite of index[0] of reverse_change.patch (rp), However, the current index output is:
fp0 = rp0
fr1 = rp2
fr2 = rp1
At least in this use case, the position of the incorrectly ordered index is irrelevant; the correct apply_patch change will be made regardless of whether index 1 and 2 are the right/wrong way round.
I couldn't spot any hardcoded reason for the position of the patch items. Is there a reason you can think of for this, or a possible approach to fix up the order?
From what it seems, changes do not have a structured order to them, making it difficult to ensure you can apply/revert patches.
Take the following example:
This ends up with the following changes
Now, just applying the patch is straightforward, you can apply the forward_change to manipulate
data1
to bedata2
, and manipulatedata2
to bedata1
. However, I've implemented a mechanism to remove a patch; this could be intermediary between numerous patches. Subsequent patches are re-adjusted to reflect the removal of a earlier patch.To do this, I was hoping that
index[0]
offorward_change.patch
(fp) is the direct opposite ofindex[0]
ofreverse_change.patch
(rp), However, the current index output is:At least in this use case, the position of the incorrectly ordered index is irrelevant; the correct
apply_patch
change will be made regardless of whether index 1 and 2 are the right/wrong way round.I couldn't spot any hardcoded reason for the position of the patch items. Is there a reason you can think of for this, or a possible approach to fix up the order?