monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] [RFC] Monotone NETSYNC Hook Extension & Abstraction


From: Ralf S. Engelschall
Subject: Re: [Monotone-devel] [RFC] Monotone NETSYNC Hook Extension & Abstraction Layer
Date: Wed, 26 Sep 2007 07:53:16 +0200
User-agent: Mutt/1.5.16 OpenPKG/CURRENT (2007-06-09)

On Wed, Sep 26, 2007, William Uther wrote:

> On 26/09/2007, at 3:14 AM, Nathaniel Smith wrote:
>> On Mon, Sep 24, 2007 at 07:24:51PM +0200, Ralf S. Engelschall wrote:
>>> We're now addressing the problem "How can we ensure that a revision is
>>> not stored into the database at all in case an ACL hook determines that
>>> one of its certificates break an ACL rule?" the following way:
>>
>> By the way -- have you considered simply dropping illegal certs?
>> This would permit a *much* simpler implementation, but I don't know
>> if it would satisfy your requirements.  It would of course allow
>> "illegal" files/revisions to take up space in your database, but
>> monotone will never actually *do* anything with a revision unless a
>> cert tells it to (or a user explicitly requests it, like with -r <full
>> rev id>).  If any such "ghost revisions" do accumulate, you can
>> garbage collect them by periodically doing a pull into a fresh
>> database, and then replacing your old database with the freshly-pulled
>> one.
>
> Or you could (in addition to dropping illegal certs) garbage collect any
> revs with no branch certs or no descendants with branch certs at the end of
> each sync.

Yes, thanks that you mention this. This was one of our ideas, too. But
we fair that this cannot be done reliably. Monotone in parallel serves
connections, so if we garbage collect bad stuff at the end of a session
the received stuff might be still already sent out again in a different
session. The problem is that the sessions' data is auto-flushed to
the database in smaller chunks and one not even can let one help by
a database transaction here. That's why our idea is that it would be
better if one already prevent the storage of bad revisions at all.

                                       Ralf S. Engelschall
                                       address@hidden
                                       www.engelschall.com





reply via email to

[Prev in Thread] Current Thread [Next in Thread]