Re: [Monotone-devel] commit ignores _MTN/options keydir

[Stephen Leake]

Derek Scherger <address@hidden> writes:

> Stephen Leake wrote:
>> I've discovered that commit ignores _MTN/options keydir; I think this
>> is a bug.
>> If I specify a keydir other than the default with 'mtn setup
>> --keydir',
>> then later do 'mtn commit' _without_ the --keydir option, the commit
>> fails with: mtn: fatal: std::logic_error:
>> ../monotone/key_store.cc:168: invariant 'I(i != keys.end())'
>> violated
>> even though the correct keydir is specified in _MTN/options.
>> This isn't noticed in the test suite because that always specifies
>> --keydir on all mtn commands.
>> If this is a bug, I'll create a test for it, and try to fix it.
>
> It's very likely a bug.
>
> I committed a change yesterday that sets a default value for the
> --keydir option for non-workspace commands (CMD_NO_WORKSPACE) in rev
> 65ac5a3fda02533e30468090f63f82e3674cac73. This prevents hitting
> another invariant on an empty key directory (i.e. the keydir name is
> "") also in the key_store. 

That makes sense. 

> Unfortunately, this "fix" also seems to trigger another invariant in
> workspace::get_ws_options (work.cc:454) I(opts.key_dir.empty())'
> which requires that there is no default keydir.

I think deleting that invariant check is the best fix. There is
nothing the in contract for get_ws_options that says 'opts' must be
empty before it is called; it just overrides the values in opts that
come from the _MTN/options file.

Although that's not true for the branchname. Perhaps there needs to be
an 'opts.branch_given' flag?

Deleting the similar check in dbname also makes sense.

The default key_dir is set in options_list.hh; it is set for _all_
commands, not just those that don't require a workspace. I think that
makes sense; that's what "default" means, after all - the value
something should have if not otherwise specified.

However, there's something basic I don't understand about the key
directory.

As I understand it, the public and private keys are stored in the
database. So why do we also require a key directory?

What is the use case for changing key_dirs after keys are entered into
a database?

Assuming we truly need a key_dir, it seems to me it should only be
specified when creating a workspace, not on subsequent commands that
use a workspace. What is the use case for overriding the key_dir when
working with an existing workspace?

I need to specify the key_dir so the Cygwin and native Win32 mtns use
the same key_dir (they have different defaults); that only needs to be
done when creating the workspace.
 
--
-- Stephe