Re: [Monotone-devel] Suggestions

[Tom Tromey]

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

bje> The nice thing about using environment variables is that you can
bje> set temporary ones, whereas if you modify .monotonerc, you upset
bje> other instances, possibly running from cron.

graydon> I'm of mixed feelings, but I tend to think the "lua file stored in
graydon> MT/" is a better approach, yeah.

Environment variables are ok as overrides, but not requirements.

Putting lua code in MT/ would address bje's problem as well.  I agree
with him -- having everything in ~/.monotonerc is also a pain, since
you would end up constantly updating it.

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.

graydon> and, er.. at the moment (possibly for some time yet) there isn't
graydon> really any safety support for multiple processes diddling the same
graydon> database or working copy anyways. it's sort of intended to be a user
graydon> tool, not a "system" tool. I guess we'll need some locking junk if
graydon> we're to support running from procmail rules though.

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.  

Tom