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

[Petr Rockai]

Hi,

Jason Dagit <dagit at codersbase.com> writes:
>> Tentative state corresponds to the real state of the repository. The
>> representation is the same except for the tentative_pristine, which is
>> stored as a sequence of patches, a diff from the real pristine.
>
> Sure.  That makes sense.
Actually, I don't know about old-fashioned (there, this would indeed make
sense), but for hashed repositories, tentative_pristine is actually an
alternative root pointer into pristine.hashed. No patches involved at all.

>> The consistency of the tentative state after a failure does not
>> matter. The tentative state is cleared before every transaction, see
>> my description above.
>
> Hmm...Okay.
Yes, this is true.

>> That would break consistency. remove_from_tentative_inventory should
>> not assume that it is the only or first operation in a transaction
>> (which actually holds, but nevertheless). There might have been an
>> arbitrary number of operations on the tentative state before it, each
>> of which could have modified the tentative_pristine. In other words,
>> we should update the tentative_pristine, not create it based on the
>> real pristine, which would drop all the changes previous operations in
>> the transaction made.
>
> 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. Doesn't darcs optimize remove orphaned patches? I just assumed it
>> is the way with darcs because obliterate does not make any effort to
>> remove orphaned patches either. But now I can't easily find anything
>> in the code that does it. This might be a separate issue.
>
> I'm not aware of any command to clean up garbage patches.  Having it
> be an option in optimize makes some sense.  If we can avoid creating
> garbage here (I'm treating this issue like a garbage collection issue,
> the inventory is our set of root pointers and the patches exist in our
> 'heap'.), then I think we should try to do so.
It probably does not happen, since it could break running remote operations on
the repository. It could be implemented as a separate command though and
shouldn't really be too hard (although not completely trivial either).

Yours,
   Petr.