[darcs-users] darcs patch: test that tentative leftover is cleared (and 2 more)

Kamil Dworakowski kamil at dworakowski.name
Sun Sep 6 20:31:05 UTC 2009

On Sun, Sep 6, 2009 at 8:18 PM, Jason Dagit<dagit at codersbase.com> wrote:
> On Sun, Sep 6, 2009 at 11:48 AM, Petr Rockai<me at mornfall.net> wrote:
>> Jason Dagit <dagit at codersbase.com> writes:
>>> In that case, the patches we want to remove from the
>>> tentative_pristine need to be removed carefully.  For example,
>>> commuting them to the end and discarding them.  The code as written
>>> writes the inverses to the tentative_pristine.  Do we make any effort
>>> to later collapse inverses and remove the resulting identity patches?
>>> The ideal case is that patches to be removed simply do not exist in
>>> the tentative_pristine when we're done.  Failing that, we need to
>>> simulate a 'rollback' which is what applying their inverse is all
>>> about.
>> This is tentative_*pristine*, not tentative patches. Even if we store patches
>> in there, these will never materialise as actual patches in the repository,
>> they exist solely for the purpose of application. (Hopefully.)
> Yes, but if you look at the code and read over my description from the
> most recent patch review, you'll see that with these changes we would
> call write_patch on changes that are tentative.  Priory to that
> write_patch was only called on patches that already existed in the
> repository but which had been changed via a commute with the patches
> to_remove.  With the change, write_patch is also called on patches
> read from the tentative inventory.

Here is how I understand the problem: To remove the (un)desired
patches from the tentative_inventory, we need to commute them to the
end. This operation may change a number of patches in that inventory
sequence and thus we have to ensure each of them is written to the
disk. Now, we write the patches to a common store shared by inventory
and tentative_inventory. Since tentative_inventory, as the name
implies, might get discarded in case of test failure for example, the
modified patches thus written will be orphaned.

However, the problem of orphaned patches exists in darcs before this
patch. For instance, the amend on success will leave the original
patch and any commuted patches orphaned (tell me if I'm wrong).
Probably any other command that commutes the patches in the inventory
does it too.

I think the orphaned patches could be a separate issue (a command
analogous to the git gc). This problem exists in the current repo, it
is not introduced by this patch. The patch addresses the lack of
atomicity in the amend-record, thus making it fully ACID. It is true
that amend before the patch used to create less garbage in case of
failure, but with the price of committing half the changes in the
middle of the transaction.


More information about the darcs-users mailing list