[02:19] Is there a command that will show when a branch was first initialized? [02:19] lifeless: also, I looked at testresources sorting last night... dijkstra's isn't at all what we want, I think. [02:20] libwilliam: interesting question [02:20] jml: simulated annealing perhaps? [02:20] lifeless: well, I think we really want TSP [02:21] * jml looks up that other thing [02:21] TSP, expand pls [02:21] lifeless: Travelling Salesman Problem. [02:21] oh right [02:21] of course, we don't have to solve it for the tests, just the set of resource combinations. [02:22] simulated annealing is one of a class of polynomial approximations for NPC [02:22] libwilliam: 'bzr log -r 1' is close, but it's not the same thing. [02:23] we don't attach a datestamp to 'init' [02:24] lifeless: well, I think there's a lot of room for flexibility in the algorithm [02:24] lifeless: since the numbers are small and the same solution will often apply across multiple test runs. [02:24] sure [02:25] jml: it is the closest possible thing I think. The only reason I was wanting the branch init date was when using a calendar I want the user to be able to select the range of when to show the status... and since status allows a revision range of revision=.. I don't know where to limit the user if they didnt commit revno 1 until the a different day. [02:26] I'll figure out a workaround. [02:26] lifeless: but a probabilistic solution to the TSP is probably a good default. [02:27] spiv suggested a modified Dijkstra's where the end node only 'appears' on the graph when all the others have been traversed [02:28] but neither of us have bother to look at the algorithmic complexity of that. [03:18] jml: uhm [03:19] just have a start node with no resources, and an end node with cost infinity [03:19] lifeless: I don't think that would work. [03:20] because the path would still be (start_node, end_node) [03:20] right, but the cost of that transition is oo [03:20] unless they weren't connected, in which case, (start_node, cheapest_test, end_node) [03:22] lifeless: yeah, but the cost of any other path from start to end will also be ∞ [03:22] right [03:22] lifeless: ok in that case I don't know what your point is. [03:24] surely that gives us what we want [03:26] Well, experiment is the ultimate arbiter here, but I don't think so. [03:26] Dijkstra's gives us the cheapest path from A to B, without necessarily traversing any nodes in between. [03:26] thats right [03:26] if A is no resources [03:26] and B is infinitely many resources (a sentinel) [03:27] then any resource-set might have a cheaper path from current pos to B [03:27] so all resource sets get inspected [03:28] the by product of the search was what was interested when I looked at this last [03:28] anyhow, I'm interested in overall improvements, not the exact algorithm used [03:28] * jml too [03:29] but I also want to re-enable the disabled test. [03:30] ok [03:30] lifeless: do you have a pre-written 'bigger than everything' object lying around? [03:30] so my concept was [03:30] [no] [03:30] [[maybe it was one of the twisted guys]] [03:31] oh yes I do [03:31] its in bzrlib [03:31] lifeless: :) [03:31] yay memory [03:33] so my idea was that even though djikstra snaps to the shortest path after inspecting everythin [03:33] h [03:33] g [03:34] you know it has inspected it, and there is a by product in the implementation, I don't recall quite what it was [03:34] alternatively [03:35] if the cost to the final sentinel is not constant, but less by the current cost of the path, it won't snap and you'd get a full traversal, which was cheapest at each individual step [03:35] which suffers local-minima problem, but thats frankly not a huge deal in this case, I think [03:35] * jml neither [03:37] either way, the trick is to force it to actually do a full traversal. [03:37] also, you want to take the final teardown costs into account. === komputes|eee is now known as komputes === mzungu_ is now known as mzungu [10:39] Hi guys.... [10:39] there is anyone that can help me? [10:43] doh === bac` is now known as bac [10:52] mwhudson: "no" === gnomefreak is now known as thunderstruck === thunderstruck is now known as gnomefreak [11:35] is there a way to checkout a bzr repo from launchpad without having bzr. My bzr does not work as I am using python 2.6, but how do i get https://code.launchpad.net/~vila/bzr/py26bzr ?? [11:36] fm: https://code.launchpad.net/~vila/bzr/py26bzr is useless for now with python-2.6, you need to find a python-2.5 [11:37] jelmer: ping [11:37] i am afraid suse will not downgrade python for bzr. most other packages are working beta1 is due next week vila... [11:37] jelmer: seems that i cant branch over a svnrepo which is on the same filesystem [11:38] fm: I'm afraid bzr will not support python-2.6 next week :) [11:38] jelmer: http://rafb.net/p/El3FTn47.html [11:39] It's quite custom for distributions to support multiple versions of python though, I'd very surprised that bzr is the only package not yet ready for python-2.6 [11:39] as 11.1 will be the base for the enterprise products, this will probably mean no bzr on them too. [11:40] you may look at https://bugzilla.novell.com/show_bug.cgi?id=425644 [11:40] bugzilla.novell.com bug 425644 in Development "bzr init fails: failed to load bzrlib.repofmt.pack_repo.RepositoryFormatKnitPack1: cannot import name U32" [Normal,New] [11:40] i will ask [11:41] I've seen that report before updating bug #269535 [11:41] Launchpad bug 269535 in bzr "bzr does not work with python2.6" [Medium,In progress] https://launchpad.net/bugs/269535 [11:42] ok ;) [11:42] Next step will be to analyze how many root causes for the failures=33, errors=35, some may be less important than others [11:43] but the __init__ behavior change is not trivial [11:44] On a slightly related note, does PQM check if we've had any regressions on 2.4 _and_ 2.5, or does it just use one or the other? [11:46] sadly I do not now python vila. I just wanted to try bzr for an assignment I am currenty working on. as it sounded really cool ... But certainly I am willing to test everything ;) [11:47] Odd_Bloke: IIRC, it just checks with 2.4 atm. [11:47] I don't use opensuse myself so I can't say how to install a python-2.5, but I'd be very surprised if no way exists to do that [11:48] spiv: are you really there or just passing around ? [11:48] vila: I'm sort here. [11:48] s/sort/sort of/ [11:49] anyway, I'd really appreciate your advice about bug #269535 regarding __init__ behavior [11:49] Launchpad bug 269535 in bzr "bzr does not work with python2.6" [Medium,In progress] https://launchpad.net/bugs/269535 [11:49] I'm not 100% sure of my diagnosis, but the code path failing is related to RemoteTranport inheriting from Transport and SmartMedium [11:50] s/Transport/ConnectedTransport/ [11:51] oh what [11:51] vila: what is the timeframe to expect python 2.6 support, certainly the next ubuntu version will ship it ... or not? [11:52] vila: FWIW, I don't see any mention of the __init__ change in http://docs.python.org/dev/whatsnew/2.6.html [11:53] spiv: I can't find back the reference but roughly __init__ now complains when receiving arguments [11:54] vila: in general, using super() when you don't know that all the bases will have a compatible signature is a bad idea I think [11:54] spiv: I think so too, try bzr gannotate bzrlib/transport/__init__.py on Transport.__init__ :D [11:55] object.__init__ doesn't seem to line base=base starting with python-2.6, that's the problem [11:56] bzr: ERROR: exceptions.TypeError: object.__init__() takes no parameters [11:58] vila: spiv http://bugs.python.org/file2323/new_init_strict.patch thats the patch i guess [11:59] fm: Thanks, that's the reference I was searching ! I read that yesterday but I can't find anymore how I went there.... [11:59] fm: yeah, I thought it probably was intentional. === Spaz is now known as Kittens [12:04] yay [12:05] It's not clear from the discussion at http://bugs.python.org/issue1683368 if they thought it would cause people's code to break. [12:05] clearly, super() is broken by design and this just proves it :) [12:08] spiv: without looking at the bug, I'm pretty sure that it wasn't a priority for them. [12:10] spiv: given that it broke the standard library in three places... [12:12] It seems to me that the intent was to apply the patch to 3k but it leaked into 2.6... [12:12] * LarstiQ reads it that way as well [12:12] hi LarstiQ ! Thanks for the support :D [12:12] vila: np :) [12:13] Anyway, we'd better fix bzr [12:22] vila: probably the best fix is to remove the multiple inheritance from RemoteTransport entirely... I'm not sure that it really needs to inherit from SmartClientMedium. [12:24] spiv: That was my intuition and the reason I wanted to ask you :) [12:25] uhm [12:25] with bundlebuggy [12:25] is there a page with all patches for all projects ? [12:27] vila: the smart client medium is really the underlying connection, so it really ought to be using the ConnectedTransport stuff for managing that, rather than mucking about with multiple inheritance I think. [12:28] so ConnectedTransport as a SmartMedium attribute ? [12:29] Huh? [12:29] I mean, ConnectedTransport already has code to manage _shared_connection and the like. [12:29] For RemoteTransport, that _shared_connection should be the smart medium. [12:30] For HttpTransportBase, a smart client medium may as well be constructed on the fly as they are needed. [12:31] Some typos are worse than othres s/as/has/ :) [12:32] Ah, ok. [12:32] vila: typo? I bet you wouldn't even pronounce the 'h' :P [12:33] Damn, uncovered, now everybody knows I use speech recognition while chatting [12:33] :) [12:33] * jml is very tired. [13:26] is it possible to edit commit messages? [13:27] after the commit is done of course [13:27] no [13:28] you can create a new commit object with a different message [13:28] too bad, I remember that svn allowed me to do that [13:30] If it's just the most recent commit, then "bzr uncommit && bzr commit" works well. [13:31] right, but it isn't the last [13:31] * spiv nods === BasicPRO is now known as BasicOSX [18:36] agh i know i have asked about this before, but forget the name of the feature, i keep hearing there is a comparative feature to svn:externals in dev, or maybe in 1.6, but can't find it in docs or anything. any word? [18:37] i don't care about compat with svn:externals in bzr-svn, am moving our deployment from svn to bzr and, though i was able to pull the externals with a bash one-liner, it was not as much fun to write as drinking beer :) [19:20] bzr/python-2.6 down to 10 failures, 1 error :D [19:20] See you tomorrow all. [19:44] vila: thanks for working on it! [20:05] does bazar support a bisect-like command? [20:11] gutworth: There is a bisect plugin. [20:11] I should have known :0 [20:48] hallo masters [20:48] how to checkout from windows repository to linux??? [20:49] can all of you help me??? [20:50] have you tried? [20:50] yes i have [20:50] i use ftp protocol [20:50] but i get problem when i commit [20:50] oh? [20:51] because bzr not support for smb protocol [20:53] ftp is not a very good protocol anyway [20:53] what can i do to solve my problem? [20:54] can you use ssh or http? [20:54] sftp? [20:54] if i checkout use http, it's clearly can not for commit back [20:55] http not support for make directories or files [20:55] how to installing ssh server on windows [20:56] bzr serve [20:56] u have any tools or applocations ssh servers for windows? [21:17] uh oh [21:18] what happens if someone merges a branches, and makes changes before committing the merge? [21:18] seems one of my devs did just that, and it scares me [21:18] the changes are just crammed in with the merge [21:19] gutworth: will bazaar know how to differentiate the two? [21:19] or will it basically screw up interactions with other branches afterwards? [21:19] what do you mean? [21:20] all that will happen is that you won't be able to separate the commits [21:20] nothing horrible [21:23] oh ok [21:23] gutworth: I guess bazaar is smarter than I expect it :) [21:52] does anybod know how to convert chroot--1211347476:///bazaartest/trunk/ to file:///bzrroot/bazaartest/trunk/ ? [21:53] so far I've been able to derive the transport from the url, but that only gives file:///bzrroot/ [21:56] AmanicA: to do an unlock? === mario_ is now known as pygi [21:57] to get the local file while in hook, to pass to other script [21:58] AmanicA: external to bzr? [21:58] I mean to convert the branch.base given to hook, into a branch url which I can pass back to bzr log [21:58] you can pass chroot--1211347476:///bazaartest/trunk/ straight to bzr log in the same process [21:59] mm the hook fires a php script which then trigers `bzr log -r ...` to obtain other info [22:00] right, so external to bzr ;) [22:00] then bzr log complains: errors.UnsupportedProtocol [22:00] transport.local_abspath('.') may work [22:00] the chroot-* syntax is a special in-process syntax only [22:00] I think I tried that [22:01] I can try again quickly [22:02] SmartMessageHandlerError: The message handler raised an exception: chroot--1211093524:///bazaartest/trunk is not a local path. [22:03] ok so I obtain the transport with : `tr = transport.get_transport(result.branch.base)` [22:03] which seems correct: `tr: ` [22:04] then `tr.external_url()` gives `file:///var/lib/gforge/bzrroot/` which is the closest to what I want [22:05] except its only the url to the base of the transport, I need file:///bzrroot/bazaartest/trunk/ [22:06] I mean file:///var/lib/gforge/bzrroot/bazaartest/trunk/ [22:08] uhm [22:08] I didn't say external_url :) [22:08] I said local_abspath [22:08] oh right, and you get an error on that [22:08] I tried that and it gave ` SmartMessageHandlerError: The message handler raised an exception: chroot--1211093524:///bazaartest/trunk is not a local path.` [22:09] I think you should file a bug; it is reasonable to want to run an external script on a branch being pushed to by the smart server [22:09] where do you think the problem/solution would be? [22:10] we need to look at the security implications [22:10] oh you mean that method should be implemented?! [22:10] oh, so no easy fix :( [22:10] and then likely both fix local_abspath to support the chroot transport type [22:11] and possibly provide a public method to get the backing location [22:12] ok I will quickly log a bug mentioning youe sugestions. [22:13] in the meanwhile I might manually translate the url to get my stuff working. I can look into fixing the bug a little later if someone which better knowledge about these things doesn't beat me to it === mario__ is now known as pygi [22:13] ok, thanks [22:14] thank YOU! [23:24] thanks lifeless, my monkey patch is 2 lines, and works beautifully. I've been trying to figure this out since saturday :( . [23:25] what are we not willing to do in the quest to do things right the fist time.. [23:36] :> [23:58] spiv, lifeless, call in 2m [23:59] * jml kills the music