[01:28] hi all [01:28] Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jameinel [02:06] do you see any problem with https://code.launchpad.net/~bialix/bzr/2.2-configobj/+merge/50507 spiv [02:09] nm, i don't think there is one [02:11] If it's the same as a patch from upstream, I don't see a problem. [02:11] i just asked because there seemed to be some worry on the bug [02:11] but i think it's spurious [02:11] Except perhaps that it leaves the version of configobj in the tree vs. upstream a bit hard to describe? [02:11] perhaps we should delete it for 2.4 [02:12] there was a mail thread [02:12] i think it's only needed on hardy? [02:12] anyhow, not urgent today [02:12] It'd be nice; we do currently have startup speed improvements in our copy that upstream probably doesn't have. [02:13] Because we simply comment out some functionality we don't use that requires some expensive imports, but presumably upstream cares about those features... [02:15] mm i see [06:58] hi all [12:35] let's try again: HI ALL [12:35] . o O (Resounding silence...) [12:36] OH HAI vila! [12:36] bonjour! [12:36] :-D [12:43] bialix: ping, yeah, I know, you're not there, but may be you grep the logs ;) [13:08] Hmm, no PP - anyone fancy looking at a pretty trivial review in a rather dusty plugin? :-) https://code.launchpad.net/~maxb/bzr-cvsps-import/fix-test/+merge/50421 [13:09] HUH ? no PP ? wtf ? poolie updated it and I see no trace of further updates... :( === vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jameinel | 2.3.0 is officially out ! (RM: vila) [13:11] *blink* [13:12] maxb: this is fix looks and feels correct, yet... I should miss something. Why did it fail ? [13:12] it also looks good here, but my CVS foo is weak. [13:12] Because of paths containing /./ which were not expected [13:12] Haaaa [13:12] I don't think the test can ever have been run successfully [13:13] maxb: approved [13:13] Elsewhere I might have been tempted to apply normpath liberally, but since this test was already testing an _underscore method, it felt right to test the internals [13:14] maxb: did r64 break the testsuite? [13:17] oh [13:17] yes it probably did [13:17] hmm [13:18] Perhaps this deserves further examination then [14:29] fwiw, the _LockWarner error I talked about the other day isn't going away of its own accord. [14:29] I've had it come up in numerous other test runs. [14:35] Hello guys, I'm a bit new here. Normally on Linux, I work with Git, but on Windows I want to try Bazaar because I want to introduce it at our company (we're using the old M$'s SourceSafe). [14:37] hiya nordin [14:38] So I started a Windows project using Visual Studio and initialized the project from Bazaar desktop GUI tool. I made from VS some canges and want to see if changes are shown with the bazar tool. But it doesn't show any changes. Can someone guide me a bit? [14:38] hello beuno :) [14:39] the changes can only be shown, if I add a file using the bazaar tool. [14:39] nordin: have you tried the refresh button at all? IIRC it only auto refreshes every 10 mins, but it's been a while for me. [14:40] Yes I refreshed it too, forgot to mention that. [14:40] wait, so you haven't added the files to bzr yet? if that's the case Bzr can't tell any changes unless they've been added to the repository [14:40] or are you saying it won't even recognize new files? [14:41] I also created an empty file and want to see if bazaar can see that a file has created, but also nothing. So I deleted the .bzr map and the trunk, re-initialized it, because I thought I might initialized it in the wrong directory. [14:41] Same result. [14:41] rubbs: no it won't recognise. [14:42] Maybe you can provide me a good link? [14:43] I used bazaar's documents for windows system based tutorials, but that's where I ended up now. [14:44] nordin: sorry it's been over a year since I've use bzr on windows now. I wish I could help more, but there are others on the chan who may be able to help more [14:44] /1/1 [14:44] erk, sorry [14:45] rubbs: no problem, I do see red marked text saying I haven't defined parent location yet... === beuno is now known as beuno-lunch === beuno-lunch is now known as beuno [17:58] new p-i running on package-import.local \o/ [17:59] bzr seems to get confused sometimes with its relative paths :| [18:00] fullermd: it depends... [18:00] . o O (You just asked for that one ;) [18:01] there are some interesting bugs filed recently. [18:06] Well, lots of things depend, but I think 'crashing' qualifies as confusion :p [18:24] bug 720853 is particularly fun. [18:24] Launchpad bug 720853 in bzr (Ubuntu) "bzr crashed with RuntimeError in normpath(): maximum recursion depth exceeded while calling a Python object" [Undecided,New] https://launchpad.net/bugs/720853 [21:34] hi! [21:35] Does anyone have a clue for what to do when you get in bzr gcommit "on bzr gcommit I get "unknown error 'sp1f-makefile.am-20010411110351-k5iezflkcrh2r5dzkgl3zuhr3cxtnsa7'" [21:36] I got the same error in two different source trees (sharing a common .bzr directory) [21:37] hi montywi [21:37] poolie: hi! [21:37] * mneptok hugs poolie [21:37] Any clue of what to do? [21:37] uh, i guess look for more information about the error in .bzr.log [21:37] with just that it's hard to tell what it means [21:37] I have a really big merge just done and would hate to have to do it again.... [21:37] .bzr.log has nothing about this [21:38] montywi: hopefully that disk issue is not to blame in any way. [21:38] it says 'All changes applied successfully" [21:38] this happend before disk crashed [21:38] ah, OK [21:38] Is it possible you could try "bzr commit" on the commandline to establish whether we are talking about a core or bzr-gtk problem? [21:38] hm, perhaps then try the commit from the command line? see if it can be reproduced? [21:38] The only clue I have is that the above is an old modified file, but in another branch [21:38] do you know what version of bzr you're using? [21:39] 2.1.0 [21:39] if I do 'bzr update' and then bzr gcommit, I get the message 'nothing to commit' [21:41] Testing by modifing one file and doing bzr commit [21:42] when testing by doing a small modification, it worked [21:43] how to test if the tree is correct? is bzr check enough? [21:45] yes [21:45] checking you can make another checkout of it would be a way to get external validation [21:46] ok, will try [21:48] i was able to do a bzr pull from another machine for the library [21:49] now doing bzr check [21:53] which of course takes a VERY long time [21:54] it could be tuned, or usefully check just the tree [21:58] still working [22:01] checking commit contents:inventories 0/2 [22:01] this has not changed for the last 10 min [22:05] there is a \ before the checking commit contents [22:05] is this supposed to 'rotate' to show that something is happening? [22:05] it's not changing, which is confusing as it's impossible to see bzr check is doing anything... [22:10] it is supposed to spin [22:10] i would try an strace on it [22:10] tbh if you want to see if your tree is ok, rather than checking all history, i'd just try branching from it [22:11] i did manage to do a branch from it [22:11] strace shows a lot of seek_set calls [22:12] FWIW, my experience with significant check's is that the spinner is stalled _way_ more often than not. [22:12] but it's hard to say if this is in a loop or not [22:13] this is happening millions of times: [22:13] open("/home/my/.bzr/repository/packs/95bf270064open("/home/my/.bzr/repository/packs/95bf270064246246a06e2f3d9639ceb5.pack", O_RDONLY) = 26 [22:13] fstat(26, {st_mode=S_IFREG|0664, st_size=144334478, ...}) = 0 [22:13] fstat(26, {st_mode=S_IFREG|0664, st_size=144334478, ...}) = 0 [22:13] mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffe228c2000 [22:13] lseek(26, 0, SEEK_SET) = 0 [22:13] read(26, "Bazaar pack format 1 (introduced"..., 4096) = 4096 [22:14] lseek(26, 52871168, SEEK_SET) = 52871168 [22:14] read(26, "\325\214H\"!\r(\243e}\252\273(\10\205\340\223\321f fstat(26, {st_mode=S_IFREG|0664, st_size=144334478, ...}) = 0 [22:14] fstat(26, {st_mode=S_IFREG|0664, st_size=144334478, ...}) = 0 [22:14] mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffe228c2000 [22:14] lseek(26, 0, SEEK_SET) = 0 [22:14] read(26, "Bazaar pack format 1 (introduced"..., 4096) = 4096 [22:14] lseek(26, 52871168, SEEK_SET) = 52871168 [22:14] read(26, "\325\214H\"!\r(\243e}\252\273(\10\205\340\223\321f sorry, a bit more than I intended.... [22:14] still it does the above over and over again, with slightly different addresses [22:14] ok, so i think it is actually checking history [22:14] still, adding a simple cache for the above should speed up things 100x [22:20] poolie: I am just worried that I got the error message twice (in different directories) when doing merges [22:29] looks like it takes 'forever' [22:29] I will go to sleep and see what it says in the morning... [23:09] is there a ui for getting at revision properties yet? [23:15] mtaylor: Sure! [23:16] mtaylor: "bzr cat-revision" [23:17] mtaylor: I'm not sure if displaying raw revision properties has much use; you can add formatters for revision properties though, and there are a few standard formatters (such as for the "bugs", "authors" and "nick" revision properties) [23:20] hi jelmer [23:26] 'morning poolie