| poolie | hello igc | 00:20 |
|---|---|---|
| igc | hi poolie | 00:20 |
| spiv | Good morning. | 01:06 |
| lifeless | hai | 01:09 |
| poolie | hi spiv | 01:15 |
| timClicks | hi all, sorry for n00b q - how to I overwrite locally modified files with the trunk? | 01:20 |
| Raim | timClicks: you can use bzr revert to go back to the unmodified version | 01:25 |
| timClicks | thanks Raim | 01:26 |
| Raim | or if you are talking about pulling new changes and forgetting any local changes, bzr pull --overwrite | 01:26 |
| timClicks | I didn't quite trust revert | 01:26 |
| lifeless | poolie: quick call ? | 01:30 |
| poolie | hi, sure | 01:30 |
| fullermd | vila: py25 on this system doesn't make any difference either. | 01:38 |
| Stavros | hello | 01:45 |
| Stavros | i pushed my repo somewhere, creating a branch, and now i want to create a workingtree there, how can i do it? | 01:45 |
| Stavros | anyone? :/ | 01:48 |
| davidstrauss | Stavros: Where do you want the working tree? | 01:48 |
| Stavros | in the branch i pushed | 01:48 |
| davidstrauss | Stavros: Can you SSH and cd to the directory? | 01:48 |
| Stavros | yes, i just need the command | 01:48 |
| Stavros | bzr up stopped working for some reason | 01:49 |
| davidstrauss | Stavros: bzr up won't create a working tree | 01:49 |
| fullermd | up doesn't create a working tree, it just updates an existing one. | 01:49 |
| davidstrauss | Stavros: Run bzr checkout | 01:49 |
| Stavros | it used to work in earlier versions | 01:49 |
| Stavros | ah, that's it, thanks | 01:49 |
| Stavros | i kept trying revert and up, but nothing | 01:49 |
| Stavros | thanks | 01:49 |
| poolie | spiv, how's stuff? | 02:12 |
| spiv | poolie: ok... I started bumping into unexpected obstacles with the homedir-relative hpss patch; I'd forgotten just how many layers there are between cmd_serve and SmartServerRequest to pass new options through. | 02:16 |
| spiv | poolie: so I decided I should take a look at implementing it as a transport decorator after all, as that is already passed through just fine. But that too is hitting some obstacles; I have written a generic path filtering transport decorator but it isn't quite passing tests yet. | 02:17 |
| poolie | ok, that sounds good | 02:19 |
| poolie | i wondered if that would be the case | 02:20 |
| poolie | spiv, i'm just thinking that many transports do abspath(arg) or similar before using paths | 02:20 |
| poolie | ie some common filtering | 02:20 |
| poolie | this seems to have some connection to wanting to do common policy on paths, but i'm not sure precisely what | 02:21 |
| spiv | Yeah, possibly. | 02:24 |
| spiv | I hope to have more firmly formed ideas on the subject Real Soon Now... | 02:27 |
| spiv | Hmm, if a patch to add "--pdb-on-failure" to selftest dropped out of the sky right about now, I wouldn't complain... | 02:28 |
| SamB | spiv: heck yeah! | 02:28 |
| SamB | though personally I would think it would make more sense to just make BZR_PDB=y work then too | 02:29 |
| SamB | but either way would be really useful | 02:29 |
| SamB | ... probably would have done it if I had been able to see how ... | 02:29 |
| spiv | SamB: the problem is BZR_PDB really means something slightly different. | 02:39 |
| spiv | So making it do this for selftest would be a bit hackish. | 02:39 |
| poolie | spiv, i'd love that too | 02:41 |
| poolie | high on my list of post-2.0 wishes | 02:41 |
| poolie | maybe this week | 02:41 |
| poolie | also --pdb-before | 02:41 |
| lifeless | I think reusing BZR_PDB would be ok, really. | 02:50 |
| lifeless | its not that conceptually different. | 02:50 |
| lifeless | I will note that the 'stock' way to do it is to use debug() rather than run() | 02:52 |
| lifeless | and then just run under pdb | 02:52 |
| lifeless | I'm not convinced that this is the most elegant/appropriate way to tackle it | 02:52 |
| poolie | saying "debug() rather than run()" is fine, but that's an api, not a ui | 02:56 |
| lifeless | yes | 02:56 |
| lifeless | the theory behind the debug() approach is that you would do 'python -m pdb bzr selftest --debug' | 02:57 |
| poolie | do you mean, start pdb from the python repl, then construct a test, then | 02:57 |
| lifeless | but, as I say, I have doubts. | 02:57 |
| poolie | interesting | 02:57 |
| poolie | i had no idea you could use pdb as a module | 02:57 |
| poolie | its docstring doesn't mention it | 02:57 |
| poolie | i think having a way by which other debuggers can run the right thing is highly worthwhile | 02:59 |
| lifeless | so the problem with debug centres around finally & cleanup code | 02:59 |
| poolie | oh i realized the reason all my work is unmerged, because lp was having a bad day on friday | 03:00 |
| spiv | Ideally I think a pdb prompt for a failed test would be started before cleanups are run. | 03:04 |
| lifeless | spiv: yes; this depends on the precise interaction of 'finally' and 'pdb.pm', for using 'debug()' as an API to do this. | 03:05 |
| lifeless | spiv: which is one [but not all] of the reasons I don't like debug | 03:05 |
| lifeless | http://paste.ubuntu.com/270620/ | 03:06 |
| lifeless | spiv: ^ enjoy. | 03:06 |
| lifeless | hooking into self.fail() would work too, but that has the problem that not all errors invoke fail, some raise directly. | 03:07 |
| naoki_ | http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#getting-help | 03:12 |
| naoki_ | s/bzr help/bzr help topics/ ? | 03:12 |
| lifeless | spiv: also https://code.edge.launchpad.net/~lifeless/bzr/selftest-pdb/+merge/11673 | 03:16 |
| poolie | what's the pqm trunk branch? | 03:22 |
| lifeless | lp:pqm ? | 03:22 |
| poolie | naoki_, you're right, the 'list of topics' is different | 03:22 |
| poolie | naoki_, file a bug/ | 03:23 |
| naoki_ | OK | 03:23 |
| poolie | actually nm | 03:23 |
| poolie | i'll change it here | 03:23 |
| poolie | lifeless: what i actually meant is, what should i put in locations.conf? | 03:24 |
| lifeless | oh :) | 03:25 |
| poolie | i think i have it now | 03:26 |
| lifeless | its in my docs proposal | 03:26 |
| lifeless | https://code.edge.launchpad.net/~lifeless/bzr/docs/+merge/11284 | 03:26 |
| lifeless | submit_branch = http://bazaar.launchpad.net/~bzr-pqm/bzr/x.y | 03:27 |
| naoki_ | https://bugs.launchpad.net/bzr/+bug/429151 | 03:28 |
| ubottu | Launchpad bug 429151 in bzr "'bzr help' in "getting help" section should be 'bzr help topics'" [Undecided,New] | 03:28 |
| AfC | Now that we have a stable default format, is there any need for `bzr init` to list off 21 options all relating to different formats possibilities? | 03:34 |
| AfC | [I thought we fixed that, but they're back] | 03:34 |
| poolie | afc, in its' help? | 03:37 |
| poolie | naoki_, https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/11674 thanks for pointing it out | 03:37 |
| poolie | check that phrasing if you like | 03:37 |
| spiv | Time for lunch. | 04:07 |
| * igc lunch | 04:54 | |
| jam | fullermd: are you sure that you're going to "write something someday" http://www.over-yonder.net/ | 05:23 |
| jam | :) | 05:23 |
| jam | anyway, night all. I'm headed to bed, and then off to Canada tomorrow | 05:23 |
| spiv | jam: Canada, eh? :) | 05:26 |
| jam | spiv: I think I'll be training some people, eh? | 05:26 |
| jam | does anyone know how to tell 'setup.py' that one of your extension needs the library built in a previous step? | 05:40 |
| jam | libraries=['extension'] | 05:40 |
| jam | is easy enough | 05:40 |
| jam | but I have to also give the path to the lib | 05:40 |
| jam | and the temporary directory where everything is being built doesn't seem to be on the default lib path | 05:41 |
| SamB_XP_ | jam: I don't think you're supposed to need symbols from other modules directly; I think you're supposed to use some Python-side APIs to find the other modules? | 05:42 |
| SamB_XP_ | the part I can't remember is how they're supposed to provide C-level APIs to other extension modules ... | 05:43 |
| jam | SamB_XP_: the point is that one C level api is using another C level api, and I need the .lib so that the compiler can resolve the imported symbol | 05:45 |
| SamB_XP_ | jam: oh, you mean they're already doing that in Linux but it doesn't work in Windows ? | 05:45 |
| SamB_XP_ | well, I think they're not supposed to do that ... | 05:46 |
| jam | SamB_XP_: I have 2 python extensions. I want to write a Key_New() function | 05:46 |
| jam | similar to PyTuple_New() | 05:46 |
| SamB_XP_ | ... isn't this covered in extending and embedding ? | 05:46 |
| jam | and I want to make use of that function in the next lib | 05:46 |
| jam | SamB_XP_: I can get it exported, and I can get it imported *if* I do: | 05:47 |
| SamB_XP_ | you probably want to do something like what the numeric library does now -- whatever it's name is these days ;-) | 05:47 |
| jam | add_pyrex_extension('bzrlib._btree_serializer_pyx', | 05:47 |
| jam | libraries=['_keys_type_c']) | 05:47 |
| jam | ext_modules[-1].library_dirs.append('build/temp.win32-2.6/Release/bzrlib') | 05:47 |
| jam | Obviously that "library_dirs" isn't going to be a stable path | 05:47 |
| jam | I haven't yet found out how to find that path properly | 05:48 |
| jam | hence the questions here | 05:48 |
| jam | Scons, for instance, when you create a build node, you can pass that to the next build node | 05:48 |
| SamB_XP_ | jam: I really, really don't think you're supposed to directly link extension modules like that ... | 05:48 |
| jam | to make it a dependency, and it has attributes like "this is where my lib is built" | 05:48 |
| jam | SamB_XP_: Not much different from linking python26.lib to get the functions from python26.dll | 05:49 |
| jam | it is just another dll | 05:49 |
| jam | just named .pyd (or .so) | 05:49 |
| spiv | SamB_XP_: but consider the case of a plain C lib that is shared between multiple Python C modules | 05:49 |
| spiv | SamB_XP_: which is certainly valid, and I think would encounter the same issue? | 05:50 |
| jam | spiv: though you have some potential issue if/when 'import' is triggered | 05:50 |
| jam | anyway | 05:50 |
| jam | as near as I can tell | 05:50 |
| jam | distutils has no concept of 'dependencies' | 05:50 |
| jam | well, I found this from 2004: http://osdir.com/ml/python.distutils.devel/2004-02/msg00116.html | 05:51 |
| jam | where they were talking about adding it | 05:51 |
| lifeless | jam: this is to build an extension that build-deps on another extension? | 05:51 |
| jam | lifeless: yeah, and links to it | 05:51 |
| SamB_XP_ | jam: http://docs.python.org/extending/extending.html#providing-a-c-api-for-an-extension-module | 05:51 |
| lifeless | spiv: does my selftest-pdb gelp you? | 05:51 |
| SamB_XP_ | jam: that's the officially sanctioned approach | 05:52 |
| SamB_XP_ | dumb as it may seem | 05:52 |
| spiv | lifeless: not yet, as I dealt with my immediate issue the old-fashioned way (import pdb; pdb.set_trace()) and haven't needed that again today. | 05:52 |
| bialix | igc: https://launchpad.net/bzr-explorer/trunk/0.8/ | 05:54 |
| jam | SamB_XP_: that is so... very... awful | 05:55 |
| SamB_XP_ | jam: so's the (\forall OS, dynamic linking) story | 05:56 |
| jam | So couldn't you just store it in PyCFunction, and then get the raw pointer out of that? | 05:57 |
| igc | bialix: awesome, thanks. | 05:57 |
| bialix | :-) | 05:58 |
| bialix | what about bzr installer? | 05:58 |
| bialix | igc: ^ | 05:58 |
| igc | bialix: I've merged your stuff to trunk and patched in explorer 0.8 | 05:58 |
| igc | bialix: I'm trying to build it now on my vista VM | 05:59 |
| bialix | igc: I hope you re-enabled TBZR | 05:59 |
| lifeless | jam: this is what pyd files do, I thought | 05:59 |
| lifeless | jam: the pyrex header stuff | 05:59 |
| igc | bialix: I will but I haven't yet | 05:59 |
| bialix | igc: ok | 05:59 |
| bialix | igc: English messages is OK? | 05:59 |
| jam | lifeless: pyd files are just a .dll named differently (for windows) | 05:59 |
| igc | bialix: likewise I need to put back the other installers according to jam's email | 05:59 |
| jam | ah, you mean pyrex pyd files | 05:59 |
| lifeless | jam: yes :) | 05:59 |
| jam | I haven't specifically played with them | 06:00 |
| bialix | igc: do you mean build all installers from your project? | 06:00 |
| jam | and there is also .pxi, IIRC | 06:00 |
| jam | or something like that, pyxi? pyi? | 06:00 |
| bialix | igc: it will be non-trivial | 06:01 |
| bialix | igc: also I was forced to disable your settings to use mingw | 06:02 |
| igc | bialix: we *might* be able to build the other installers from 2.0.0 trunk - dunno | 06:02 |
| bialix | igc: I believe you can set such settings in distutils.cfg | 06:02 |
| igc | bialix: I'm still learning how all this stuff hangs together | 06:02 |
| bialix | igc: it hangs together very badly | 06:02 |
| SamB_XP_ | bialix: that's probably why he's still learning ;-p | 06:03 |
| igc | bialix: it's challenging that's for sure | 06:03 |
| bialix | SamB_XP_: no | 06:03 |
| SamB_XP_ | if it hung together well, it probably would be a breeze to learn ;-P | 06:04 |
| igc | bialix: it will be good as we gradually reduce the dependences, etc. | 06:04 |
| bialix | igc: it won't help much | 06:05 |
| bialix | igc: removing cog is just a tiny change | 06:05 |
| igc | bialix: right. But I'd like other clean-ups as well so build-installer.bat was python say. | 06:06 |
| bialix | igc: be back online after 2-3 hours | 06:06 |
| igc | bialix: then we can perhaps use it for os x, etc. | 06:06 |
| bialix | igc: unlikely | 06:06 |
| * bialix bbl | 06:07 | |
| igc | bye | 06:07 |
| lifeless | jam: is this for meliae? | 06:11 |
| lifeless | I'd look at pyrex's interface stuff | 06:12 |
| fullermd | jam: :P Someday encompasses a lot :p | 06:16 |
| * fullermd boggles. | 06:30 | |
| fullermd | Selftest is using 120 threads? That CAN'T be right, can it? | 06:30 |
| lifeless | fullermd: if they aren't getting gc'd | 06:31 |
| fullermd | Well, it's on 9222/22518, and it's been running for almost 5 hours. | 06:31 |
| fullermd | It's eating a hundred thousand context switches a second, so it's actually getting about 3% of the CPU. I'm thinking something's not quite right. | 06:32 |
| lifeless | that would be the GIL | 06:32 |
| fullermd | And it's spit a giant pile of "Can't assign requrest address" from various per_transport tests. Related? | 06:32 |
| lifeless | yes | 06:32 |
| lifeless | server threads not winding up properly. | 06:33 |
| fullermd | So those errors are symptom, not cause? | 06:33 |
| lifeless | reported as 'selftest hanging on windows' I think, but not debugged/pinned down | 06:33 |
| lifeless | yes, i think they are a symptom | 06:33 |
| fullermd | Is there something I can try now while it's running to get info about the cause, or should I just murderlize it? | 06:34 |
| lifeless | gdb | 06:34 |
| lifeless | get a pystack in some of the threads | 06:34 |
| fullermd | 'cuz I ain't letting my server sit on its knees for another 7 hours to finish... | 06:34 |
| fullermd | 'k... I'll look into that after I finish lunch. | 06:35 |
| jml | how big is the bzr 2a repo? | 06:35 |
| lifeless | 30MB | 06:36 |
| jml | thanks. | 06:37 |
| fullermd | You have a handy ref on doing that? I've never used gdb with python. | 06:38 |
| lifeless | http://wiki.python.org/moin/DebuggingWithGdb | 06:38 |
| fullermd | Mmm. Would pdb be easier? It would take a little doing to get a debug symbol'd python... | 06:39 |
| fullermd | (that matches the running one) | 06:39 |
| lifeless | you could try ctrl-\ and debug | 06:39 |
| lifeless | no guarantees that it will do anything sensible with other threads. | 06:40 |
| lifeless | pdb is rather more capable ;) | 06:40 |
| lifeless | sorry | 06:40 |
| lifeless | gdb is ... | 06:40 |
| vila | fullermd: not fully awake yet, but first thing *I* would try is: '--parallel=fork' which is known to work around the thread issue (see gentoo)... (be back after coffee) | 06:41 |
| fullermd | Well, _fixing_ it would work around the thread issue too :p | 06:41 |
| fullermd | 's I can help in that direction... | 06:41 |
| fullermd | 'k, running just -s per_transport.TransportTests seems to be doing the same thing; every HttpServer_urllib test spits the error, and the thread count is climbing. | 06:42 |
| fullermd | So I guess it's easy to reproduce in this instance. | 06:42 |
| lifeless | vila: We should fix this | 06:43 |
| fullermd | How odd. It gets the error calling socket.shutdown()?! | 06:43 |
| lifeless | fullermd: don't worry about working around; try to get to the bottom of it. | 06:43 |
| fullermd | What a bizarre place to get a Can't assign error. | 06:43 |
| vila | lifeless: the bottom of it is to call transport.close() :-) Pending that, it's to properly shutdown (as you pointed in some bug) | 06:44 |
| vila | fullermd: what error in shutdown() ? | 06:44 |
| lifeless | vila: I don't agree vis-a-vis close() | 06:44 |
| vila | lifeless: let's talk about it (but let me have a coffee and a shower first :) | 06:45 |
| fullermd | vila: http://paste.ubuntu.com/270691/ is what the tracebacks look like on the failed tests when I ^C. | 06:45 |
| vila | fullermd: 8-) That's when I realize I'm dreaming... | 06:46 |
| * vila won't be back before 2 coffees now | 06:47 | |
| fullermd | Oh my god, the best thing I can dream of now is not just bzr selftest, but bzr selftest _FAILING_?! | 06:47 |
| * fullermd . o O ( Down, then across... ) | 06:47 | |
| === beuno-on-vacatio is now known as beuni | ||
| === beuni is now known as beuno | ||
| lifeless | vila: if t.close() is needed, production servers will leak resources. | 07:11 |
| vila | lifeless: I agree. t.close() and s.shutdown() are both valid ways to fix the issue. I'd like to try *both* separately once I'm able to reproduce the problem reliably (I'm there on gentoo). But s.shutdown() is to be prefered, yes. Nevertheless t.close() is needed in other contexts (or if not strictly needed is the most natural to use, pullers were involved in the two cases my memory brings back) | 07:15 |
| poolie | lifeless: still here? | 07:15 |
| poolie | can you explain to me what you mean by using debug() for debug support in selftest? | 07:16 |
| poolie | hi vila | 07:16 |
| vila | hello poolie | 07:16 |
| vila | fullermd: so, just to be sure, I understand your context correctly: 1) You now have brz.dev in 2a format, 2) you're running python-2.5, 3) You're experiencing thread leaks, | 07:19 |
| vila | fullermd: what about the revision not found errors then ? | 07:20 |
| fullermd | This is separate from that. | 07:20 |
| vila | fullermd: but 1 & 2 are correct, right ? | 07:20 |
| fullermd | I get the RevNotFound with 2.5 and 2.6 on my workstation (8/amd64). Trying to see what I get on my server (7/i386/py25) that I'm seeing the thread leak stuff. | 07:20 |
| fullermd | (on both bzr.dev and installed 1.18) | 07:20 |
| fullermd | It only got partway through the test suite on the server due to that problem, but I haven't seen any RNF's there _yet_. And at 9k and change, I'm pretty sure I would have if they were coming up with near the same frequency. | 07:21 |
| * fullermd is working on a debug build of python at the moment to see if anything pops out of that. | 07:22 | |
| vila | fullermd: hmm, well, the thread leaks generally make a lot of noise but most importantly make the tests fail early, so once you start getting one such error, most of the subsequent ones are 100% noise | 07:22 |
| fullermd | Yah. But my backscroll has none of the RNF's. I'm pretty sure I saw then in the first thousand at least on my workstation. | 07:23 |
| fullermd | Now, there's two variables there; 7.x vs 8.x, and i386 vs amd64. But you're running 7.x/amd64 and not seeing them, right? | 07:24 |
| fullermd | So that suggests 7/8 is the culprit. | 07:24 |
| vila | 7/amd64 yes (in a VM but hopefully that's unrelated) | 07:25 |
| fullermd | Hopefully. | 07:25 |
| vila | fullermd: checking again, you built the C extensions right ? | 07:25 |
| fullermd | It's a working theory anyway. | 07:25 |
| fullermd | Yah. | 07:25 |
| fullermd | OK, there's a debug build... | 07:26 |
| vila | so we need at least some test names to start searching further | 07:26 |
| fullermd | Easy peasy. | 07:27 |
| fullermd | Actually, I don't think the list has much changed since previous runs... | 07:27 |
| vila | just thinking aloud :) | 07:27 |
| fullermd | But there's a copy just in case you're too far from your mail quota :p | 07:28 |
| fullermd | As a guess, I'd say that EVERY problem there is the same thign. | 07:28 |
| vila | my mail quota is my local disk available space :) | 07:28 |
| fullermd | The 82 ERROR's that got sorted together obviously are. | 07:28 |
| fullermd | But the other 9 FAIL's seem like they could actually be the same thing, expressed differently. | 07:28 |
| fullermd | (e.g., all the test_statistics, that got 0 revs instead of 3, the 2 unreferenced texts instead of 0... all sound like they could be the result of the same 'revisions going off into lala land' problem) | 07:29 |
| fullermd | Which sadly, suggests it may not be as simple as a broken test or two, but may be a real problem :| | 07:30 |
| fullermd | Though I should note that I've NEVER seen revisions disappear in _using_ bzr. | 07:30 |
| fullermd | Now, let's see how this gdb stuff woiks... | 07:32 |
| fullermd | lifeless: OK, what am I... Urg. | 07:36 |
| fullermd | pystack on a thread hanging around from an error throws gdb into a tight loop. Loverly. | 07:37 |
| fullermd | bialix: Hey there. Quit pinging me and running off before I can reply 6 hours later :p | 07:37 |
| bialix | fullermd: ok | 07:37 |
| bialix | fullermd: my hosting admins are unable to install bzr correctly | 07:38 |
| vila | bialix: +1 on that, it would be nice if you could find a way to be more reliably pingable on IRC :-/ | 07:38 |
| bialix | after 3 mails from me about wrong chmod bits they finally fixed problem | 07:38 |
| vila | bialix: hi by the way :) | 07:38 |
| bialix | vila: bonjour | 07:38 |
| bialix | vila: it was joke? | 07:38 |
| bialix | fullermd: what is the right way to install bzr on BSD? | 07:39 |
| fullermd | From the port? Just like any other port. | 07:39 |
| fullermd | What chmod issues were cropping up? | 07:39 |
| vila | bialix: like fullermd I often wish I can ping you, but since you're not always online, it makes rather hard to reach you that way, and sometimes writing a mail is not appropriate ,nothing serious, just wanted to echo fullermd's feeling | 07:40 |
| bialix | fullermd: they install bzr only for root. my account even can't read bzrlib modules. therefore I've got consistent ImportError | 07:40 |
| bialix | vila: you can ping me and hope that I'll read irclogs | 07:40 |
| bialix | vila: or use gtalk | 07:40 |
| vila | bialix: haaaa, I see | 07:40 |
| fullermd | Mmm. You mean the .py{,c,o} files are 600 or something? What about the 'bzr' script itself? | 07:41 |
| bialix | fullermd: yeah, something like that | 07:41 |
| bialix | first time (2 years ago everything was nice) | 07:41 |
| fullermd | Ports assumes that root means what they say with their umask, so if they have it set to 077 or something, and bzr's build doesn't explicitly override it, you could end up with that result. | 07:41 |
| bialix | fullermd: yes, admin told something about umask | 07:42 |
| fullermd | (bzr would hardly be the only thing affected by that; lots of ports will do what they _say_ rather than what they may think they _mean_ in that situation) | 07:42 |
| fullermd | It does give warnings when you build/install with restrictive umasks, but if you're not watching the build, it's fairly easy to miss. | 07:43 |
| bialix | it seems so | 07:43 |
| bialix | so next time I'll asking about upgrade of bzr I need to tell them: "remember about umask" | 07:43 |
| bialix | fullermd: heh, ok. thanks | 07:44 |
| fullermd | Yeah. They really should remember about that all around; lots of things meant to be run by non-root will be screwy in that case. | 07:44 |
| * bialix stopped ping fullermd for next 6 months or so | 07:44 | |
| fullermd | Of course, you'd never notice with something like apache or a MTA or such, since they DO get run by root, but... heck, _python_ could be seriously impacted, unless it overrules umask. | 07:45 |
| fullermd | (that would be 2 wrongs making a right, I guess :p) | 07:45 |
| bialix | :-) | 07:45 |
| * igc out for a bit | 07:46 | |
| bialix | vila: I really have no idea how to solve this ping problem | 07:46 |
| vila | bialix: stay connected ? | 07:46 |
| bialix | ubottu: can you work as irc postmaster? | 07:46 |
| ubottu | Error: I am only a bot, please don't think I'm intelligent :) | 07:46 |
| bialix | vila: no way for work computer | 07:47 |
| vila | bialix: end of discussion :-D | 07:47 |
| fullermd | freenode has a MemoServ. But that's probably more trouble than email. | 07:47 |
| bialix | vila: and even if I'll let my home laptop working 24/7 it won't help me while I'm at work | 07:47 |
| fullermd | Sure it will, that's what screen is for :p | 07:47 |
| * bialix run away screaming | 07:48 | |
| vila | yeah or any other irc proxy (not that I used one myself, but I understand that's one of their duties) | 07:48 |
| bialix | irclogs.ubuntu.com btw has dealy around 2-3 hours | 07:48 |
| bialix | so it's not very reliable | 07:48 |
| vila | yeah, that makes quite a high latency :-/ | 07:48 |
| bialix | *delay | 07:48 |
| fullermd | Anyway, nothing jumps out at me from screwing with gdb here. So I'll shelve that for now. | 07:49 |
| * bialix hides | 07:49 | |
| vila | fullermd: so I can work on the leak issue from gentoo, but the RNF are out of reach until I setup an 8/amd64... | 07:51 |
| fullermd | Yeah. Wonder what triggers that leak. | 07:52 |
| fullermd | Never happened on my workstation, but is reliable on server. And the server isn't setup much different from your VM. Wacky. | 07:52 |
| fullermd | Well, i386/amd64 I guess, but that hardly seems a likely culprit. | 07:54 |
| fullermd | Perhaps academic now, but re: your setting up 25 and 26; that would be... well, possible, but you don't wanna try it. Lots of manual frobbery needed there. | 07:57 |
| fullermd | (though why you wouldn't just want to go 2.6... :p) | 07:57 |
| beuno | poolie, hi | 08:04 |
| poolie | hi! | 08:04 |
| poolie | and bye, unfortunately | 08:04 |
| beuno | poolie, :) I'll catch up on the website emails then | 08:05 |
| poolie | welcome back btw | 08:06 |
| poolie | were you on holidays? | 08:06 |
| vila | fullermd: I suspect you have a different *limit* for the threads, we're leaking reliably almost everywhere, we're just rarely caught doing that :-D | 08:06 |
| fullermd | I'm not explicitly setting one. And wouldn't I get those address assignment errors whether or not it was hitting a limit? | 08:07 |
| vila | fullermd: What are the steps to upgrade from 7.2 to 8 ? I should be able to clone my VM to start a 8 one | 08:07 |
| fullermd | (I mean, I only have 2 threads when first I get one...) | 08:07 |
| fullermd | vila: Basically, checkout the source, build and install. | 08:07 |
| fullermd | You could grab an ISO or such for ... BETA4 I think is the latest? if you wanted to go the binary way. | 08:08 |
| vila | ok, let me prepare things first (if you expect to still be online for a bit that is) | 08:08 |
| vila | hmm, I don't know which one will be the shortest... | 08:08 |
| fullermd | Oh, yes. I've got coffee, and I'm settling down for an afternoon of working. | 08:09 |
| fullermd | The build will probably be shortest in time you have to pay attention to it, though it'll presumably take longer in a VM than on bare iron. | 08:09 |
| vila | may be worth starting again though | 08:09 |
| vila | http://lists.freebsd.org/pipermail/freebsd-stable/2009-September/051801.html sounds full of good advices for upgrading no ? | 08:15 |
| spiv | Hmm, I think have a reasonable implementation of /~/ (and /~user/) expansion for bzr serve now. | 08:15 |
| vila | spiv: good to hear ! | 08:16 |
| fullermd | vila: Could work. I've never used freebsd-update(8), so I don't know what (if any) hitches or tricks there might be in it. | 08:17 |
| fullermd | spiv: beer++! | 08:17 |
| === Pilky_ is now known as Pilky | ||
| vila | fullermd: is that a "good for me"/"good for noobs" dichotomy which shouldn't discourage me to try ? :) | 08:18 |
| fullermd | Well, freebsd-update is basically a tool for binary updates between releases. It requires that you're using the distributed binary bits, since it uses bindiffs. | 08:18 |
| fullermd | Being as I never run releases, and always have locally compiled stuff, it's just not applicable to me :p | 08:19 |
| fullermd | OTOH, I have faith in the authors and maintainers, and have no reason to disbelieve that, in those cases, it works as advertised. | 08:19 |
| vila | right, but since I installed from a 7.2 ISO and didn't update (as far as I recall) I should be able to just follow that right ? | 08:20 |
| fullermd | Just that I have faith that all software has gotchas somewhere, and I don't know where they might be in f-u. | 08:20 |
| fullermd | Yah. | 08:20 |
| vila | So I\ll try that first, if that fails, I'll went the checkout/build/install route :) | 08:20 |
| fullermd | Sounds like a plan. What's the worst that could happ*SLAP* | 08:26 |
| vila | fullermd: :-D Nothing, one more broken VM is not a big deal :) | 08:33 |
| vila | fullermd: Does this look reasonable (y/n)? | 08:46 |
| vila | fullermd: gee, yes, I guess :-D | 08:46 |
| * fullermd is always tempted to see what 'n' does to questions like that :p | 08:49 | |
| === spiv_ is now known as spiv | ||
| * igc dinner | 09:50 | |
| Stavros | hello | 11:11 |
| fullermd | No, you say _goodbye_. _I_ say hello. | 11:11 |
| SamB_XP_ | fullermd: why's that ? | 11:14 |
| fullermd | I dunno. John Lennon made me do it. | 11:15 |
| SamB_XP_ | in soviet russia, hello says you | 11:18 |
| awilkins | jelmer: "Unexpected keyword argument '_override_hook_source_branch'" ; does this ring a bell? | 11:20 |
| awilkins | jelmer: A colleague is getting this trying to push a revision to an SVN repository | 11:21 |
| SamB_XP_ | awilkins: would there happen to be a file and line attached to the error ? | 11:22 |
| awilkins | SamB: I've got a trace coming to me ; http://pastebin.ubuntu.com/270796/ | 11:23 |
| * SamB_XP_ curses bzr for not using cgitb... | 11:26 | |
| awilkins | It did it with both 1.16 and 1.18-1 | 11:30 |
| awilkins | I'm suspicious | 11:30 |
| SamB_XP_ | of what ? | 11:31 |
| SamB_XP_ | ... anyway, there sure doesn't seem to be a bug for that ... | 11:34 |
| awilkins | Ok, it happens for lightweight checkouts but not heavies | 11:53 |
| awilkins | Looks like a path in the code that the test suite must pass over | 11:54 |
| SamB | awilkins: lightweight checkouts of SVN repositories themselves ? | 11:54 |
| SamB | that sounds like a phenominally bad idea ;-) | 11:54 |
| awilkins | Lightweight checkout of a branch mirrored from an SVN repo | 11:54 |
| SamB | oh | 11:54 |
| SamB | I do that all the time on Linux ... | 11:54 |
| awilkins | I don't think it's necessarily linked to bzr-svn | 11:54 |
| SamB | well, I think it's highly likely that bzr-svn is at least triggering it | 11:55 |
| awilkins | The bug is line 2468 of remote.py (in 1.18 at least) | 11:55 |
| SamB | because it looked like at least 90% of tracebacks with that keyword argument in them were in bugs filed against bzr-svn | 11:55 |
| awilkins | If bzr-svn is exercising the API in a legitimate way there should be a unit test that's doing the same thing | 11:56 |
| SamB | when I say "triggering", I just doing what it should, but triggering a bug in bzr itself ;-) | 11:56 |
| SamB | yeah, true | 11:56 |
| SamB | or a similar sort of thing | 11:57 |
| SamB | is that method supposed to accept any keyword arguments whatsoever ? | 11:57 |
| fm | i have a bzr-pipeline. now i want to create a patch for every pipe, how is it done. | 11:58 |
| fm | ? | 11:58 |
| SamB | fm: does bzr-pipeline have no docs??? | 11:58 |
| fm | i cannot find docs about how to generate a patch series .... | 11:59 |
| fm | there are neither docs how to reorder the pipes in the pipeline ... | 12:00 |
| jelmer | awilkins: please file a bug | 12:01 |
| === beuno is now known as beuno-lunch | ||
| SamB | fm: you checked http://bazaar-vcs.org/BzrPipeline ? | 12:03 |
| SamB | that's what launchpad has for the homepage of bzr-pipeline | 12:03 |
| SamB | fm: anyway, if you can't see how to do something even after reading all the docs you can find for bzr-pipeline using `bzr help' *and* reading the wiki page, go ahead and file a bug | 12:05 |
| fm | SamB: i have read http://bazaar-vcs.org/BzrPipeline#id3 but they do it manually. i am looking for a command bzr export-pipes which creates a patch for every part of the pipe. i thought that was the use case of bzr-pipeline? | 12:06 |
| fm | should i file a feature request for that, or do i miss something? | 12:07 |
| SamB | fm: feel free to file a bug about that too ;-) | 12:07 |
| SamB | go ahead | 12:07 |
| fm | bzr help pipeline does not help alot ... | 12:07 |
| SamB | well, if it's thare and help pipeline doesn't help you find it, that's also a problem | 12:07 |
| SamB | so yeah, go ahead and file a bug about how you expect such a command and can't find it | 12:08 |
| jam | lifeless: actually it is for bzr, so that I can have a "Key" type, and have btree_serializer create them directly. It is 738ms => 720ms for 'bzr log -n0 -r-1' if you build a tuple to pass it to Keys.__init__ versus using Key_New() and then setting the values. | 12:09 |
| SamB | jam: that doesn't sound like much of a difference | 12:15 |
| fm | https://bugs.launchpad.net/bzr-pipeline/+bug/429301 SamB | 12:23 |
| ubottu | Launchpad bug 429301 in bzr-pipeline "export pipeline as a series of patches" [Undecided,New] | 12:23 |
| === beuno-lunch is now known as beuno | ||
| === mrevell is now known as mrevell-lunch | ||
| === Pilky_ is now known as Pilky | ||
| === james_w` is now known as james_w | ||
| bialix | SamB: be careful when talking about soviet russia. somebody watching you | 14:06 |
| jelmer | bialix: :-) | 14:08 |
| fullermd | In Soviet Russia, you watching SOMEBOD... wait, that doesn't quite work... | 14:08 |
| bialix | jelmer: hi, sorry, have no chance to run git tests fro you yet | 14:09 |
| bialix | for you | 14:09 |
| jelmer | bialix: np | 14:09 |
| jelmer | are you subscribed to the windows bugreport for bzr-git by any chance? | 14:10 |
| jelmer | There were some folks commenting on it the other day | 14:10 |
| bialix | jelmer: subscribed to windows bugreports? how it's possible? | 14:11 |
| bialix | IIUC lp allows me subscribe to all project bugmails, but it's not intelligent enough to distinguish between OS bugs | 14:12 |
| jelmer | bialix: one particular bug report I mean | 14:12 |
| bialix | err, I think no, but I'd like to | 14:13 |
| bialix | which one? | 14:13 |
| jelmer | bug 382125 | 14:14 |
| ubottu | Launchpad bug 382125 in bzr-git "Can't branch from remote repository on Windows" [Undecided,New] https://launchpad.net/bugs/382125 | 14:14 |
| bialix | jelmer: if you think I will be interested in particular bug report you can subscribe me freely. I know how to unsubscribe if I found that bug unrelated to me | 14:14 |
| * bialix looking | 14:14 | |
| bialix | I saw it other day but not yet was subcribed. Now subscribed | 14:15 |
| bialix | jelmer: as comments say it's wrong approach to open memory-mapped file in w mode | 14:15 |
| bialix | jelmer: actually you can't | 14:15 |
| bialix | on Windows | 14:15 |
| bialix | only r+ | 14:16 |
| bialix | you even can't memory map the file of 0 length | 14:16 |
| jelmer | bialix: Thanks, I'll do that in the future | 14:18 |
| jelmer | bialix: Sucks that memory mapping is readonly :-/ | 14:18 |
| jelmer | so I guess we'll just have to read manually | 14:18 |
| bialix | jelmer: perhaps I'm not quite understand your intent | 14:18 |
| bialix | jelmer: python documentation on mmap module has many special remarks re Windows behavior | 14:21 |
| jelmer | bialix: yeah, I guess I should have a look at that | 14:21 |
| jelmer | we mostly use it to read packs so I guess we should be able to solve this pretty easily | 14:21 |
| bialix | clearly RTFM case | 14:21 |
| sidnei | jelmer, bialix: nowhere in the python documentation it mentions that mmap is read-only on windows | 14:21 |
| bialix | jelmer: well, in this case it seems so | 14:22 |
| bialix | [16:18]<jelmer>bialix: Sucks that memory mapping is readonly :-/ | 14:22 |
| bialix | I'm not sure what jelmer means when he said "that" | 14:22 |
| bialix | sidnei: hi, btw | 14:22 |
| sidnei | bialix: hi! :_ | 14:23 |
| sidnei | :) | 14:23 |
| jelmer | bialix: sorry, I think I must've misunderstood | 14:23 |
| jelmer | bialix: you're saying that there can only be one person with a file opened for mmap write access at the time? | 14:23 |
| bialix | sidnei: after some experience with buildout for main bzr installer I wonder how to build smaller one to package just bzr-svn into installer :-D | 14:24 |
| bialix | jelmer: no, I don't say so | 14:24 |
| sidnei | bialix: yeah, should be possible. i wish i had time to dedicate to this :( | 14:25 |
| jelmer | bialix: hmm, not sure I follow then. I guess I'll read the docs first :-) | 14:25 |
| bialix | jelmer: bug 382125 said about error while trying to open the mmaped file in "w" mode | 14:25 |
| ubottu | Launchpad bug 382125 in bzr-git "Can't branch from remote repository on Windows" [Undecided,New] https://launchpad.net/bugs/382125 | 14:25 |
| bialix | jelmer: J really have to look at your sources first | 14:26 |
| bialix | jelmer: but if your intent is read and write in the same file via mmap, then you can achieve this, but initially you should open the file in r+ mode | 14:27 |
| bialix | sidnei: yep :-( | 14:27 |
| sidnei | i suspect the problem is that you can't open the same file for writing on windows twice (through the standard python api, you can open it in shared mode through pywin32), period. nothing to do with mmap? | 14:27 |
| bialix | sidnei: I suspect jelmer don't need to open the same file twice, because it's inprocess stuff, not IPC | 14:31 |
| jelmer | I suspect we're accidently opening the same file twice | 14:31 |
| === mrevell-lunch is now known as mrevell | ||
| bialix | jelmer: lp:dulwich branch has very strange fomat: unnamed | 14:48 |
| bialix | jelmer: can you upgrade it to 2a | 14:48 |
| bialix | ? | 14:48 |
| fullermd | You sure it's not? lp:anything is unnamed when you're logged in, since it's the smart server remote fake format. | 14:49 |
| bialix | fullermd: I've just branching it | 14:49 |
| bialix | and have 2a repo + branch 6 | 14:49 |
| bialix | locally | 14:50 |
| fullermd | Oh. What's branch7? Stacking? | 14:50 |
| fullermd | (except not, since you can stack on branch6, right? Don't quite understand that...) | 14:51 |
| bialix | fullermd: you can see full info -v output here: https://bugs.launchpad.net/bzr-git/+bug/429394 | 14:52 |
| ubottu | Launchpad bug 429394 in bzr-git "If git plugin installed without dulwich it blocks usual bzr operations with bzr trees" [Undecided,New] | 14:52 |
| bialix | fullermd: do you remember which format supports views? | 14:52 |
| fullermd | Do views actually really work? | 14:53 |
| fullermd | I think it was side by side with content filtering anyway, so that would be wt5 or whatever it is in 1.14+. | 14:54 |
| bialix | I dunno, but I'd like use it | 14:54 |
| bialix | oh | 14:54 |
| bialix | jelmer: what's the strange combination in lp:dulwich: repo 2a, branch 6, wt 7 | 14:54 |
| bialix | bzr.dev in 2a has: repo 2a, branch 7, wt 4 | 14:55 |
| fullermd | I've got wt6 in my 2a bzr.dev. | 14:55 |
| bialix | err dulwich: repo 2a, branch 6, wt 6 | 14:55 |
| bialix | fullermd: really? | 14:55 |
| fullermd | The 2a rollup is 2a-rep/br7/wt6 | 14:55 |
| bialix | so it's 1.18 issue | 14:55 |
| bialix | filing a bug is useless, core devs stopped support 1.18 already | 14:56 |
| fullermd | 1.18 creates the same thing... | 14:56 |
| fullermd | That's what the 2a rollup has always meant, I'm pretty sure. | 14:56 |
| bialix | fullermd: not for me | 14:56 |
| fullermd | Oh, maybe it's different on Windows? | 14:57 |
| * bialix branching lp:bzr again from scratch w/o shared repo | 14:57 | |
| bialix | fullermd: do you think it's a joke? | 14:57 |
| fullermd | I dunno. Wasn't Windows using a different WT format by default for a while? | 14:57 |
| bialix | never heard this | 14:58 |
| bialix | AFAIC it's contradict to default policy of bzr.devs | 14:58 |
| fullermd | The format registry for 2a lists Rep2a/Branch7/WT6, ans has since the revision that created the 2a format (4428.2.1) | 14:59 |
| * bialix still branching | 15:03 | |
| fullermd | Now, I can see how you might end up with WT4 using 1.18 to branch bzr.dev... | 15:04 |
| fullermd | (since there's no WT format on remote sides to copy, it'll just use the default, which in 1.18 is still pack-0.92, which uses WT4) | 15:04 |
| fullermd | But that should show as unnamed, not 2a for the rollup name. | 15:05 |
| bialix | fullermd: it seems so | 15:09 |
| bialix | I've just finished to branch lp:bzr and again have: repo 2a, branch 7, wt 4 | 15:10 |
| bialix | damned zoo of formats | 15:10 |
| fullermd | If you upgrade --2a it you should get wt6 though. | 15:10 |
| fullermd | (or if you'd used 2.x+ to do the branch) | 15:11 |
| bialix | yes, after upgrade to --2a I've got wt 6 | 15:11 |
| bialix | really really weird | 15:11 |
| bialix | I think I'll file a bug to see what core devs might say | 15:12 |
| vila | bialix: making 2a the new default is a significant step *away* from the zoo... you have good reasons for not taking that into account, but accept the consequences too then :D | 15:12 |
| bialix | vila: it's inconsistent | 15:12 |
| vila | file the bug anyway, 'unnamed' is never good | 15:13 |
| fullermd | The problem is that there're two behaviors here, and neither of them is (by current concensus) strictly a bug. | 15:13 |
| bialix | do you really think the behavior I see is good? | 15:13 |
| vila | bialix: ^ | 15:13 |
| vila | bseeing 'unnamed' is *never* good | 15:13 |
| fullermd | The first is that branch'ing from remote creates the local WT in the default WT format for that release, since WT's that are remote don't exist to bzr, so it has no format to copy. | 15:13 |
| bialix | getting inconsistent 2a branch is a bug for me | 15:14 |
| fullermd | And the second is that the 3 (or 4, I guess) formats are independent. | 15:14 |
| fullermd | So as far as 1.18 is concerned, wt4 _is_ the proper WT format when you haven't requested anything else. | 15:15 |
| fullermd | (since that's what it's config'd to create) | 15:16 |
| bialix | I think it's a bug https://bugs.launchpad.net/bzr/+bug/292553 | 15:21 |
| ubottu | Launchpad bug 292553 in bzr "Format "unnamed" when creating "default" branches in newer repository formats" [Medium,Triaged] | 15:21 |
| bialix | vila: I understand that nobody will work on this bug because default policy is to use bzr 2.0+ | 15:23 |
| fullermd | Well, it's more that nobody will work on it because what should be done is awful unclear. | 15:23 |
| bialix | vila: but from theoretical POV: is it possible to bzr doing the RIGHT thing? looking at formats registry, found matched combination of repo/branch formats and determine default wt format? | 15:24 |
| fullermd | None of the 3 formats is dependent on the others, so you can't guess what the WT format 'should' be based on the repo and branch format you see. | 15:24 |
| bialix | fullermd: there is registry of formats | 15:24 |
| bialix | fullermd: if you see repo 2a and branch 7 it's natural to expect this is 2a branch? | 15:24 |
| fullermd | Not necessarily. If you see a knit repo and a branch5, what wt format do you create? | 15:25 |
| bialix | wt is special for treeless central repos, so bzr can be more smart about detecting the right format, rather than using defqult one | 15:25 |
| bialix | fullermd: I dunno? | 15:25 |
| bialix | but maybe bzr devs care to provide special registry then? | 15:26 |
| bialix | to lookup default wt format based on repo+branch combination? | 15:26 |
| fullermd | The point is, nobody can know. It could be wt3 OR wt4. Both are defined with that branch/repo combination. | 15:26 |
| bialix | you really talk about ancient things | 15:27 |
| fullermd | And there's no reason to believe the 'right' answer isn't wt7 for that branch either, just because you don't have a defined rollup format for it. | 15:27 |
| bialix | I'm talking about new things | 15:27 |
| bialix | urgh | 15:27 |
| fullermd | There's no rule that multiple WT formats for given repo/branch combinations are only historical. | 15:27 |
| bialix | I don't care | 15:28 |
| bialix | I wanna have consistent 2a branch after branching lp:bzr | 15:28 |
| bialix | I can't | 15:28 |
| fullermd | 1.9 and 1.14 both use pack6 and branc7, but they have different WT formats. | 15:28 |
| bialix | bzr is broken then | 15:28 |
| bialix | I hate it | 15:28 |
| fullermd | Who cares? The WT works just fine. | 15:28 |
| bialix | 1.14 never was in favor | 15:28 |
| bialix | it was experimental thing nobody really used | 15:28 |
| vila | not at all, it wasn't providing the same benefits to all cases so it was promoted mostly where it was | 15:29 |
| fullermd | Everybody's [will be] using it, since it's contained in the 2a WT format. | 15:29 |
| vila | but 2.0 was already worked on anyway so there was little incentive is pushing everybody to upgrade to 1.14 | 15:30 |
| bialix | zoo of formats zoo of formats zoo of formats | 15:30 |
| vila | s/2.0/2a/ | 15:30 |
| fullermd | The repo and branch formats, taken in combination, tell you nothing about what the WT "should be", if that's even a meaningful question in the first place. | 15:30 |
| bialix | why not create all possible permutations then? | 15:30 |
| fullermd | For me, I think the rollup format name is the problem in the first place. | 15:30 |
| * bialix reallyhave to shut up | 15:31 | |
| vila | yeah sure, you can repeat that ad nauseam, we are working to get out of that anyway | 15:31 |
| fullermd | I think it just causes way more trouble than it saves. | 15:31 |
| vila | fullermd: I agree. It should be fixed nevertheless. | 15:33 |
| vila | (including replacing it by several parts if needed) | 15:33 |
| fullermd | Well, that just opens the question of "what's the fix"; if the problem is "'unnamed' is alarming", then just not showing a rollup line is a fix :p | 15:34 |
| vila | not sure we can get two votes on that one :-D | 15:34 |
| bialix | is not this simply hides the problem deeper? | 15:36 |
| fullermd | A matter of perspective. | 15:37 |
| bialix | if wt7 is filter-aware format and you expect to have proper filtering and... | 15:37 |
| bialix | naoki_: hi | 16:03 |
| naoki_ | hi | 16:03 |
| bialix | naoki_: small proposal re tbzr | 16:04 |
| naoki_ | what's? | 16:05 |
| bialix | will be nice if you will update version info after some changes you made | 16:05 |
| bialix | so each bzr-X.Y.Z-setup build will be with more or less unique tbzr version | 16:05 |
| bialix | having 0.2 still while you doing many improvements does not sound right | 16:05 |
| bialix | at least it was my impression looking at recent bug reports | 16:06 |
| naoki_ | I see. | 16:06 |
| naoki_ | After releasing 2.0, version compatibility is more problem. | 16:07 |
| bialix | it will be much simpler to check bug reports | 16:07 |
| bialix | what do you mean? | 16:07 |
| naoki_ | TortoiseBZR have released with newest bzr. | 16:08 |
| naoki_ | There are no like 1.13.5 after 1.14 released. | 16:08 |
| bialix | I don't quite understand | 16:09 |
| naoki_ | But after 2.0, 2.0.5 can released after 2.1 released. | 16:09 |
| bialix | this is not problem per se | 16:09 |
| bialix | having 2 branches: one for stable 2.0.x and other for trunk | 16:09 |
| naoki_ | So, TortoiseBZR should define compatible bzr version like other plugins. | 16:09 |
| bialix | something like that will be nice, yes | 16:10 |
| bialix | but TBZR is not plugin | 16:10 |
| bialix | so you need to show the error message in different (GUI) way | 16:10 |
| naoki_ | Yes, but relying to bzr api. | 16:10 |
| bialix | and unless TBZR can be build separately of bzr.exe, it's not a problem | 16:10 |
| naoki_ | hmm. | 16:11 |
| bialix | igc has started separate windows-installer project, so you can stick specific tbzr version to specific bzr release | 16:11 |
| naoki_ | So, I can use simple version number for TBZR. | 16:11 |
| bialix | anything that will work for you is good | 16:12 |
| naoki_ | OK. | 16:12 |
| naoki_ | I'll branch and tag 0.2 | 16:13 |
| bialix | this is just suggestion based on my qbzr release manager experience | 16:13 |
| bialix | version numbers is just numbers | 16:13 |
| bialix | they are needed solely to distinguish between them | 16:13 |
| bialix | no more no less | 16:14 |
| bialix | version numbers like 1.0 and 2.0 is more than numbers | 16:14 |
| bialix | they are MESSAGE to the worls | 16:14 |
| bialix | world | 16:14 |
| naoki_ | Yes, people feels "1.0" is stable. | 16:15 |
| naoki_ | I have not done some operation on Launchpad, like series, release, etc... | 16:21 |
| naoki_ | Now I tagging release-0.2.0 and push. | 16:22 |
| naoki_ | It will compatible with bzr-1.18, 2.0, and qbzr-1.14 | 16:22 |
| bialix | it's ok | 16:23 |
| bialix | just mention these dependencies in README or somewhere | 16:24 |
| bialix | have to go. bye all | 16:24 |
| igc | night all | 16:25 |
| naoki_ | good night | 16:25 |
| === deryck is now known as deryck[lunch] | ||
| === deryck[lunch] is now known as deryck | ||
| bialix | good evening | 18:51 |
| bialix | I want to ask about mainline idea | 18:51 |
| bialix | anybody knows where from it comes? originates? | 18:51 |
| === davidstrauss_ is now known as davidstrauss | ||
| malibu | Hi there... | 19:07 |
| malibu | use bzr break-lock chroot-19383696:///r/repo/bzr/work/.bzr/branch/lock | 19:07 |
| malibu | " | 19:07 |
| malibu | when I do this, I get invalid protocol for chroot-19383696 | 19:08 |
| malibu | When I go to the root of my repo and just do 'bzr break-lock', it hangs | 19:08 |
| malibu | Is there a way for me to just go into the repo and manually clear the lock? I have full access to it | 19:08 |
| bialix | chroot-xxx is temp protocol for bzr+ssh | 19:14 |
| bialix | use bzr break-lock url | 19:14 |
| bialix | it should not hang | 19:15 |
| fullermd | bialix: I would guess at least some of it comes from arch. | 19:15 |
| bialix | but it asked you about confirmation: y/N | 19:15 |
| bialix | fullermd: I'm not familiar with arch | 19:15 |
| bialix | fullermd: do you have any docs/links? | 19:16 |
| fullermd | (not that I have more than a passing knowledge of it myself, but AIUI it did have some level of similar dichotomy between 'happened here' and 'grabbed from elsewhere') | 19:16 |
| fullermd | No, just a general sense from some reading way back when and mentions of it since. | 19:17 |
| bialix | is it correct if I assume mainline is like trunk in svn when UQDS used? | 19:17 |
| fullermd | Your best bet may be to corner poolie and see how much was planned or emergent. | 19:17 |
| bialix | fullermd: mainline in your country is more like man railroad or high way? | 19:18 |
| bialix | s/man/main/ | 19:18 |
| bialix | hmm | 19:18 |
| fullermd | I don't really think of it as either; without context it just strikes me kinda abstractly... | 19:18 |
| bialix | poolie maybe will be good person for this question, but he's in oz time :-/ | 19:19 |
| LarstiQ | I'm not sure where the thinking that mainline is imported came from | 19:19 |
| bialix | fullermd: ok, can you provide me some expressions with this word, please? | 19:19 |
| LarstiQ | important | 19:19 |
| bialix | LarstiQ, fullermd: I'm writing article about mainline concept in bzr and its impact on daily work | 19:20 |
| bialix | I want to provide some simple explanation | 19:21 |
| fullermd | I'm not sure. I don't think of it as a strong analogy to some other thing; just the hazy concept of a privileged path compared to others... | 19:21 |
| bialix | in Russian I've translated mainline as main branch or main development line | 19:21 |
| bialix | as line of revisions | 19:21 |
| fullermd | Now, my understanding of how it applies in bzr in particular and version control in general, and why it's important and useful, didn't come from any docs I read or discussions I saw, AFAICT. It just sort of built itself up from fiddling. | 19:21 |
| malibu | bialix: Do I use the url to the actual file, or just to the root of my repo? | 19:22 |
| bialix | malibu: root of branch or repo | 19:22 |
| LarstiQ | malibu: to your branch | 19:22 |
| malibu | ok.. | 19:22 |
| fullermd | Yeah, there's some ambiguity there; it's sometimes used as 'main branch' (e.g., 'trunk' or the like). But in this context, it's more like.... mmm... 'primary path through history', maybe? | 19:22 |
| fullermd | It's the antithesis of relativity; a privileged frame of reference ;p | 19:23 |
| bialix | fullermd: it's mentioned on b-v.o wiki in Workflows document | 19:23 |
| bialix | primary path through history -- very poetic, I like it | 19:23 |
| bialix | technically it's just left hand revisions chain | 19:24 |
| bialix | but this is ugly technical detail | 19:24 |
| fullermd | It's a cross-section of the history that, if you work in a certain way, allows you to get a good high-level view of what's happened, much more quickly than if you have to read every page. | 19:25 |
| fullermd | Cliff Notes to a branch (I wonder how well that translates...) | 19:25 |
| fullermd | I think that's mostly a US-ism. | 19:25 |
| bialix | http://en.wikipedia.org/wiki/CliffsNotes -- this one? | 19:26 |
| fullermd | Yah. | 19:26 |
| bialix | yes, it's hard to translate | 19:27 |
| bialix | I'm little worried about dark side of mainline though | 19:27 |
| bialix | you should use only mainline otherwise you will be screwed | 19:28 |
| bialix | or your history will be hard to read/undersatdn | 19:28 |
| bialix | understand | 19:28 |
| fullermd | Well, it's a mechanism to ignore information. If you ignore the right stuff, it can be a big aid. If you ignore the wrong stuff, you're in trouble. | 19:28 |
| bialix | how people deal with it? | 19:28 |
| fullermd | And (tautologically) if you work in a way that mainline doesn't end up holding the right information, you won't get the right information from it (FSVO 'right'). | 19:29 |
| bialix | fullermd: well, log -n1 now default, so it's possible to say by default bzr ignores both right and wrong dtuff | 19:29 |
| bialix | stuff, sorry | 19:30 |
| LarstiQ | bialix: does your audience have experience with hg or git log? | 19:30 |
| bialix | LarstiQ: I'm writing articles so it's self-contained | 19:31 |
| fullermd | It can be simpler if they don't, since that brings biases. | 19:31 |
| bialix | I don't do explicit references to hg or git | 19:31 |
| LarstiQ | ok | 19:31 |
| bialix | I often compare with svn though | 19:31 |
| bialix | because it makes some examples simpler | 19:32 |
| bialix | LarstiQ: btw, do you heard about group extension for hg? | 19:32 |
| fullermd | That can be more useful; it's easier to describe the capabilities it provides as "svn log"++, rather than a sort of "git log"--. | 19:32 |
| LarstiQ | bialix: I haven't | 19:33 |
| fullermd | Anyway, it's way past my bedtime; I'm too far gone to dream up good analogies tonite :| | 19:33 |
| bialix | although I'm writing for newbies mostly I'm trying to explain things not for dummies, so even experienced people can get some new info | 19:33 |
| LarstiQ | fullermd: I was thinking of the non-discriminating nature | 19:33 |
| bialix | fullermd: what? are you going to sleep? | 19:34 |
| fullermd | I was planning more on staring muzzily at the ceiling for a few hours, but... call it what you will. | 19:34 |
| bialix | LarstiQ: this extension aims to combine several revisions into logical group, something similar to bzr mainline | 19:35 |
| bialix | fullermd: lol :-D | 19:35 |
| LarstiQ | bialix: cool :) | 19:35 |
| bialix | fullermd: ok, you win, bye | 19:35 |
| zsquareplusc | bialix: and you already have articles online? | 19:36 |
| * fullermd quickly hides away so bialix doesn't ping him in his sleep... | 19:36 | |
| bialix | zsquareplusc: yes, http://bzr-day.blogspot.com | 19:36 |
| bialix | fullermd: I've promised to not ping ou next 6 months | 19:36 |
| zsquareplusc | ah, wrong encoding for me :-) | 19:36 |
| bialix | *you, err | 19:37 |
| bialix | zsquareplusc: ru_RU | 19:37 |
| fullermd | Well, if I'm really lucky, I'll sleep longer than that ;p | 19:37 |
| bialix | :-D | 19:37 |
| bialix | :-D :-D :-D | 19:37 |
| zsquareplusc | bialix: yea i know, the characters look perfectly as they should. it's me that can't make any sense from them ;-) | 19:38 |
| bialix | yeah :-D | 19:38 |
| bialix | don't try to use google translate service | 19:39 |
| bialix | result is rather unpredictable :_D | 19:39 |
| bialix | :-D | 19:39 |
| bialix | especially funny when it tranlsate "command" as "team" | 19:40 |
| bialix | just because these words are sound the same in Russian | 19:41 |
| bialix | "bzr add team" | 19:41 |
| === kiko-afk is now known as kiko | ||
| bialix | how you can say "dotted revno" in other words? | 20:15 |
| LarstiQ | "revno with branchpoint information encoded" | 20:18 |
| Tak | is checking WorkingTree.merge_modified against none or empty The Correct Way to determine if there are merges pending commit? | 20:18 |
| bialix | look at cmd_push in builtins.py | 20:21 |
| bialix | there is check that wt has no changes files or pending merges | 20:21 |
| Tak | cool, thanks | 20:23 |
| bialix | Tak: len(tree.get_parent_ids()) > 1) | 20:23 |
| Tak | thanks more! | 20:23 |
| Tak | (prosiba? :-P) | 20:24 |
| bialix | Tak: spasibo | 20:25 |
| Tak | damn | 20:26 |
| bialix | nm | 20:26 |
| * Tak blame mumblers | 20:26 | |
| bialix | Russian is close to English in one feature: what is written often spelled very differently | 20:27 |
| bialix | Tak: so if you want to write use: spasibo, if you will spell it, then close to your original variant | 20:28 |
| * Tak nod | 20:32 | |
| bialix | What is codename of Ubuntu 8.04 ? | 20:32 |
| jderose | bialix: hardy | 20:33 |
| bialix | oh | 20:33 |
| bialix | it's from beginning of 2008? | 20:34 |
| zsquareplusc | yes the number IS the date | 20:34 |
| bialix | nice | 20:34 |
| bialix | what is LTS period? 5 years? | 20:34 |
| bialix | anybody knows how to install newer qt on hardy? | 20:35 |
| bialix | bug 429549 | 20:35 |
| ubottu | Launchpad bug 429549 in bzr-explorer "Opening Preferences: bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute 'QFormLayout'" [Undecided,New] https://launchpad.net/bugs/429549 | 20:35 |
| zsquareplusc | you'll probably get better support in #ubuntu ;-) | 20:35 |
| bialix | meh | 20:36 |
| Tak | so what behavior would one expect from a review/commit dialog on a tree with pending merges? | 20:36 |
| bialix | I'll leave this question for igc | 20:36 |
| bialix | Tak: review? | 20:36 |
| LarstiQ | bialix: "see if I want to commit it as is" | 20:37 |
| Tak | examine changes | 20:37 |
| bialix | Tak: look at qcommit? | 20:37 |
| * zsquareplusc misses the checkboxes and easy diff as TortoiseSVN has it for commits | 20:38 | |
| bialix | zsquareplusc: IIUC qcommit has checkboxes | 20:38 |
| bialix | Tak: there is one big difference vs plain commit: when there is pending merges you always should commit entire tree, you can't select files for commit | 20:39 |
| Tak | precisely | 20:40 |
| * bialix nods | 20:41 | |
| zsquareplusc | bialix: a yes it has. i run the gtk gui more often than qbzr | 20:41 |
| Tak | the current dialog: http://img294.imageshack.us/img294/1847/mdbzrreviewcommit.png | 20:41 |
| bialix | Tak: so what is your question about? | 20:41 |
| Tak | I'm trying to figure out the most helpful way for the gui to behave when there are pending merges | 20:42 |
| bialix | zsquareplusc: try qbzr then | 20:42 |
| bialix | Tak: it's not easy, indeed | 20:43 |
| bialix | Tak: nothing better than suggesting show some explanation message about pending merges | 20:43 |
| bialix | can you commit several files from your GUI? | 20:44 |
| Tak | yes | 20:44 |
| bialix | so maybe forcing this mode when there is merge? | 20:44 |
| Tak | right now, if there's a merge pending, it requires you to commit everything in order for the commit to succeed | 20:45 |
| bialix | do you support per-file commit messages? | 20:45 |
| Tak | no, not currently | 20:45 |
| bialix | on your screenshot there is prompt: Commit message for file 'vgtk' | 20:46 |
| bialix | this can be misleading for pending merge case | 20:46 |
| Tak | yeah, it is a little misleading | 20:46 |
| Tak | What that actually does is create a commit message like: * blah.c: Fixed x.\n * blah.h: Fixed y. ... | 20:47 |
| bialix | something like per-file entries, I suppose | 20:48 |
| Tak | yeah | 20:48 |
| bialix | and where is main commit message will be edited? | 20:48 |
| Tak | it was originally designed for svn | 20:48 |
| bialix | hehe | 20:49 |
| bialix | I've reused svn support in FTE editor for bzr actions | 20:49 |
| Tak | when "Commit" is pressed, a verification dialog pops up with the list of selected files and the full commit message | 20:49 |
| bialix | it was so easy and mostly work | 20:49 |
| bialix | Tak: ok, so use this dialog | 20:50 |
| bialix | or invoke gcommit if this is gtk-based stuff | 20:50 |
| Tak | yeah, bzr's ui maps nicely | 20:50 |
| bialix | I'm still not quite understand what is your question actually | 20:51 |
| phinze | so i don't shoot myself in the foot: do shelves as stored `bzr shelve` survive a bzr switch in a lightweight checkout? | 20:53 |
| phinze | or, alternatively, do they stick to their associated branches somehow (though i don't know how that world even work implementation-wise) | 20:54 |
| phinze | use case: jam-style setup, realize i started working on something that should be tracked in a new task branch, want to shelve, switch to new task branch, unshelve, selectively commit, reshelve rest, switch back, commit rest | 20:55 |
| bialix | jam-sttyle :-) | 20:55 |
| bialix | phinze: basically shelved changes stored in your checkout | 20:56 |
| bialix | so they keep intact on switch | 20:56 |
| bialix | they can know about base revision though | 20:57 |
| bialix | so | 20:57 |
| bialix | if your new branch based on current --everything should be fine | 20:57 |
| bialix | old shelve1 working via plain patches | 20:58 |
| bialix | you still can use it | 20:58 |
| Tak | bialix: just wondering about the nicest way to present the user with the fact that 1) There are pending merges and 2) Commits have suddenly become all-or-nothing | 20:59 |
| bialix | Tak: in qcommit we show list (graph) of pending merge | 21:00 |
| phinze | bialix: awesome thanks | 21:03 |
| luks | bzr could really support file selection even on merge commits | 21:04 |
| luks | you can easily work it around by reverting/shelving the files before commit | 21:04 |
| bialix | luks: hi | 21:04 |
| luks | hi bialix | 21:04 |
| bialix | luks: why? | 21:04 |
| luks | I think it just unnecessarily restricts the user | 21:05 |
| bialix | I think this is downside of mainline paradigm we talked earlier | 21:05 |
| bialix | maybe you're right, IIRC there is bug report opened long time ago | 21:05 |
| Tak | I agree with luks | 21:06 |
| bialix | about unshelve or about restrict? | 21:06 |
| bialix | from my experience I need selective commit on merge very rarely | 21:07 |
| luks | I would understand the behavior if revert/shelve refused to work on a merge | 21:07 |
| Tak | bialix: about both, really | 21:08 |
| bialix | ok | 21:08 |
| luks | hm, but revert is actually useful for resolving merges | 21:08 |
| luks | so that wouldn't work | 21:08 |
| bialix | what difference between log -n0 and log --include-merges? | 21:11 |
| * luks hasn't used bzr log for ages :) | 21:13 | |
| * bialix too | 21:13 | |
| bialix | qlog rules | 21:13 |
| bialix | but for article I have to | 21:14 |
| LarstiQ | bialix: less cryptic name | 21:15 |
| bialix | ok | 21:15 |
| === Pilky_ is now known as Pilky | ||
| rocky | jelmer: hey, is there a version of bzr-svn for bzr 2.0dev yet? | 22:00 |
| lifeless | moinmoin | 23:01 |
| poolie | hi lifeless | 23:02 |
| thefirstdude | hi poolie | 23:03 |
| poolie | hi | 23:05 |
| * davidstrauss joins the hi-fest | 23:11 | |
| davidstrauss | Hi! | 23:11 |
| jelmer | rocky: yeah, the 1.0 branch of bzr-svn should work with 2.0 | 23:11 |
| poolie | jelmer: could you make at least an rc of it in the next couple of days | 23:19 |
| poolie | so that we will have something suitable to sync into jaunty? | 23:19 |
| bialix | poolie: hi | 23:37 |
| poolie | hello bialix | 23:37 |
| bialix | several hours ago I've asked about mainline paradigm origin and fullermd suggested to asking you | 23:38 |
| bialix | can you make some remarks about mainline and its roots? | 23:38 |
| bialix | I need this for my new article | 23:39 |
| bialix | poolie: ^ | 23:39 |
| poolie | sure | 23:39 |
| poolie | about why people have a mainline at all? | 23:39 |
| bialix | no, about why bzr has mainline concept | 23:40 |
| bialix | and no one else dvcs seems to have it | 23:40 |
| jam1 | hi all | 23:40 |
| jam1 | ghost jam | 23:41 |
| bialix | and what is mainline in other words | 23:41 |
| jam1 | sorry mt | 23:41 |
| lifeless | jam1: hi. I suggest looking at pyrexes interface stuff | 23:41 |
| poolie | hello jam1 | 23:41 |
| bialix | hello jam1 | 23:41 |
| === jam1 is now known as jam | ||
| poolie | bialix: oh, mainline in the sense of having revisions numbered along the left side? | 23:41 |
| poolie | well | 23:41 |
| jam | lifeless: sure, I'll probably poke into that next week | 23:41 |
| lifeless | the amount of C we're writing.. | 23:42 |
| bialix | poolie: I eager to know everything, but even short vision from you as original author will help | 23:42 |
| lifeless | I am getting my feeling back of 'just do it in C' :P | 23:42 |
| poolie | it's a bit hard for people to visualize unrestricted dags, and a bit hard to represent them well in text mode | 23:42 |
| poolie | if you just give them arbitrary revision ids, they're impossible to compare | 23:42 |
| poolie | and dates are not reliable in a distributed system | 23:43 |
| bialix | esp when you have rebase | 23:43 |
| poolie | right | 23:43 |
| bialix | why collapsing merges revisions? | 23:43 |
| poolie | in the log? | 23:43 |
| poolie | any ideas about bug 429553? | 23:44 |
| ubottu | Launchpad bug 429553 in bzr "bzr diff errors with "no revision"" [Undecided,New] https://launchpad.net/bugs/429553 | 23:44 |
| bialix | um... yes | 23:44 |
| jam | is igc around? | 23:44 |
| lifeless | bialix: do you mean 'why -n1 by default' ? | 23:44 |
| jam | I wanted to ask a bit about cvs2bzr | 23:44 |
| lifeless | jam: haven't seen him yet this morning | 23:44 |
| bialix | poolie: this question about bug for me? | 23:45 |
| bialix | poolie: I dunno | 23:45 |
| poolie | no, more jam or lifeless | 23:45 |
| poolie | bialix: i think that merges are not perfectly symmetric from the human's point of view | 23:45 |
| bialix | lifeless: no, not -n1, about entire ideas of distinct clearly between left hand revs and merged revs | 23:45 |
| poolie | i don't think people see it as 'merge A and B' but more 'merge B into A' | 23:46 |
| bialix | it depends | 23:46 |
| poolie | well, | 23:46 |
| poolie | let's say it's often the second | 23:46 |
| jam | poolie: I don't have a specific idea, but this line looks odd | 23:46 |
| jam | File "bzrlib\repository.pyo", line 1826, in get_revision_reconcile | 23:46 |
| bialix | poolie: I found mainline idea good for disciplined developers | 23:46 |
| bialix | but bad for bad developers | 23:46 |
| poolie | if people often push or push overwrite it probably makes things confusing | 23:47 |
| poolie | is that the sort of thing you mean? | 23:47 |
| jam | bialix: how is it worse for undisciplined developers than not having a mainline at all? | 23:47 |
| jam | hence you get the win with "disciplined" developers, but status quo for the rset | 23:47 |
| jam | rest | 23:47 |
| bialix | poolie: I have one in my team, who prefer to use only one his branch instead of make features branches for every new feature | 23:47 |
| poolie | and he just merges to and from his branch? | 23:48 |
| bialix | well, your idea about merge is not symmetric does not work when bad developer merge several weeks of work at once | 23:48 |
| bialix | i.e. merge several new features interlined | 23:49 |
| bialix | poolie: he just merge trunk into his own branch and don't pay attention about mainline annotation | 23:49 |
| poolie | and then he pushes his branch to trunk? | 23:49 |
| bialix | without append_revisions_only things become nightmare | 23:49 |
| bialix | poolie: in the past yes, pushed. now I've restricted him to use me as gatekeeper | 23:50 |
| poolie | hm | 23:50 |
| bialix | poolie: hg has version numbers but does not have mainline | 23:50 |
| poolie | why does he do this? | 23:50 |
| jam | poolie: one possibility for the 'diff' is that it is trying to get the old revision so that it can fake a timestamp | 23:51 |
| jam | and perhaps that revision is a ghost? | 23:51 |
| poolie | right, in hg i think the versions are numbered in arbitrary topo-sorted order | 23:51 |
| bialix | and hg guys "invent" group extension which does similar thing | 23:51 |
| jam | poolie: right, they are the 'order the revision appeared in my repo' | 23:51 |
| jam | and your numbers and mine are not the same | 23:51 |
| jam | for the same rev | 23:51 |
| bialix | i.e. add group comment to the several revisions to make them logical group in log | 23:51 |
| bialix | poolie: I mean hg reinvent our wheel here: some sort of history annotation (as fullermd said) | 23:52 |
| bialix | we have this for free from hardcoded mainline support | 23:52 |
| poolie | basically i think the view you get from a bzr trunk branch is very good | 23:53 |
| poolie | first this happened, then this happened, then this happened... | 23:53 |
| bialix | so basically what is bother me a lot is this hardcoded mainline paradigm. | 23:53 |
| poolie | and you can look at the details of all of the individual commits leading up to any of them | 23:53 |
| bialix | yes, bzr follow this paradigm very well | 23:53 |
| bialix | but not all projects are so disciplined | 23:54 |
| bialix | what is your suggestions then? | 23:54 |
| lifeless | poolie: in hg changes are in repo-add order | 23:54 |
| bialix | and yes, default log -n1 makes the things a bit harder for undisciplined devs | 23:54 |
| poolie | lifeless: i know | 23:54 |
| lifeless | bialix: why not set 'append_only' on your branch ? | 23:54 |
| bialix | lifeless: I did | 23:55 |
| lifeless | poolie: sorry :P you said 'I think' :P | 23:55 |
| bialix | but it's not default | 23:55 |
| bialix | I understand reasons behind log -n1 (dotted revnos), I', just trying to understand mainline as word and paradigm | 23:56 |
| bialix | is not it too restrictive? | 23:56 |
| poolie | the idea is that when you're looking at a particular branch, it focuses attention on revisions that were actually committed in that particular branch (or its parent), rather than merged into it | 23:57 |
| poolie | i think this is useful | 23:58 |
| poolie | but if it turns out to be restrictive, we should try to relax those restrictions | 23:58 |
| malibu | When I do break-lock from command line, bzr hangs | 23:58 |
| poolie | in other words bzr should never hold you back from seeing or working with the real graph | 23:58 |
| malibu | bialix: I think you were helping me before.. it does in fact hang | 23:58 |
| malibu | I've been leaving it sit for 2 hours now | 23:58 |
| bialix | malibu: many core devs around, please show us some pastebin | 23:59 |
| bialix | you can file a bug though | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
