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

[Thomas Keller]

Am 25.05.2010 04:42, schrieb Timothy Brownawell:
> On 05/23/2010 05:08 PM, Thomas Keller wrote:
>>
>> Hi all!
>>
>> I think I've fleshed out most of the bugs and annoyances of the initial
>> implementation of the database management branch and also updated the
>> documentation and test cases accordingly. For all of you who haven't
>> followed the development before, here is a short summary of what changes
>> in this branch:
>>
>> * databases are now not only addressable via their full path, but also
>>    via their file names (dubbed aliases); these aliases start with a
>>    single colon ":" followed by the name of the file (with or without
>>    the suffix ".mtn", which automatically gets appended if not given)
>> * the location of these "managed" databases is configurable and defaults
>>    to $HOME/.monotone/databases
> 
> What about Windows? That uses %APPDATA%\monotone instead of ~/.monotone
> . ... I see the hook uses get_confdir() so it's fine, just the
> documentation is a bit off.

You're right, I'll add the Windows default to the documentation as well.

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

>> * to ease the management of those "specially located" databases a new
>>    "list databases" command has been introduced which lists all known
>>    valid databases and their configured workspaces. The latter is
>>    updated automatically as soon as a managed workspace is set or removed
>>    for a particular workspace, i.e. also for checkout, clone, setup,
>>    update, basically everything which accepts a -d option.
> 
> I don't see a way to gc the managed workspace list, if I just rm a
> workspace without unregistering it first.

Yes, the lists are not cleaned and could possibly collect many
non-existing workspaces at some time. I wasn't sure how to fix that
properly, adding a "clean this stuff up" command just for that purpose
seemed over-engineered and the only other thing I could come up with was
"clean invalid paths on addition / removal of other paths". What do you
think?

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

signature.asc
Description: OpenPGP digital signature