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: Stephen Leake
Subject: Re: [Monotone-devel] Please review nvm.experiment.database-management
Date: Tue, 25 May 2010 17:16:13 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (windows-nt)

Thomas Keller <address@hidden> writes:

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

Since the path is ordered, it could take the first one found. That would
be consistent with other uses of search paths.

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

I don't remember saying that, but I did mention being consistent with
other uses of search paths, which usually have at least local and
system-wide directories.


-- 
-- Stephe



reply via email to

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