Re: [Monotone-devel] Re: mtn:// sync
Markus Schiltknecht wrote: No, seriously, what's the problem you want to solve fundamentally? Are you saying you never want to download revision without it's certs? Yes (...without /all/ of its certs). I know that certs are loosely coupled to their respective revision. Nevertheless, it is unexpected to get, during a sync, a revision, and all its other certs, but not its branch certs (which in turn shows, that there must be some logic explicitly blocking them, because they are, in principle, not different from the other certs that are transmitted). Regards, Thomas signature.asc Description: This is a digitally signed message part. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: mtn:// sync
Derek Scherger wrote: Markus Schiltknecht wrote: Hi, Thomas Moschny wrote: Ok. I vaguely had in mind that there also was a non-technical reason. I don't know any non-technical reason. I believe it's a consequence of the invariant enforced by the database that no revision will be stored unless it's parents are also stored. This ultimately requires that all ancestry for a revision is in the local database before the revision can be stored. This is clear. But the question was, is there a non-technical reason to not sync the branch certs of these ancestor revisions? Regards, Thomas signature.asc Description: This is a digitally signed message part. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mainline unit tests fixed
Zack Weinberg [EMAIL PROTECTED] writes: On Tue, Mar 25, 2008 at 4:48 PM, Markus Schiltknecht [EMAIL PROTECTED] wrote: Stephen, please, before you commit, run the testsuite - that's what we have it for. I did, on the box I have access to; MinGW. It passed. I also looked at the buildbot results; they are all failing except MinGW. They were failing before this change, as well. The buildbot master is supposed to have a way to examine the test logs, but that is broken at the moment. So I did not have a good way to tell if introducing --ssh-sign=no had any effects. Hmm. I can retrieve the list of which tests are failing on each buildbot, so I could have checked whether the ssh-agent tests started failing. I didn't do that; I'll remember that for next time. I now realize that all of the ssh-agent tests are skipped on MinGW, because they don't work there. So it was not a good idea for me to introduce that change. I'm waiting for Richard to finish setting up the Cygwin buildbot. Then I can start running Cygwin as well as MinGW for all commits, and fix things on my local box; that should catch more stuff like this. Then commit on mainline only if it passes all the tests. Use a branch if you want to commit experimental stuff, which doesn't pass the tests. I am 100% agreed with this rule, however. Me too; I'm doing my best to follow it. There is now a MinGW buildbot, so people can more easily tell if their changes break something on Windows. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Hiding suspended branches in viewmtn 0.10
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Viewmtn claims to have support to hide suspended branches, but I can't seem to find how to enable? Does anybody know how to do that with viewmtn 0.10? regards, koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFH6iumMkyGM64RGpERAv1AAJ9AoAkvRPzkeA0H70y9HbIRAeLwggCgiHtD HchqB6sLfODhLl9Fah2VZ1c= =d+9A -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: mtn:// sync
Hi, Thomas Moschny wrote: Yes (...without /all/ of its certs). I know that certs are loosely coupled to their respective revision. Nevertheless, it is unexpected to get, during a sync, a revision, and all its other certs, but not its branch certs (which in turn shows, that there must be some logic explicitly blocking them, because they are, in principle, not different from the other certs that are transmitted). +1 I think nuskool (or netsync, but I'm more willing to implement that for the former) should transfer all certs (or maybe just all trusted certs) for each revision it sends, no matter what caused the revision to be sent initially. Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mainline unit tests fixed
Hi, Nathaniel Smith wrote: Yeah, touching $HOME is weird, we should be using --confdir or whatever it's called... that said, setting HOME to something isn't *too* crazy a way to sandbox the mtn-under-test. But if we do go that way, we'd better set APPDATA too... The reason I was fiddling with $HOME was, that ssh_agent wants to tests all variants of --ssh-sign, including not specifying it. Maybe it's safer to add --ssh-sign=no to lua-testsuite.lua, and just special case the ssh_agent test. The problem isn't spawning a private copy of the daemon, IIRC the tests do that; the problem is that after spawning a private copy of the daemon, we need a way to run the mtn binary that will actually be willing to talk to the daemon :-). That's part of why we have all the different *mtn() functions, because different parts of the test suite can accept more or less defaults. Maybe in this case the right solution is to add an extra --ssh-sign=yes to the agent tests, though -- will that override an -ssh-sign=no given earlier on the command line? I'm not quite sure I'm understanding this. Testing all variants of that option still makes sense to me. And that seems to work only with overriding $HOME - or is there a better way? But as I said: I'm not an expert for ssh-agents. Someone with more in-depth insights should fix that test, please. Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mainline unit tests fixed
Hi, Stephen Leake wrote: I think Markus' fix is better. Then we can also put specific stuff in the $HOME directory, to test the behavior in those cases. We should experiment with adding that $HOME fix to the core 'safe_mtn' command; carefully, of course :). You mean, as a general test case setup? Hm.. dunno how cross-platform that is, but it would certainly work for my Linux boxen. And who cares about Vista, anyway. :-) Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mainline unit tests fixed
Markus Schiltknecht [EMAIL PROTECTED] writes: Stephen Leake wrote: I think Markus' fix is better. Then we can also put specific stuff in the $HOME directory, to test the behavior in those cases. We should experiment with adding that $HOME fix to the core safe_mtn' command; carefully, of course :). You mean, as a general test case setup? Yes. Hm.. dunno how cross-platform that is, but it would certainly work for my Linux boxen. And who cares about Vista, anyway. :-) Well, I don't care about Vista at the moment, but I do care about MinGW on Windows XP; my team is using it at work. And eventually they'll make us move to Vista. That would require setting APPDATA instead of HOME, but otherwise it's the same. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] library-build branch
Hi, to get into autoconf et al, I've played around with the library-build branch. Hope Zack doesn't mind... :-) I've reverted botan to its own directory layout, using its configure.pl script. I'm not sure invocation of that perl script is correct in configure.ac, however, it seems to work. For everything else (idna, pcre, sqlite, lua), I've just added a handwritten Makefile.am. From here, that now compiles .a files for every library we use. To be able to really compile and test monotone itself, we still need to clean up between Makefile.am and monotone/Makefile.am. Also, adding more --with-system-$(library) switches would be useful, however, first of all, I'd like to make monotone compile again that way. Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] library-build branch
On Wed, Mar 26, 2008 at 7:02 PM, Markus Schiltknecht [EMAIL PROTECTED] wrote: Hi, to get into autoconf et al, I've played around with the library-build branch. Hope Zack doesn't mind... :-) cool. I had gotten seriously stuck on that, so I'm glad to see you picking up on it. I've not got much time for monotone in the next few days but when I do I'll lookat it. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time to think about a release?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Richard Levitte wrote: It seems to be that part of the month, doesn't it? In Sweden, the 25th is the day you usually get your monthly paycheck in Sweden, and why not get a release at the same time? ;-) spanish translation fully updated. and sorry for the delay. But I digress... Anyway, it seems like we need to settle the whole mtn:// matter before a release can be done at this point. Also, around last release, there was some talk about merging some branches back into the main branch, but I haven't seen any of that happen... maybe I missed something? Anyway, what's the plan now regarding that? Cheers, Richard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH6u+3mjsZS9ZBxv8RAq6QAJ4sUKWtK1OYaIoin6GqnoxSVIM++wCfeZbo 6Q18eQf+49Q3q72zSRG3Ahk= =2Oip -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] viewmtn errors
Hello,
I seem to be getting errors from viewmtn like:
[Wed Mar 26 14:31:00 2008] [error] [client 66.249.70.152] FastCGI: server
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py stderr: mtn: misuse: invalid
restriction
[Wed Mar 26 14:32:16 2008] [error] [client 66.249.70.152] FastCGI: server
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py stderr: Traceback (most
recent call last):
[Wed Mar 26 14:32:16 2008] [error] [client 66.249.70.152] FastCGI: server
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py stderr: File
/home/viewmtn/net.angrygoats.viewmtn/web/webapi.py, line 304, in wsgifunc
[Wed Mar 26 14:32:16 2008] [error] [client 66.249.70.152] FastCGI: server
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py stderr: result = func()
[Wed Mar 26 14:32:16 2008] [error] [client 66.249.70.152] FastCGI: server
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py stderr: File
/home/viewmtn/net.angrygoats.viewmtn/web/request.py, line 131, in lambda
[Wed Mar 26 14:32:16 2008] [error] [client 66.249.70.152] FastCGI: server
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py stderr: func = lambda:
handle(inp, fvars)
[Wed Mar 26 14:32:16 2008] [error] [client 66.249.70.152] FastCGI: server
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py stderr: File
/home/viewmtn/net.angrygoats.viewmtn/web/request.py, line 61, in handle
[Wed Mar 26 14:32:16 2008] [error] [client 66.249.70.152] FastCGI: server
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py stderr: return
tocall(*([x and urllib.unquote(x) for x in args] + fna))
[Wed Mar 26 14:32:16 2008] [error] [client 66.249.70.152] FastCGI: server
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py stderr: File
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py, line 123, in GET
[Wed Mar 26 14:32:16 2008] [error] [client 66.249.70.152] FastCGI: server
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py stderr: return
handler.GET (ctxt, *other_args, **kwargs)
[Wed Mar 26 14:32:16 2008] [error] [client 66.249.70.152] FastCGI: server
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py stderr: File
/home/viewmtn/net.angrygoats.viewmtn/handlers.py, line 400, in GET
[Wed Mar 26 14:32:16 2008] [error] [client 66.249.70.152] FastCGI: server
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py stderr: files=files)
[Wed Mar 26 14:32:16 2008] [error] [client 66.249.70.152] FastCGI: server
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py stderr: File
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py, line 46, in render
[Wed Mar 26 14:32:16 2008] [error] [client 66.249.70.152] FastCGI: server
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py stderr:
self.renderer.render (self, *args, **kwargs)
[Wed Mar 26 14:32:16 2008] [error] [client 66.249.70.152] FastCGI: server
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py stderr: File
/home/viewmtn/net.angrygoats.viewmtn/render.py, line 168, in render
[Wed Mar 26 14:32:16 2008] [error] [client 66.249.70.152] FastCGI: server
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py stderr:
web.render(template, terms)
[Wed Mar 26 14:32:16 2008] [error] [client 66.249.70.152] FastCGI: server
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py stderr: File
/home/viewmtn/net.angrygoats.viewmtn/web/cheetah.py, line 98, in render
[Wed Mar 26 14:32:16 2008] [error] [client 66.249.70.152] FastCGI: server
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py stderr: return
output(str(compiled_tmpl))
[Wed Mar 26 14:32:16 2008] [error] [client 66.249.70.152] FastCGI: server
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py stderr: File
/var/lib/python-support/python2.4/Cheetah/Template.py, line 989, in __str__
[Wed Mar 26 14:32:16 2008] [error] [client 66.249.70.152] FastCGI: server
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py stderr: def
__str__(self): return getattr(self, mainMethName)()
[Wed Mar 26 14:32:16 2008] [error] [client 66.249.70.152] FastCGI: server
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py stderr: File string,
line 272, in respond
[Wed Mar 26 14:32:16 2008] [error] [client 66.249.70.152] FastCGI: server
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py stderr: File string,
line 123, in body
[Wed Mar 26 14:32:16 2008] [error] [client 66.249.70.152] FastCGI: server
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py stderr: File
/home/viewmtn/net.angrygoats.viewmtn/syntax.py, line 71, in __highlight
[Wed Mar 26 14:32:16 2008] [error] [client 66.249.70.152] FastCGI: server
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py stderr: tochild_buf +=
lines.next()
[Wed Mar 26 14:32:16 2008] [error] [client 66.249.70.152] FastCGI: server
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py stderr: File
/home/viewmtn/net.angrygoats.viewmtn/mtn.py, line 456, in diff
[Wed Mar 26 14:32:16 2008] [error] [client 66.249.70.152] FastCGI: server
/home/viewmtn/net.angrygoats.viewmtn/viewmtn.py stderr: for line in
self.standalone.run('diff', args):
[Wed Mar 26 14:32:16 2008] [error] [client
