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

[Markus Schiltknecht]

Hi,

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).

Regards

Markus