Bug 213893 - regenerate_rosters called unconditionally
regenerate_rosters called unconditionally
Product: Fedora
Classification: Fedora
Component: monotone (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Roland McGrath
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2006-11-03 12:04 EST by Thomas Moschny
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 0.35-3.fc6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-05-24 17:41:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Thomas Moschny 2006-11-03 12:04:19 EST
Description of problem:
`service monotone start' always calls `mtn db regenerate_rosters', regardless 
of whether needed or not.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. /etc/init.d/monotone stop
2. /etc/init.d/monotone start
Actual results:
#/etc/init.d/monotone stop
Stopping monotone server:                                  [  OK  ]
#/etc/init.d/monotone start
Checking database format in /var/db/monotone/server.mtn:
mtn: calculating necessary migration steps
mtn: no migration performed; database schema already up-to-date at 
mtn: regenerating cached rosters
mtn: calculating rosters to regenerate
mtn: regenerated
mtn:     379/379

Additional info:
Calling regenerate_rosters doesn't harm, but can take a long time if the 
repository contains many revisions, so should not be called unconditionally. 
It would be better to inspect the output of `mtn db migrate', as mtn will tell 
the user whether running needed regenerate_rosters is needed. For this to 
work, LC_MESSAGES has to be set to en_US or C prior to calling mtn, however.

Note also that the rc for `mtn db migrate' is null in case no schema migration 
is needed.
Comment 1 Thomas Moschny 2007-03-02 05:45:56 EST
The problem persists with monotone-server-0.32-1.fc6.
Comment 2 Thomas Moschny 2007-03-05 06:39:13 EST
And while it is nice to see the new package so fast after release of 0.33, the problem 
is still there in monotone-server-0.33-1.fc6.
Comment 3 Thomas Moschny 2007-04-12 03:01:48 EDT
Still the same behavior with monotone-server-0.34-1.fc6.

What about a construct like this:
  ( LC_MESSAGES=C mtn db version | grep 'needs migration' ) > /dev/null &&
  mtn db migrate && mtn db regenerate_caches

Or, if you don't like the LC_MESSAGES thing, you could explicitly grep for the 
database schema:
  ( mtn db version | grep -v 7ca81b45279403419581d7fde31ed888a80bd34e ) 
> /dev/null &&
  mtn db migrate && mtn db regenerate_caches
but then you'd have to adjust the schema from time to time in the init file.
Comment 4 Roland McGrath 2007-05-15 17:15:26 EDT
I did a hack in the init.d script for 0.35-2, please try that.
It worked ok for me, though the needs-migration case hasn't actually been tested.
Comment 5 Thomas Moschny 2007-05-16 17:10:11 EDT
The hack doesn't work with LANG="de_DE.UTF-8" in /etc/sysconfig/i18n, because 
mtn's output is localized, and grep'ing for some expected (English) output 
will fail.

You should either set LC_MESSAGES to "C", or grep for the expected schema 
version, see above.

Comment 6 Roland McGrath 2007-05-16 23:06:13 EDT
Should be fixed in monotone-0.35-3.fc6
Comment 7 Thomas Moschny 2007-05-17 04:13:43 EDT
(In reply to comment #6)
> Should be fixed in monotone-0.35-3.fc6

Seems to work. 

However, I really don't see why you set LC_ALL, when the test in fact only 
needs  LC_MESSAGES. Although this doesn't seem to do any harmful here, LC_ALL 
also overrides LC_CTYPE, so affects the way in which file system paths are 
interpreted, and you clearly don't want to change that for the test.
Comment 8 Roland McGrath 2007-05-24 17:41:00 EDT
LC_CTYPE has no effect on file names.  Setting LC_MESSAGES with the wrong
LC_CTYPE can break display in sufficiently strange circumstances.  

Note You need to log in before you can comment on or make changes to this bug.