[00:00] ok [00:01] done [00:11] New bug: #165086 in bzr "bzr ls doesn't accept -V" [Undecided,New] https://launchpad.net/bugs/165086 [00:12] thanks === kiko is now known as kiko-zzz [02:03] poolie_: down to 4 failures [02:03] poolie_: 2 with this CRC thing [02:03] poolie_: 2 with the one you are patching [02:04] cool [04:16] poolie_: 6 tests to go [04:16] can run just upgrade repository_imp tests to see them [04:19] poolie_: I'm finishing now for the day [04:20] k [04:20] have a good night [04:20] you too [04:20] i am reasonably confident i will fix this today [04:20] cool [04:51] New bug: #165106 in bzr "check that get_data_stream distinguishes annotated and unannotated knits" [High,Incomplete] https://launchpad.net/bugs/165106 [06:52] morning all [08:03] hello vincent [08:03] poolie_: hi :) [08:05] working on bug #165061 I get a traceback when branching a pack repository into a fresh branch (i.e. no repo sharing) mentionning bzr: ERROR: Revision {robertc@robertcollins.net-20050919044328-0205c679f3051340} not present in "". [08:05] Launchpad bug 165061 in bzr "bzr branch http:// with a pack repository takes too long" [High,Triaged] https://launchpad.net/bugs/165061 [08:05] does that ring a bell ? [08:08] vila, that might be bug 164637 that i was just working on [08:09] Launchpad bug 164637 in bzr "hpss data_stream from pack repository has deltas out of order, fails with KnitCorrupt exception" [Critical,Fix committed] https://launchpad.net/bugs/164637 [08:10] ok then, seems a bit surprising that robert did not encounter it, but it's not blocking for me (investigating the bug I mean), I'll watch for your patch anyway [08:54] vila: that particular repo is unreconciled and buggy [08:54] vila: so don't worry about that error at the end [08:54] lifeless: ok [08:54] vila: it wasn't relevant to the bg so I didn't mention it:) [08:54] ;-) [08:57] lifeless: what is your latency against that branch ? [08:58] lifeless: well, not *yours* as such, your computer's (before fullermd made any remark ;) [09:02] hi bzr rockers [09:03] bzr-svn just stopped working for me and now complains about a "scheme are not unique" IntegrityError in sqlite; is that really due to bzr-svn, or did something change in bzr itself? [09:03] I filed it as bug 165136 for now [09:03] Launchpad bug 165136 in bzr-svn "svn+ssh:// push: IntegrityError: columns max_revnum, min_revnum, path, scheme are not unique" [Undecided,New] https://launchpad.net/bugs/165136 [09:06] hi pitti [09:06] pitti: what version of bzr-svn are you using? [09:06] hey jelmer! [09:06] 0.4.4-1 [09:06] * pitti is on current hardy [09:07] pitti: you may be able to fix it by blowing away the relevant unique index [09:08] * pitti tries to make a clueful face about what that means [09:08] sorry for for being vague :-) [09:09] if you open the bzr-svn cache for the repository in question, you should be able to remove the index that is causing problems [09:09] a workaround would be very much appreciated indeed :) [09:09] the simplest thing to do would be to remove ~/.bazaar/svn-cache/ and try again [09:09] ah, in ~/.bzr/svn-cache [09:09] awesome [09:10] assuming you've used different versions of bzr-svn on the same machine before? [09:10] yes, I did [09:10] at least 0.4.1 on gutsy, but probably older ones, too [09:10] yay, that helped [09:11] jelmer: you saved my day, thanks; I'll mention the workaround in the bug report, for others who might have the same problem [09:11] pitti: cool [09:11] pitti: btw, now that you're here.. [09:11] I much appreciate the editmoin package [09:12] * pitti loves it, too [09:12] but it's only included in Ubuntu, not in Debian yet - are you a DD? [09:12] yes, I am [09:12] jelmer: indeed, I'll file an ITP now, and upload it in a bit [09:13] pitti: Thanks, that would be very nice :-) [09:21] jelmer: ITP sent [09:21] thanks for the poke; it was on my list for a long time, but I forgot about it [09:29] vila: home to uk [09:29] vila: so lots, but we only do four reads, so it shouldn't be a significant factor [09:30] you do 62 requests, 4 of which are readv for the pack (one failing so that makes 5) [09:31] # requests: 62 [09:31] Bytes read: 68437333 [09:31] Bytes written: 0 [09:31] Average latency: 1588ms [09:32] that's for fr to uk with a ping of ~20ms, so the http server do quite some work before replying... [09:33] that's from transportstats plugin, but the 68M figure may be skewed by the retry [09:35] New bug: #165136 in bzr-svn "svn+ssh:// push: IntegrityError: columns max_revnum, min_revnum, path, scheme are not unique" [Undecided,New] https://launchpad.net/bugs/165136 [09:36] Morning bazaaristas [09:37] scratch that, the retry doesn't appear in the stats, so the 68M is correct and coherent with du -sk pack-branch-speed [09:37] 63336 pack-branch-speed [09:48] lifeless: reading your report again something strange appears, read my additional comment on the bug report [09:49] lifeless: if you can mail me your .bzr.log it could help too [09:49] lifeless: and tell me if you use pycurl or ulrlib [09:49] :) [09:55] vila: uhm, I dunno. whatever. [09:56] vila: pycurl is installed [09:56] ok, so it's used [10:03] vila: so, I know a root cause of the problem [10:04] vila: look in pack.py at make_readv_reader or whatever it's called. [10:06] yes, and ? [10:07] lifeless: ouch the retry request 55M [10:07] right [10:09] lifeless: is there any hack to allow backslashes to be added to inventories but not considering them path separators? [10:09] jelmer: I hope not. [10:09] I'm trying to decide how to solve bug 163858 [10:09] Launchpad bug 163858 in bzr-svn "bzr-svn cannot check out lintian repository" [Undecided,Confirmed] https://launchpad.net/bugs/163858 [10:10] lintian contains filenames with a backslash in them [10:10] so far, the only solution I can think of is ignoring such files [10:10] as well as non utf8 chars [10:11] my opinion on this is that if you want stupid characters as test data, its appropriate to construct these at runtime, not version the fuckers [10:11] argh, and then, the transport remembering that a previous multiple range request failed stays on single range mode and issues one 57M request [10:11] vila: and there we go, problem found [10:11] lifeless: here is the problem [10:11] lifeless: sure, but the problem is you can actual control what users can version whereas I can merely deal with what has already happened :-) [10:12] jelmer: I would escape it [10:12] jelmer: this affects ~vcs-imports fairly frequently too, of course [10:12] jelmer: hex or otherwise encode everything that's not valid [10:12] lifeless: that means I have to deescape as well [10:12] then a pair of plugins for tree operations can make them be as broken on disk as the user may desire [10:13] lifeless: and potentially interpret filenames that were never escaped things at all [10:13] lifeless: yup, problem found, the 4 readvs ends up transferring 5,8M, 25M, 55M and 57M [10:13] mwhudson: what does lp do? Escape? [10:14] jelmer: there is a hard choice here. Either we allow any pathname, or we don't :). Converters naturally want the widest range of characters - no artificial limits. [10:15] jelmer: fail [10:16] mwhudson: fail as in fail to import the branch? Or simply fail for that one file and skip it? [10:16] jelmer: fail to import the branch [10:21] jelmer: to date, our approach has been to require paths to be valid utf8 and not directory separators on any platform. [10:21] jelmer: IIRC lintian's tree has more than just \'s that are a problem, which is why I'm not getting excited about it - because we need to handle the fact that we can't encode the other paths either [10:23] lifeless: Sure, but there will be other repositories with just one file with a backslash or non-utf8 character in their name [10:25] at the very least I'll make bzr-svn throw a comprehensible exception, but I'd like to fix it if possible [10:25] jelmer: I think encoding is a decent answer. You can list all the encoded files in a rev in a rev property; so that you don't decode user files that happen to be encoded [10:25] paths with \ and non-utf8 chars are really unportable anyway [10:27] lifeless: that's a nice idea [10:27] would require a mapping upgrade though :-/ [10:28] * jelmer sees another use for custom file properties, storing the original name of files that are encoded [10:28] well [10:29] or maybe custom file properties are like a hammer to me.. [10:29] yup [10:29] they are [10:29] I guess I've spent too much time working with svn where everything is stored in properties [10:29] encoded_paths: {file_id:(path, orig_path)...} is all you need [10:29] properties are evil [10:30] properties are good [10:30] we could store them in extended attributes! [10:30] * jelmer gets all excited [10:30] at the core of the system, a dict like mechanism is a useful implementation strategy, but its a terrible API [10:30] :-P [10:32] I agree they're a storage mechanism, not fit as an API [10:35] $ getfattr -n user.bzr-svn.original_name foo.txt [10:35] <<<< THIS [10:35] ... [10:36] :) [10:38] jelmer: and svn's heinous mistake here is to expose them as an API. [10:38] mwhudson: I'm a hurta youa [10:42] lifeless: I think the main problem with svn is that exposes the property API as the primary UI and API for managing externals or ignores [10:42] gnight [10:42] exposing the property API in general isn't a problem [10:42] night lifeless === cprov-away is now known as cprov [10:50] New bug: #165151 in bzr "Silently ignores add of file "\\"" [Undecided,New] https://launchpad.net/bugs/165151 [11:39] jelmer: btw, my second attempt at pushing to pydoctor worked fine [11:39] (not sure if i mentioned this last night) [11:44] mwhudson: ah, cool [11:44] so it appears the ulimit was the problem? [11:44] jelmer: i have no idea === kiko-zzz is now known as kiko [12:56] can lock_read() fail? [13:13] mwhudson: It can fail for working trees if they're already locked. I don't think it can fail for branches or repos. [13:14] modulo system-type errors like MemoryError... [13:14] abentley: just looking at Merge3Merger.__init__ which will leave the working tree locked for writing if a lock_read fails [13:16] That would be a bug. It was written before WorkingTree.lock_read was expected to fail. [13:16] gotta run. [13:16] ok === cprov is now known as cprov-lunch [13:38] * mwhudson stabs python's __ mangling === mw|out is now known as mw === kiko is now known as kiko-fud === vila_ is now known as vila [14:20] abentley: yay, i managed to get diff-as-merged to work using TransformPreview for a launchpad merge! [14:21] (took 4s vs 215s :) [14:21] i had to comment out lots of stuff to do with conflict handling, mind [14:21] * mwhudson goes back to look at that [14:25] abentley: bundlebuggy's version is currently at 1.0 - are you sure it shouldn't be 0.x ? [14:26] (just checking, otherwise I have to mess around with versions in Debian later on) [14:46] hi [14:46] is it me or bzr (0.92) does not respect my umask? [14:47] I have a umask 077, it seems to me that bzr always applies umask 022 [14:52] * Nafallo spreads the love off bzr on the office :-) [15:12] abentley: hi === kiko-fud is now known as kiko === cprov-lunch is now known as cprov === me_too is now known as too_short === too_short is now known as me_too === me_too is now known as too_short === too_short is now known as me_too === me_too is now known as too_short === too_short is now known as me_too === me_too is now known as too_short === too_short is now known as me_too [17:11] New bug: #165215 in bzr "pull overwrite does not always find revisions after bind" [Undecided,New] https://launchpad.net/bugs/165215 [18:52] hey all. I've been giving bzr a test drive vs. mercurial and have a couple questions [18:53] I'm primarily hoping to use one to enable home directory sync between a desktop and a laptop, and I'm wondering how soon bug #107967 will make it to a release? [18:53] Launchpad bug 107967 in bzr "Using bzr mv --after on a directory (as opposed to a filename) fails" [Medium,In progress] https://launchpad.net/bugs/107967 [18:54] n[ate]vw, version control systems are not a good way to do that [18:55] they are good at ... controlling versions of files, not syncing workspaces [18:56] * dato recommends unison instead. [18:57] yeah, I don't really need the version history (although I can imagine scenarios where it'd be nice), and some of this stuff will be binary files (although I'll probably manage photos/music externally) [18:59] any suggestions for a painless sync system? don't want to pay for .Mac (rumored slow, still not enough space to be worth it) and am not sure how much of a pain it is to set up a Home Sync without OS X Server [19:00] to complicate matters, I really don't want my complete home directory synced. I'd like to keep separate desktops, and don't have room on the laptop for all my photos, etc [19:03] I'll check out Unison again, thanks, I'd forgotten about that. [19:04] I'm still a bit lured by the siren call of http://www.onlamp.com/pub/a/onlamp/2005/01/06/svn_homedir.html, especially with the advantages of DVCS [19:20] on another note, is there anybody on who uses both bzr and Xcode? I'm wondering if there's a good way to take advantage of Xcode's SCM integration, although only CVS/svn have out-of-box support [19:46] n[ate]vw: I'm not aware of a bzr/Xcode user, but we'd sure love someone to write the plugin for XCode :) === mw is now known as mw|food [20:21] New bug: #165255 in bzr-eclipse "NullPointerException in share project dialog" [Undecided,New] https://launchpad.net/bugs/165255 [20:31] vila: so, you hav figured out the problem; what next - whats the easiest way to download only what we need ? [20:32] lifeless: fix still not written (RL), but I've looked at the code and I may avoid rewriting response.py and just rewrite _readv [20:33] seems to me _readv can act as a generator quite easily [20:33] yes [20:34] let me know if you need anything for this [20:34] I'm to tired to do that this evening, but I think tomorrow will be ok [20:34] because Martin wants to make packs default real soon (days) [20:34] and IMO this would be a black eye for bzr :( [20:35] the actual implementation is correct but yes, http should behave :) [20:35] first this bug, then getting rid of file in memory [20:36] will it be ok to keep 65K in memory and switch to a temp file above that ? [20:36] 65K being a class constant [20:36] uhm [20:37] why the temp file? (you'll fragment disk and IO patterns) [20:37] I'd really not want anything touching disk until we're downloading about 80% of main memory [20:38] better still would be to just provide the data as you get it in reasonable amounts (note that if the caller used get_file_bytes we're asking for it in memory anyway) [20:38] that'd force everything out of my cache though [20:38] radix: how much mem do yo uhave? [20:39] 2GB [20:39] lifeless: yeah, thanks for refreshing these bits, I lost context, I'll go to sleep with that in mind then ;) [20:40] so, 1.6GB of version control history is needed for my statement; and if we did get a 1.6GB single pack and streamed it to disk, then read it back - what do you think will happen to your cache then ? [20:41] radix: the OS has a swap file for exactly this reason; if our access pattern to 1.6GB of memory is the same as it would be to a 1.6GB temp file (it will be) then there's no basic difference, except our code is simpler. [20:41] lifeless: ok :) [20:42] really though, buffering of any sort is the problem, and its that that we need to fix [20:42] because waiting for 1.6Gb to download before we start processing is silly, and waits a whole lot of concurrency === mw|food is now known as mw [20:54] hey I need to help someone on windows to learn bzr, is there any good gui? the tortoise one seems rather incomplete? [20:54] * AnMaster uses FreeBSD/Linux himself [20:55] AnMaster: qbzr is quite good from what I've heard [20:56] jelmer, any link? [20:56] AnMaster: http://bazaar-vcs.org/QBzr I think [20:56] qt? hm qt is for windows? [20:56] qt is the kde toolkit [20:56] I know that [20:57] is multi-platform [20:57] didn't know the window version was free though [20:57] lifeless: "the toolkit that kde uses", to be precise ;) [20:57] thought it was closed [20:57] not since v4 [20:57] dato: pedants of the world unite [20:57] * AnMaster is a KDE user himself [21:00] New bug: #165259 in bzr-eclipse "Does not recognize branches sometimes" [Undecided,New] https://launchpad.net/bugs/165259 [21:01] luks: did a class-dump of /Developer/Library/Xcode/Plug-ins/XcodeSubversionPlugin.xcplugin/Contents/MacOS/XcodeSubversionPlugin, but might wait until http://lists.apple.com/archives/xcode-users/2007/Jan/msg00072.html comes true to invest much into it. plus I'm still testing Mercurial as well ;-) [21:08] AnMaster, qbzr is not really a "bzr gui" [21:09] oh? [21:10] luks, I'm used to command line, the user I'm trying to introduce to bzr is not [21:10] so now what? [21:10] then qbzr is not what you want :) [21:10] olive perhaps [21:10] luks, what do I want then? [21:10] (the bzr-gtk gui shell) [21:11] I don't think there is anything complete [21:11] hm :( [21:13] I was tempted to build a GUI application around qbzr a couple of times, but bzrlib doesn't really make it easy to make something usable :( [21:14] luks: huh? We've put quite some effort into making it wrappable; please do file bugs anywhere you find it hard to use the library directly. [21:15] lifeless, it's blocking by design and it touches a lot of global objects [21:15] which rules out either async event-based approach or threading [21:15] and running a separate process is bit too much [21:15] luks: we have one global, the ui_factory [21:16] lifeless, configs, registries, locks, ... [21:16] blocking by design is true, I ported bzr to twisted a couple of years ago but I got overrulled. [21:16] configs are not global, they are instances [21:16] registries are meant to be static once loaded [21:17] I had a lot of troubles when I tried to load log from a thread [21:17] locks are instances, where global state is used in a lock its to implement correct mutexing within a single process between instances and we'd love patches to make them thread correct if they are not today. [21:17] certainly LockDir locks do not need global state [21:17] luks: please please please file bugs; we need feedback on this. [21:18] there's no point having a strict library separation if it's not usable. [21:18] well, it is usable [21:18] for guis I mean [21:19] thats a major use case for the library [21:19] web apps is another, and they are often threaded [21:24] is there any way with bzr to force native line endings [21:24] like the svn property [21:24] nope [21:24] luks, any plans to add it? [21:24] yes [21:24] someone should write it as a plugin so we can evaluate it properly [21:25] then we'll probably fold it into a core [21:25] it is rather important for this project, compiler on either side will barf if native line endings are not used [21:25] :( [21:25] I don't think it will be possible to do from a plugin [21:25] so I guess I got to use svn for now then [21:25] at least not easily (without reimplementing most of WorkingTree functionality) [21:25] sigh [21:26] AnMaster: if you're the *nix guy, can't you just use an editor able to edit \r\n files? [21:26] luks: its totally possible to do from a plugin [21:26] lifeless, it would require a lot of code to trick dirstate [21:27] AnMaster: ouch, thats really interesting. Could you perhaps edit the wiki page about this to note this scenario ? [21:27] dato, yes I can edit such files the problem is the compiler used for the project always want native line endings, it will error out if CRLF is used on linux and plain LF is used on windows [21:27] luks: you don't need to trick dirstate [21:27] not ub to me [21:27] up* [21:27] AnMaster: ouch, baad compiler [21:27] lifeless, well, then converting the files every time it has to compare them, but that would be much slower [21:27] (compare == check if they are modified) [21:27] I can't give details about the compiler, it is internal to the company *growl* [21:27] and I can't fix that part [21:27] :/ [21:28] luks: dirstate should always reflect reality [21:28] dato, I fully agree [21:28] lifeless, that's the tricky party [21:28] you have two realities [21:28] repository and working three, both different [21:28] lifeless, and what wiki page? [21:29] http://bazaar-vcs.org/LineEndings [21:29] I don't think your particularly hard case is documented there today. [21:30] "The way mercurial recently implemented this seems like a good idea." <-- ah, *goes to look, at least that is better than svn, though I prefer bzr* [21:30] luks: anyhow, basically it comes down to this: Someone needs to write the code, plugin or branch of bzr.dev, I don't care. We need code that does the job without changing the storage model; as a starting point to evaluate. From there we can look at how to version the setting and how it should work. [21:30] AnMaster, the mercurial way is really bad [21:31] e.g. it very often marks unchanged files as changed [21:31] luks, hm I see [21:31] svn's way seems to work well [21:31] svn works well because it enforces line endings in a particular way [21:31] ok [21:32] both mercurial and git pretend they support LE conversions, but both suck at it for this reason [21:33] and bzr has a pretty high bar in our qa and design process [21:33] hm ok [21:33] we're not happy with cruddy solutions :) [21:33] and git I can't stand, way too many different commands [21:33] I always get lost trying to do simple stuff [21:33] AnMaster: I would say - use svn [21:34] lifeless, svk maybe then, kind of need distributed [21:34] AnMaster: bzr-svn is really cool; you can use that on the linux side :). And when we get line ending support for you migrate to bzr. [21:34] bzr-svn :) [21:34] heh [21:34] hm [21:35] also a lot of windows editors have a habit of storing mixed line endings [21:35] so lines you edit or whatever gets CRLF and the rest if left as is [21:36] hrm...is bzr-svn supposed to eat a lot of memory? [21:36] yes, it's a known bug either in svn or the python bindings [21:37] ah, that's right. [21:37] I had forgotten. [21:37] https://bugs.launchpad.net/bzr-svn/+bug/54253 [21:37] Launchpad bug 54253 in bzr-svn "Excessive memory usage in bzr-svn" [Undecided,Confirmed] [21:37] malept, uups forget it then [21:38] repo is like 5 GB iirc === cprov is now known as cprov-out [21:38] no wait, the source repo is 700 MB, the data repo is 5 GB [21:38] still [21:39] there's a workaround in the bug. [21:41] I'm actually seeing 800MB+ memory usage in a 150MB svn repo. [21:41] I'm going to see if it persists with the workaround. [21:50] found it! [21:50] breakfast, then I fix hpss for packs [21:52] hrm...I don't see much difference with the workaround. [21:55] hey jelmer [21:56] hi kiko [21:57] jelmer, I want to help you out with your question -- what packages do you need to maintain which you don't currently? there may be a misunderstanding. [21:57] kiko: I'm upstream and Debian maintainer for bzr-svn [21:57] but in ubuntu the package is synced from Debian [21:57] jelmer, okay. and what is it that you want to do that you can't? [21:58] so I can't actually change priority on bugs reported against the Ubuntu bzr-svn package [21:58] I'm not sure whether this is how it's supposed to work either [21:58] jelmer, gotcha. [21:59] jelmer, this is an interesting second case of a problem I've seen before. [21:59] jelmer, let me talk to brian murray. hang on. [22:02] kiko: ok [22:09] its correct [22:10] you need to be in ubuntu-qa to change priority [22:10] or in motu/core-dev [22:10] join motu :) [22:11] already on the list :-) [22:11] Debian Bazaar Maintainers is listed as maintainer though [22:11] and I am in that team [22:11] except that launchpad doesn't recognize it as a team [22:11] that's what my support Q was about [22:12] jelmer: on the list != being a motu; you'd probably breeze through the acceptance process [22:12] I think its correct as it is, because if you think about it it's not appropriate for someone outside the distro to say how important something is within the distro [22:12] thats a function of the distro's qa and work practices. [22:13] lifeless: I understand the theory behind it [22:13] ubuntu does not have maintainers [22:13] I take that back [22:13] the maintainer field has no meaning? [22:13] the package maintainer field? [22:14] yeah, as listed on the launchpad bug page [22:14] url me up [22:14] https://bugs.edge.launchpad.net/ubuntu/+source/bzr-svn/+bug/79333 [22:14] Launchpad bug 79333 in bzr-svn "Use commit notifier in SvnWorkingTree.commit()" [Wishlist,Confirmed] [22:14] has a box in the bottom that says "bzr-svn" source package, and who the maintainer is, etc [22:15] that's the bit that suggested to me that being in "Debian Bazaar Maintainer" would allow me to change the bug [22:15] but I guess it's just the field imported from Debian? [22:16] yah [22:17] in Ubuntu, any motu can upload any package in universe; there is no concept of NMU [22:17] and any core-dev can upload any package in main or universe [22:17] that said, people do specialise, and uploading e.g. a kernel when you have no idea about the kernels would be frowned upon, but the maintainer lock is well and truely gone. [22:18] its one of the major social differences between ubuntu and debian package management [22:19] teams are social grouping for people working on the same thing; we'd need to either a) only allow devs (core-dev + motu) into such teams, or b) ignore such teams for the purpose of access control, to do acl's sanely [22:19] we've chosen b) because that allows interested folk that are only prospective developers (aka going through NM) to participate more [22:20] from ubuntu's perspective you are currently a prospective developer, you haven't passed the assessment to get upload rights & all that comes with that. [22:20] ah, k - thanks [22:20] jelmer: and you totally should to that now!. kthxbye -> #ubuntu-motu [22:21] kiko: ^ [22:21] yean yean [22:21] lifeless: I did know the bit about not having maintainers, it was the fact that it actually listed a maintainer (with clickable address) that confused me [22:21] kiko: just making sure you'd seen it :) [22:22] yeah well === kiko is now known as kiko-zzz [22:22] time to enjoy the evening [22:26] night kiko-zzz [22:38] ok [22:38] NOW packs can run as default in terms of the test suite. [22:38] thumper: you vant a kall? [22:38] lifeless: sure, gimmie a minute, skype? [22:39] k [22:58] lifeless, jam: two minutes [23:00] poolie: are you going to ring-out? [23:00] poolie: or is it on the canonical conf server? [23:00] also, note that jam is not on IRC:) [23:00] on the conference centre today, i'll send mail about it [23:08] Good evening, folks. [23:08] poolie: ping [23:16] hi abentle1 [23:16] abentle1: poolie is on the phone with me [23:16] Hi there. [23:16] Okay. [23:17] I was just going to ask about the diff refactoring. [23:17] e [23:17] he's promised to look at it. [23:18] Okay. [23:18] I don't think it's urgent for 1.0, I'd just like to know. [23:18] I'd love to have it in [23:19] because then we can write crazy stuff like an adapter to read/use gits path attributes and diff control stuff [23:21] lifeless: your update and data size patches look good to me [23:21] +1 on both [23:21] lifeless: Yep, sounds crazy :-) [23:22] abentle1: on this patch: http://bundlebuggy.aaronbentley.com/request/%3C1196112144.32300.184.camel@lifeless-64%3E [23:22]