[01:28] <poolie> hi all
[01:28] <poolie>  Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jameinel
[02:06] <poolie> do you see any problem with https://code.launchpad.net/~bialix/bzr/2.2-configobj/+merge/50507 spiv
[02:09] <poolie> nm, i don't think there is one
[02:11] <spiv> If it's the same as a patch from upstream, I don't see a problem.
[02:11] <poolie> i just asked because there seemed to be some worry on the bug
[02:11] <poolie> but i think it's spurious
[02:11] <spiv> Except perhaps that it leaves the version of configobj in the tree vs. upstream a bit hard to describe?
[02:11] <poolie> perhaps we should delete it for 2.4
[02:12] <poolie> there was a mail thread
[02:12] <poolie> i think it's only needed on hardy?
[02:12] <poolie> anyhow, not urgent today
[02:12] <spiv> It'd be nice; we do currently have startup speed improvements in our copy that upstream probably doesn't have.
[02:13] <spiv> 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] <poolie> mm i see
[06:58] <vila> hi all
[12:35] <vila> let's try again: HI ALL
[12:35] <vila> . o O (Resounding silence...)
[12:36] <beuno> OH HAI vila!
[12:36] <Tak> bonjour!
[12:36] <vila> :-D
[12:43] <vila> bialix: ping, yeah, I know, you're not there, but may be you grep the logs ;)
[13:08] <maxb> 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] <vila> HUH ? no PP ? wtf ? poolie updated it and I see no trace of further updates... :(
[13:11] <vila> *blink*
[13:12] <vila> maxb: this is fix looks and feels correct, yet... I should miss something. Why did it fail ?
[13:12] <jelmer> it also looks good here, but my CVS foo is weak.
[13:12] <maxb> Because of paths containing /./ which were not expected
[13:12] <vila> Haaaa
[13:12] <maxb> I don't think the test can ever have been run successfully
[13:13] <vila> maxb: approved
[13:13] <maxb> 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] <jelmer> maxb: did r64 break the testsuite?
[13:17] <maxb> oh
[13:17] <maxb> yes it probably did
[13:17] <maxb> hmm
[13:18] <maxb> Perhaps this deserves further examination then
[14:29] <jml> fwiw, the _LockWarner error I talked about the other day isn't going away of its own accord.
[14:29] <jml> I've had it come up in numerous other test runs.
[14:35] <nordin> 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] <beuno> hiya nordin
[14:38] <nordin> 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] <nordin> hello beuno :)
[14:39] <nordin> the changes can only be shown, if I add a file using the bazaar tool.
[14:39] <rubbs> 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] <nordin> Yes I refreshed it too, forgot to mention that.
[14:40] <rubbs> 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] <rubbs> or are you saying it won't even recognize new files?
[14:41] <nordin> 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] <nordin> Same result.
[14:41] <nordin> rubbs: no it won't recognise.
[14:42] <nordin> Maybe you can provide me a good link?
[14:43] <nordin> I used bazaar's documents for windows system based tutorials, but that's where I ended up now.
[14:44] <rubbs> 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] <Peng> /1/1
[14:44] <Peng> erk, sorry
[14:45] <nordin> rubbs: no problem, I do see red marked text saying I haven't defined parent location yet...
[17:58] <vila> new p-i running on package-import.local \o/
[17:59] <fullermd> bzr seems to get confused sometimes with its relative paths   :|
[18:00] <vila> fullermd: it depends...
[18:00] <vila> . o O (You just asked for that one ;)
[18:01] <mgz> there are some interesting bugs filed recently.
[18:06] <fullermd> Well, lots of things depend, but I think 'crashing' qualifies as confusion   :p
[18:24] <mgz> bug 720853 is particularly fun.
[21:34] <montywi> hi!
[21:35] <montywi> 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] <montywi> I got the same error in two different source trees (sharing a common .bzr directory)
[21:37] <poolie> hi montywi
[21:37] <montywi> poolie: hi!
[21:37]  * mneptok hugs poolie 
[21:37] <montywi> Any clue of what to do?
[21:37] <poolie> uh, i guess look for more information about the error in .bzr.log
[21:37] <poolie> with just that it's hard to tell what it means
[21:37] <montywi> I have a really big merge just done and would hate to have to do it again....
[21:37] <montywi> .bzr.log has nothing about this
[21:38] <mneptok> montywi: hopefully that disk issue is not to blame in any way.
[21:38] <montywi> it says 'All changes applied successfully"
[21:38] <montywi> this happend before disk crashed
[21:38] <mneptok> ah, OK
[21:38] <maxb> 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] <poolie> hm, perhaps then try the commit from the command line? see if it can be reproduced?
[21:38] <montywi> The only clue I have is that the above is an old modified file, but in another branch
[21:38] <poolie> do you know what version of bzr you're using?
[21:39] <montywi> 2.1.0
[21:39] <montywi> if I do 'bzr update' and then bzr gcommit, I get the message 'nothing to commit'
[21:41] <montywi> Testing by modifing one file and doing bzr commit
[21:42] <montywi> when testing by doing a small modification, it worked
[21:43] <montywi> how to test if the tree is correct?  is bzr check enough?
[21:45] <poolie> yes
[21:45] <poolie> checking you can make another checkout of it would be a way to get external validation
[21:46] <montywi> ok, will try
[21:48] <montywi> i was able to do a bzr pull from another machine for the library
[21:49] <montywi> now doing bzr check
[21:53] <montywi> which of course takes a VERY long time
[21:54] <poolie> it could be tuned, or usefully check just the tree
[21:58] <montywi> still working
[22:01] <montywi> checking commit contents:inventories 0/2
[22:01] <montywi> this has not changed for the last 10 min
[22:05] <montywi> there is a \ before the checking commit contents
[22:05] <montywi> is this supposed to 'rotate' to show that something is happening?
[22:05] <montywi> it's not changing, which is confusing as it's impossible to see bzr check is doing anything...
[22:10] <poolie> it is supposed to spin
[22:10] <poolie> i would try an strace on it
[22:10] <poolie> 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] <montywi> i did manage to do a branch from it
[22:11] <montywi> strace shows a lot of seek_set calls
[22:12] <fullermd> FWIW, my experience with significant check's is that the spinner is stalled _way_ more often than not.
[22:12] <montywi> but it's hard to say if this is in a loop or not
[22:13] <montywi> this is happening millions of times:
[22:13] <montywi> open("/home/my/.bzr/repository/packs/95bf270064open("/home/my/.bzr/repository/packs/95bf270064246246a06e2f3d9639ceb5.pack", O_RDONLY) = 26
[22:13] <montywi> fstat(26, {st_mode=S_IFREG|0664, st_size=144334478, ...}) = 0
[22:13] <montywi> fstat(26, {st_mode=S_IFREG|0664, st_size=144334478, ...}) = 0
[22:13] <montywi> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffe228c2000
[22:13] <montywi> lseek(26, 0, SEEK_SET)                  = 0
[22:13] <montywi> read(26, "Bazaar pack format 1 (introduced"..., 4096) = 4096
[22:14] <montywi> lseek(26, 52871168, SEEK_SET)           = 52871168
[22:14] <montywi> read(26, "\325\214H\"!\r(\243e}\252\273(\10\205\340\223\321f<j\316\271\243\1\"\3246246a06e2f3d9639ceb5.pack", O_RDONLY) = 26
[22:14] <montywi> fstat(26, {st_mode=S_IFREG|0664, st_size=144334478, ...}) = 0
[22:14] <montywi> fstat(26, {st_mode=S_IFREG|0664, st_size=144334478, ...}) = 0
[22:14] <montywi> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffe228c2000
[22:14] <montywi> lseek(26, 0, SEEK_SET)                  = 0
[22:14] <montywi> read(26, "Bazaar pack format 1 (introduced"..., 4096) = 4096
[22:14] <montywi> lseek(26, 52871168, SEEK_SET)           = 52871168
[22:14] <montywi> read(26, "\325\214H\"!\r(\243e}\252\273(\10\205\340\223\321f<j\316\271\243\1\"\3
[22:14] <montywi> sorry, a bit more than I intended....
[22:14] <montywi> still it does the above over and over again, with slightly different addresses
[22:14] <poolie> ok, so i think it is actually checking history
[22:14] <montywi> still, adding a simple cache for the above should speed up things 100x
[22:20] <montywi> poolie: I am just worried that I got the error message twice (in different directories) when doing merges
[22:29] <montywi> looks like it takes 'forever'
[22:29] <montywi> I will go to sleep and see what it says in the morning...
[23:09] <mtaylor> is there a ui for getting at revision properties yet?
[23:15] <soren> mtaylor: Sure!
[23:16] <soren> mtaylor: "bzr cat-revision"
[23:17] <jelmer> 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] <poolie> hi jelmer
[23:26] <jelmer> 'morning poolie