On Sun, Sep 6, 2009 at 8:18 PM, Jason Dagit<[email protected]> wrote: > On Sun, Sep 6, 2009 at 11:48 AM, Petr Rockai<[email protected]> wrote: >> Jason Dagit <[email protected]> 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. -- Thanks Kamil _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
