monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Please review nvm.experiment.database-management


From: Timothy Brownawell
Subject: Re: [Monotone-devel] Please review nvm.experiment.database-management
Date: Tue, 25 May 2010 07:31:51 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100515 Icedove/3.0.4

On 05/25/2010 07:10 AM, Thomas Keller wrote:
Am 25.05.2010 14:00, schrieb Timothy Brownawell:
On 05/25/2010 02:02 AM, Thomas Keller wrote:
Am 25.05.2010 04:42, schrieb Timothy Brownawell:
On 05/23/2010 05:08 PM, Thomas Keller wrote:

One of the tests has two "foo.mtn" databases in different managed
directories. It looks like in this case there's no way to use either of
those as a managed database, because they can only be found by giving
the full path?

Thats right - I don't plan to support equally named databases in
different locations. Such a case should merely act as a reminder for the
user to rename one of the two to a more distinct name.

When the second managed 'foo.mtn' is added, any existing workspaces that
had been set up with ':foo' will lose track of their database. I could
see this confusing people... but then it can only happen if you're
mucking about in those hooks, so you'd presumably know what you'd done.

Well, I haven't tested this, but if a :foo setting in _MTN/options is no
longer uniquely resolvable to a single path, monotone should, just as if
you give -d :foo directly, display the databases to which the alias
resolves, so people can very early and very easily fix the problem.

What's the reason for allowing multiple directories of managed
databases? Only having one would get rid of the ambiguity case here, and
would also mean you can't get confused by which managed directory a new
database gets put in.

I also thought I should allow only one place where databases should be
located, but then Stephe said it might be cool to "aggregate" databases
from different sources. I don't know how valid this use case is, but
then it did not make much work either to include support for n>  1
locations.

What is your general feeling about the branch? Do we need an explicit
garbage-collecting functionality for the registered workspaces? What
would you propose?

I like it in general.

There should be some way to remove old workspaces. A full gc would be nice, but from what Stephen said there should also (or instead) be a way to remove individual stale workspaces.

Having multiple managed db directories adds potential for confusion, and doesn't seem terribly useful. The best case that comes to mind is if you want to keep some of your dbs on removable media, but I think that would be better made explicit so you don't accidentally init a new db on the wrong disk, or attach something to a removable db when you meant to init a new one.

--
Timothy

Free public monotone hosting: http://mtn-host.prjek.net



reply via email to

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