Issue 113: commands silently default to :memory: database - A distributed version control system

Reported by Timothy Brownawell, Nov 27, 2010

Steps to reproduce the problem:
-------------------------------

1. make sure you're outside any workspaces
2. run "mtn serve", "mtn ls branches", "mtn 
pull", etc
3. results are not persistent but do not say "misuse: no 
database specified", for example things pulled do not show up 
in a later "ls branches"

Expected result:
----------------

Commands should never default to :memory:

Actual results:
---------------

commands *silently* default to :memory:

Output of `mtn version --full`:
-------------------------------

Bisected to:

Revision: 0007c40d9d12137729fdd27c05572f21974d72b7
Parent:   5be91109b5bbc338669cc1f60ebdc99cdc718ab4
Author:   me@thomaskeller.biz
Date:     05/12/2010 07:49:34 AM
Branch:   net.venge.monotone.experiment.database-management

Changelog: 

* use an enum to describe the database type (memory, managed, 
unmanaged)
* refactor the path resolver for the db out and make it callable 
elsewhere (f.e. from work::set_options)
* set_options needs now a lua_hooks instance, quite a couple of 
changes therefor
* expand "foo" to "foo.mtn" automatically and 
always look for "foo.mtn", not for "foo"
* open issue: _MTN/options still saves the full path, not the 
managed one - we might want to change that some time

Comment 1 by Thomas Keller, Nov 28, 2010

I agree that :memory: is a bad default, but I wonder if we should 
(not silently of course) default to the db / alias given by the 
get_default_database_alias hook?

Comment 2 by Thomas Keller, Nov 28, 2010

The problem is btw located in src:database.cc line 4932 - the code 
issues a log message and returns without setting a path just like it 
would do for the :memory: option. Either we E() there or we try to 
(verbosily) default to an existing default database.

Comment 3 by Thomas Keller, Dec 28, 2010

Labels: Milestone:1.0

Comment 4 by Thomas Keller, Jan 9, 2011

Status: Started
Owner: tommyd

Comment 5 by Thomas Keller, Jan 9, 2011

Fixed in rev 01dce6f01b4958850742305cebf0937bf57d0d97

Status: Fixed