[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] usher
From: |
Thomas Keller |
Subject: |
Re: [Monotone-devel] usher |
Date: |
Thu, 15 Apr 2010 13:33:43 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.1.8) Gecko/20100228 SUSE/3.0.3-1.1.1 Lightning/1.0b2pre Thunderbird/3.0.3 |
Am 15.04.2010 09:13, schrieb Thomas Keller:
> Am 15.04.2010 04:50, schrieb Timothy Brownawell:
>>> Maybe there is a third way, which would require changes in monotone
>>> though: what about picking the database / server to use for netsync
>>> directly from the client? I vaguely remember that we introduced an URL
>>> schema in monotone a couple of versions ago (0.40 or so) and while its
>>> nowhere documented beside in NEWS (not even functional in 0.47 for me
>>> anymore, I get a network error "service name resolution failed for:
>>> mtn", but the lua test still seems to run through),
>>
>> Huh, that's not good.
>>
>> ...I don't get that error, but it's treating the whole thing as the
>> pattern instead of parsing it out. Different behavior, maybe something's
>> uninitialized? Something more to look at, I guess...
>
> I haven't looked into that any further, but I'm putting that on my
> agenda. Especially since the unit tests still seem to run through this
> might as well be some kind of weird local / shell error (I'm using zsh
> here).
I played around with it 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.
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
- [Monotone-devel] usher, Thomas Keller, 2010/04/13
- Re: [Monotone-devel] usher, Timothy Brownawell, 2010/04/13
- Re: [Monotone-devel] usher, Thomas Keller, 2010/04/14
- Re: [Monotone-devel] usher, Timothy Brownawell, 2010/04/14
- Re: [Monotone-devel] usher, Thomas Keller, 2010/04/15
- Re: [Monotone-devel] usher,
Thomas Keller <=
- netsync connection info cleanup Was: Re: [Monotone-devel] usher, Thomas Keller, 2010/04/15
- Re: netsync connection info cleanup Was: Re: [Monotone-devel] usher, Timothy Brownawell, 2010/04/17
- [Monotone-devel] Re: netsync connection info cleanup, Thomas Keller, 2010/04/18
- Re: [Monotone-devel] Re: netsync connection info cleanup, Zack Weinberg, 2010/04/18
- Re: [Monotone-devel] Re: netsync connection info cleanup, Thomas Keller, 2010/04/18
- [Monotone-devel] Re: netsync connection info cleanup, Timothy Brownawell, 2010/04/27
- Re: [Monotone-devel] Re: netsync connection info cleanup, Zack Weinberg, 2010/04/27
- Re: [Monotone-devel] Re: netsync connection info cleanup, Timothy Brownawell, 2010/04/27
- Re: [Monotone-devel] Re: netsync connection info cleanup, Thomas Keller, 2010/04/28
- Re: [Monotone-devel] Re: netsync connection info cleanup, Derek Scherger, 2010/04/28