Am 15.04.2010 13:33, schrieb Thomas Keller:
I played around with [mtn://-style uris] further, there are a couple of serious
bugs in
this feature. Apparently the uri scheme only works if a port (and may it
only be the standard port 4691) is given and thats also the reason why
the tests don't alert the problem, becase they always run a local mtn
instance on the non-standard port.
Furthermore, known-servers gets the complete URI instead of just the
hostname set when the mtn uri is used:
known-servers: mtn://guitone.thomaskeller.biz:4691
f814415176bf04178c64895b19ef99752159626d
known-servers:
mtn://guitone.thomaskeller.biz:4691?include=net.venge.monotone.guitone
f814415176bf04178c64895b19ef99752159626d
This leads to new entries each time the branch pattern changes only
slightly and means also that the user is alerted of a "new server" each
time.
I don't had the time yet to debug this further, I only re-assured that
parse_uri() itself doesn't seem to be the problem, because port-less
URIs are tested there and the test succeeds.
I started a new branch (net.venge.monotone.connection_info_cleanup)
where I tried to fix some of the issues. mtn://server-style URIs with no
port should work already, also the known-servers problem has been fixed.
However there is a bug in our parse_uri() implementation: If no scheme
(f.e. mtn://) is given, it treats the string as path rather than as
hostname. This leads to the problem that the scheme-less default server
setting we store in the db vars is not treated correctly and that a host
which is entered by the user is now also parsed wrongly.
As I said, I'd rather change the implementation of parse_uri than
forcing the user to pull "mtn://monotone.ca" instead of just
"monotone.ca"...