Re: [Monotone-devel] Light The Touch Paper And RUN! :-)

[Thomas Keller]

Hi Anthony!

>    A small question. Why is monotone at version 0.42 (listed as alpha on
> freshmeat)? I know that development is ongoing and all that. But what is
> there now (bar that little bugget to do with select that reports errors
> on syncing), is VERY stable. In fact dare I say, more stable than some
> other similar products that have been released for some time.

Well, the alpha state could probably be removed on the next release on
freshmeat, you're of course right, monotone is pretty stable.

>    Would it not be an idea to have a bug fix only release and release it
> at 1.0? I have a nasty feeling that other systems are going to get more
> widely adopted just because of a release number...

The reason why we haven't announced anything so far 1.0 is because there
are several long-standing issues unresolved of which most of us think
should be resolved before 1.0 lands: partial pull, database locking and
improvements in the authentication / distribution rights management
comes into my mind.

>    On another completely different point. I heard rumours about a
> locking issue when using mtn au and syncing. Is this still an issue (I
> haven't had any issues myself with 0.42)?

`mtn serve` locks the database even if no client is reading or writing
data. The issue we have underknees is that we don't allow multiple
concurrent readers.

>    If there are issues with mtn au keeping the database open, then this
> may have been related to a request by me to make things go faster when
> using mtn au get_content_changed (slowed right down in 0.40 and 0.41). I
> believe that db context is now left open between au commands.

No, the database was opened before as well, because we wanted to let
stdio fail early if there is some problem with opening / reading from
it. The fix you're mentioned actually only introduces a shared pointer
so we _reuse_ the opened database handle instead of throwing it away
after each command.

>    As I said, 0.42 is fine performance wise and I have had no issues
> with locking myself. It's just that a friend of mine has been using mtn
> trac and setting that up and apparently that has an issue. Sorry if this
> is out of date info or wrong....

Thats exactly the locking issue I talked about earlier: People want to
commit to the same repository and have some web frontend reading fresh
commits / details from it.

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature