monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] setup creates _MTN/mtn.db


From: Thomas Keller
Subject: Re: [Monotone-devel] setup creates _MTN/mtn.db
Date: Sun, 09 May 2010 02:48:42 +0200
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b2pre Thunderbird/3.0.4

Am 09.05.10 01:33, schrieb Zack Weinberg:
> On Sat, May 8, 2010 at 5:08 AM, Thomas Keller <address@hidden> wrote:
>> Am 08.05.10 13:44, schrieb Stephen Leake:
>>> Second, what is the rationale, both for providing any default name, and
>>> choosing this particular name?
>>
>> The rationale is simply to make monotone less database-centric and
>> verbose with respect to the commands needed to start with a fresh project.
>>
>>> I can see that proving a default db name it makes it easy to start a
>>> totally new project. But it's a significant change, and I'm not happy
>>> with the path.
>>>
>>> I'm ok with initializing the database if needed.
>>>
>>> Once the project grows a branch that they want to checkout into a
>>> different directory, having the database in <branch_1>/_MTN/mtn.db will
>>> be very odd and confusing; people will wonder if there should be one db
>>> per branch, or one db per workspace.
> 
> I sympathise with Stephen here a bit - Monotone's ability to share one
> database among many workspaces is a significant difference from Git
> and Mercurial, and one that should be up-front rather than buried.
> 
> How about putting the database in the parent directory of the checkout
> and naming it something like _store.mtn by default?

In general I agree, but I fear a behaviour is much more unpredictable
and hard to implement than just putting the database into the
bookkeeping root. Imagine what happens if the setup / clone path is
writable, but the parent of this path is not, what if there already
exists a db in the parent path with the same name, et cetera pp.

Maybe this is all solvable with more path / rights checking and unique
naming, but still, whatever we come up with afterwards, I fear it will
look equally if not even more clumsy compared to what we have now, a
self-contained workspace.

Maybe we could make it easier to "extract", or better "move" an
internalized database to an external place and vice versa, so people
don't have to mess with _MTN/options by hand? Then maybe
$HOME/.monotone/databases/<user-chosen-name>.mtn is a good default,
similar to what Stephen proposed. We could add more management features
there, f.e. a "list databases" command which lists available known
databases, a way to find a database only by its name (ie. -d foo would
look for and find $HOME/.monotone/databases/foo.mtn), we could "connect"
databases and workspaces by adding known workspaces of a database as db
variables and list those as well in the database list. There could be a
hook "get_default_database_location" which could be altered by the user
to a different path than the default one underknees $HOME, stuff like that.

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]