=== medberry is now known as med_out === JasonO_ is now known as JasonO [07:25] hi all! [07:25] is there a magic "upgrade all launchpad bzr trees for project X to new repo format" button hiding somewhere? [07:25] or does the magic sftp "bzr upgrade" work for all that... [07:27] and also, any idea what "Standalone tree (format: unnamed)" could possibly mean ? [07:39] it info -v [07:39] bah [07:39] info -v will help you see what it means [07:41] ahh.. packs with knits without subtree [07:41] probably an unusual combination of tree/branch/repo [08:10] I'm working with the branch http://bzr.savannah.gnu.org/r/grub/trunk/grub/. "bzr log | grep tags:" prints "tags: 1.99" yet "bzr checkout -r tag:1.99 /tmp/grub" fails with "bzr: ERROR: No such tag: 1.99". What am I doing wrong? [08:11] Ahh, I see what I did wrong now. [08:16] I thought that if ommitted branch location would be the branch corrosponding to the current directory. I guess it's not. [08:32] Jordan_U: it will try to check out /tmp/grub in the current location [08:32] LarstiQ: Thanks. [08:35] Jordan_U: I suspect you might be used to git checkout? [08:36] LarstiQ: Yes :) [08:36] Jordan_U: yeah, same names unfortunately don't always imply same operation :) [08:37] LarstiQ: I actually did read "bzr help checkout" before using it. [08:37] * LarstiQ shakes a fist at Estonian/Finnish false friends while at it [08:38] Jordan_U: maybe it should be more explicit that one can't supply TO_LOCATION without supplying BRANCH_LOCATION? [08:38] LarstiQ: I'd say so. [08:39] hmm, not sure how to get the option parser to spit that out [08:43] * LarstiQ will file a bug and let other people sort it out [08:44] is there anything for bzr in ubuntu 10.10 like there is for tortoise svn on windows where the UI is your file explorer? [08:44] LarstiQ: Thanks. [08:44] dandaman: nautilus-bzr exists, don't know if it is on the same level [08:45] dandaman: might be packaged in bzr-gtk [08:45] i shall investigate [08:46] i'm not well acquainted with the command line yet(which i'd really like to, but no time) and the explorer ui is garbage [08:46] * dandaman apologizes if anyone who worked on that is in the channel, just my opinion [08:46] his* [08:47] dandaman: the apology would carry more weight if you gave feedback on why you think that ;P [08:48] not that I'm involved [08:49] its just a lot less inferior to a folder explorer UI, less intuitive [08:55] dandaman: mkay, that might be taste I suppose [08:55] dandaman: found nautilus-bzr yet? [08:55] yeah i installed it [08:55] I'll get it set up when i'm not stoned, and thus be able to read instructions [08:55] * LarstiQ personally abhors the explorer/nautilus view [08:56] dandaman: hah, ok :) [08:56] really? [08:56] yeah [08:56] its so easy to us [08:56] use* [08:56] dandaman: how do you quantify easy? :) [08:56] just right click on the file you worked on a second ago and its committed [08:56] dandaman: except I don't use a filemanager in my daily workflow to begin with [08:56] barely worry about conflicts because you commit one file at a time [08:56] do you use the command line? [08:56] yeah [08:57] well see [08:57] and emacs/vi integration [08:57] command line is probably the most efficient [08:57] and qbzr [08:57] i just don't exactly have the time to learn how to use it to the point where i'd feel comfortable with it [08:57] * LarstiQ nods [08:57] that's fair [08:57] after graduation i'll have some time [08:57] and i'm going to learn a whole bunch of stuff i meant to learn on the side [08:58] also, i need to find a place that wants to hire api programmers [08:58] don't know why, but i decided that's what I want to do [09:06] Jordan_U: took a while, but: https://bugs.launchpad.net/bzr/+bug/784459 [09:06] Ubuntu bug 784459 in Bazaar ""bzr help checkout" should make dependence of TO_LOCATION on BRANCH_LOCATION more explicit" [Medium,Confirmed] [09:23] morning all! [09:24] morning mgz :) [09:26] LarstiQ: if you're still interested in the file handles issue for pypy, I have a couple of tools that may help [09:27] also, vila and I are going to investigate later today to see if the babune osx and windows issues are also file handle exhaustion related [09:30] mgz: yeah [09:30] mgz: I have made some notes [09:30] and some lacking commits [09:30] I'll push the latter [09:32] mgz: http://richtlijn.be/~larstiq/DEBUG_NOTES [09:33] mgz: and maybe it is useful to put a small test script to demonstrate the generator-with-resources problem [09:36] mgz: http://richtlijn.be/~larstiq/halfcon.py [09:37] mgz: most fun: enable the pdb line, run the script (cpython or pypy, doesn't matter in this case), note the pid it prints out, run "watch -n 1 'ls -lU /proc//fd"; and step through the code [09:37] mgz: (not too fast, watch only updates once a second) [09:38] * jelmer waves [09:38] jelmer: hei jelmer :) [09:39] LarstiQ, dude! [09:40] mgz: even with those attempts at cleaning up resources, running `pypy ./bzr selftest -s bt.blackbox` the amount of open files fluctuates. Usually between 700 and 1023 (where we get too many open files) [09:40] jelmer: still alive ;) [09:41] mgz: I hope the DEBUG_NOTES file is clear? [09:42] okay, back from swapping [09:42] * mgz reads notes [09:45] LarstiQ, so, jam recently added a cleanup in Transport._seek_and_read which is what Transport._readv (always?) calls [09:46] are there cases where that codepath with the close isn't being hit? [09:46] * LarstiQ looks at the code [09:46] mgz: LocalTransport should always call _seek_and_read, HTTP and others don't [09:46] mgz: where is this cleanup? [09:47] LarstiQ: try/except/fp.close raise else: fp.close [09:47] line 718 in bzrlib/transport/__init__.py [09:47] jam: that is no good if the generator is not fully consumed [09:47] mgz: and we can change that back to try/finally now \o/ [09:47] LarstiQ: generators raise GeneratorExit if they aren't consumed [09:47] at least in python 2.5+ [09:48] pypy *should* be doing the same [09:48] jam: in what case? [09:48] when they're garbage collected? [09:48] That may take a while [09:48] LarstiQ: yes [09:48] jam: it _does_ clean them up from time to time, dropping from say 800 to 300 open files [09:48] but not fast enough [09:49] okay, that sounds fun. [09:49] LarstiQ: so 1) we can change it to try/finally so it is at least clearer. 2) We can look at changing the StopIteration code black to close them again [09:49] jam: the reason I think it is due to not being consumed is that I added debug prints/sys.counter checking, and we were not hitting the final fp.close [09:50] LarstiQ: http://paste.ubuntu.com/609397/ [09:50] try that [09:50] it should allow the file to get closed when its associated iterator is consumed [09:50] before we yield [09:50] and it should be pretty rare that we don't access all the readv data [09:50] LarstiQ: I also have a record of which testcases in the suite use files and rely on refcount semantics to clean them up, this can also add to your 800 files open scenario [09:50] lots of the problems are shallow issues with particular tests [09:50] it will occasionally happen that we do "zip(X, readv)" and the X stops, so it doesn't even check if the readv is stopped [09:50] I have another idea, too [09:51] jam: that is almost what my code looks like, but I'll try that (the raise might be different) [09:51] LarstiQ: we don't want the raise there [09:51] that was a bug in my diff [09:51] ah, my diff removed it [09:51] I just read it wrong [09:51] mgz: hmm, maybe. But I don't think so [09:51] see (warning, big page) http://float.endofinternet.org/xmlbin/newtestresult and click any of the little yellow boxes [09:51] anyway, you don't have to do that part, but you can [09:52] except... that's buggy to [09:52] too [09:52] it looks like we still iterate c_offset [09:52] it's possible pypy can be clever about some of those formulations [09:52] so closing the file early will bring other bugs [09:52] let me think about it a bit [09:52] we should only close the file once we're sure we've read everything [09:53] ah, nm [09:53] if offset_stack is empty [09:53] then we know we're done [09:53] since we have returned everything the caller asked of us [09:55] jam: that fp.close in the StopIteration works wonder [09:55] * LarstiQ failed to see it the first time :/ [09:56] LarstiQ: it used to be there, but we moved it because it is cleaner to have just the try/finally (and doesn't matter much in production code) [09:56] that's a little suprising, [09:56] mgz: I'm not terribly surprised. anything with a lazy garbage collector can be *really* lazy [09:56] and we do a lot of readv [09:56] do lots of callers use the zip idiom and never exhaust the generator? [09:56] mgz: I wouldn't have thought lots [09:56] if so, might want the close there, and try/except/close/raise [09:57] but if BTreeGraphIndex does [09:57] that is a pretty core [09:57] rather than try/finally [09:57] mgz: you can always close twice [09:57] at least with all the objects I tried [09:57] but can't close lists [09:57] ...that's probably safe [09:57] LarstiQ: fp should never be a list [09:57] mgz: note that you *can't* os.close(FID) twice, but that should be safely encapsulated for us [09:58] jam: aye, I was referring to the 'if isinstance(data_ranges, types.GeneratorType)' in https://code.launchpad.net/~larstiq/bzr/bzr-pypy/+merge/60986 [09:58] since you can explicitly close a generator [09:59] since python 2.5 iirc [09:59] yup. [10:00] * LarstiQ is 10% into the blackbox tests and observes a maximum of 37 open files dropping down to 7 every couple of seconds [10:08] LarstiQ: so I'd rather not change btree_index unless we have to. [10:08] it is going to be really rare for btree_index to not get fully consumed [10:09] I'm guessing what you are running into is actually in pack.py [10:09] Where when reading disk content [10:09] jam: I have no firm grasp on the matter [10:09] we create a Readv* class [10:09] which doesn't have StopIteration written anywhere [10:09] so it is probably never consuming the readv object [10:09] jam: right, I pondered a .close method on that [10:13] jam: so, shall I uncommit the previous revision, reinstate the close on StopIteration, and push --overwrite? [10:15] jam, hi [10:15] you can dial in if you like [10:15] also i was wondering if it would work for you to benchmark on gcc-linaro rather than a synthetic tree [10:15] poolie: I'm dialed in [10:16] just on mute because they are doing construction here [10:16] poolie: I did it on gcc-linaro [10:19] yay, blackbox tests completed with 160 open files max [10:19] o/ LarstiQ [10:19] great [10:20] i wonder if we can add assertion there are no more open files from the start of a test to an end [10:20] well, not specifically an assertion, but eg a fixture [10:46] mgz: I'm fixing the remaining cases of file(path, mode).write(content) in the blackbox tests [11:05] jam are you still there and muted? [11:05] i'm just putting statik's graphs onto the blogpost [11:05] i love how the right hand bar is basically imperceptible [11:05] Hi, is there a pre branch hook? I can't seem to find one? [11:05] LarstiQ: cool. do refer to that webpage I posted earlier if it helps you see which tests don't close files. [11:06] mgz: I got the ones done that were causing failures in blackbox [11:07] loads more of occurences that don't cause immediate failures, but won't tackle those right now === jam1 is now known as jam [11:07] mgz: http://float.endofinternet.org/xmlbin/newtestresult makes my browser unhappy :) [11:09] yes, that's the problem with the number of tests bzr has... I need to remember one of the blackbox-only runs [11:10] * LarstiQ is running all the tests now [11:10] * LarstiQ knows of 3 failures in blackbox: 1 LocaleError, and two cases where the order of files returned is different than under cpython [11:11] we'll see if there are any outside [11:11] in, oh, 2 hours [11:11] mgz: is the width of an entry relevant there? [11:11] I don't quite understand the narrow grey vs the wide green, etc. [11:13] the wide ones are tests [11:13] the narrow ones are containers, test class, module etc [11:13] click the narrow one to expand all the tests in that class [12:01] mgz, LarstiQ: the fp.close() change has landed in bzr.dev 5890 [12:13] jam: cheers [12:13] bah [12:13] pypy oomed :/ [12:14] LarstiQ: is there a way to ask pypy to run the garbage collector more often? [12:14] jam: --jit threshold=N maybe [12:14] * LarstiQ looks for more documentation [12:15] or, now that I think of it, that probably has to do with how often code runs before it is cached [12:16] LarstiQ: AIUI, pypy has higher memory requirements than CPython, but mostly for the code parts, not necessarily for the data parts [12:16] though how would you OOM from code parts? [12:17] * LarstiQ has trouble reading the oom-killer output [12:19] jam: http://paste.ubuntu.com/609458/ fwiw [12:20] * LarstiQ does have a fairly memory constrained setup, and no swap [12:20] LarstiQ: not that I know what to do with that :) [12:20] jam: you're good at making sense of things ;) [12:20] offhand it looks like you were about 1.5GB which would certainly be oh-crap big [12:21] are you in 32-bit or 64-bit? [12:22] 32bit, and 1.5GB is the amount of physical memory I have [12:34] jam: trying PYPY_GC_MAX=50MB now [12:39] vila: set_last_revision_info *is* an RPC, but we always allow VFS fallbacks. so it is possible for clients to override if they get really clever, or run old versions of bzr [12:39] so in the "I haven't tested this" I think if the server says "append_revisions_only=True" then it will be refused [12:40] jam: yeah, I know this will take time to be truly fixed :-/ [12:40] jam: but I'm happy enough with what we already have in the mean time [12:45] jam: also, IMHO, the "flaw" I'm referring to is that we shouldn't *blindly* allow overriding server settings [12:46] vila: believing that a pure client will respect server settings is flawed [12:46] someone can always hack the client to not [12:46] making sure that it is enforced *by the server* is a much better way [12:58] vila: and then we disable VFS [12:59] jam: sure, we can enforce that for a smart server but we should also try to have a reasonable behavior for dumb servers [12:59] jam: I think we're are in violent agreement here ;) [13:00] vila: I think having someone set it in locations.conf is not much removed from someone hacking branch.py to ignore the value [13:00] it is slightly easier, but they need to know to do it [13:01] jam: s/removed/remote/ ? [13:02] jam: what do we do with https://code.launchpad.net/~songofacandy/bzr/fix-523746-dev/+merge/20537 [13:03] right, but you mentioned consenting adults, so my point is that we should be clearer for the users about what *can* be safely overriden in locations.conf and what shouldn't [13:04] vila: someone setting append_revisions_only = False in locations.conf could almost as easily change branch.py to ignore the setting [13:04] so if someone is going to hack their client to get around a setting [13:04] they're going to do it anywhay [13:04] ... [13:05] so lets make sure we do it correctly where it matters [13:05] and try to be nice, but we don't have to bend over backwards [13:05] vila: as said above, if they have direct write access they can also not hack bzr but just do [13:05] sftp .bzr/branch/last-revision sftp://REMOTE/branch/.bzr/branch [13:06] vila: so I file it under "I'm not worried about local settings overriding remote ones for cases where users can do the work anyway'" [13:06] dumb servers can't enforce anything obviously [13:06] jam: I think perhaps vila's point is that it's surprising to users, not that users can do it anyway [13:07] what I want is that a smart server admin can say: this is my server, you can access it only with bzr+ssh, and don't mess my append_revisions_only, ok ? [13:07] we are not there yet [13:07] vila: we are if we were at the point that you could disable VFS [13:07] so lets do that instead [13:07] no [13:08] even with no vfs we don't forbid overriding in locations.conf [13:08] vila: with no vfs the *server* will enforce append_revisions_only [13:08] but yes [13:08] set_last_revision() is already calling an RPC [13:08] let's get rid of vfs first [13:08] and I'm sure the server can't read my locations.conf fil/e [13:08] file [13:08] vila: well, if the server is enforcing it what the client's config thinks is a bit irrelevant. [13:11] really ? Even when we create the branch ? Where is append_revisions_only is coming from ? [13:11] and what if I just use bzr config -d remote a_r_o=False ? [13:12] The server may have a plugin installed that always sets that flag when creating branches. [13:12] It could even have a plugin that intercepts config update RPCs. [13:12] right, there are various ways to solve the issue, but there still is an issue ;) [13:14] Or perhaps the server's locations.conf globally enables append_revisions_only ;) [13:15] spiv: indeed, but this works only for the smart server since we don't even try to read the remote locations.conf for the dumb ones [13:15] Of course, but we were discussing the smart server case. [13:15] and that's the flaw I'm referring to, the actual model has some dark spots [13:15] * vila nods [13:15] There's no ambiguity about what dumb servers do :) [13:16] I'm worried for people that don't realize that running both a smart server *and* a dumb one can have surprising effects [13:16] Conflicts during merge: Text conflict in doc/en/release-notes/bzr-2.4.txt [13:16] * spiv blinks [13:16] and until recently even lp was running both a smart and an sftp server right ? [13:17] vila: still is [13:18] I think people aren't too surprised by "you can set a setting in multiple places, and if you do and they disagree, then you might have to think carefully/experiment to find out which value wins" [13:19] spiv: hmm, right, so I don't want to discuss to much on that now but can we agree that there are some confusing scenarios around ? [13:19] spiv: yup [13:20] In general our story for "I'm an admin of a bzr host, and I want to set policies for the branches/repos" is pretty lacking. [14:17] spiv: yes, thanks, that's I was trying to express :) [14:17] s//what/ [14:18] it's related to the way we [should] handle BranchConfig and RemoteBranchConfig (or even RemoteConfig) [14:21] http://bazaarvcs.wordpress.com/2011/05/17/faster-large-tree-handling/ this seems really interesting, is there some more benchmarks planned for when this is merged? [14:21] comparing to mercurial and git, etc [14:23] I do know that the guy that did some benchmarks for bazaar passed away but this looks like a huge speed gain for it [14:31] santagada: yes, we probably will [14:31] do comparisons [14:31] jam, still here? want to join us? [14:32] hrmf [14:33] someone with more memory will need to run the complete testsuite under pypy [14:33] cos it leaks? [14:33] LarstiQ, if you have a simple step by step I can run it here (4gb 64bit linux) [14:34] poolie: at 1.0GB rsize my oom-killer won't let it live anymore [14:34] santagada: just a sec [14:36] LarstiQ, do you want to run it on trunk or 1.5? I would recommend trunk [14:42] santagada: I've been using a 1.5 binary, but if you can try pypy trunk that would be nice too [14:42] * LarstiQ has no resources to translate it himself [14:43] santagada: once you have a copy of lp:bzr and pypy, it is just "pypy ./bzr selftest | tee selftest.log" [14:45] LarstiQ, will do... will take some time to download lp:bzr [14:46] santagada: that's ok with me [14:46] maybe I should update bzr first (2.3.1 here) [14:46] santagada: where is it at now? [14:47] I think the daily nightly has some of the patches I just pated here so it should be faster at checkout stuff [14:48] santagada: the 2.4 fixes are about a local checkout afaik, the issue is working tree handling/building, not network transfer [14:49] santagada: are you branch over http or bzr+ssh? (ie, is your launchpad-login set) [14:49] santagada: do I understand correctly you already have pypy setup? [14:54] bzr: ERROR: No module named testtools [14:54] LarstiQ, bzr: ERROR: No module named testtools [14:55] santagada: ah, right [14:55] LarstiQ, I use bzr+ssh, and I have pypy-1.5 and the latest nightly installed [14:55] santagada: cool :) [14:56] * LarstiQ growls at browsers [14:57] santagada: you can download testtools from pypi.python.org [14:57] untar it, and run `pypy setup.py install` [14:57] LarstiQ, ok [14:57] possibly you could get away with importing it from cpython site-packages, but this is quick enough [14:59] LarstiQ, installed in both pypy version... it is running 5/25157 [15:00] santagada: thanks! [15:00] just to be clear, tests are probably going to be slower or the same speed as cpython [15:01] not much the jit can do about those [15:01] LarstiQ, I could also run some benchmarks if they are as easy as this selftest thing [15:02] santagada: they're quite a bit slower ime [15:02] santagada: that would be good too, let me see if I can figure out how the benchmarking is done [15:03] I would guess merges are going to be faster if using this new ordering/data structure [15:05] santagada: https://launchpad.net/bzr-usertest replaced the old selftest --benchmark apparently [15:06] should I stop the selftest? [15:06] 118/25k [15:06] santagada: please let that run (first) [15:07] santagada: I'm aware of a couple of failures on pypy, but I'd like the complete set run now [15:07] the docs on that page point to a user that doesn't exist anymore on launchpad [15:07] it is probably similar to what Naoki reported, but want to be sure [15:07] santagada: yeah :/ [15:08] LarstiQ, I'm running on nightly so you don't report on issues already solved. After I can run on pypy-1.5 just for comparisons [15:08] poolie: https://launchpad.net/bzr-usertest links to http://people.ubuntu.com/~ianc/plugins/usertest/doc/ [15:08] poolie: which no longer exists [15:09] santagada: right, I'm reasonably confident they're bugs in bzr depending on cpythong behaviour, but extra confirmation doesn't hurt :) [15:09] hm [15:10] i wonder if i can still get it out [15:10] or perhaps i have a copy [15:10] LarstiQ, cpython [15:10] :D [15:10] argh [15:10] santagada: indeed [15:10] pythong would be a good 1st April joke [15:11] I think it's been made before [15:11] a leaner python or something [15:38] LarstiQ, 701/25k I think this will take a lot of time [15:39] santagada: hmm, I'm inclined to say that seems to go slower than it did on my netbook? [15:40] santagada: if you don't mind running it, I can wait [15:40] or rather, do mathematics in the mean time :) [15:45] vila: http://people.canonical.com/~mwh/bzrlibapi/bzrlib.html [15:45] Riddell: thanks ;) [15:49] Riddell: http://doc.bazaar.canonical.com/bzr.dev/developers/integration.html and http://doc.bazaar.canonical.com/bzr.dev/developers/overview.html were those docs I just mentioned [15:49] (in case you hadn't already seen them) [16:18] santagada: hmm, we might actually have found a pypy bug [16:18] I'm trying to use bzr just to download some source code... I don't even know what that is called in bzr-lingo. I can't find any docs basic enough to help me, is there a good starting point doc-wise? [16:18] LarstiQ, what? [16:19] quiznilo, I don't know for sure, but "bzr checkout --lightweight lp:" might be exactly what you want [16:19] santagada: you might not have seen the failure yet, but you made me ready for the posibility it might not be bzr :) [16:20] thank you sir [16:20] santagada: locale.setlocale() raises different error classes between python and pypy it seems [16:21] santagada, quiznilo: --lightweight isn't really designed for non-local usage, so that might be slower than just `bzr branch lp:` [16:22] unable to authenticate to SSH host [16:22] I'm just downloading, I'm not uploading... [16:22] LarstiQ, my log for now http://nopaste.linux-dev.org/?11997 [16:23] quiznilo: if you have launchpad-login set, bzr will use ssh also for download because it can be faster that way [16:23] so unset launchpad-login? [16:23] quiznilo, I think launchpad should have a tarball download option you should probably fill a issue somewhere [16:24] quiznilo: that, or login, or there is some way to turn ssh off [16:24] quiznilo, yep, or send your ssh-key to launchpad [16:24] * LarstiQ looks it up [16:24] this is windows lol [16:24] I don't have a ssh-key [16:24] ok then just unset it [16:24] if you just want to look at code [16:24] santagada: hmm, blackbox.test_info.TestInfo.test_info_locking is new to me [16:25] LarstiQ, this is running with the latest pypy [16:25] santagada: that, and mgz turned on unexpected successes counting as failures today or yesterday [16:25] but he's not online atm [16:26] * LarstiQ is currently looking into that LocaleError [16:26] LarstiQ, I leave work in 2 hours, but I will let this running [16:26] santagada: cheers [16:27] the mbcs one is also new to me, but the rest I've squashed [16:30] there is no 'bzr unset' command or anything else to unset my user [16:40] james_w: Thanks for the approve on lp:~maxb/udd/explanations - just to note, I don't have landing access - will you land, or shall I ask one of the folks at the bzr sprint with me to do so? (Or is it acceptable for me to be added to ~udd ?) [16:41] maxb, I don't think there would be an issue with you being in ~udd, let me add you [16:42] quiznilo, I don't know, maybe edit the bzr config by hand [16:43] maxb, added, please go ahead and land [16:43] Thanks, will do! [16:48] santagada: https://code.launchpad.net/~larstiq/bzr/bzr-pypy/+merge/60986 fwiw [16:49] quiznilo: there is bzr config, which has a --remove option [16:52] k [16:53] LarstiQ, my user is santagada on launchpad.net also [16:53] http://howto.praqma.net/bazaar/bazaar-on-windows <-- helped with SSH issues [16:53] santagada: stable usernames are so convenient :) [16:53] quiznilo: good [16:59] bzr checkout lp:IrcDotNet <- yeilds: bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/%2Bbranch/IrcDotNet/". === beuno is now known as beuno-lunch [17:00] I know the project has a link to the 0.4.0 SRC, but I was told to use BZR to download 'tip' [17:01] quiznilo: the projectname appears to be lower case [17:01] I think he said 'tip' [17:01] quiznilo: lp:ircdotnet exists [17:01] hmm [17:01] there it goes... I think [17:01] quiznilo: 'tip' means the most recent revision (on a branch, in this case lp:ircdotnet is assumed methinks) [17:02] well, it's a bit more general in say mercurial, but never mind that :) [17:02] I think I got it, thanks for your help, I've never used a VCS system before beyond: git co git://whatever [17:09] quiznilo, if you plan to program you should learn at least one [17:09] quiznilo, and use it [17:13] I've been programming for years [17:14] thanks for the help === hunger_ is now known as hunger === deryck is now known as deryck[lunch] === beuno-lunch is now known as beuno === deryck[lunch] is now known as deryck [18:52] o/ jam [18:52] hi poolie, just casually around [18:57] np, hi [18:57] I have this update_basis_by_delta monkey on my back [18:57] I can't shake it :) [19:01] http://www.pixoulphotography.com/2011/05/18/official-uds-o-group-photo-and-personal-photo-set/ nice === BasicPRO is now known as BasicOSX [19:53] jelmer, maxb: thanks for all the branches/fixes [19:53] I guess you've finished for the day now, so I can get back to work ;-) [20:01] james_w: Hey :) [20:02] james_w: Sorry (: Thanks for the quick reviews, that's really useful. [20:02] no problem [20:02] I'm only kidding [20:02]