[02:19] <libwilliam> Is there a command that will show when a branch was first initialized?
[02:19] <jml> lifeless: also, I looked at testresources sorting last night... dijkstra's isn't at all what we want, I think.
[02:20] <jml> libwilliam: interesting question
[02:20] <lifeless> jml: simulated annealing perhaps?
[02:20] <jml> lifeless: well, I think we really want TSP
[02:21]  * jml looks up that other thing 
[02:21] <lifeless> TSP, expand pls
[02:21] <jml> lifeless: Travelling Salesman Problem.
[02:21] <lifeless> oh right
[02:21] <jml> of course, we don't have to solve it for the tests, just the set of resource combinations.
[02:22] <lifeless> simulated annealing is one of a class of polynomial approximations for NPC
[02:22] <jml> libwilliam: 'bzr log -r 1' is close, but it's not the same thing.
[02:23] <lifeless> we don't attach a datestamp to 'init'
[02:24] <jml> lifeless: well, I think there's a lot of room for flexibility in the algorithm
[02:24] <jml> lifeless: since the numbers are small and the same solution will often apply across multiple test runs.
[02:24] <lifeless> sure
[02:25] <libwilliam> 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] <libwilliam> I'll figure out a workaround.
[02:26] <jml> lifeless: but a probabilistic solution to the TSP is probably a good default.
[02:27] <jml> spiv suggested a modified Dijkstra's where the end node only 'appears' on the graph when all the others have been traversed
[02:28] <jml> but neither of us have bother to look at the algorithmic complexity of that.
[03:18] <lifeless> jml: uhm
[03:19] <lifeless> just have a start node with no resources, and an end node with cost infinity
[03:19] <jml> lifeless: I don't think that would work.
[03:20] <jml> because the path would still be (start_node, end_node)
[03:20] <lifeless> right, but the cost of that transition is oo
[03:20] <jml> unless they weren't connected, in which case, (start_node, cheapest_test, end_node)
[03:22] <jml> lifeless: yeah, but the cost of any other path from start to end will also be ∞
[03:22] <lifeless> right
[03:22] <jml> lifeless: ok in that case I don't know what your point is.
[03:24] <lifeless> surely that gives us what we want
[03:26] <jml> Well, experiment is the ultimate arbiter here, but I don't think so.
[03:26] <jml> Dijkstra's gives us the cheapest path from A to B, without necessarily traversing any nodes in between.
[03:26] <lifeless> thats right
[03:26] <lifeless> if A is no resources
[03:26] <lifeless> and B is infinitely many resources (a sentinel)
[03:27] <lifeless> then any resource-set might have a cheaper path from current pos to B
[03:27] <lifeless> so all resource sets get inspected
[03:28] <lifeless> the by product of the search was what was interested when I looked at this last
[03:28] <lifeless> anyhow, I'm interested in overall improvements, not the exact algorithm used
[03:28]  * jml too
[03:29] <jml> but I also want to re-enable the disabled test.
[03:30] <lifeless> ok
[03:30] <jml> lifeless: do you have a pre-written 'bigger than everything' object lying around?
[03:30] <lifeless> so my concept was
[03:30] <lifeless> [no]
[03:30] <jml> [[maybe it was one of the twisted guys]]
[03:31] <lifeless> oh yes I do
[03:31] <lifeless> its in bzrlib
[03:31] <jml> lifeless: :)
[03:31] <jml> yay memory
[03:33] <lifeless> so my idea was that even though djikstra snaps to the shortest path after inspecting everythin
[03:33] <lifeless> h
[03:33] <lifeless> g
[03:34] <lifeless> 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] <lifeless> alternatively
[03:35] <lifeless> 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] <lifeless> which suffers local-minima problem, but thats frankly not a huge deal in this case, I think
[03:35]  * jml neither
[03:37] <jml> either way, the trick is to force it to actually do a full traversal.
[03:37] <jml> also, you want to take the final teardown costs into account.
[10:39] <paolettopn> Hi guys....
[10:39] <paolettopn> there is anyone that can help me?
[10:43] <mwhudson> doh
[10:52] <lifeless> mwhudson: "no"
[11:35] <fm> 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] <vila> 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] <kiorky> jelmer: ping
[11:37] <fm> i am afraid suse will not downgrade python for bzr. most other packages are working beta1 is due next week vila...
[11:37] <kiorky> jelmer: seems that i cant branch over a svnrepo which is on the same filesystem
[11:38] <vila> fm: I'm afraid bzr will not support python-2.6 next week :)
[11:38] <kiorky> jelmer: http://rafb.net/p/El3FTn47.html
[11:39] <vila> 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] <fm> as 11.1 will be the base for the enterprise products, this will probably mean no bzr on them too.
[11:40] <fm> you may look at https://bugzilla.novell.com/show_bug.cgi?id=425644
[11:40] <fm> i will ask
[11:41] <vila> I've seen that report before updating bug #269535
[11:42] <fm> ok ;)
[11:42] <vila> 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] <vila> but the __init__ behavior change is not trivial
[11:44] <Odd_Bloke> 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] <fm> 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] <spiv> Odd_Bloke: IIRC, it just checks with 2.4 atm.
[11:47] <vila> 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] <vila> spiv: are you really there or just passing around ?
[11:48] <spiv> vila: I'm sort here.
[11:48] <spiv> s/sort/sort of/
[11:49] <vila> anyway, I'd really appreciate your advice about bug #269535 regarding __init__ behavior
[11:49] <vila> I'm not 100% sure of my diagnosis, but the code path failing is related to RemoteTranport inheriting from Transport and SmartMedium
[11:50] <vila> s/Transport/ConnectedTransport/
[11:51] <mwhudson> oh what
[11:51] <fm> vila: what is the timeframe to expect python 2.6 support, certainly the next ubuntu version will ship it ... or not?
[11:52] <spiv> vila: FWIW, I don't see any mention of the __init__ change in http://docs.python.org/dev/whatsnew/2.6.html
[11:53] <vila> spiv: I can't find back the reference but roughly __init__ now complains when receiving arguments
[11:54] <spiv> 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] <vila> spiv: I think so too, try bzr gannotate bzrlib/transport/__init__.py on Transport.__init__ :D
[11:55] <vila> object.__init__ doesn't seem to line base=base starting with python-2.6, that's the problem
[11:56] <vila> bzr: ERROR: exceptions.TypeError: object.__init__() takes no parameters
[11:58] <fm> vila: spiv http://bugs.python.org/file2323/new_init_strict.patch thats the patch i guess
[11:59] <vila> 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] <spiv> fm: yeah, I thought it probably was intentional.
[12:04] <lifeless> yay
[12:05] <spiv> 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] <lifeless> clearly, super() is broken by design and this just proves it :)
[12:08] <jml> spiv: without looking at the bug, I'm pretty sure that it wasn't a priority for them.
[12:10] <mwhudson> spiv: given that it broke the standard library in three places...
[12:12] <vila> 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] <vila> hi LarstiQ ! Thanks for the support :D
[12:12] <LarstiQ> vila: np :)
[12:13] <vila> Anyway, we'd better fix bzr
[12:22] <spiv> 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] <vila> spiv: That was my intuition and the reason I wanted to ask you :)
[12:25] <kiorky> uhm
[12:25] <kiorky> with bundlebuggy
[12:25] <kiorky> is there a page with all patches for all projects ?
[12:27] <spiv> 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] <vila> so ConnectedTransport as a SmartMedium attribute ?
[12:29] <spiv> Huh?
[12:29] <spiv> I mean, ConnectedTransport already has code to manage _shared_connection and the like.
[12:29] <spiv> For RemoteTransport, that _shared_connection should be the smart medium.
[12:30] <spiv> For HttpTransportBase, a smart client medium may as well be constructed on the fly as they are needed.
[12:31] <vila> Some typos are worse than othres s/as/has/ :)
[12:32] <spiv> Ah, ok.
[12:32] <jml> vila: typo? I bet you wouldn't even pronounce the 'h' :P
[12:33] <vila> Damn, uncovered, now everybody knows I use speech recognition while chatting
[12:33] <jml> :)
[12:33]  * jml is very tired.
[13:26] <johan> is it possible to edit commit messages?
[13:27] <johan> after the commit is done of course
[13:27] <lifeless> no
[13:28] <lifeless> you can create a new commit object with a different message
[13:28] <johan> too bad, I remember that svn allowed me to do that
[13:30] <spiv> If it's just the most recent commit, then "bzr uncommit && bzr commit" works well.
[13:31] <johan> right, but it isn't the last
[13:31]  * spiv nods
[18:36] <justizin> 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] <justizin> 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] <vila> bzr/python-2.6 down to 10 failures, 1 error :D
[19:20] <vila> See you tomorrow all.
[19:44] <fm> vila: thanks for working on it!
[20:05] <gutworth> does bazar support a bisect-like command?
[20:11] <Odd_Bloke> gutworth: There is a bisect plugin.
[20:11] <gutworth> I should have known :0
[20:48] <unangz> hallo masters
[20:48] <unangz> how to checkout from windows repository to linux???
[20:49] <unangz> can all of you help me???
[20:50] <gutworth> have you tried?
[20:50] <unangz> yes i have
[20:50] <unangz> i use ftp protocol
[20:50] <unangz> but i get problem when i commit
[20:50] <gutworth> oh?
[20:51] <unangz> because bzr not support for smb protocol
[20:53] <gutworth> ftp is not a very good protocol anyway
[20:53] <unangz> what can i do to solve my problem?
[20:54] <gutworth> can you use ssh or http?
[20:54] <gutworth> sftp?
[20:54] <unangz> if i checkout use http, it's clearly can not for commit back
[20:55] <unangz> http not support for make directories or files
[20:55] <unangz> how to installing ssh server on windows
[20:56] <gutworth> bzr serve
[20:56] <unangz> u have any tools or applocations ssh servers for windows?
[21:17] <nekohayo> uh oh
[21:18] <nekohayo> what happens if someone merges a branches, and makes changes before committing the merge?
[21:18] <nekohayo> seems one of my devs did just that, and it scares me
[21:18] <gutworth> the changes are just crammed in with the merge
[21:19] <nekohayo> gutworth: will bazaar know how to differentiate the two?
[21:19] <nekohayo> or will it basically screw up interactions with other branches afterwards?
[21:19] <gutworth> what do you mean?
[21:20] <gutworth> all that will happen is that you won't be able to separate the commits
[21:20] <gutworth> nothing horrible
[21:23] <nekohayo> oh ok
[21:23] <nekohayo> gutworth: I guess bazaar is smarter than I expect it :)
[21:52] <AmanicA> does anybod know how to convert chroot--1211347476:///bazaartest/trunk/  to file:///bzrroot/bazaartest/trunk/  ?
[21:53] <AmanicA> so far I've been able to derive the transport from the url, but that only gives file:///bzrroot/
[21:56] <lifeless> AmanicA: to do an unlock?
[21:57] <AmanicA> to get the local file while in hook, to pass to other script
[21:58] <lifeless> AmanicA: external to bzr?
[21:58] <AmanicA> I mean to convert the branch.base given to hook, into a branch url which I can pass back to bzr log
[21:58] <lifeless> you can pass chroot--1211347476:///bazaartest/trunk/ straight to bzr log in the same process
[21:59] <AmanicA> mm the hook fires a php script which then trigers `bzr log -r ...` to obtain other info
[22:00] <lifeless> right, so external to bzr ;)
[22:00] <AmanicA> then bzr log complains: errors.UnsupportedProtocol
[22:00] <lifeless> transport.local_abspath('.') may work
[22:00] <lifeless> the chroot-* syntax is a special in-process syntax only
[22:00] <AmanicA> I think I tried that
[22:01] <AmanicA> I can try again quickly
[22:02] <AmanicA> SmartMessageHandlerError: The message handler raised an exception: chroot--1211093524:///bazaartest/trunk is not a local path.
[22:03] <AmanicA> ok so I obtain the transport with : `tr = transport.get_transport(result.branch.base)`
[22:03] <AmanicA> which seems correct: `tr: <bzrlib.transport.chroot.ChrootTransport url=chroot--1211093524:///bazaartest/trunk/>`
[22:04] <AmanicA> then `tr.external_url()` gives `file:///var/lib/gforge/bzrroot/` which is the closest to what I want
[22:05] <AmanicA> except its only the url to the base of the transport, I need file:///bzrroot/bazaartest/trunk/
[22:06] <AmanicA> I mean file:///var/lib/gforge/bzrroot/bazaartest/trunk/
[22:08] <lifeless> uhm
[22:08] <lifeless> I didn't say external_url :)
[22:08] <lifeless> I said local_abspath
[22:08] <lifeless> oh right, and you get an error on that
[22:08] <AmanicA> I tried that and it gave ` SmartMessageHandlerError: The message handler raised an exception: chroot--1211093524:///bazaartest/trunk is not a local path.`
[22:09] <lifeless> 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] <AmanicA> where do you think the problem/solution would be?
[22:10] <lifeless> we need to look at the security implications
[22:10] <AmanicA> oh you mean that method should be implemented?!
[22:10] <AmanicA> oh, so no easy fix :(
[22:10] <lifeless> and then likely both fix local_abspath to support the chroot transport type
[22:11] <lifeless> and possibly provide a public method to get the backing location
[22:12] <AmanicA> ok I will quickly log a bug mentioning youe sugestions.
[22:13] <AmanicA> 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
[22:13] <lifeless> ok, thanks
[22:14] <AmanicA> thank YOU!
[23:24] <AmanicA> thanks lifeless, my monkey patch is 2 lines, and works beautifully. I've been trying to figure this out since saturday :( .
[23:25] <AmanicA> what are we not willing to do in the quest to do things right the fist time..
[23:36] <lifeless> :>
[23:58] <poolie> spiv, lifeless, call in 2m
[23:59]  * jml kills the music