Hi, Jason Dagit <[email protected]> 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. _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
