Due to an outage of our old server yesterday, we’ve been forced to switch monotone’s main site, wiki, documentation and the remaining infrastructure earlier than expected to the new server. While not every automatism is in place for the new server, we think that it is actually already usable and decided to not switch back to the old one.
This has one important implication though: The monotone instance running on the new server does no longer allow connections without a path, i.e. pulling like this
$ mtn pull ‘montone.ca’ ‘net.venge.monotone’
will fail. Instead, you have to use a slightly changed URI syntax for monotone clients up to 0.48:
$ mtn pull ‘mtn://monotone.ca/monotone’ \
‘net.venge.monotone’
or, if `mtn` is not in your `/etc/services` and you cannot add
mtn 4691/tcp # Monotone Network Protocol
mtn 4691/udp # Monotone Network Protocol
to it either, use
$ mtn pull ‘monotone://monotone.ca/monotone’ \
‘net.venge.monotone’
because there are a couple of URI parsing bugs in this version which prevent an action with the standard URI syntax unfortunately.
If you don’t want to go through this hassle, you’re also free to push / pull just from the now back-to-life old server:
$ mtn pull ‘old.monotone.ca’ ‘net.venge.monotone’
The **leading server** is however the new one and since both aren’t yet synchronized, it might take a little longer until we see changes which are only pushed to the old one.
Please also note that the new monotone instance separates projects from each other, so if you don’t find a branch at the monotone instance, you might want to try a different one. A list of projects and all of their served branches is available via code.monotone.ca: select a project and click the “Source” tab, you’ll see the branches then listed on the left.
If you are a monotone committer, ensure that you also **do not push unrelated branches** into project databases which do not belong there. (It has proven to be helpful to use different local databases for different projects…) We have no way of enforcing that on the server level as of now, but are working on a solution.
Thanks for reading!
Why UDP?
Also, seems to me that some ‘nvm{,.}’ branches are in different projects now (as whey should be).
Is there an easy way to have a “new” ‘nvm{,.}’ local database without pulling it from scratch?
Because it is already listed in /etc/services and while we do not use it, it makes no harm to have it there either (maybe for the future :)).
The only viable alternative I came up with was scripting something, i.e. find out the root revision of nvm, get a list of local branches (including suspended ones), calculate the common ancestors of ([root-rev], [h:branch]) and skip the branch if no common ancestors are returned. Then, build one giant pull pattern out of all the individual branches and pull them locally from the old into the new database.