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: Thomas Keller
Subject: Re: [Monotone-devel] Please review nvm.experiment.database-management
Date: Tue, 25 May 2010 14:10:23 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.1.9) Gecko/20100317 SUSE/3.0.4-1.1.1 Lightning/1.0b2pre Thunderbird/3.0.4

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?

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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