[Top][All Lists]

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

Re: [Monotone-devel] Time to think about a release?

From: Markus Schiltknecht
Subject: Re: [Monotone-devel] Time to think about a release?
Date: Tue, 25 Mar 2008 14:12:37 +0100
User-agent: Mozilla-Thunderbird (X11/20080110)


Thomas Moschny wrote:
For the end user, this change should not have any noticeable effect,
except mtn being a tiny bit faster and the database taking somewhat less
space. Every other difference in automate or locking behavior should be
considered a bug. :-)

Oh, sorry, I've been talking about nvm.experiment.db-compaction, which hasn't landed, yet. I'm much more into that, at the moment....

How can the changes in nvm.experiment.encapsulation make the database take less space?

Correct, it does not.

And why would would you consider changes in the locking behavior a bug?

Because its not and intended or wanted change, neither for nvm.e.encapsulation nor for nvm.e.db-compaction. And as such, it might likely be a bug, IMO.

In fact, the current behavior is buggy (imho), because mtn acquires coarse-grained write-locks to the database, so e.g. concurrent access via automate and mtn serve is not possible. And to me it seemed the efforts in nvmee were part of the plan to overcome this issue.

Yes, a step into that direction. Instead of a database class only, there's now the exposed database interface class, plus a database implementation class, which might be changed underneath and isn't exposed to other parts of the code. Encapsulation.

That should flatten the way to a read-only database access (allowing concurrent readers), and maybe even support for other databases. However, it's just one step, we aren't there, yet. (The most difficult thing I see there will be "upgrading" the read-only database to a writable one on demand).



reply via email to

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