Re: [Monotone-devel] Re: About the maintainance of monotone
Hello monotoners, Shaun, this is Tomas Fasth pinging the monotone world. I am very sorry for having been absent for such a long time, but I have been busy recovering from a minor stroke. I have been suggesting Shaun to take over the maintainership of the monotone package in Debian, since I do not any longer have the capacity to do the task. Keep on with your excellent work and contribution to the open source community!RegardsTomas FasthOn 20/04/06, Shaun Jackman [EMAIL PROTECTED] wrote:On 4/18/06, Shaun Jackman [EMAIL PROTECTED] wrote: After fixing these minor issues, the NMU package would be suitable for uploading. Would anyone like to first test it out? I've posted my monotone 0.25-0.1 packages: http://people.debian.org/~sjackman/debian/pool/main/m/monotone/I've uploaded monotone 0.25-0.1 to the delayed 7-day queue. Without intervention from the maintainer, it will move to Debian's masterqueue in seven days.I've also uploaded monotone 0.26-0.1 to people.debian.org/~sjackman. I have *not* tested this binary, because I have not yet made the move torosters. Once I have, I'll post my experience and upload 0.26-0.1 tothe delayed 7-day queue.Cheers,Shaun___ Monotone-devel mailing listMonotone-devel@nongnu.orghttp://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: About the maintainance of monotone
On 13/05/06, Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED] on Sat, 13 May 2006 10:33:29 +0200, Tomas Fasth [EMAIL PROTECTED] said:tomfado ... I have been busy recovering from a minor stroke.Oh man, I'm sorry to hear you had such an experience!Are you wellnow, or still recovering? Thanks for caring, Richard. I'm basically okay. I was very lucky, got to the hospital in less than 20 minutes. The more permanent remaining effects of this traumatic event is a partial loss of sense in the left side of my body, an always present sense of dizziness, and an inability to focus on a task for an extended amount of time. Other than that, I am functioning as before. However, it has changed my priorities in life, of course. tomfado since I do not any longer have the capacity to do the task. Best wishes, and thanks for all you did!Thanks, best wishes to you as well!Tomas Fasth ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Instructions to compile usher?
Hi. It seems that there are no instructions to compile Usher. I have used autotools for a few projects already, but can't figure out how to compile usher. What is the method I should use? Thanks, J. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Instructions to compile usher?
On Sat, 2006-05-13 at 07:33 -0300, Jeronimo Pellegrini wrote: Hi. It seems that there are no instructions to compile Usher. I have used autotools for a few projects already, but can't figure out how to compile usher. What is the method I should use? Which one? There's the (old) single-file version in contrib/ in the monotone source tree, where you do g++ contrib/usher.cc -o usher. There's also the version in net.venge.monotone.contrib.usher, which uses autotools. For that one, you run the appropriate autotools magic (something that seems to work is in ./bootstrap), then ./configure and make. Tim ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Instructions to compile usher?
On Sat, May 13, 2006 at 06:26:46AM -0500, Timothy Brownawell wrote: On Sat, 2006-05-13 at 07:33 -0300, Jeronimo Pellegrini wrote: Hi. It seems that there are no instructions to compile Usher. I have used autotools for a few projects already, but can't figure out how to compile usher. What is the method I should use? Which one? There's the (old) single-file version in contrib/ in the monotone source tree, where you do g++ contrib/usher.cc -o usher. There's also the version in net.venge.monotone.contrib.usher, which uses autotools. For that one, you run the appropriate autotools magic (something that seems to work is in ./bootstrap), then ./configure and make. Hm, I didn't know about bootstrap. I was never really an autotools fan (too much complexity just to get thing to compile :-) Anyway -- thanks! J. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Usher not easily found? Was: Re: [Monotone-devel] Instructions to compile usher?
On Sat, May 13, 2006 at 06:26:46AM -0500, Timothy Brownawell wrote: There's also the version in net.venge.monotone.contrib.usher, which uses autotools. For that one, you run the appropriate autotools magic (something that seems to work is in ./bootstrap), then ./configure and make. BTW, shouldn't this be on the Wiki at net.venge.monotone? There is a list of tools there, but nothing about usher. I only knew about usher when I heard people talking about it here in this list. J. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Instructions to compile usher?
On Sat, 2006-05-13 at 08:28 -0300, Jeronimo Pellegrini wrote: On Sat, May 13, 2006 at 06:26:46AM -0500, Timothy Brownawell wrote: On Sat, 2006-05-13 at 07:33 -0300, Jeronimo Pellegrini wrote: Hi. It seems that there are no instructions to compile Usher. I have used autotools for a few projects already, but can't figure out how to compile usher. What is the method I should use? Which one? There's the (old) single-file version in contrib/ in the monotone source tree, where you do g++ contrib/usher.cc -o usher. There's also the version in net.venge.monotone.contrib.usher, which uses autotools. For that one, you run the appropriate autotools magic (something that seems to work is in ./bootstrap), then ./configure and make. Hm, I didn't know about bootstrap. I was never really an autotools fan (too much complexity just to get thing to compile :-) Eh, it's not anything standard. I just put it there so I don't have to go look up what commands to use to get things started. Tim ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Usher not easily found? Was: Re: [Monotone-devel] Instructions to compile usher?
On Sat, 2006-05-13 at 08:40 -0300, Jeronimo Pellegrini wrote: On Sat, May 13, 2006 at 06:26:46AM -0500, Timothy Brownawell wrote: There's also the version in net.venge.monotone.contrib.usher, which uses autotools. For that one, you run the appropriate autotools magic (something that seems to work is in ./bootstrap), then ./configure and make. BTW, shouldn't this be on the Wiki at net.venge.monotone? There is a list of tools there, but nothing about usher. I only knew about usher when I heard people talking about it here in this list. It seems to be in there now... Tim ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] limited-scope annotate
Would it be possible to implement a --from-revision or --last option in annotate in order to find the revision that altered each line only if in the examined range and printing past or something in the lines not changed since the first revision examined? I guess, if possible at all, this would be much faster than a full annotate and would be much faster if releases are decently close one another? The original problem that led me to think about this is: trunk monotone seems to be broken on Cygwin (see below) while 0.26 compiled perfectly. I did a mtn diff -r t:monotone-0.26 xdelta.cc but the changed lines were many and moreover line 79 cited in the error was not changed, so usually I would have used annotate to see, but it is too slow to be usable (though I guess I'll take some tea+biscuits and launch it in the meantime). In this case, were I know the exact range the problem appeared, a limited-rage-annotate would be quite enough and most probably much faster than a full one. Please note the question is only is it possible (and how difficult it would be), not a request to do it ,-) (if the second answer is easy I may well consider it for a bite-sized approach at monotone's sources myself...) - if g++ -DLOCALEDIR=\/usr/local/share/locale\ -DHAVE_CONFIG_H -I. -I. -I. -I./lua -I./sqlite -DNDEBUG -DBOOST_DISABLE_THREADS -DBOOST_SP_DISABLE_THREADS -I/usr/include/boost-1_33_1/ -fno-strict-aliasing -Wall -W -Wno-unused -MT mtn-xdelta.o -MD -MP -MF .deps/mtn-xdelta.Tpo -c -o mtn-xdelta.o `test -f 'xdelta.cc' || echo './'`xdelta.cc; \ then mv -f .deps/mtn-xdelta.Tpo .deps/mtn-xdelta.Po; else rm -f .deps/mtn-xdelta.Tpo; exit 1; fi /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/ext/hashtable.h: In member function `size_t __gnu_cxx::hashtable_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc::_M_bkt_num_key(const _Key, size_t) const [with _Val = std::pairconst u32, extent, _Key = u32, _HashFcn = hashmap::hashu32, _ExtractKey = std::_Select1ststd::pairconst u32, extent , _EqualKey = hashmap::equal_tou32, _Alloc = std::allocatorextent]': /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/ext/hashtable.h:508: instantiated from `size_t __gnu_cxx::hashtable_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc::_M_bkt_num_key(const _Key) const [with _Val = std::pairconst u32, extent, _Key = u32, _HashFcn = hashmap::hashu32, _ExtractKey = std::_Select1ststd::pairconst u32, extent , _EqualKey = hashmap::equal_tou32, _Alloc = std::allocatorextent]' /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/ext/hashtable.h:447: instantiated from `__gnu_cxx::_Hashtable_iterator_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc __gnu_cxx::hashtable_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc::find(const _Key) [with _Val = std::pairconst u32, extent, _Key = u32, _HashFcn = hashmap::hashu32, _ExtractKey = std::_Select1ststd::pairconst u32, extent , _EqualKey = hashmap::equal_tou32, _Alloc = std::allocatorextent]' /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/ext/hash_map:176: instantiated from `typename __gnu_cxx::hashtablestd::pairconst _Key, _Tp, _Key, _HashFcn, std::_Select1ststd::pairconst _Key, _Tp , _EqualKey, _Alloc::iterator __gnu_cxx::hash_map_Key, _Tp, _HashFcn, _EqualKey, _Alloc::find(const typename __gnu_cxx::hashtablestd::pairconst _Key, _Tp, _Key, _HashFcn, std::_Select1ststd::pairconst _Key, _Tp , _EqualKey, _Alloc::key_type) [with _Key = u32, _Tp = extent, _HashFcn = hashmap::hashu32, _EqualKey = hashmap::equal_tou32, _Alloc = std::allocatorextent]' xdelta.cc:79: instantiated from here /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/ext/hashtable.h:518: error: no match for call to `(const hashmap::hashu32) (const long unsigned int)' -- Lapo Luchini [EMAIL PROTECTED] (OpenPGP X.509) www.lapo.it (Jabber, ICQ, MSN) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Usher crashes
Hi.
I just compiled usher, and started it:
$ ./usher -m mtn -kmy_key -a 127.0.0.1:1 usher.cfg
usher.cfg has the following:
userpass jp no_I_wont_tell_you
server phd
host localhost
pattern info.aleph0.phd*
local -d /home/jeronimo/monotone/phd.db
server main
host localhost
pattern info.aleph0.*
local -d /home/jeronimo/monotone/main.db
=
I hope that matching first info.aleph0.phd* and later info.aleph0.*
is not a problem...
OK, so I did:
=
$ telnet localhost 1
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
LIST
main phd
Connection closed by foreign host.
$ telnet localhost 1
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
STATUS main
SLEEPING
Connection closed by foreign host.
==
OK, everything is there, and usher is running.
Now, from another host:
==
$ mtn push rumi
mtn: connecting to rumi
mtn: error: I/O failure while talking to peer rumi, disconnecting
==
And at rumi, who is running usher:
==
Segmentation fault
==
I ran usher under gdb (the same command line options were passed), and got this:
=
Program received signal SIGSEGV, Segmentation fault.
server_manager::prefix::cmp (this=0xbfffeffc, [EMAIL PROTECTED]) at
basic_string.h:269
269 { return ((reinterpret_cast_Rep* (_M_data()))[-1]); }
(gdb) where
#0 server_manager::prefix::cmp (this=0xbfffeffc, [EMAIL PROTECTED]) at
basic_string.h:269
#1 0x0805cee3 in server_manager::prefix::operator== (this=0xbfffeffc, [EMAIL
PROTECTED]) at server_manager.cc:55
#2 0x0806041f in server_manager::connect_to_server (this=0xbfffefd0, [EMAIL
PROTECTED], [EMAIL PROTECTED]) at stl_tree.h:176
#3 0x08056421 in channel::process_selected (this=0x8081810, [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]) at channel.cc:101
#4 0x080675a9 in main (argc=6, argv=0x8081808) at stl_list.h:135
==
Also, I noticed that usher will start and pretend that everything is OK,
even if one of the local databases does not exist. Maybe the server
could exit with an error, or at least issue a warning?
Thanks,
J.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Usher crashes
Also... I just realized from the email I sent that usher is also not requiring the USERPASS command befor LIST and STATUS, and probably before any other command. Also, I tried to use a wrong username and password, and usher did not close the connection. J. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Usher crashes
On Sat, 2006-05-13 at 12:22 -0300, Jeronimo Pellegrini wrote:
Hi.
I just compiled usher, and started it:
$ ./usher -m mtn -kmy_key -a 127.0.0.1:1 usher.cfg
It treats the -m argument as an executable name, not a command line. So
it'll be looking for an execuable named mtn -kmy_key, not looking for
an execuable named mtn and giving the -kmy_key argument. Really I
should probably replace this argument with a line in the config file,
which could allow for this.
usher.cfg has the following:
userpass jp no_I_wont_tell_you
server phd
host localhost
pattern info.aleph0.phd*
local -d /home/jeronimo/monotone/phd.db
server main
host localhost
pattern info.aleph0.*
local -d /home/jeronimo/monotone/main.db
=
I hope that matching first info.aleph0.phd* and later info.aleph0.*
is not a problem...
I see it needs better documentation.
It finds a matching server by first looking for one with a correct
'host' line. If there isn't a matching host line, then it looks for a
matching 'pattern' line.
The 'host' line is matched as a prefix of the hostname that the client
is given to talk to, and the 'pattern' line is matched as a prefix of
the include pattern. In each case, it takes the longest one that
matches.
Note that the 'pattern' line is a string prefix of the include pattern,
not a glob.
Also, you still have to provide the pattern argument that the serve
command requires in the 'local' line. And since it sounds like this
argument is going away soon, I'm not going to have it try to guess it.
Now, from another host:
==
$ mtn push rumi
mtn: connecting to rumi
mtn: error: I/O failure while talking to peer rumi, disconnecting
==
And at rumi, who is running usher:
==
Segmentation fault
==
I ran usher under gdb (the same command line options were passed), and got
this:
=
Program received signal SIGSEGV, Segmentation fault.
server_manager::prefix::cmp (this=0xbfffeffc, [EMAIL PROTECTED]) at
basic_string.h:269
269 { return ((reinterpret_cast_Rep* (_M_data()))[-1]); }
(gdb) where
#0 server_manager::prefix::cmp (this=0xbfffeffc, [EMAIL PROTECTED]) at
basic_string.h:269
#1 0x0805cee3 in server_manager::prefix::operator== (this=0xbfffeffc, [EMAIL
PROTECTED]) at server_manager.cc:55
#2 0x0806041f in server_manager::connect_to_server (this=0xbfffefd0, [EMAIL
PROTECTED], [EMAIL PROTECTED]) at stl_tree.h:176
#3 0x08056421 in channel::process_selected (this=0x8081810, [EMAIL
PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at channel.cc:101
#4 0x080675a9 in main (argc=6, argv=0x8081808) at stl_list.h:135
==
This might be fixed now.
Also, I noticed that usher will start and pretend that everything is OK,
even if one of the local databases does not exist. Maybe the server
could exit with an error, or at least issue a warning?
It doesn't actually parse the arguments in the 'local', it just passes
them on to the server. So it can't know there's a problem until the
server fails to start.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Usher crashes
On Sat, May 13, 2006 at 06:16:36PM -0500, Timothy Brownawell wrote: On Sat, 2006-05-13 at 12:22 -0300, Jeronimo Pellegrini wrote: Hi. I just compiled usher, and started it: $ ./usher -m mtn -kmy_key -a 127.0.0.1:1 usher.cfg It treats the -m argument as an executable name, not a command line. So it'll be looking for an execuable named mtn -kmy_key, not looking for an execuable named mtn and giving the -kmy_key argument. Really I should probably replace this argument with a line in the config file, which could allow for this. Ah. I see... I see it needs better documentation. It finds a matching server by first looking for one with a correct 'host' line. If there isn't a matching host line, then it looks for a matching 'pattern' line. The 'host' line is matched as a prefix of the hostname that the client is given to talk to, and the 'pattern' line is matched as a prefix of the include pattern. In each case, it takes the longest one that matches. Note that the 'pattern' line is a string prefix of the include pattern, not a glob. Also, you still have to provide the pattern argument that the serve command requires in the 'local' line. And since it sounds like this argument is going away soon, I'm not going to have it try to guess it. Well, I can see lots of problems with what I was doing! This might be fixed now. Yep. It doesn't crash anymore! :-) Thanks a lot, Tim! Right now I just need to find out why usher can't find the server, but it will eventually work. :-) J. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Usher crashes
Right now I just need to find out why usher can't find the server, but
it will eventually work. :-)
I found it.
If I use:
server main
host localhost
pattern info.aleph0
local -d /home/jeronimo/monotone/main.db *
And try to sync brahch:
info.aleph0.my_branch
Neither if I try:
server main
host localhost
pattern info.aleph0.*
local -d /home/jeronimo/monotone/main.db *
But if I use:
pattern info.aleph0.my_branch
it works.
It will not match. So it seems that I need to specify each branch in one
separate server?
I took a look at server_manager.cc, and found this:
if (!srv !pattern.empty() !by_pattern.empty())
{
i = --by_pattern.upper_bound(pattern);
if (i-first == prefix(host))
srv = i-second;
}
Is the inner if correct? Shouldn't it match against pattern, instead of
host?
Also, I tried to change host to pattern, but it still doesn't match
my_branch (as above). I don't understand exactly what prefix::operator==
does.
I just started ot read the code, so I may be writing a lot of nonsense...
J.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Usher pattern matching (was Re: [Monotone-devel] Usher crashes)
OK, I'll compile the problems I found before:
If I use:
server main
host localhost
pattern info.aleph0
local -d /home/jeronimo/monotone/main.db *
And try to sync brahch info.aleph0.my_branch
It won't work.
Neither if I try:
pattern info.aleph0.*
But if I use:
pattern info.aleph0.my_branch
It works, but only if I fix line 185 of server_manager::connect_to_server
where it matches pattern against host:
if (!srv !pattern.empty() !by_pattern.empty())
{
i = by_pattern.lower_bound(pattern);
if (i != by_pattern.end() i-first == prefix(host))
And even if I try to make it match against pattern, it fails,
because of the way operator== works for struct prefix. Is this
intentional? Shouldn't it also do partial matches?
J.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Usher pattern matching (was Re: [Monotone-devel] Usher crashes)
On Sat, 2006-05-13 at 23:29 -0300, Jeronimo Pellegrini wrote:
OK, I'll compile the problems I found before:
If I use:
server main
host localhost
pattern info.aleph0
local -d /home/jeronimo/monotone/main.db *
And try to sync brahch info.aleph0.my_branch
It won't work.
Neither if I try:
pattern info.aleph0.*
But if I use:
pattern info.aleph0.my_branch
It works, but only if I fix line 185 of server_manager::connect_to_server
where it matches pattern against host:
if (!srv !pattern.empty() !by_pattern.empty())
{
i = by_pattern.lower_bound(pattern);
if (i != by_pattern.end() i-first == prefix(host))
Um, that should be fixed now.
And even if I try to make it match against pattern, it fails,
because of the way operator== works for struct prefix. Is this
intentional? Shouldn't it also do partial matches?
It should, and I think now it does.
As you can probably tell, this hasn't exactly had extensive testing
since being reorganized. ;-p
Tim
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
