Re: [Monotone-devel] Suggestions

[graydon hoare]

Tom Tromey <address@hidden> writes:

> I played with monotone a little this morning.  I managed to
> successfully import an automake tree.

neat. I should point out that my experiments with RCS importing have
given me a lot of reason to doubt the storage layer I shipped with the
first monotone release; its integrity seems OK but its efficiency is
crap. the version of librsync in there has a checksum mis-calculation
bug which means its reverse deltas are usually "the whole file". sigh.

anyways, I've got a fixed (bootleg) librsync here, I just want to
track down the precise state of development from mbp and run some more
profiling of large RCS imports to see if I can find more speed
problems, then I'll do another release.

> Monotone could search up the directory tree looking for "MT", but
> then only work on the appropriate subdirectory of the tree.

yeah, I wanted this behavior too, just never got around to
implementing it. patch welcome :)

> Having MT_BRANCH and MT_DB in the environment is a bit unfriendly.
> This is something that has always plagued CVS.  With CVS, if you use
> multiple repositories, you may have to switch CVS_RSH back and forth
> when switching tasks.  It would be much nicer if this info was
> stored in the MT directory.

funny you mention this. at first I didn't have such a thing, then bje
asked for it as a way to switch a particular shell session to a
different branch or database. he said this:

 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.

I'm of mixed feelings, but I tend to think the "lua file stored in
MT/" is a better approach, yeah. it's more often the case that you
reflect the state of your work in the filesystem, such as 2 different
working copies in different directories. you want changing directories
to change some settings. and anyways a cron job can always override
things with explicit command-line flags, without much usability
impact.

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

-graydon