Thomas, that sounds like a different issue... what happens is that administrator::reload_conffile is called (it calls administrator::initialize, which gives you that error message), and as far as I can tell from the source, that only happens when usher gets a SIGHUP.
This works fine for me with "-v" enabled, though I get a different problem here (not sure if this is related or not, it might also be something OSX specific): If I kill and start a specific server instance through the admin interface shortly after another, the admin interface hangs and usher issues two times Could not initialize admin port: cannot bind to address: Address already in use If I debug with gdb into usher, I only get back #0 0x00007fff85064e52 in select$DARWIN_EXTSN () #1 0x000000010001f157 in main (argc=2, argv=0x7fff5fbff730) at src/usher.cc:160 and if I continue and break a little later, I get #0 0x00007fff8509ee72 in accept () #1 0x000000010001e092 in sock::accept (this=<value temporarily unavailable, due to optimizations>) at src/sock.cc:52 #2 0x000000010001f565 in main (argc=2, argv=0x7fff5fbff730) at src/usher.cc:170 The temporary solution for me is now to add a little time frame between the stop and the restart. 2 seconds helped in my case.
I'd suggest trying on revision 1336ca3b4c1b316eeeec33f333f7506dcc40a858 and see if that makes life better...
This issue has really been around for some time, just not addressed before now. I just has a look at the code, and I believe it should be possible to remove all the code that looks for "beginning service", and instead add some code in server::connect that loops around sock::connect as long as the monotone server that was just forked is still up. Something like that... I'll experiment a bit and see what I can come up with.Status: Started
Steps to reproduce the problem: 1. Add a print statement to your rcfile "print('hello out there') 2. Start usher such that that rcfile will load 3. Attempt to sync with usher Expected result: Ideally: usher forks monotone and sync begins. Less ideally: usher reports somewhere, anywhere that the output "hello out there" is not the expected "beginning service" Actual result: "Received warning from usher: Cannot fork server." This is caused by server::fork checking only the first line for 'beginning service' based on the commented assumption that otherwise monotone's stderr is reporting that it failed to launch. A side effect of this is that adding -v to the monotone args will also silently crash Usher.
Because the stdio version of monotone-viz was far too slow for our work db (older direct access one would take say 10 seconds for a given query, new stdio one would take 2-3 minutes). I am currently working on a similar facility in mtn-browse. The critical thing being that if I couldn't match the performance of the old version then there's no point. Anyway I managed it. Also trying to get a list of unsuspended branches can be very slow (when there are a large number say ~1500) and one usually ends up using the --ignore-suspended switch. mtn-browse had to offer this feature for performance reasons (50 seconds vs 1). The key point is to keep the stdio stuff to a minimum couple of selects along the lines of l6:selectN:b:BRANCH/l:DATE/e:DATE and then do as much work as possible in the app at the expense of memory as stdio is the bottleneck. Also when should a suspended branch be shown? Never not even if it at some point was merged into another unsuspended branch? What about date ranges cropping the suspended head revisions? All adds to complexity and performance overhead. What is unavoidable is at some point you have to get the certs for those revisions you display (e.g. what about branch/author colouring?). At that point you could determine what selected branches have a suspend cert on any of their revisions being graphed and then act accordingly (i.e. highlight in some way or exclude). This is by no means ideal but does have explainable logic behind it. I.e. suspended revisions are displayed if at that point in the graph they weren't suspended...?
Shouldn't something like this work: mtn au select 'l:DATE/e:DATE/(ancestors(h:*)|h:*)' - it does for the little test case. (Interestingly, if one commutes the expression like this: mtn au select '(ancestors(h:*)|h:*)/l:DATE/e:DATE' mtn complains about an unmatched paren, and that seems like a bug in monotone.)
The fault is really in how it's called... I've had a look at what mtn-viz does when it tries to figure things out. It seems that it selects revisions like this: l6:selectN:b:BRANCH/l:DATE/e:DATE That one will return anything that is in said branch within those dates, and doesn't care about the suspend cert (it wouldn't matter much, if it did, we would simply not see the suspended revisions, but would still see the revisions in that same branch that aren't suspended). It's quite possible that monotone-viz should do it a bit more work, I'm imagining something corresponding to the following: for b in `mtn automate branches`; do for r in `mtn automate heads $b; do mtn select "ancestors($r)/l:DATE/e:DATE" done done ... except it seems that composite selectors don't quite work that way for now (perhaps it's a bug in monotone?).
Ah-hah! You're quite right, in the most normal case... I guess I've stumbled on a special case, which can be reproduced like this: cd /tmp mtn -d foo.mtn db init mtn -d foo.mtn setup foo -b foo cd foo echo a > a; mtn add a; mtn ci -m a a echo b >> a; mtn ci -m a a mtn suspend w: cd .. mtn -d foo.mtn setup foo2 -b foo cd foo2 echo c > c; mtn add c; mtn ci -m c c echo d >> c; mtn ci -m c c mtn-viz Presto, you get to see both lines of development (both in branch foo), even though one of them is suspended. My personal setup is that I basically had to redo a series of commits as a branch of another project instead of a standalone branch, then suspended the standalone branch... needless to say, it's a little irritating to still see it in mtn-viz
Are you sure you've got that the right way round? Running monotone-viz, I can't enable viewing of any suspended branches since they don't appear. This is far more annoying since after I've merged and suspended a branch, I can't view its history in monotone-viz.
*bump (for email)*
*bump (for email)*
Steps to reproduce the problem: 1. cd YourFavoriteWorkspace 2. run monotone-viz 3. press "Refresh" Expected result: A refresh of the display Actual result: The monotone-viz windows disappears, and the following is displayed in the terminal window: The program 'monotone-viz' received an X Window System error. This probably reflects a bug in the program. The error was 'BadWindow (invalid Window parameter)'. (Details: serial 4912 error_code 3 request_code 10 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) I tried it in ocamldebug, and could get the following: Lost connection with process 20527 (active process) between time 4010000 and time 4020000 Restart from time 4010000 and try to get closer of the problem ? (y or n) y ... Time : 4012418 - pc : 755344 - module View 787 s.w#set_default_response `VIEW<|a|> ; (ocd) bt Backtrace: #0 Pc : 755344 View char 23605 #1 Pc : 787712 App char 3875 (Encountered a function with no debugging information) The monotone-viz that I did this with is revision c3fdb3af1c7c89989c7da8062bb62203f2aaccf0
Since monotone-viz was last hacked at, monotone got the 'suspend' feature. Unfortunately, monotone-viz doesn't handle it at all, as far as I can see, and will happily show branches where the head revision is suspended. I'd very much like to see a change where lines of development with head being suspended aren't shown. The selection dialog could have a checkbox where one could choose if one would like to see the suspended lines of development or not...