Re: [Monotone-devel] Suggestions

[graydon hoare]

Tom Tromey <address@hidden> writes:

> graydon> yeah, I wanted this behavior too, just never got around to
> graydon> implementing it. patch welcome :)
> 
> My play time is really limited, this week in particular.  I'd send a
> patch or two (not this, probably), except building it would suck up
> all available hours...

yeah, unfortunately still true. that's the other trick: I want to put
RPMs up on the webpage which are the exact set of headers and binary
libraries I'm developing against. I've got one for sqlite, nana
(patched), and boost. need to finish decent librsync and cryptopp
RPMs, and decide what to do with the necessary bits of boost.sandbox.

> Environment variables are ok as overrides, but not requirements.

well, my cocnern about many ways of specifying options is that it becomes
unclear which one overrides which other one. I think the layering should
be something like:

- builtins (monotone has a lua file objcopied into it)
- ~/.monotonerc
- MT/settings.lua
- $ENV
- command line

in increasing order of overridey-ness; but I feel there's a chance
you'd miss-guess that order and get a surprise, so I might prefer to
kick out $ENV if we're going to adopt MT/settings.lua.

> It might be nice to be able to specify the default signer for commits
> per-workspace as well.  Then in a scratch tree I can commit as a
> relatively-untrusted user and then later promote the patch when it is
> done.  (This is just a guess at one way of working, since obviously I
> haven't used monotone "in anger" yet.)  Maybe there's already a lua
> hook for this; I haven't looked at this part thoroughly.

eh.. I think there's already a hook which takes a branch name and
returns a key ID, yeah. that might not be enough. anyways, I certainly
agree with making that use-case easy.

> That seems needed regardless.  For gcc, the current CVS database is
> 1.2G.  Now, with monotone and a nice pruning tool I would probably
> keep a lot less than that around.  But I wouldn't want to keep one
> database per working tree -- I currently have 4 gcc trees around
> (trunk, 3.3, tree-ssa, and a pristine nightly build tree), and I know
> some other gcc folks keep more than that.  

oh, I don't mean that; you can certainly work on 4 working copies from
1 database. what I mean is that 4 concurrent monotone processes (or
any more than 1, really) cannot safely *simultaneously* access the
same database or working copy. they don't do locking to avoid stepping
on each other's feet. transactions are atomic, but the DB / working
copy is not locked during the transaction. so it's not really safe to
be cronning or procmailing against a database you're using for work,
just yet.

-graydon