=== sdboyer_ is now known as sdboyer [00:08] poolie: have you read transition (iain banks) [00:16] maybe, is that the new one? [00:16] hi! does bzr support shallow clones? [00:19] domas: sorry, what do you mean? [00:20] domas: also if i got the chance to talk to you, are you now working on Cassandra? [00:21] I'm working on MySQL [00:21] At Facebook? Interesting development :) [00:21] why? [00:22] facebook is mysql shop, isn't it? :) [00:22] well, they released cassandra didnt they :) [00:22] you missed http://www.facebook.com/MySQLatFacebook?ref=nf ? :) [00:24] yes i did [00:25] anyways, let me answer to my best knowledge -- bzr does not support that but i am a humble bzr user not a developer. afaik bzr works with complete trees always. [00:25] hehe [00:25] or what you really mean by shallow clone? [00:25] yeah, I don't want to know everything about every revision ten years ago [00:25] Use a stacked branch? [00:26] works locally [00:26] not remotely :) [00:26] use checkout? [00:26] checkout --lightweight? [00:27] it won't be a branch then! ;-) [00:27] you can commit --local :) [00:27] hm! ;-) [00:27] not to lightweight. [00:27] domas: we don't support offline shallow clones [00:27] but normal co , yea [00:28] domas: we do support online shallow clones - thats a stacked branch. However we don't support committing directly to those yet. [00:30] chx: anyway, to answer properly your question, fb is very much mysql shop, Mark Callaghan started to work few months ago, I joined recently too [00:30] great [01:14] kfogel: hi, thanks for following up about the contributor agreement === mneptok is now known as weremnep === weremnep is now known as mneptok [01:41] all, please take a few stabs at https://answers.edge.launchpad.net/bzr/+questions?field.sort=recently+updated+first&field.actions.search=Search&field.status=Open&field.search_text= [01:59] i think stephen turnbull has managed to find a way to make his network connections travel faster than light... [02:08] mwhudson: ? [02:08] Peng: claiming that ssh vs not only makes a difference between 5 and 15 ms [02:08] 15 light milliseconds [02:08] 4486 kilometres, I think [02:09] lifeless: that's about what i came out with [02:09] hahaha [02:09] Heh. [02:10] If you use a master SSH connection, you don't have to reconnect every time. [02:10] I do that when I'm busy with LP. I figure it'd be rude to keep a connection open 24/7, though. [02:10] Peng: its still not long enough to send to the uk and back. [02:10] units\n15 light milli seconds\n kilometres [02:11] I know. I was just sayin'. [02:12] Peng: right [02:12] Peng: keeping an sftp connection open is fine [02:13] Oh? What's the difference? [02:13] and idle master connection is just a tcp socket [02:13] more-or-less [02:13] Oh, really? I would've assumed there was an sshd on the remote side. [02:14] sshd process* [02:14] if we ran sshd [02:27] lifeless: Oh. Right. [02:27] So, it's OK to leave a connection open? :D [02:35] if mwhudson says so [02:36] well if everyone did it life might get a bit interesting [02:36] but yes, it should be fine [03:15] <_Andrew> Anyone here used bzr upload? [03:15] <_Andrew> https://launchpad.net/bzr-upload [03:16] many people I think [04:20] If I'd like to use bzr-git, where might I best get it from? It doesn't seem to be in https://launchpad.net/~bzr/+archive/ppa === shikibu_ is now known as shikibu [04:22] Oh, looks like I opened a connection 7 hours ago and forgot. :D [04:41] poolie: I'd prefer a lawnmower shed. :D [05:02] lifeless: i guess discussing which of them is best is not bad [05:03] but ... random measurements of latency don't seem very correlated with that [06:24] EOD [06:39] hi folks, if i branch a lp:project and make my changes after this i push in other branch, that maintain the stack branch default? [06:42] ovnicraft: ....Yes? [06:42] ovnicraft: Pushing to LP will automatically stack on the project's development focus branch. [06:45] Peng, so the project what i branch has 53MB but pushing after my 2KB changes continue pushing in 70MB, this is for stack? [06:48] What? [06:59] * lifeless guesses a transcoding issue. [07:34] I'm so sorry to be dense, but am I missing anything on https://launchpad.net/bzr-git which would tell someone who knows better where to get a .deb of it from? [07:35] hi all [07:37] AfC: its packaged in debian(unstable/testing)/derivatives, if you want a newer version you might need to backport yourself. [07:37] Kamping_Kaiser: ah [07:37] Kamping_Kaiser: alright, thanks. [07:38] AfC: np... if you find a backport for debian stable let me know ;) [07:38] That's the second time today I've hit "seems like it's time to learn how to add Debian repositories to my /etc/apt/sources.list & pinning with /etc/apt/preferences" [07:39] hehe. advice: add the repos to sources.list.d/foo.list [07:42] Still; it doesn't seem unreasonable to wonder if we might get bzr-git & dulwich into the ~bzr/ppa [07:43] AfC: useful commands to know, #432, 'rmadison bzr-git' and 'rmadison -u debian bzr-git' [07:43] Not sure what might inhibit that. [07:43] afc, for ubuntu or for debian? [07:43] AfC: also apt-cache policy bzr-git [07:43] poolie: Karmic [07:43] presumably for ubuntu [07:43] rmadison? [07:43] AfC: 0.4.1-1 is the version in Debian, and in ubuntu: [07:43] sounds even more like something pornographic [07:43] bzr-git | 0.4.1-1 | karmic/universe | source, all [07:43] anyhow, good night [07:43] bzr-git | 0.4.1-1 | unstable | source, all [07:44] poolie: :P remote madison [07:44] :) [07:44] i did guess actualyl [07:44] lifeless: jeesh! so it is. [07:44] Not sure how I missed that. Whatever I searched on didn't turn it up. [07:45] Oh, well, I looked at the bzr PPA page, since that's where I get Bazaar from, and so the absence of bzr-git there threw me. [07:45] lifeless: so; _would_ it be appropriate for newer releases of bzr-git & dulwich to be in ~bzr/ppa? [07:48] AfC: yes [07:49] * vila disclaims: I may not be the one doing it :) [07:50] vila: sure [07:50] * AfC gets that [07:51] AfC: But I was as surprised as you to not find it in https://launchpad.net/~bzr/+archive/ppa [08:30] hi [09:14] are branches directories like in svn or histories like in git? [09:16] they are like in bzr [09:16] * chx grins [09:17] donri: yes a branch is a directory but unlike in svn it's one unit you can't checkout a subdir or commit it. [09:17] donri: and that's a GOOD thing. One of the reasons I love bzr. [09:19] uhm. i can't stand thingsl like /project/trunk :/ [09:19] so don't name them that way [09:20] donri: every branch in bzr is like separate clone in git [09:21] sounds expensive [09:21] hello vila, have a minute? [09:21] donri: yeah, and we have rich-roots in addition [09:21] directories cost up to 4KB of disk [09:22] bialix: ask your question :) [09:22] so bzr is for rich people. perhaps [09:22] bialix: and hi ! [09:22] vila: about real gui testing in qbzr [09:22] maybe it's good idea to check some env variable and skip those tests? [09:22] e.g. QBZR_DISABLE_GUI_TEST [09:22] or something like that? what do you think? [09:22] a git clone holds complete history, usually quite more than 4kb [09:23] donri: yep, bzr too [09:23] last i checked, disk space, for all practical usages was free. (youtube videos are not practical :p) [09:23] donri, but you can cheat and use shared repo [09:23] so if i want a topic branch, i have to copy the whole project? [09:23] donri: of course not [09:23] bialix: That's a good workaround if you can't find a better way, at least on unix, DISPLAY should be set if you want to be able to display anything, I guess it doesn't matter on windows [09:24] bialix: what is your motivation ? [09:24] vila: yep, it does not matter on windows, I wanna cross-platform way [09:24] to check what ? [09:24] that a display is available ? [09:24] vila: I'll add more of such tests, trying to figure out how's better layout our tests [09:25] so if i want a topic branch, i have to keep a directory both for the source branch and the new branch? i quite like the cleanliness of gits "one directory, use commands like checkout to change state" [09:25] no, I'm just want a useful knob to disable them sometimes for speed reasons [09:25] a test feature, then you can decide how probe() should behave [09:25] donri: what's your interest in bzr? [09:26] donri: look http://oxygene.sk/lukas/2009/10/working-with-branches-in-bazaar/ [09:27] donri: first you have to understand the difference between a branch and a working tree, in both bzr and git branches are cheap, but in bzr the default workflow creates a working tree for each branch. If you don't want that behavior you have to work a bit more [09:28] vila: another possibility is to separate gui and non-gui tests to different subpackages and control with selftest regexp [09:28] I don't use git, but I'm pretty sure you have several working trees by working a bit more too [09:28] bialix: that's up to you, but using a test feature will offer greater flexibility [09:29] vila: does knob via env variable is good candidate for feature? [09:29] vila: I understand what you mean about $DISPLAY [09:30] but this is slightly different use case [09:32] anything that can be checked by python code is a good candidate, the sky is the limit ! :) What is the qbzr basic sanity check before displaying any window ? [09:32] vila: mmm? only presence of pyqt4 I guess [09:33] bialix: hmm, so what happens if I try to run qlog on an headless PC ? [09:33] headless? [09:33] what's that beast [09:34] with no screen, a server for example [09:34] oh, I have no idea [09:34] perhaps it will eat your kitty [09:34] lol [09:34] ok, that's exactly the missing check :) [09:35] I suspect qt is smart enough to check this itself [09:36] ...and raise an appropriate error, that's the error you want to check [09:36] bzr-gtk does that in __init__.py.opend_display() [09:36] * bialix checks [09:36] vila: do you have headless server to check? [09:37] Greetings. I have a documentation 'sanity check' question. Could someone glance at http://doc.bazaar-vcs.org/bzr.2.0/en/user-guide/publishing_a_branch.html [09:37] no, the best I can do is to unset DISPLAY I presume, let me checl [09:38] bzr: cannot connect to X server is what I get [09:38] In 'example of the Second Way' I think the final push is typographically wrong (should be PROJECT u/c) and redundant? [09:38] 'bzr: cannot connect to X server' is what I get [09:39] can you pastebin traceback? [09:39] bialix: no traceback [09:40] even in .bzr.log? [09:40] even in .bzr.log [09:40] * bialix mutters: interesting bzr-gtk is not support 1.18, but does support 2.1, funny [09:41] vila: cannoct connect to X server is different from bzr-gtk check ("could not open display") [09:42] (I know I'm boring and overly pedantic) [09:43] bialix: what makes you think 1.18 is not supported ? [09:43] there is explicit list of supported versions [09:43] and the errors are different because is not qt maybe ? :-D [09:43] after 1.17 there is 2.1 [09:43] bialix: no, there is a list of supported bzrlib APIs [09:44] the variable called COMPATIBLE_BZR_VERSIONS [09:44] not COMPATIBLE_BZR_API [09:44] (the same remark about bialix boring) [09:45] ignore me [09:45] bialix: read the next line, what matters is how the variable is used :) [09:45] thanks vila, I will try to do something about qbzr test suite soon [09:46] bialix: but if you have a patch to clarify gtk sources, it will be welcome :-D [09:46] BIG FLASHING RED JOKE, this code lies anyway, like all plugins only the latests bzr versions are supported, devs are just too lazy to maintain an accurate list :) [09:52] :-D [09:56] that's why we don't have such list [10:03] Greetings. I have a documentation 'sanity check' question. Could someone glance at http://doc.bazaar-vcs.org/bzr.2.0/en/user-guide/publishing_a_branch.html [10:04] In 'example of the Second Way' I think the final push is typographically wrong (should be PROJECT u/c) and redundant? [10:24] smartgpx: you're right [10:24] push is wrong there, because in 2nd case it's checkout [10:25] smartgpx: I think you're welcome to https://launchpad.net/~bzr-doc [10:25] thanks. still sufficiently 'newbie' to be uncertain, but it seemed to conflict with the explanation in the next sentence. [10:26] I'll look at patching it. (a one-line deletion) [10:26] copy-paste error I guess [10:27] Yes, except that the case 0f the PROJECT dir changed. no matter, we know what to do. [10:33] all this cp -ar stuff is not very windows friendly, so I'm just ignore it [10:36] bialix: so, are you working on that doc then? Agree with your comments about cp, but I can see it's difficult to make cli examples os-neutral [10:36] smartgpx: no, I'm working on qbzr [10:37] I'm not native English man, so working on English docs is not for me [10:37] this was just "sigh" comment [10:38] to save me a long Branch operation, is the source in lp:bzr ? (or lp:bzr-alldocs ?) [10:39] OK - brain in gear, I can browse LP to find out before I Branch them! no reply needed. [10:53] I'm trying to do a bzr pull from my launchpad project, but it only gets a small way in the "pull phase" and then hangs [10:58] hmm it's finally completed after 10 mins [11:14] <_Andrew> Anyone know off the top of their heads where I install plugins on ubuntu to make them system wide [11:15] <_Andrew> /usr/share/pyshared/bzrlib/plugins ? [11:16] thanks vila for the merge... but didn't you already provide an alternative solution? (i'm talking about my bzr-upload branch) [11:17] beaumonta: I think it was built on top of yours (or at least on top of your idea). I was just cleaning up the merge proposals queue and thought 'merged' was the closest status for yours [11:18] _Andrew: 'bzr plugins -v' should give your pointers [11:23] vila: I see, so it's not a real code merge, ok, thanks for your consideration! [11:23] beaumonta: thanks for your contribution, without you the option would still be waiting to be implemented :-D [11:48] vila: yup :) [11:55] Should I expect sshfs to get in the way of bzr at all? I have a local SVN checkout, and "bzr st" works fine on it using bzr-svn. I have an sshfs mount of a remote machine having checked out the same thing. That throws a wobbly about: bzr: ERROR: exceptions.TypeError: expected a character buffer object [12:13] Ahh.. It seems sshfs isn't the problem.. I can sshfs mount localhost in some crazy loopback setup, and bzr-svn works fine over that. I suspect maybe bzr-svn is confused by the remote checkout [12:18] And.. yes.. if I make my local desktop 'svn co' it again, then bzr is happy with it. I think I blame the remote svn [12:26] LeoNerd, can you paste a backtrace? [12:27] http://paste.leonerd.org.uk/?show=698 [12:36] LeoNerd, hmm, that's odd - I didn't know repos could be None [12:37] Mmm? [12:38] can you add a line before that assertion in workingtree.py? [12:38] print self.entry.repos [12:38] I suspect that will print None [12:41] None indeed [12:48] If 'repos' is repository root url gleaned from the subversion working copy, then it will be because ancient svn versions didn't record that information [14:23] bialix: ping [14:24] bialix: I'd like your input about win32utils.get_console_size(), there is a comment there about avoiding problem with redirecting output via pipe and using stderr instead. But what if stderr is redirected too ? [14:24] vila: heya! [14:25] vila: if stderr is also redirected then we fallback to default value [14:25] I can test for you [14:25] it was long time ago [14:25] oh, because the GetConsoleScreenBufferInfo fail ? [14:25] what's your real question? [14:25] :-) [14:25] IIRC -- yes [14:26] * bialix looks at the code [14:26] We want to change the default width to None instead of 80 when we can't establish the terminal width [14:27] bah, don't worry, I can just pass None as the default value, no need to modify that function... [14:27] cool :-D [14:27] always happy to help [14:27] :-D [14:27] thanks for being my teddy bear :) [14:28] i.e. the one listening to my baby cries :) [14:29] never had teddy bear [14:29] I had a rabbit myself :) [14:29] but one nice girl once upon ago call me "bear" [14:30] despite my appearance [14:30] :-D [14:39] morning all [14:51] morning jam ! [14:52] morning ham! :p [14:52] hi jam [14:54] morning chy [14:54] and vila and bialix [14:55] vilb and bialy ? [14:55] bialiy, sorry for the typo :D === vds1 is now known as vds [15:37] well he was the only one to typo [15:44] jelmer: have you seen https://lists.ubuntu.com/archives/bazaar/2009q4/064932.html? Apparently Norbert Tretkowski has uploaded a bzr 2.0.2 lenny backport to http://people.debian.org/~nobse/temp/bzr/. He said he was going to upload it to backports.org, but I don't see it at http://packages.debian.org/lenny-backports/bzr. Is this something you can do? (It would help us for the Emacs switchover.) [15:53] kfogel: I am able to upload, but we should probably check with him [15:54] jelmer: I don't know him, and his email address doesn't appear to be in that mail, but do you know how to contact him? I can try to track him down if not. [15:54] kfogel, his email address is nobse at debian.org [15:55] he is also here on IRC as nobse [15:55] If you haven't asked him about the backports yet, I'm happy to talk to him [15:57] jelmer: I haven't talked to him about it yet. If you can coordinate with him, that'd be great. As soon as it's on backports, we'll ask the savannah.gnu.org admins to install it, and there's some built-in delay there already (as they're volunteers). [16:03] Hi, is anyone able to help me with a bundlebuggy (or possibly rio-related) problem? [16:04] We've been using BB just fine for months. Today it is broken, in a very odd way. [16:05] We are getting the following backtrace when viewing a merge request: http://pastebin.com/m85d2194 === beuno is now known as beuno-lunch [16:06] Now, the request list pages currently work, but they didn't before I rejected the three requests that were submitted this morning. They also failed with similar backtraces. [16:06] The only thing I can think of is that last night I did a merge with the upstream BB trunk. But all that did was bring in the lastest revision "Merge references fix" [16:06] I have since reverted that change, but we still have a broken BB. [16:07] bzr version on the server is 2.0.1 [16:07] Python 2.5.4 [16:09] kfogel: I've pinged him in private but he doesn't appear to be around at the moment [16:10] kfogel: I'll try to remember to ask him about it again in the next few days [16:10] jelmer: thanks [16:19] kfogel: the package is already uploaded but waiting for manual approval because it introduces a new binary package - nobse is doing that now, so I suspect the package should be on backports.org in a day or so [16:20] verterok: hi [16:20] kfogel, s/day/hour/ [16:20] jelmer: excellent! Thank you. I'll keep checking. === beuno-lunch is now known as beuno [17:35] if I have an unversioned subdirectory containing unversioned files, in a branch working tree, 'bzr ls' should or should not list the unversioned files in the unversioned subdirectory? [17:47] is there a magic switch to enable post mortem debugging in bzr? [17:51] hazmat: set BZR_PDB=1 (as environment variable) [17:54] LeoNerd, any chance you can try again with bzr-svn trunk? [17:56] jelmer, thx [18:03] jelmer: Hmm... if I work out how to install that, rather than just using the debian package... [18:03] LeoNerd, bzr branch lp:bzr-svn ~/.bazaar/plugins/svn [18:05] OK.. it fails in a different way :) [18:05] TypeError: object of type 'NoneType' has no len() at File "/home/paul/.bazaar/plugins/svn/tree.py", line 385, in find_ids relpath = urllib.unquote(entry.url[len(entry.repos):].strip("/")) [18:09] LeoNerd, please pull and try again [18:09] I've committed a fix for that particular issue [18:09] No revisions to pull. [18:14] I would like to discover the history of discussions into URL formats for addressing colocated branches. Can anyone point me in the right direction? [18:14] LeoNerd, sorry, please try again [18:14] maxb, have you tried searching the mailing list archives for "colocated branches" ? [18:15] maxb: Also, see doc/developers/colocated-branches.txt [18:15] contains a link to the discussion on the list [18:16] aha, thanks. lists.ubuntu.com isn't searchable, unfortunately [18:16] jelmer: OK... 'bzr st' now works.. :) claims my working tree is out of date, so I bzr up, which... segfaults. :) [18:16] But.. no great problem; I can svn up on the remote end... I mainly wanted bzr for the shelve ability [18:18] LeoNerd: probably a similar issue where we rely on .repos being non-None [18:18] or, in the C code - non-NULL [18:18] Yah.. [18:18] It's possibly not that important to fix... the version of svn that created this checkout is quite old [18:18] svn, version 1.1.4 (r13838) compiled May 10 2005, 13:50:02 it claims [18:19] LeoNerd, It would still be nice to fix - if you are familiar with gdb, any chance you can get a backtrace? [18:21] Hrm.... gdb claims /usr/bin/bzr is not an executable file format [18:21] Ahh.. do I have to gdb python ? [18:24] Hrm.... I have a backtrace, but it's mostly Python internals... [18:24] that might still be helpful [18:24] http://paste.leonerd.org.uk/?show=699 [18:25] ah, it's unfortunate you don't have debugging symbols for subvertpy [18:27] Hrm.. no debug package appears in debian [18:29] abentley, hi, are you around? do you have any insight on: http://paste.ubuntu.com/333305/ [18:30] beuno: looks like bug 273978 [18:30] Launchpad bug 273978 in bzr "UnicodeDecodeError when strerror is not ascii" [Low,Confirmed] https://launchpad.net/bugs/273978 [18:31] buuuut maybe not [18:31] I remember seeing that error before though [18:31] beuno: I haven't looked at that yet. [18:31] dOxxx, I think that this bug may be in bzrtools instead of bzr [18:32] beuno: gotcha. [18:33] beuno: it looks like bug 352006 [18:33] Launchpad bug 352006 in bzrtools ""bzr branch-history | more" fails with UnicodeEncodeError" [Undecided,New] https://launchpad.net/bugs/352006 [18:34] abentley, it does, thanks. the Emacs guys are hitting this bug [18:35] beuno: I'm surprised, because even I don't use that command anymore. [18:35] abentley, I don't even use emacs :) [18:35] I have no idea why they're using it [18:36] beuno: I've never even shopped at a bazaar :-) [18:36] heh, touche [18:48] I'm having difficulty to branch from launchpad ATM eg. `bzr branch lp:bzr-explorer` . Is it just me ? [18:50] I've just managed to bzr log10 it [18:52] mm.. `bzr log lp:bzr-explorer` also fails for me: [18:52] bzr: ERROR: exceptions.NotImplementedError: should resend request to http://feeds.edge.launchpad.net/bazaar/, but this isn't implemented [18:52] might be hiding the real error :( [19:00] could log https://code.launchpad.net/~bzr-explorer-dev/bzr-explorer/trunk now. i think for some reason lp:bzr-explorer resolved wrongly [19:01] (or I just cant access it over bzr+ssh for some reason) [19:58] jam: awesome! I only get 1 failure and 2 errors running the full selftest on win32 :) === ahasenack is now known as ahasenack-away [20:43] Ben Finney wrote on the mailing list that he created a patch that removed trailing whitespace from the doc folder. He couldn't contribute because he hadn't signed the contributor agreement. [20:43] I created a branch that did the same thing [20:44] Is it even worth trying to get it merged in? [20:44] I mostly did it as an exersize to learn sed [20:44] propose it, see what happens :) [20:44] dOxx: ok, I'll try it out. [20:45] you know how to handle the merge proposal stuff? [20:45] yeah [20:45] cool [20:45] I've gotten a few in before, but didn't know if this was even worth it. [20:45] clean docs are good, imo :) [20:45] but I guess your point made sense... only one way to find out. [20:46] good point [20:46] you separated the whitespace change from the VCS vs RCS change right? [20:49] dOxxx: what failures? I just ran once and didn't get any failures [20:49] jam: http://pastebin.com/d5c922b00 [20:51] dOxxx: so the 'diff' failure is because you don't have a diff.exe on your machine [20:51] cPickle.load is strange [20:51] jam: I have some of the gnuwin32 stuff installed, I can install the diff too. [20:52] the ssh one, I also don't quite understand [20:53] jam: installed gnuwin32 diff and bb.test_diff passes now [20:54] do you know what version of python you are running? [20:54] I'm wondering if you don't have the right lsprof libs installed [20:55] jam: 2.6.4 ActiveState ActivePython [20:55] 32-bit [20:55] running on vista64 though [20:55] where would I find the lsprof libs? [20:55] hmm.. I wonder if activpython versus stock python... [20:56] well, I would first run the test directly, to make sure it still fails [20:56] I don't see lsprof in python\libs [20:56] trying [20:56] lsprof became cProfile and started being bundled with python stdlib [20:56] test_lsprof passed... [20:57] so, it seems like a spurious/race condition [20:57] possibly the output code isn't flushing? [20:57] yeah [20:57] dOxxx: yes [20:57] the ssh test still fails when run on its own though [20:57] rubbs: go for it :) [20:58] dOxxx: cool thanks === ahasenack-away is now known as ahasenack [21:13] jam: selftest is sometimes hanging in test_breakin on win32 [21:16] dOxxx: are you on a single cpu machine? [21:17] jam: core i7, looks like 8 CPUs [21:18] jam: using r4852 of bzr.dev [21:39] dOxxx: its 4 real, with hyperthreading [21:39] lifeless: yes [21:39] jam: does gc in win32 python run threaded or something? [21:39] s/looks like/appears to OS as/ [21:40] :) [21:42] I just pushed my first draft of .bzrmeta/ignore to lp:~doxxx/bzr/bzrmeta-ignore [21:42] no backwards compatibility yet === tommieb is now known as t0mm13b [21:53] good morning [21:53] hey poolie [21:55] lifeless: I don't think gc is threaded, but if you have del SFTPFile, it calls "CMD_CLOSE" in async mode [21:56] and *that* may not finish before the next command [21:56] however, I'm also seeing self.write_stream.close(); transport.rename() fail [21:56] and that is calling .close() synchronously === tommieb is now known as t0mm13b [22:06] dOxxx: what does that branch change? [22:07] lifeless: it changes all handling of .bzrignore to use .bzrmeta/ignore instead [22:07] that seems likely to cause headaches for folk on older versions; is it really worth changing? [22:08] lifeless: it's speculative and I'm using it as an opportunity to learn more about the internals. [22:08] have you considered having .bzr/meta/ignore be a symlink to ../.bzrignore? [22:10] lifeless: that would work in the absence of backwards compatibility as the branch currently stands [22:11] side question, why .bzrmeta/ and not .bzr/meta ? [22:11] because .bzr is not versioned [22:11] dOxxx: I'm not concerned about backwards compatability, rather forwards compatability. [22:11] the ignore file must be versioned [22:12] ah I see, ok thanks [22:12] lifeless: could you describe a scenario? [22:13] dOxxx: user installs karmic. bzr branches, runs make, runs bzr st sees a tonne of files. [22:13]