[00:01] <poolie> hello
[00:01] <poolie> spiv, jam, good morning
[00:02] <spiv> morning
[00:03] <lifeless> hi poolie
[00:03] <poolie> hello beuno, lifeless
[00:04] <lifeless> https://bugs.edge.launchpad.net/bzr/+bug/256409
[00:04] <lifeless> I'm working on this
[00:04] <lifeless> I think its quite serious, I'm trying to understand it enough to create a test and figure out if its just 1.3.1 or if 1.6 is affected too
[00:05] <rocky> so did jelmer ever wake up today? :)
[00:06] <beuno> I haven't seen him
[00:06] <lifeless> jelmer won't be around for a bit
[00:06] <beuno> I've been expecting a
[00:06] <beuno> "w00t, bzr-upload and bzr-search are in Debian", but nothing
[00:06] <beuno> lifeless, is he OK?
[00:06] <lifeless> beuno: yup all good
[00:07] <jam> hey poolie, where's the call?
[00:09] <poolie> hi
[00:09] <poolie> i was waiting for you here
[00:10] <jam> ah, sorry
[00:10] <jam> I saw the hello
[00:10] <poolie> np
[00:10] <jam> you usually just call without response :)
[00:44] <lifeless> jam: youhave a reply - and thanks for reading my essay :/
[00:48] <spiv> jam: I admired your ascii art.
[00:51] <mwhudson> hardly ascii
[00:51] <spiv> Well, yeah.
[00:53] <lifeless> back shortly
[01:29] <mwhudson> hm
[01:29] <mwhudson> are 'location aliases' documented anywhere?
[01:30] <lifeless> are what now?
[01:32] <mwhudson> things like :this
[01:32] <mwhudson> (which turned out to be the one i wanted)
[02:14] <abentley> mwhudson: no.  I should do that.
[02:15] <abentley> lifeless: I thought bug 256409 was a solved problem!  What's up with it?
[02:15] <jjesse> good evening i'm having problems chceking out the ubuntu-docs branch from #lp and getting this error: http://pastebin.ubuntu.com/36701 in regards to a KnitPackRepository error
[02:15] <lifeless> abentley: I'm trying to reproduce at the moment
[02:15] <lifeless> abentley: I'm leaning towards 'what I found and fixed has just been causing trouble for people'
[02:15] <lifeless> abentley: but until I can trigger it with test code in 1.3.1, I can't check it against 1.6/1.7 either
[02:16] <lifeless> abentley: its pretty scary regardless of whether its now-fixed or not, because 1.3.1 is widely spread
[02:16] <lifeless> abentley: if you want to poke at it too that would be great
[02:16] <abentley> lifeless: Oh, I had this confused with something else.
[02:17] <abentley> lifeless: You remember we had a problem where file kinds weren't being properly updated by TreeTransform.apply()?
[02:18] <lifeless> vaguely
[02:18] <lifeless> this seems to be a cluster of problems - my note about what we need to do itemises them
[02:47] <emmajane> beuno: thanks :)
[02:48] <beuno> emmajane, :)
[02:48] <emmajane> beuno: is it not possible to have something on the launchpad page to that effect?
[02:49] <beuno> emmajane, the explanation itself?
[02:49] <emmajane> I mean, I'm all about increasing karma points by asking easily answered questions, but... ;)
[02:49] <emmajane> yeah
[02:49] <beuno> hahah
[02:49] <beuno> I agree. I haven't done so because vila should be back from his vacation any day now, and we should be able to wrap it up and release a tarball
[02:49] <emmajane> that'd be fantastic.
[02:50] <emmajane> I know it's going to be discussed at a BoF at the DrupalCon in two weeks.
[02:50] <beuno> so, that and a .deb will supersede the bzr co...
[02:50] <beuno> bzr-upload?
[02:50] <emmajane> bzr generally.
[02:50] <beuno> ah, how cool!
[02:50] <beuno> please get us some feedback on whatever comes out of that
[02:50] <emmajane> absolutely!
[02:50] <emmajane> I'm just looking for the session description.
[02:51] <emmajane> http://szeged2008.drupalcon.org/program/sessions/bzr-bazaar-source-revision-control-system
[02:52] <emmajane> The workflows page in the documentation is excellent, btw. Not sure who wrote it but my full compliments go to them.
[02:53] <beuno> emmajane, that would be Ian Clatworthy, which I don't see around at the moment
[02:53] <beuno> he's done most of the docs
[02:53] <emmajane> The Five Minute intro had a few leaps of logic that I wasn't able to make (I only know CVS and SVN...and basic skills at that)
[02:53] <beuno> emmajane, like?
[02:54] <emmajane> This will expose my naivety. ;)
[02:54] <jam> poolie: see my email on the list, the log performance slowdown is because of the VersionedFiles changes and how it changes how we get at the per-file graph.
[02:54] <beuno> good, that we wat we can learn
[02:54] <jam> I proposed a "possible" fix.
[02:54] <poolie> jam, i just saw it
[02:54] <poolie> thankyou!
[02:54] <jam> Though it probably needs some discussion with lifeless
[02:54] <emmajane> beuno: the --push felt like it was the equivalent (mirror) of a checkout but in the opposite direction. This is not the case at all.
[02:55]  * beuno looks
[02:55] <emmajane> an extra sentence which read, "This will upload only the .bzr directory." would have helped me immensely.
[02:56] <emmajane> I think of a branch as being a set of files that I download to work on in CVS.
[02:56] <emmajane> which is an incorrect interpretation of that word, if I've correctly understood the first little bitof the full intro.
[02:57] <beuno> emmajane, is this the part you are reffering to?  http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html#publishing-your-branch-with-sftp
[02:57] <poolie> hello emmajane
[02:57] <emmajane> beuno: that's the part, yes.
[02:58]  * emmajane waves at poolie
[02:58] <beuno> emmajane, I see, it would make sense to explain that it only uploads the repository
[02:59] <beuno> as a side note, if you push locally, you actually do push the full working tree (the actual files) as well
[02:59] <emmajane> but not if you're going over the 'net?
[03:00] <beuno> emmajane, not if it's something remote  (sftp/ftp/ssh)
[03:00]  * emmajane nods
[03:00] <emmajane> I think the five minute intro would also benefit from having a link to the workflow page. It seems as though the setups are different depending on what you want to set up (go figure).
[03:00] <beuno> emmajane, are you subscribed to our mailing list?
[03:01] <emmajane> not at this point.
[03:01] <beuno> if you'd like to (it's fairly high traffic though), and maybe send in your views so we can discuss them, I can put together a patch to fix it
[03:02] <beuno> I can fix it anyway, it would just be more interesting if you could put it all together, and we can ping-pong with everyone else to see what else we can improve
[03:02] <emmajane> I'd be happy to once I've actually figured out where I think the documentation is unclear. :) Sometimes it's just my fault that I'm skimming. :)
[03:02] <emmajane> I'm keeping notes on what I'm doing to set up my environment though.
[03:02] <beuno> emmajane, that information is still intersting, because we can change things so they get cought while skimming too  :)
[03:03] <emmajane> heh
[03:07] <poolie> emmajane, yes if you send a mail with it all in one place that would be good
[03:09]  * emmajane nods. I'm keeping very careful notes at this piont, but I thought it would be better to get things running the way I want and then go back and evaluate my notes and the original documentation to see what would have really helped.
[03:26] <markh> I'm getting a strange error when trying to branch from an smb mounted share with bzr.dev: "ERROR: Transport error: [Errno 12] Cannot allocate memory.../filename.rix".  Is that a known problem?
[03:27] <lifeless> markh: no
[03:29] <abentley> beuno: Actually, I wrote the workflows page, and Ian polished it.
[03:29] <markh> its a little strange - a branch seemed to fail, but a checkout worked.  Then I did "bzr up" on the checkout, annd it said it applied all (1) changes, *then* gave the error.
[03:29] <markh> I'll look in the log once the test suite finishes
[03:29] <lifeless> markh: we have another bug open with SMB shares
[03:29]  * markh decided he should try to test his patches on Linux ;)
[03:30] <beuno> abentley, my apologies then. emmajane ^
[03:30] <abentley> And I forget who did the images.
[03:30] <emmajane> abentley: The workflows page is /fantastic/
[03:30] <abentley> emmajane: Glad you like.
[03:32] <lifeless> markh: bug 255656
[03:33] <lifeless> markh: my guess is there is a commonality of some sort
[03:33] <lifeless> (beyond 'windows sucks')
[03:34] <markh> :)
[03:40] <lifeless> markh: if you could look into that it would be really good
[03:56] <Verterok> mornin' all
[03:57] <beuno> evening Verterok
[03:59] <Verterok> Hi beuno, g'evening
[04:04]  * beuno is off to bed
[04:33] <markh> lifeless:   File "/home/skip/src/bazaar/bzr.dev/bzrlib/osutils.py", line 598, in sha_file_by_name
[04:33] <markh>     f = os.open(fname, os.O_RDONLY | O_BINARY)
[04:33] <markh> OSError: [Errno 12] Cannot allocate memory: '/home/skip/o/src/bazaar/bzr.work.tests.blackbox//bzrlib/bugtracker.py'
[04:34] <markh> but immediately after that, Python can do a normal open(fname, "rb") on that file
[04:34] <markh> maybe samba's just running out of file handles.
[04:36] <lifeless> interesting
[04:36] <lifeless> try a gc.collect() before that call ?
[04:36] <markh> ok
[04:39] <markh> seems to work!  removing it again to make sure
[04:39] <lifeless> so
[04:39] <lifeless> I speculate its a HANDLE leak
[04:39] <lifeless> we do a lot of readvs
[04:39] <markh> probably the same one causing test suite failures all over windows :)
[04:40] <markh> both LockContentions and warning messages about loads of test dirs being left behind
[04:40] <markh> I can't make it fail again.  Did bzr pack the remote branch?
[04:41] <markh> it failed when it said "Finishing Pack" on the progress bar.  Now it completes every time
[04:44] <lifeless> hi jonnyde1
[04:55] <jonnyde1> hi lifeless :)
[04:55] <jonnyde1> just got an email about your new bug comment message
[04:56] <jonnyde1> I will try your suggestions when I'm back at work, today...
[04:58] <jonnyde1> need to have my breakfast now and then go to work... best regards and many thanks for your help :)
[05:03] <lifeless> bug 256409
[05:33] <gour> morning
[05:35] <gour> i'm advocating usage of LP to GNUmed project...how is it possible to report bugs via email? does one configures separate email-list (i did something similar with roundup) or something else?
[05:35] <lifeless> https://help.launchpad.net/BugTrackerEmailInterface
[05:36] <gour> thanks a lot
[05:43] <mwhudson> i'd like to be able to stick stuff on the end of location aliases
[05:44] <mwhudson> bzr push :parent/../other
[05:48] <poolie> mwhudson, that would be good
[05:49] <mwhudson> i guess it's even not that hard
[05:49] <mwhudson> just a bit more code in AliasDirectory.look_up
[06:10] <poolie> lifeless, i have a clue
[06:10] <lifeless> yay!
[06:10] <lifeless> alexander graham bells invention time?
[06:15] <lifeless> poolie: whats your clue?
[06:15] <poolie> see mail
[06:15] <poolie> (phone)
[07:16] <gour> today is bazaar-1.6 release day?
[07:33] <thumper> gour: I don't think so
[07:33] <thumper> poolie: do you have a release day for 1.6 specified?
[07:35] <jamesh> running "bzr upgrade" on a dirstate-tags branch prints a deprecation warning telling you that the branch is in ann old format and that you should run "bzr upgrade" ...
[07:35] <jamesh> (that's with 1.6rc1)
[07:36] <gour> hmm, someone told me the other day that something is gonna to be released today...
[07:38] <markh> hrm - merge.py's do_merge takes 3 locks, then sets up a finally to release them all.  Shouldn't there be a finally per lock?
[07:40] <spiv> jamesh: yeah, it's a known bug that "bzr upgrade" does that (it's not specific to this particular format transition).
[07:41] <spiv> markh: probably that would be more correct, although the risk of the two unlocks for the lock_reads failing is pretty slim.
[07:41] <markh> I'm thinking the test suite as much as anything...
[07:42] <lifeless> markh: so, gc.collect() worked ?
[07:42] <markh> lifeless: yeah, I replied.  After that though I can't repro it by taking it out.  Is that because bzr would have packed the remote branch?
[07:42] <lifeless> markh: packing occurs on write operations only
[07:43] <lifeless> markh: you can check your bzr.log to see if a pack occured
[07:43] <markh> and gc.collect() fixes failure to remove test directories in some cases, so I'm wondering if cases like that do_merge might be responsible...
[07:46] <lifeless> so, we do have a high volume of file operations
[07:46] <lifeless> is there some way to tell python to suck less?
[07:47] <markh> so now I can't repro it again :(
[07:48] <robsta> hi lifeless, sorry, i don't remember what exactly i did back then :/
[07:48] <lifeless> robsta: ah hi
[07:49] <lifeless> robsta: so, the branch is a bit of a mess, I've spent all day trying to figure out WTF happened
[07:49] <lifeless> I'm probably your number #1 spammer in your INBOX as a result :)
[07:49] <robsta> lifeless: "bzr mv" i did , that's for sure
[07:49] <lifeless> what was revno6 about by the way
[07:50] <lifeless> you said 'repaired' ...
[07:52] <robsta> lifeless: i did something that broke my local repo, therefore cloned again and copied over changes
[07:52] <lifeless> when you say broke
[07:52] <lifeless> what do you mean
[07:52] <robsta> oh, a stale lock
[07:52] <lifeless> oh
[07:52] <lifeless> ok
[07:52] <lifeless> 'bzr break-lock'
[07:53] <robsta> oh (:
[07:53] <lifeless> we avoid os-locks for our core data - the don't work well on e.g. FTP :)
[07:56] <robsta> lifeless: so can i do anything apart from starting over in a new repo?
[07:56] <lifeless> because we don't use os-locks, its possible to get stale locks, and thats what happend; probably you had some external event, or possibly triggered some actual assertion
[07:56] <lifeless> robsta: I've written several test cases to try and reproduce and I have failed to date
[07:57] <lifeless> robsta: can you attach your ~/.bzr.log* to the bug report
[07:59] <robsta> done
[08:00] <lifeless> thanks, looking
[08:03] <lifeless> I'm going to study this
[08:04] <lifeless> until I can reproduce it its pretty hard to say how-long the piece of string is
[08:04] <lifeless> I think yes, copy the whole tree, rm -rf .bzr, init and start over :(
[08:04] <lifeless> I'm not happy about this advice
[08:05] <robsta> can i do something to fix the repo on gnome's bzr-playground too, or would that need manual intervention?
[08:05] <lifeless> that will probably be fine if you do push --overwrite
[08:06] <lifeless> it will have cruft that can be garbage collected but unreferenced data is not fetched
[08:06] <lifeless> or propogated
[08:06] <robsta> oh, good
[08:07] <lifeless> ok, interestingly you used mkdir cbd
[08:07] <lifeless> I'm going to use this log to try to reproduce again
[08:08] <robsta> possibly i used "bzr mv" with wildcards a few times
[08:13] <Peng_> Could someone do me a small favor and "bzr upgrade lp:~bzr/bzr-push-and-update/trunk"? It's still using knits.
[08:16] <lifeless> beuno: ^
[08:21] <jml> Peng_: done.
[08:22] <Peng_> jml: Thanks. :)
[08:38] <ronny> is there a simple howto for using bzr's api to controll workdirs?
[08:38] <lifeless> theres some stuff on the wiki
[08:38] <ronny> (i need to rewrite pidas bzr integration, currently its a ugly hack with subprocess))
[08:39] <lifeless> robsta: good, news I seem to have reproduction
[08:40] <robsta> lifeless: it's easing my pain a bit to know the suffering was not in vein :P
[08:40] <poolie> lifeless, yay
[08:40] <lifeless> robsta: I have duplicated the failure at revision 11
[08:41] <lifeless> robsta: I suspect the others will be dups, reflecting how you used the tool
[08:42] <robsta> lifeless: oh, what's triggering it?
[08:42] <lifeless> robsta: I am reducing the size of test at the moment
[08:42] <lifeless> robsta: still a lot of variables
[08:56] <lifeless> damn
[08:56] <lifeless> missed a change in my test, still can't reproduce
[08:57]  * lifeless tries real-old-fashioned reproduction
[08:58] <RAOF> That's a wonderful out-of-context quote :)
[09:04] <lifeless> RAOF: heh
[09:04] <lifeless> robsta: have you been using the same bzr version the whole time ?
[09:05] <robsta> lifeless: think so, unless ubuntu changed it
[09:05] <robsta> that is, no dist upgrade
[09:05] <markh> I'm tracking down LockContention on Windows and I don't understand how it is supposed to work.  I've instrumented 'do_merge' and can prove that in some cases, self.this_tree._dirstate._filename == self.base_tree._dirstate._filename
[09:06] <lifeless> markh: things like revert could do that
[09:06] <markh> then that method takes a WriteLock on the lhs, and attempts a ReadLock on the rhs - the readlock fails - which seems to be correct.  But it works on Linux (and the paths compare true there too)
[09:07] <lifeless> markh: yes, oslocks are different on windows and linux
[09:07] <markh> heh - no wonder then :)  Is that by design?
[09:08] <markh> ie, what do we do about the test failures?
[09:08] <poolie> markh, it's the documented behaviour of locks
[09:08] <lifeless> no; see my mail to the list about a simple change to reduce the issues here
[09:08] <poolie> i would say we made a poor choice (in hindsight) to use them
[09:08] <markh> so we just skip those tests on Windows?
[09:09] <poolie> (on phone to lifeless)
[09:09] <poolie> i think there is a 'known failure' for the fact that they're not exclusive on linux
[09:10] <poolie> i _think_ the general approach is meant to be that we should detect that they're the same object and handle that at a higher level
[09:11] <poolie> i don't have your context here
[09:13] <markh> many tests on Windows are failing with a LockContention error - as the locks are exclusive on Windows.
[09:14] <markh> so if Linux had exclusive locks, I guess all those tests would fail there too?
[09:15] <markh> best I can tell, do_merge, in some cases at least, is taking a read and write lock on the same dirstate (and failing to take the read lock)
[09:16] <markh> I hit 54 such cases
[09:16] <markh> s/I/the test suite/
[09:20] <markh> heh - which is more than 1/2 the total remaining errors ;)
[09:30] <Stumbles> hi, I'm just starting to develop using Bazzar. I've been merging back and forwards between two branches. If I merge again I've just merged and committed when there's nothing to be done, it seems to create a "pending merge" in the destination. Am I doing something wrong?
[09:32] <alex_muntada> i commited and pushed a change that contains a bad log entry; is there way to fix the log for that revision? should i uncommit my last revision and push it again? i've search in bazaar-vcs.org docs with no luck, so i'd appreciate some help or advise, whatever you like
[09:32] <lifeless> Stumbles: no, its normal behaviour (though not very useful)
[09:32] <lifeless> Stumbles: I plan to enahnce the 'nothing to do' check to catch that as well
[09:32] <lifeless> alex_muntada: if you really care about it, uncommit and commit and push --overwrite
[09:32] <Stumbles> lifeless: so I should just `bzr revert` to back out of that?
[09:33] <lifeless> Stumbles: yup
[09:33] <markh> will he need to --forget-pending-merges too?
[09:34] <alex_muntada> lifeless: it's not a typo and it could be misinterpreted, so thanks for the tip :-)
[09:34] <lifeless> markh: no
[09:36] <lifeless> robsta: so
[09:36]  * robsta perks up
[09:36] <lifeless> robsta: I suspect something is going on that is outside the variables I can meaningfully choose to examine here
[09:36] <lifeless> robsta: I'd like to ask you to do a few things for me, if I may
[09:37] <Stumbles> lifeless: cheers
[09:37] <lifeless> Stumbles: happy to help
[09:37] <lifeless> robsta: you're using a deb package right?
[09:37] <lifeless> robsta: can you do dpkg -l bzr?
[09:38] <robsta> lifeless: yes and dpkg -l bzr
[09:38] <robsta> Desired=Unknown/Install/Remove/Purge/Hold
[09:38] <robsta> | Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend
[09:38] <robsta> |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
[09:38] <robsta> ||/ Name                      Version                   Description
[09:38] <robsta> +++-[09:38] <robsta> ii  bzr                       1.3.1-1ubuntu0.1          easy to use distributed version control system
[09:38] <lifeless> ok cool
[09:39] <lifeless> I did grab that packages source and test with it myself to no avail
[09:39] <lifeless> robsta: are you using NFS or anything other than a local filesystem (for the branch that glitched)
[09:39] <robsta> no
[09:39] <lifeless> have any other branches done this sort of thing to you ?
[09:40] <robsta> no, this is my only bzr project ATM
[09:40] <lifeless> ok
[09:41] <lifeless> can you, in a terminal somewhere, run 'bzr selftest --noplugins'
[09:41] <robsta> bzr: ERROR: no such option: --noplugins
[09:41] <lifeless> --no-plugins
[09:41] <lifeless> this will take a bit of time
[09:42] <lifeless> but if it fails in an unexpected manner it may help explain things
[09:42] <lifeless> also, I'd like you to take a copy of the corrupt branch
[09:42] <lifeless> and in that copy:
[09:42] <lifeless> rm -rf .bzr/checkout
[09:43] <lifeless> bzr branch -r 10 . ../FOO
[09:43] <lifeless> cd ../FOO
[09:44] <lifeless> bzr mkdir cbd
[09:44] <lifeless> bzr mv ../src/css-border.c ../src/css-border.h .
[09:44] <lifeless> (oh, cd cbd first :)
[09:44] <lifeless> bzr mv ../src/css-color.h .
[09:44] <lifeless> bzr mv ../src/css-gtk.c ../src/css-gtk.h .
[09:44] <lifeless> bzr mv ../src/css.h .
[09:44] <lifeless> bzr commit -m "test commands"
[09:45] <lifeless> bzr check
[09:45] <lifeless> (and post the output)
[09:45] <robsta> "bzr mv ../src/css-border.c ../src/css-border.h ." fails, the paths are wrong
[09:45] <lifeless> yeah cd to cbd first
[09:45] <lifeless> I forgot to mention that cause its not in .bzr.log ;)
[09:46] <robsta> lifeless: sorry, you even wrote it above
[09:46] <robsta> didn't read that far
[09:46] <lifeless> thats ok :)
[09:47] <robsta> here goes
[09:47] <robsta> bzr check
[09:47] <robsta> checked branch file:///home/rstaudinger/Desktop/Devel/FOO/ format Bazaar Branch Format 6 (bzr 0.15)
[09:47] <robsta> checked repository <bzrlib.transport.local.LocalTransport url=file:///home/rstaudinger/Desktop/Devel/FOO/> format <RepositoryFormatKnitPack1>
[09:47] <robsta>     11 revisions
[09:47] <robsta>     32 file-ids
[09:47] <robsta>     64 unique file texts
[09:47] <robsta>    179 repeated file texts
[09:47] <robsta>      0 unreferenced text versions
[09:49] <lifeless> one final check
[09:49] <lifeless> cd ..
[09:49] <lifeless> bzr branch -r 10 FOO BAR
[09:49] <lifeless> cd BAR
[09:49] <lifeless> bzr pull ../FOO
[09:50] <robsta> from "FOO/cbd" i need to "cd .." twice, right ?
[09:50] <robsta> just trying to make sure everything is exactly right
[09:50] <lifeless> ah yeah
[09:51] <robsta> "All changes applied successfully.
[09:51] <robsta> Now on revision 11.
[09:51] <robsta> "
[09:51] <robsta> the self test is thru too
[09:52] <robsta> Ran 10755 tests in 511.042s
[09:52] <robsta> OK (known_failures=9)
[09:52] <robsta> 663 tests skipped
[09:52] <robsta> Missing feature 'FTPServer' skipped 76 tests.
[09:52] <robsta> Missing feature 'Internally performed glob expansion' skipped 5 tests.
[09:52] <robsta> Missing feature '_winreg' skipped 2 tests.
[09:52] <robsta> Missing feature 'case-insensitive filesystem' skipped 2 tests.
[09:52] <robsta> tests passed
[09:52] <lifeless> ok
[09:52] <lifeless> the good news, is that doing what you appear to have done previously, has worked
[09:52] <lifeless> and there isn't anything obviously wrong system wide
[09:53] <lifeless> what plugins do you have installed (bzr plugins)
[09:53] <robsta> bzr plugins
[09:53] <robsta> launchpad
[09:53] <robsta>     Launchpad.net integration plugin for Bazaar.
[09:53] <robsta> svn 0.4.9
[09:53] <robsta>     Support for Subversion branches
[09:53] <lifeless> yeah, fine
[09:55] <lifeless> so the bad news then is that if this is representative of your system, bzr behaved correctly previously, so something must have caused the confusion subsequently
[09:55] <lifeless> now you said you'd had a locking problem
[09:55] <lifeless> has that happened more than once?
[09:57] <robsta> no, and it was my fault, closed the terminal while bzr was prompting for commit msg
[09:57] <lifeless> heh
[09:57] <robsta> that works in svn
[09:57]  * robsta ducks
[09:57] <lifeless> mmm, wonder what signal bzr got, perhaps it could handle it better
[09:57] <lifeless> feel free to file a bug
[09:59] <robsta> not that important
[09:59] <awilkins> Use vim, it ignored ctrl-c
[09:59] <awilkins> It chastises you and makes you use :q!
[10:01] <lifeless> awilkins: closing the terminal is a little harsher
[10:01] <lifeless> robsta: still, be a nice bit of polish
[10:01] <lifeless> robsta: I'll file it
[10:01] <lifeless> done
[10:01] <robsta> awilkins: $EDITOR ignores it too, nano or whatever is default
[10:02] <lifeless> now, the icing on the cake
[10:02] <lifeless> is that there is only one missing key
[10:02] <lifeless> the one for the new directory
[10:09] <robsta> lifeless: out of interest, have you ever regretted writing bzr in python?
[10:09] <robsta> for lack of compiler checks and whatnot
[10:10] <lifeless> nope
[10:10] <lifeless> compiler checks catch such a small number of genuine bugs
[10:11] <lifeless> by which I mean code that would be syntactically correct, pass selftests but a compiler can tell you about
[10:11] <awilkins> Hmm ; I find checked languages to be easier going in a good IDE
[10:12] <awilkins> If nothing else the IDE usually helps you out more
[10:12] <robsta> lifeless: yeah, that was my next question; figured it might be an advantage being forced to write tests for just about everything
[10:13] <awilkins> When I'm hacking bzr I am often stymied by what "interface" a given class is supposed to support (and where in the hierarchy it gets it from)
[10:13] <awilkins> Hunting around in text files is the usualy result
[10:13] <lifeless> awilkins: static analysis is reall quite orthogonal
[10:13] <lifeless> awilkins: consider erlang for instance
[10:13] <lifeless> or ocaml
[10:14] <awilkins> I'm too tired to think right now ; was up all night installing Windows (a thousand curses to Dell for fiddly BIOSes that only boot USB with legacy support on)
[10:15] <awilkins> And another thousand curses to IT beurocracies that insist on Windows-only full-disk encryption tools
[10:15] <lifeless> awilkins: heh, ouch
[10:15] <awilkins> And a small curse to my wife for giving in to them
[10:15] <lifeless> awilkins: just install windows in a linux VM :)
[10:15] <awilkins> I was all prepared to reinstall Ubuntu on dm-crypt partitions for her
[10:16] <lifeless> robsta: I'll look at possible corruptors tomorrow
[10:16] <awilkins> I could have left that running and gone to bed
[10:16] <lifeless> robsta: I did find *one* code path that could cause it, but it doesn't look like it could possibly have been involved with the parameters you used
[10:17] <robsta> lifeless: well, thanks for the awesome support
[10:17] <kiorky> uhm, i have a merge problem, i try to recouncile two divergeant branches
[10:17] <kiorky> it tells me that i must precise a reivsion base, so i tell it which reivisions to apply
[10:18] <lifeless> robsta: and I've sent a patch up for that which will be in trunk tomorrow
[10:18] <kiorky> the merge occurs succesfully
[10:18] <kiorky> then i try to push, but then, it tells me again that the branches diverge
[10:18] <lifeless> robsta: this is the first seriously borked repository we've ever had that wasn't quite obviously a NFS FAIL or memory bit-errors or the like
[10:18] <lifeless> robsta: so I'm taking it very seriously
[10:23] <kiorky> No one for an idea ? :)
[10:24] <lifeless> kiorky: are you sure they are diverged and not just completely unrelated?
[10:24] <kiorky> lifeless: they are unreleated
[10:25] <kiorky> lifeless: why i thought why something like that : i merge from the other branches, what is different
[10:25] <kiorky> then i pushed back the changes
[10:25] <kiorky> lifeless: thing is that i update my bzr-svn repo, more nicely, and i try to merge back a locally branched thign.
[10:25] <kiorky> (that was done before i updated my "svn" branch"
[10:26] <kiorky> lifeless: What i have suceed to do is to get the svn changes in the local branch. What is left is to push back things to the svn branch
[10:26] <kiorky> lifeless: Am i clear ? :)
[10:27] <lifeless> kiorky: I have no idea what you're talking about :) - I think my brain has melted, its been a long day
[10:27] <kiorky> lifeless: hang on, i ll make a draw :p
[10:27] <lifeless> spiv: are you around perchance?
[10:30] <kiorky> lifeless: http://www.friendpaste.com/MH3aG9k2
[10:30] <kiorky> lifeless: is that more clear for you ?
[10:31] <lifeless> kiorky: after you merge, you need to do a commit
[10:31] <lifeless> because merge puts the result in a pending state
[10:31] <kiorky> lifeless: i forgot in the pastebin
[10:31] <kiorky> but its commited, of course
[10:32] <lifeless> if you have done merge oldsvn; commit; then push oldsvn should just work
[10:32] <kiorky> uhn, and stupid question, do you have a tip referrer like "head" or "tip" in bzr world ?
[10:32] <kiorky> lifeless: nope
[10:32] <lifeless> yes, -1 is the head of a branch
[10:33] <kiorky> lifeless: http://www.friendpaste.com/5h5axg9V
[10:33] <kiorky> lifeless: ok
[10:33] <lifeless> 73 does not look like a merge to me
[10:33] <lifeless> if it was a merge there would be merged revisions
[10:34] <lifeless> what does bzr missing oldsvn show?
[10:34] <lifeless> actually, I *have* to go
[10:34] <lifeless> hopefully someone else can give you a hand
[10:34] <kiorky> lifeless: just go :)
[10:34] <lifeless> sorry
[10:34] <kiorky> i hope, i just have to rumble the channel
[10:34] <kiorky> *rumble*
[10:35] <kiorky> lifeless: missing just make a lot of noise
[10:35] <kiorky> lifeless: i ll try to merge thez others, so.
[10:37] <strk> does any backup occur on 'bzr revert' ?
[10:38] <weigon> strk: nope, use $ bzr shelve if you need a backup
[10:39] <lifeless> strk: yes
[10:39] <lifeless> strk: bzr makes .name~X files
[10:39] <strk> great
[10:39] <lifeless> (just passing through again)
[10:39] <strk> they change on 'bzr switch' right ?
[10:39]  * lifeless is really gone
[11:41] <Peng_> beuno: With LH, does ?start_revid do anything useful on /annotate/ URLs? Particularly for Googlebot? (I don't think so, but I'm not sure.)
[11:45] <Peng_> beuno: What about on /revision/?
[11:45] <mwhudson> Peng_: on revision at least it makes a difference
[11:45] <Peng_> Oh, hi.
[11:46] <Peng_> ISTM it causes start_revid to be appended to most of the URLs, and changes the Previous/Next links.
[11:46] <mwhudson> dang, i blew my cover
[11:46] <mwhudson> Peng_: yeah, that's about right
[11:47] <mwhudson> Peng_: by default loggerhead views the mainline of the branch
[11:47] <Peng_> mwhudson: So...not useful?
[11:47] <Peng_> Oh?
[11:47] <mwhudson> if you give it a start_revid, instead of mainline it views what you get by starting at the start_revid and repeatedly taking the left-hand parent
[11:47] <mwhudson> (which will converge with mainline sooner or later)
[11:48] <mwhudson> i'm not at all convinced this makes sense as an organizing principle of navigation
[11:48] <mwhudson> but i haven't really thought up anything clearly better yet
[11:48] <Peng_> Well, does it lead to anything Googlebot would otherwise miss out on?
[11:48] <mwhudson> (i have thought up some stuff that would be mostly better)
[11:48] <mwhudson> er
[11:49] <mwhudson> probably not
[11:49]  * Peng_ feels very confident. :P
[11:50] <Peng_> I've managed to whittle down most of the useless pages Googlebot finds, and start_revid is the only thing left.
[11:51] <mwhudson> well
[11:51] <markh> can I convert a checkout to a branch?
[11:51] <mwhudson> Peng_: start_revid certainly doesn't affect the content of the page over much
[11:51] <Peng_> markh: bzr unbind
[11:51] <markh> Peng_: thanks!
[11:51] <Peng_> :)
[11:51] <mwhudson> Peng_: there might be pages that are only linked to with start_revid=<something> though
[11:52] <Peng_> I know start_revid is useful on some pages (/changes), but I think it's added to a lot where it isn't.
[11:52] <markh> hrm - "bzr: ERROR: Local branch is not bound" - its a light-weight branch - does that matter?
[11:52] <Peng_> (Well, by "useful" I mean "useful to Googlebot". It usually does change the page in some way.)
[11:53] <mwhudson> i'm not going to dispute that
[11:53] <mwhudson> markh: reconfigure can probably do it
[11:53] <Peng_> I'm just not sure which pages those are. :P
[11:54] <mwhudson> Peng_: ah right, it's added to non-/changes pages so that it can be preserved for links to /changes pages, is all
[11:54] <mwhudson> Peng_: this much i am actually fairly confident on
[11:55] <markh> mwhudson: it could indeed - thx
[11:56] <markh> I've ~ 95 commands staring me in the face with 'bzr help commands' :)
[11:56] <Peng_> Hmm.
[11:59] <Peng_> OK, it's definitely useless on /atom.
[12:02] <kiorky> jelmer: i tried to update bzr-svn this morning, and it seems broken for me
[12:03] <kiorky> jelmer: http://www.friendpaste.com/EYAgFfR4
[12:03] <kiorky> jelmer: http://foo is a svn repo.
[12:12] <kiorky> jelmer: syncing my bzr.dev helped, sorry for the noise.
[13:03]  * beuno opens one eye and gets coffee
[13:03] <Peng_> Good morning.
[13:04] <beuno> g'mornin Peng_
[13:04] <beuno> how are you today?
[13:04] <Peng_> Um, I'm fine. How are you?
[13:05] <beuno> I think I'm good too, but I should find more about that after the caffeine kicks in
[13:05] <Peng_> Heh.
[13:12] <awilkins> Here's one for you ; bzr rm <folder> complains about not wanting to delete files that you have already bzr mv'ed out of the folder
[13:13] <beuno> awilkins, makes sense in my pre-caffeinated state
[13:13] <beuno> maybe --force it?
[13:13] <awilkins> Hmm, this is part of a merge.
[13:13] <awilkins> I'm bzr mv-ing the files out of folder.moved to folder
[13:14] <awilkins> The complaint is from bzr rm folder.moved
[13:14] <beuno> are you suppose to bzr mv things in  .moved, or just plain mv them?
[13:15] <awilkins> I think you have to bzr mv them ; "folder" is the new folder, folder.moved is still a owefwef
[13:15] <awilkins> a part of the inventory
[13:16] <awilkins> It seems to think that by deleting folder.moved (which is now empty of files) the files I have renamed to "folder" will be deleted
[13:17] <awilkins> Which doesn't make sense to me
[13:19] <markh> woohoo - both "failures" and "errors" are under 100 on windows :)
[13:20]  * beuno cheers markh 
[13:20] <awilkins> (skipped is now sadly above 12,900 and rising.....)   :-P
[13:22] <awilkins> What fixed the liargest proportion of those errors?
[13:22] <markh> heh - skipped remains under 1000 :)
[13:22] <awilkins> And is there a fix for the evil "Can't delete temp folder" problem?
[13:22] <markh> closing file handles, changing out of the directory being removed, etc :)
[13:22] <markh> yeah - all of them are gone :)
[13:23] <markh> s/all/most/ ;)
[13:23] <awilkins> I can't help thinknig that test framework support for that would be nice
[13:23] <Keybuk> how do I remove part of a pending merge from my working tree?
[13:23] <markh> test framework has some support, but when a test explcitly makes a dir, then changes into it, then tries to remove it, there's not alot that can be done
[13:23] <Keybuk> the merge brought in two revisions, but I only want one
[13:24] <markh> most of the remaining errors are LockContention errors, which apparently is known
[13:25] <gimaker`> Keybuk: bzr revert, bzr merge -rX..X+1 /merged/branch ?
[13:25] <Keybuk> gimaker`: I've already resolved the conflicts for the bit I want, and don't want to lose that
[13:25] <gimaker`> ah
[13:26] <gimaker`> can't you use shelve to store the conflict resolution you done, then do what I said and unshelve the fix?
[13:26] <Keybuk> is there a way to "fake merge" ?
[13:26] <Keybuk> ie. just bring in the merge reference without the diff?
[13:27] <lifeless> Keybuk: merge thing; revert .
[13:28] <Keybuk> lifeless: great! thanks
[14:17] <Pilky> Does anyone know if there's any sort of plugin to allow you to do something like 'bzr resolve --other' which will resolve everything to the .OTHER files?
[14:18] <Peng_> Patches are probably welcome. :P
[14:21] <Pilky> yet another of the projects I need to do when I find the time to learn Python I guess :P
[14:24] <Peng_> You could file a bug.
[14:24] <Peng_> (There might already be one, of course.)
[14:26] <Pilky> I'll have a look and file one if there isn't, might get it in quicker than waiting for me to have time to learn python ;)
[14:26] <Peng_> :)
[14:27] <gimaker`> Any rebasing experts in here? I'm (still) struggling with trying to remove history at the beginning of a branch
[14:31] <mheld> hey
[14:32] <mheld> does anybody know of any OS X specific GUIs for bazaar?
[14:37] <Pilky> mheld: yes and no
[14:37] <mheld> i know there's gtk-bzr
[14:37] <Pilky> I'm the project lead on one but it's not even got to 0.1 yet
[14:37] <Pilky> launchpad.net/bazaarx
[14:37] <mheld> but, i don't want to have to install mac ports on all of my computers
[14:38] <Pilky> plus we're doing a major re-write of the core parts so it could be a while before we get to 0.1
[14:38] <mheld> ah
[14:38] <Pilky> hopefully within a month
[14:50] <bvk> hi, is there any bzr extension similar to mercurial's patch-queues (MQ) extension ?
[14:50] <gimaker`> bvk: bzr-loom, I belive (haven't used it myself yet)
[14:51] <bvk> gimaker`: ok, i will try it out :-)
[16:38] <TheEric> dumb question - if someone removed all revisions, is there a way to revert back on launchpad?
[16:39] <beuno> TheEric, removed al revisions?
[16:39] <TheEric> removed from the branch, yah.
[16:40] <luks> how?
[16:40] <TheEric> no clue.
[16:40] <luks> how do you know they are removed then? :)
[16:40] <TheEric> "1264 revisions were removed from the branch."
[16:41] <luks> that's from which command?
[16:41] <TheEric> That's from an email I received.
[16:41] <TheEric> Manfre : Heh.
[16:41] <luks> from launchpad?
[16:41] <beuno> TheEric, ah, someone merged and pushed
[16:41] <beuno> TheEric, you can do push --overwrite
[16:41] <luks> no, somebody did push --overwrite
[16:42] <beuno> ah, right, makes more sense
[16:42] <luks> merge will never decrease the number of revisions
[16:42] <luks> it might decrease the number of mainline revisions, but not the total number of revisions
[16:42] <luks> TheEric: what is the branch?
[16:42] <beuno> right, well, LP only shows mainline, so it makes me wonder...
[16:43] <luks> TheEric: or, to be sure, you want to rever the branch to the original state?
[16:43] <Manfre> lp:xpattern should be reverted to rev 1264
[16:43] <TheEric> Exactly. to Revision 1264
[16:43] <TheEric> It shows as 1 revision right now.
[16:43] <luks> so somebody made a new branch and ran push --overwrite?
[16:44] <TheEric> *shrug*
[16:44] <luks> probably
[16:44] <beuno> something's not right: http://bazaar.launchpad.net/~xpattern/xpattern/xpattern-1.0/changes
[16:44] <james_w> yeah
[16:44] <beuno> it may be LP being dumb
[16:45] <luks> TheEric: this is recoverable, but I still wonder how did it happen
[16:45] <beuno> luks, it doesn't seem like a problem with the actual branch
[16:45] <TheEric> Manfre is listed as the admin with all the requisit access. (points at Manfre)
[16:46] <luks> beuno: bzr log shows exactly one revision
[16:46] <beuno> luks, that's interesting, loggerhead shows 1256
[16:46] <luks> loggerhead is probably cached, isn't it?
[16:46] <beuno> nope
[16:46] <beuno> reading straight off the repo
[16:47] <luks> oh, the cache code was removed?
[16:47] <Manfre> this the most recent subscription update http://xpat.pastebin.com/m8676527
[16:47] <beuno> yeap, a while ago
[16:47] <beuno> it only caches changed files
[16:47] <Manfre> i truncated the file contents out of it
[16:47] <luks> oh, I see
[16:47] <luks> hmm
[16:48] <luks> this is interesting
[16:48] <TheEric> yah, and the removal of the revisions was done after the push
[16:48] <luks> looks like the parent is a ghost
[16:49] <TheEric> but the two events were done ~ seconds of each other.
[16:51] <Manfre> i need to step away  from the computer for a bit. So I'll defer any magically sign offs to TheEric...but i'm pretty sure it's obvious this is an error that needs correcting
[16:51] <luks> I wouldn't touch the branch for now, as it looks like a bug
[16:51] <luks> but all the data are on the server, so it should be recoverable
[16:51] <luks> TheEric: can you please file a bug report?
[16:52] <TheEric> Sure.
[16:56] <luks> hmm, even more interesting, bzrlib has no problem reading the missing revisions
[16:57] <luks> so it looks just like an UI bug
[16:57] <luks> but a really serious UI bug, I think
[16:59] <thorwil> hi. it now happened 2 times that a bzr push would hang at 0. needs 2 times ctrl-c to kill it. i then need break-lock and afterwards push works and takes almost no time
[16:59] <thorwil> any ideas on what's going on?
[17:00] <luks> TheEric: well, I've found the problem
[17:00] <TheEric> oh?
[17:00] <luks> the branch data is broken, the repository data is not
[17:00] <luks> http://bazaar.launchpad.net/~xpattern/xpattern/xpattern-1.0/.bzr/branch/last-revision is not supposed to list revno 1
[17:00] <TheEric> any idea how that happened?
[17:00] <luks> I have no idea at all
[17:00] <luks> you better way for some bzr devs for that
[17:00] <luks> but make sure you file the bug report
[17:00] <TheEric> I am.
[17:01] <TheEric> or already have.
[17:01] <TheEric> I just added your current comment to the description.
[17:01] <TheEric> I'm out to lunch. bbl.
[17:02] <luks> the fix is as simple as changing 1 to 1265 in .bzr/branch/last-revision
[17:02] <luks> but I wouldn't do that on the official branch until you head from a bzr dev
[17:02] <luks> *hear
[17:03] <luks> TheEric: hm, what's the link to the bug report? I can't find it in launchpad
[17:04] <luks> I wonder if this could be some stacking related bug
[17:08] <rockstar> Manfre, TheEric, do either of you have the branch that was used to push lp:xpattern ?
[17:12] <rockstar> On branching that branch, I get bzr: ERROR: bzrlib.errors.NotLefthandHistory: Supplied history does not follow left-hand parents
[17:21] <Lea> is there any way of turning off this message? -- bzr: ERROR: no changes to commit. use --unchanged to commit anyhow -- I want to commit changes every 15 minutes from cron, silently doing nothing if there's nothing changed
[17:24] <james_w> Lea: "if bzr diff >/dev/null; then bzr commit -m 'autocommit'; fi" may what you want
[17:26] <Lea> james_w, thanks for the idea
[17:27] <luks> rockstar: works for me using bzr.dev, which version are you using?
[17:27] <james_w> Lea: you may need to invert the test
[17:27] <rockstar> luks, whatever's in the PPA currently.
[17:27] <luks> it fetches all the ancestry, correctly packs it into a single pack, but leaves last-revision broken
[17:27] <rockstar> luks, yea.  I've seen this bug once before.
[17:28] <Lea> james_w, yeh, already noticed that
[17:28] <james_w> luks: does "bzr check" fail?
[17:28] <rockstar> I thought it was a user error, because I didn't have much confidence in the user...
[17:28] <luks> I've seen mismatch between the two numbers, but never last-revision reset to 1
[17:28] <james_w> if not then check should probably check for "len(branch.revision_history()) == branch.last_revision_info()[1]"
[17:28] <luks> james_w: I don't think it has a reaso n to fail, but I'll check
[17:29] <luks> hm, true
[17:29] <luks> rockstar: oh, it fails for me now, too
[17:29] <luks> I'll check what's changed since then
[17:30] <luks> interestingly, lp:xpattern fails, http://bazaar.launchpad.net/~xpattern/xpattern/xpattern-1.0/ doesn't
[17:30] <luks> I thought it uses the same code path
[17:31] <rockstar> Interesting.
[17:31] <luks> ah, that's probably bzr+ssh vs http
[17:31] <rockstar> Yea, that's probably what it is.
[17:31] <luks> http just fetches the last-revision file, with bzr+ssh it has to recreate it
[17:31] <luks> and recreating it fails on the assert
[17:31] <rockstar> So maybe the bug is in the transport.
[17:32] <luks> I still suspect it has something to do with stacking
[17:32] <luks> I can't see why would anything in bzr reset the number to 1
[17:32] <rockstar> luks, do you have the original branch on your system?
[17:32] <rockstar> I saw this bug long before stacking was even CLOSE to being in trunk, back in maybe May.
[17:33] <luks> rockstar: this is not my branch, so no :)
[17:33] <rockstar> Yea, I figured.
[17:33] <rockstar> Whoever has the original branch would probably be helpful.
[17:33] <luks> the original .bzr.log would help more than the branch, though
[17:34] <luks> since the branch is already broken and the last-revision file overwritten
[17:34] <luks> the state before the commit would help
[17:35] <rockstar> Yea, but the original branch would have everything we need, unless that branch is also screwed
[17:36] <luks> I guess it is, unless this is indeed a bzr+ssh bug and it rewrote the number on push
[17:37] <rockstar> Which would make sense.  I don't think it has much to do with stacking, but I have no clue how to reproduce it.
[17:37] <luks> I didn't mean stacking directly, but some bug introduced with stacking
[17:39] <luks> Manfre: I understand you were the one who pushed the branch? was it just 'bzr push' or 'bzr push --overwrite'?
[17:39] <beuno> TheEric, 'bzr reconcile lp:xpattern' will fix the problem
[17:39] <beuno> (as mentioned by abentley)
[17:45] <abentley> So, what would be interesting: the source branch this was pushed from.  An idea of when the branch was created.  The .bzr.log from the most recent push.
[17:45] <beuno> TheEric, ca you get in touch with the person you pushed last?
[17:47] <abentley> Oh, the bzr version used for pushing, of course.
[18:06] <TheEric> Back
[18:07] <TheEric> Manfre is the project lead, and not the person who last pushed.
[18:08] <Manfre> i'm back
[18:09] <Manfre> so the person who did the last commit needs to run "bzr reconcile lp:xpattern" ?
[18:10] <beuno> Manfre, anyone who has access can do that
[18:10] <beuno> it will fix it
[18:10] <beuno> although, if you could grab the person who pushed and get everything abentley mentioned above, it would be very helpful to us in the future
[19:08] <TheEric> the reconcile didn't fix the problem.
[19:09] <TheEric> it completed about ten minutes ago, I tried to download the branch, and it's still giving me the same error.
[19:20] <TheEric> https://bugs.launchpad.net/launchpad-bazaar/+bug/257340
[19:20] <beuno> TheEric, thanks for the report
[19:21] <beuno> could you pastebin the last bits of your .bzr.log?
[19:21] <TheEric> from the reconcile?
[19:21] <beuno> yeap
[19:22] <TheEric> Umm. Interesting....
[19:23] <TheEric> I don't seem to have that in the .bzr folder and the contents of my local xpattern directory is now, empty.
[19:24] <pickscrape> TheEric: ~/.bzr.log
[19:24] <luks> I wouldn't trust reconcile over bzr+ssh
[19:24] <TheEric> it's on a windows install.
[19:25] <Manfre> my documents folder
[19:25] <pickscrape> TheEric: in that case I have no idea where it would be :)
[19:25] <TheEric> I'm just a bit confused as to why -all- my local files for xpat are gone.
[19:26] <TheEric> just bazaar.conf and ignore
[19:26] <Manfre> odd
[19:26] <luks> TheEric: are you looking to the right folder?
[19:26] <Manfre> i wonder if the reconcile wiped it
[19:27] <TheEric> I am.
[19:27] <luks> bazaar.conf and ignore should be in Application Data/bazaar/2.0
[19:27] <luks> not in .bzr dir of your branch
[19:27] <TheEric> I looked in the .bzr dir in the branch, and there wasn't any sort of log file.
[19:27] <TheEric> of course, the xpattern directory is empty except for that folder.
[19:27] <luks> .bzr.log should be in the home folder
[19:27] <Manfre> .bzr.log is in the My Documents folder on my system
[19:29] <TheEric> found it.
[19:30] <TheEric> and it's blank.
[19:37] <TheEric> yah, did a further search, and no other .bzr.log - only the blank file. That's odd as I've used bzr on this computer, multiple times.
[19:38] <abentley> TheEric: bzr --version will tell you where it's putting the log file.
[19:38] <TheEric> same exact location where I found the blank log.
[19:39] <abentley> TheEric: can you post the output that bzr reconcile gave you?
[19:40] <abentley> ubottu: pastebin
[19:40] <TheEric> Well, there's nothign really to post - the .bzr.log file is blank. 0 bytes.
[19:41] <Manfre> i think they want the console output from the command
[19:41] <Manfre> hopefully you didn't close the prompt
[19:42] <TheEric> http://pastebin.com/d3404dfe6
[19:42] <abentley> TheEric: I meant the console output.
[19:42] <TheEric> yah, that's above.
[19:45] <abentley> TheEric: Strangely, it seems to think your revision_history is okay.
[19:53] <abentley> TheEric: I was able to branch successfully over http, but not bzr+ssh.  Reconciling over sftp might work correctly.
[19:55] <Manfre> abentley: is it possible to revert to 1264 over http?
[19:55] <abentley> Manfre: Not over http, but it would be possible over sftp.
[19:56] <Manfre> i'm not familiar with using bzr with sftp...only http and bzr+ssh
[19:57] <abentley> Manfre: it's very similar to bzr+ssh, but a bit slower.  You just change the URL.
[19:58] <abentley> i.e. replace "bzr+ssh:" with "sftp:"
[20:01] <Manfre> unsupported protocol
[20:01] <Manfre> don't have module paramiko
[20:03] <abentley> Manfre: Okay, try changing "bzr+ssh" to "nosmart+bzr+ssh"
[20:04] <abentley> Manfre: But I'd recommend getting paramiko at some point.  All the full installers should have it.
[20:44] <Toranin> I just installed Bazaar via ports and wanted to work with svn.  After installing the svn 1.5 bindings and the bzr-svn plugin, I ran "$ bzr co -v svn+https://server/repos/trunk" to test and got "Assertion failed: (*path != '/'), function svn_ra_get_log2, file subversion/libsvn_ra/ra_loader.c, line 940." followed by a SIGABRT coredump
[20:44] <Toranin> ideas?
[20:48] <Toranin> same assertion fails in bzr selftest svn after: "[9/824 in 4s] bzrlib.plugins.svn.tests.test_branch.WorkingSubversionBranch.test_create_checkout"
[21:14] <Toranin> I tried to check out from http://people.samba.org/bzr/jelmer/bzr-svn/0.4/ and build, but then it fails to load the extension altogether
[21:19] <jam> abentley: hey, I can't seem to "bzr merge http://bundlebuggy...." anymore. I sent a message to the list
[21:20] <jam> It seems that BB isn't returning 404 for missing documents
[21:20] <jam> it is returning 200 OK, with a 404 page.
[21:22] <jam> Toranin: you might try running "bzr command -Derror" which might help figrue out why the extension is failing to load.
[21:22] <abentley> jam: Yeah, it does look broken.  You might be able to work around it with nosmart+http.
[21:23] <jam> abentley: nope, "Unknown bzrdir format: <!DOCTYPE ..."
[21:23] <jam> same thing if I revert to an earlier version of bzr
[21:23] <jam> When it probes for .bzr/branch/format it gets a 200 OK document
[21:23] <jam> but then doesn't recognize the contents.
[21:24] <abentley> It's supposed to try to use the bundle, and if that succeeds, not use the branch.
[21:25] <jam> abentley: well, neither seems to be working ...
[21:25] <jam> I can 'wget' and then merge from that, though.
[21:25] <jam> and it is still broken for bzr.dev @ 3400, 3500, etc
[21:25] <jam> so it doesn't seem to be something new for bzr
[21:25] <Toranin> jam: it already gives an exception output now
[21:25] <Toranin> jam: let me pastebin it for you
[21:26] <mxpxpod> jelmer: ping?
[21:27] <Toranin> jam: http://pastebin.com/d1f33eabd <-- says 'did you build it?' in there, but I did
[21:28] <jam> Toranin: did you use "build_ext -i" or just "build" ?
[21:28] <Toranin> if I go into the ~/.bazaar/plugins/svn directory and do 'PYTHONPATH=. python', I can import the modules it's failing on
[21:28] <jam> I'm guessing you built it into a "build/XXX/...." directory
[21:28] <jam> so it can't find it
[21:28] <jam> python setup.py build_ext -i
[21:28] <Toranin> okay
[21:28] <jam> *should* be what you want
[21:28] <Toranin> will do
[21:28] <jam> but I'm guessing a bit
[21:28] <Toranin> I just did gmake
[21:28] <Toranin> there's a makefile that invokes setup but not sure exactly how
[21:29] <Toranin> ran your command, didn't appear to do anything
[21:29] <Toranin> I already have 4 .so files in the svn dir
[21:30] <Toranin> the makefile appears to invoke python setup.py build_ext --inplace by default, which I presume is the same
[21:32] <mxpxpod> Toranin: do you have editor.o in your root directory?
[21:34] <Toranin> no -- what the build_ext did was put the o file in the build/... tree and then copy the .so (module) files back up into the root dir
[21:36] <Toranin> I just tried copying the .o files into place, didn't help any
[21:37] <Toranin> is this new?  I notice there are no c or so files in the 4.10 tarball
[21:43] <mxpxpod> Toranin: https://lists.ubuntu.com/archives/bazaar-announce/2008-August/000172.html
[21:45] <Toranin> noted
[21:47] <Toranin> hmm, does bzr do some kind of magic overrides on the import statement?
[21:47] <Toranin> otherwise I can't see how the imports in question are supposed to work
[21:58] <Toranin> ahh, I see
[21:59] <Toranin> the svn plugin as written assumes it's installed under bzrlib/...
[21:59] <Toranin> which is not the case for a homedir install
[22:01] <abentley> Toranin: Plugins are always loaded into bzrlib.plugins, regardless of their filesystem location.
[22:06] <Toranin> abentley: I'd have thought so
[22:06] <Toranin> but given the error I tried just installing it unto site-packages
[22:06] <Toranin> didn't help any, as you probably expected
[22:08] <Toranin> I'm just weirded out by the error, because I can manually import the .so file from the command line
[22:08] <lifeless> moin
[22:19] <lifeless> abentley: ping
[22:19] <lifeless> abentley: bb seems to think squid bundles are bazaar project bundls
[22:19] <lifeless> abentley: or is it the wrong target branch leading to the confusion ?
[22:20] <abentley> lifeless: It would be the wrong target branch, I expect.
[22:20] <lifeless> ok,
[22:20] <lifeless> I'll tweak the squid doco; what do you think about categorising by history as well?
[22:22] <abentley> lifeless: I think that merge directives should be mergeable.  A merge directive with the wrong target branch isn't mergeable, because the target branch isn't available as a resource for retrieving revisions.
[22:22]  * Toranin tried upgrading bzr to 1.6rc1
[22:24] <lifeless> abentley: ah yes
[22:24] <lifeless> abentley: however, if the base is a revision I know about in my repo then the target doesn't strictly matter
[22:24] <abentley> lifeless: I'm not completely against adding more heuristics.
[22:25] <abentley> lifeless: But someone sending a merge directive doesn't typically know what's in your repository.
[22:31] <lifeless> abentley: agreed; kinkies patch was against trunk though; as a user he did the right thing but is missing public_location
[22:31] <lifeless> abentley: are you still suffering some contention issues on the BB database?
[22:32] <abentley> lifeless: I've got a load average of 6.24
[22:32] <lifeless> all from BB?
[22:33] <Toranin> well, that's working much better...the tests are running, though there're some failures
[22:33] <abentley> lifeless: No, that machine handles my mail and web site as well.
[22:35] <lifeless> ah whew, I'd hate to think review was using up that much order ;)
[22:36] <abentley> Order?
[22:39] <lifeless> well doing work increase entropy, so decreases order :)
[22:39] <beuno> lifeless, do you have a minute to discuss bug #248018 - I can't reproduce it, really
[22:39] <lifeless> beuno: yes
[22:40] <beuno> lifeless, well, for starters, I can't get LH to override results  :)
[22:40] <beuno> the code is in place to prevent it
[22:40] <beuno> so I need to reproduce it to find out where it's slipping
[22:41] <lifeless> go to http://bzr-playground.gnome.org/accerciser/trunk/
[22:41] <lifeless> type 'a', wait a 1/2 second, type b
[22:41] <lifeless> you should get ab showing a tad later, then the results for a
[22:42] <beuno> lifeless, yeap, got it.  Is it running the latest LH?
[22:42] <lifeless> search thumper
[22:44] <beuno> lifeless, nm, it has the same js, enough for me
[22:45] <beuno> now, let's see how to debug that...
[22:45] <lifeless> see, easy :)
[22:46] <lifeless> jam: so btree - 3 times faster
[22:47] <lifeless> jam: I'm really starting to feel it would be of benefit to drop the core btree support into bzrlib in some form real soon
[23:06] <lifeless> beuno: you need more from me on that?
[23:06] <beuno> lifeless, nope, thanks
[23:10] <jdobrien> statik: nice changes to the scripts
[23:24] <beuno> mwhudson, did you manage to figure out the "I'm serving from root" issue in https://code.edge.launchpad.net/~pickscrape/loggerhead/directory_breadcrumbs ?
[23:25] <mwhudson> beuno: no, didn't really look at it properly
[23:26] <beuno> mwhudson, k, np. I'll come back to it after I finish the remaining 1.6 bugs, if you haven't managed to before
[23:26] <mwhudson> beuno: i'll try to look at it now
[23:27] <beuno> mwhudson, you rock, thanks!  :)
[23:32] <mwhudson> beuno: your 'bundles' branch looks mergeable to me
[23:32] <mwhudson> beuno: can you rename the 's' StringIO variable though?
[23:33] <beuno> mwhudson, it still needs a link to download the actual diff  :)
[23:33] <jdong> hey guys, thanks for bzr, helped out GREAT at work for some badly VCS'ed jumble of code :D
[23:33] <beuno> mwhudson, sure, rename to...?
[23:33] <jdong> I am guilty of trying Git on Windows XP first though....
[23:33] <jdong> that was not fun
[23:33] <mwhudson> it would also be possible to stream the output, dunno if that's worth it though....
[23:33] <jdong> at all.
[23:33] <mwhudson> beuno: 'diff_content' ?
[23:33] <mwhudson> hm, maybe not that
[23:33] <beuno> mwhudson, just 'content'?
[23:34] <mwhudson> 'diff_content_stream' ?
[23:34] <pickscrape> mwhudson: should I delete that superseded branch?
[23:34] <mwhudson> pickscrape: if you like, no real need though
[23:34] <pickscrape> I like to keep things tidy :)
[23:34] <mwhudson> i guess it could be marked 'abandoned'
[23:34] <mwhudson> mark it abandoned then, it will disappear from almost all listings that way
[23:34] <pickscrape> Will that make it drop off the loggerhead branch list?
[23:34] <pickscrape> OK, I'll do that.
[23:35] <beuno> mwhudson, I'll tweak the remaining bits, and rename, and propose for merging
[23:36] <mwhudson> beuno: ok
[23:36] <mwhudson> beuno: and yeah, a link to it would be handy i guess :)
[23:48] <jam> lifeless: I agree that we should bring them in, possibly before GC
[23:48] <jam> I would probably bring them in without blooms
[23:48] <jam> We have very little evidence that it will be better, and if we do tweak them to get better
[23:48] <jam> it will likely be incompatible with existing bloom code anyway