/srv/irclogs.ubuntu.com/2009/04/07/#bzr.txt

* SamB gripes about bzr viz not being able to run from a repo ...00:45
jelmerlifeless: will iter_changes() yield unchanged parent directories of changed files00:50
=== mario_ is now known as pygi
lifelessjelmer: look for use_record_iter in commit.py00:59
lifelessjames_w: ping01:03
james_whey lifeless01:03
lifelessjames_w: can I get you to debug the stacking bug you stuffered?01:03
james_wsure01:03
lifelesslook at rev 417401:04
lifelessit has the last change to this01:04
lifelessand a test01:04
lifelesspdb somewhere in its new code should help isolate whats going on01:04
spivlifeless: you're welcome to come up here today.01:04
lifelessspiv: ok, I'll head up shortly then if thats ok; we've got a lot to get across :)01:05
james_wah, that sort of debugging :-)01:05
lifelessjames_w: yes :)01:06
james_wtomorrow then I feel01:06
spivlifeless: sure.01:06
lifelessok01:06
lifelessjames_w: please attach bzr info -v of your source branch then01:07
lifelessjames_w: as well as checking you did push with a bzr >> 417401:07
pygiis there any docs for nested branches support?01:16
jelmerlifeless: well, I'm almost done implementing record_iter_changes01:20
jelmerlifeless: is iter_changes() O(delta) or O(tree) on bbc trees?01:21
lifelessjelmer: working tree is O(tree), revision trees are a function of delta size and log(tree)01:24
lifeless-> train to spivs, online again in ~4001:24
thewrathhello all01:41
lifelessjelmer: back01:59
=== ja1 is now known as jam
jelmerlifeless: IIUC iter_changes does depth-first search based on the target tree?02:53
jelmerso if I see a directory is being processed and then see some sibling is being processed I can assume that directory is "done" ?02:53
lifelessjelmer: I wouldn't make that assumption03:34
lifelessjelmer: because it can jump around with renames and stuff03:34
lifelessit might start with one file in a dir, then subdirs, siblings, then find that the dir was reparented and include the parent03:34
=== UdontKnow is now known as \0
=== \0 is now known as UdontKnow
=== thunderstruck is now known as gnomefreak
BasicOSXlifeless:  just came here to report the stacking issue, but I see you are on it, I was just about to upload 1.14rc1, I can wait if bug 354036 fix is close06:30
ubottuLaunchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Critical,Confirmed] https://launchpad.net/bugs/35403606:31
lifelessBasicOSX: we're getting close, I'm landing the last bits of brisbane-core at the moment too06:36
BasicOSXwe are all good then, was working vila  osx patches and Ian's filter registration patch, so I can hold off until that lands06:38
lifelessBasicOSX: cool06:38
Peng_BasicOSX: Are you planning to merge the RemoteBranchConfig stuff from r4251 of bzr.dev into 1.14?06:50
BasicOSXPeng:  no one specifically requested that06:51
Peng_Eh.06:51
Peng_lifeless: ^^ Did you want that for 1.14?06:52
lifelessBasicOSX: Oh, I thought I did06:54
lifelessBasicOSX: in my mail about it to the list, I noted that it fixes a regression vs 1.1306:54
BasicOSXhmm, only merge requests I see are the osx test failures and the simplify the content filter registration API06:57
BasicOSXwell, and bug 35403606:57
ubottuLaunchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Critical,Confirmed] https://launchpad.net/bugs/35403606:57
lifelesshttp://bundlebuggy.aaronbentley.com/project/bzr/request/%3C49D53C9C.2070200%40mattnordhoff.com%3E06:58
lifelessactually thats not the one06:58
lifelessBasicOSX: its rev 4251 of bzr.dev07:01
lifelessI'll send a mail now07:01
vilahi all07:01
Peng_vila: Hello07:01
BasicOSXlifeless:  got that,   (robertc) Fix handling of fallback repositories some more, just cannot find request to cherry pick it (hello vila)07:01
lifelessBasicOSX: I've just sent one to the list07:02
vilaBasicOSX: That was the purpose of lp:~vila/bzr/1.1407:03
BasicOSXI apologize if I missed the initial request... oh, wait07:03
BasicOSXinfo overload lately trying to weed through the 1.14 RC date thread :-(07:04
lifeless:P07:04
vilaBasicOSX: np, that's what teams are for :)07:04
lifelessif I can ask a small favour07:04
lifelessplease leave pqm clear for thie next cole of hours, I'm trying to land all of brisbane core07:04
BasicOSXnp07:04
lifelessand finding gaps in e.g. python2.4 support for it07:05
lifelesswhich are trivialish but a round trip to fix07:05
Peng_lifeless: All of it? Like, "bzr merge ../brisbane-core"?07:05
vilalifeless: fwiw, full test suite passed for python2.[456] here07:05
lifelessPeng_: well no, I'm not planning on do that at all07:06
lifelessPeng_: but do the point there is nothing we want to land07:07
lifelessvila: check the _chk_map.pyx and _groupcompress.pyx files :)07:07
lifelessvila: _chk_map is in .dev, groupcompress in p.u.c/~robertc/baz2.0/integration07:07
Peng_lifeless: Oh. Well, congrats. :)07:10
lifelessgroupcompress up to ascii :)07:10
BasicOSXlifeless:  sorry to pester, but did you find the initial request to merge fallback repositories stuff? I would like to know so I can attempt to fix the holes in my tracking of merge requests.07:10
lifelessBasicOSX: I haven't kept looking07:12
BasicOSXnp07:12
lifelessBasicOSX: the fallback repositories stuff was fallout exposed by fixing the config stuff07:12
lifelessthe branch was about configs07:12
vilaBasicOSX: I'm not sure there was one, but as I was bitten by #354036, I merged it and prepare the branch for you to merge07:12
vilaBasicOSX: I'm not sure there was one, but as I was bitten by #354036, I merged it *in bzr.dev* and prepare the branch for you to merge in 1.1407:12
* BasicOSX groans 07:13
lifelessbug 35403607:14
BasicOSXGetting 354036 issue07:14
ubottuError: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/354036/+text)07:14
lifelessbug 35403607:14
ubottuLaunchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Critical,Confirmed] https://launchpad.net/bugs/35403607:14
lifelessvila: thats a different bug ;)07:14
vilagrr07:14
lifelessvila: so have we fixed --parallel ?07:15
BasicOSXPeng:  thanks for the catch on the missed merge07:16
vilathen #354075 fixed by matt, merged by lifeless in his 'Fix handling of fallback repositories some more' patch07:17
BasicOSXshould the http transport for vila's 1.14 branch work (pass the smart server code)?07:17
vilalifeless: --parallel works great here07:17
vilalifeless: but you mentioned problems with ec2 ?07:18
BasicOSXhttp worked :-)07:19
vilaBasicOSX: you mean for pqm submissions ?07:19
lifelessvila: yes07:19
BasicOSXno, to merge your code into my prepare-1.14rc1 (lifeless  requested I stay out of PQM for a couple hours)07:19
lifelessBasicOSX: http doesn't trigger the problem07:19
lifelessBasicOSX: oh, you can merge from lp all you want, just don't run bzr pqm-submit :)07:20
lifelessvila: give ec2test a spin, you'll see07:20
lifelessFAIL: test_merge.TestMergerEntriesLCA.test_one_lca_supersedes_path07:20
lifeless    RemoteException: Traceback (most recent call last):07:20
lifeless  File "/home/bzrtest/test_branch/bzrlib/tests/test_merge.py", line 1598, in test_one_lca_supersedes_path07:20
lifeless    self.assertEqual, [], list(merge_obj._entries_lca()))07:20
lifeless  File "/home/bzrtest/test_branch/bzrlib/tests/__init__.py", line 1055, in expectFailure07:20
lifeless    raise KnownFailure(reason)07:20
lifelessKnownFailure: We don't do an actual heads() check on lca values, or use the per-attribute graph07:20
BasicOSXlp = smart server07:20
BasicOSX?07:20
vilalifeless, BasicOSX : Someone else than *me* triggers the lp/pqm bug ? Hurrah ! Not jinxed anymore !07:20
lifelessstill07:20
lifelessBasicOSX: lp: urls reoslve to using bzr+ssh and thus a smart server07:21
vilalifeless: I can't do that, I don't have access to ec2, not even sure I can find boto module ?07:21
BasicOSXyep, and I'm getting bit but the smart server bug, so I just got vila's patch via http07:21
lifelessBasicOSX: oh right, I'm synced() now :)07:22
lifelessvila: sign up :)07:22
lifelessvila: see the company cloud computing policy in the all hands list archives07:22
vilalifeless: I'll look07:24
vilaBy the way, it seems that we have more "warnings.warn("%r was gc'd while locked" % self.repr)" these days nist of them (if not all, involving a LockableFiles(<bzrlib.transport.remote.RemoteTCPTransport url=bzr://127.0.0.1:33810 blah blah), does that ring someone's bell ¿07:25
vilagee how did I type that reverse ?07:25
BasicOSXheh07:26
lifeless-> home, groupcompress has landed, I'll be landing the remaining bits very soon.07:53
lifelesswell, ->home shortly07:53
lifelessvila: the answer btw to InterCHKRevisionTree is s/development5/development/08:24
lifelessvila: found the ec2 doc stuff?08:24
lifeless-> home now08:25
vilalifeless: I need to find what login/pass I should use to access allhands archive first :-(08:42
fullermdWell, if it's allhands, I presume you need a fingerprint rather than a password   8-}08:49
vilatime to upgrade ff then :)08:51
lifelessBasicOSX: around?09:06
igclifeless: thanks for landing that stuff today09:11
* igc dinner - bbl09:12
vilalifeless: still around ?09:48
vilaI'd still prefer to run locally (for many reasons including ease of debugging). So my question is: do you feel that the problem you encounter is related to the tests protocols rather than any ec2 specific reason ?09:50
vilalifeless: by 'locally' I mean connecting via ssh in my LAN to get a close-enough approximation of course09:52
vilalifeless: and also because that's a setup I want to be able to use from my laptop to my "data center" :-)09:53
=== bob2 is now known as Guest95719
=== Guest95719 is now known as bob2
lifelessigc: nearly done10:48
lifelessvila: yes, I'm around10:48
lifelessvila: I would like it if you were familiar enough with bzr-ec2test to debug problems when it is used10:49
lifelessvila: thus, I plan to drag you kicking and screaming through it once :)10:49
vilalifeless: ha, I thought so but was unsure :-)10:51
lifelessvila: concretely it is failing to de-and-re serialise from ec210:53
lifelesswhich I haven't had time to debug myself test.10:53
vilalifeless: so it's not directly related to my last patch (as in, it was failing before ?)10:54
lifelessI think so10:54
lifeless:)10:54
viladevil :)10:54
lifelesswell10:56
lifelessI figure a little latitude is due, for doing the heavy lifting to get you your desired parallel suite :)10:56
lifelessvila: I have a separate favour for you to do though, and this is rather more important. I'm about to land --development6-rich-root10:57
vilahuh ? We still separate rich-root ?10:57
lifelessits the only one10:58
lifelessno dev610:58
lifelessand aaron has said subtrees need more stuff so leaving out for now10:58
vilaha, to underlined that it *is* rich root10:58
lifelessyes10:58
vilaok10:58
lifeless*do-not* want random upgrades and folk having deep troubles10:58
* awilkins applauds the lack of not-rich-root10:59
vilaDidn't we say we'll call it --dev6-rich-root-eat-your-dog ?10:59
awilkins--dev6-rich-root-cat-taxidermist  ?11:00
vilaanyway, what favour ? (The more you wait to ask, the bigger is should be, the more I'm frighten :)11:00
vilaawilkins: don't touch cats11:00
awilkinsToxoplasmosis?11:00
lifelessvila: merge all the components of brisbane-core from bzr.dev to a single branch and then that into 1.14/get BasicOSX to merge it into 1.1411:03
lifelessvila: *note* I *have not* and do *not intend* to merge the brisbane-core branch directly.11:03
lifelessvila: it has content we don't want to land in bzr.dev at this point.11:03
vilalifeless: right, so cherry pick from bzr.dev ok. Two things,11:04
Peng_The sucky thing about not having a non-rich-root format is that the Big Rich Root Transition will have to take place before I can use it locally on most projects. :\11:04
vilalifeless: Do you have some reference branch I can use for verification purposes (though one)11:05
vilalifeless: two: that means losing the annotations or did your (and Ian's) submissions somehow preserve them ?11:05
vilalifeless: if answer to two is yes, don't bother explaining, I can understand why, just want to be clear11:06
awilkinsWhat exactly is the reason for things not being bi-directionally compatible with rich-root?11:06
bob2why aren't floats bidirectionally compatible with ints?11:06
awilkinsThat isn't "exactly"11:07
bob2rich-root has data non-rich-root can't represent11:07
awilkinsYes, but what is it?11:07
vilaawilkins: root data :)11:07
awilkinsGinger? Valerian?11:07
vilaawilkins: that data makes root rich11:07
bob2an id for the root directory of a branch11:07
lifelessvila: they are gone, we have used --author11:09
lifelessawilkins: and versioning of the root11:09
lifelessawilkins: which we use in a number of merge corner cases, and for nested trees.11:10
awilkinsThe band-aid needs to be ripped off!  .... of course, it doesn't matter much to me, the majority of branches I use are rich-root so I can keep my manager happy with svn commits11:11
lifelessvila: btw its 120 seconds for me to run the test suite with 2 ec2 instances11:13
vilalifeless: right so, from bzr.dev log that means revnos 4262 4261 4260 4259 4254 4248 4247 4246 4245? 4244 4243 and the one where you land the --dev6 format ?11:14
vilalifeless: 120... hmpf11:14
vilalifeless: that doesn't include bzr-loom of course :-)11:14
=== AnMaster_ipv6 is now known as AnMaster
=== Mez is now known as CrazyShoe
=== CrazyShoe is now known as Mez
lifelessigc: ping11:36
* lifeless tapdances on igc's toes11:53
=== siretart_ is now known as siretart
lifelessvila: it passed tests in bzr.dev because many tests were not running for it12:11
lifelessvila: grab my integration branch if you want to see it blow up ;)12:12
vilalifeless: errr, context ? ec2 ? bbc ?12:12
igclifeless: here to help - which branch should I grab?12:13
lifelessigc: my integration branch12:15
lifelessvila: bbc12:15
lifelessigc: if you run bzrlib.tests.workingtree_implementations.test_eol_conversion.TestEolConversion.test_eol_native_with_crlf_i12:16
lifelessfor selftest12:16
lifelessit should fail with a clearly wrong line ending12:16
lifelessI see12:16
lifelessAssertionError: not equal:12:16
lifelessa = 'hello\r\nworld\r\n'12:16
lifelessb = 'hello\nworld\r\n'12:16
lifelessfor instance12:16
lifelessgive me a clear pointer at whats likely wrong and I'll happily fix. right now I'm fixing real issues with tests that were incorrectly not enabled in bbc that became clear as I did the integration12:17
lifelesss/real/other real/12:17
igclifeless: grabing the branch now. The code on lp is up to 4248 and due for mirroring again in 2 hours so I can't just use loggerhead there12:19
=== thunderstruck is now known as gnomefreak
lifelessigc: sorry yes :)12:23
lifelessigc: regardless loggerhead wouldn't help you I don't think12:23
igcnp - it's down now12:23
lifelessso, found an issue with labels12:23
lifelesswithout labels in the pack12:23
lifelesstwo packs with different content can then collide, but the indices are no longer equivalnet12:25
lifeless[tests fail]12:25
igclifeless: ./bzr selftest TestEolConversion --no-plugins -1 passes for me12:26
igcon 424912:26
igcof your integration branch12:26
igchmm12:26
lifelessset LANG=C12:26
ronnyhmm12:26
ronnysadly bzr is the only vcs that has merge instead of pull if the remote diverged12:27
bob2'has'?  you can merge in git in that situation (after fetching)12:28
igcronny: try bzr merge --pull12:29
ronnyhg and git allow me to pull first, merge later12:30
bob2you can bzr pull to your local mirror of that branch (and if it is in a repository with your branches, it is space efficient)12:31
lifelessronny: bzr can do that too, via fetch12:31
bob2bzr's mass branch management is a bit lacking alas12:31
ronnylifeless: so fetch pulls a dangling head into the backing repo?12:32
igclifeless: setting LANG=C doesn't break things for me12:32
ronnyhmm12:32
igcI'll try a wider set of tests12:32
ronnyi love how this shit differs - in hg/mtn pull is history sync, in bzr/git it has some merge potential (and bzr is the one that needs explicit merge)12:33
ronnylifeless: will the fetched remote data get any special marker other than showing up in the heads?12:36
lifelessigc: interesting12:36
lifelessronny: no12:36
igclifeless: so the filtered views tests are failing for me cause you deleted development-wt6 - trying them now with development-wt6-rich-rott12:36
igcroo12:37
igcroot12:37
lifelessigc: yes,they are passing for me12:37
lifelessI have some uncommitted fixes fixing most of the tests12:37
igcit needs to go as well and be replaced with you new format12:37
igclifeless: so filtered view tests pass on development6-rich-root, development-wt6-rich-root needs deletion if you haven't done it already12:41
lifelessigc: yes, done12:42
igclifeless: did you try --no-plugins?12:43
jelmerhey lifeless, igc12:43
igchi jelmer12:43
jelmervila: ping12:43
jelmervila: You mentioned using factory.stdin.getvalue() in your review12:44
jelmervila: but the rest of the file also uses factory.stdin.readline() and the main point is checking the position of the stream12:44
igclifeless: if you put the output from bzr diff in a pastebin, I'll apply that and run the tests again12:47
vilajelmer: I think the comment says: ensures stdin is empty no ? Oops, no, the previous test is with a non-empty stdin, sorry, forget that remark then12:47
jelmervila: ok, just making sure I wasn't missing anything. Thanks again for reviewing, I've fixed the other issues.12:49
lifelessigc: sure, one sec12:49
lifelesshttp://paste.ubuntu.com/146177/13:00
lifelesssorry, phone call13:00
lifelessigc: ^13:04
lifelessigc: I'm going to recommit in a minute, as I had to back out some of the cleanup13:04
lifelessand try it again13:04
lifelessok ec2testing13:21
lifelessigc: if it fails on the NoEol stuff, I'm going to shove it a pqm13:21
lifelessI think it might be me ;)13:21
igclifeless: might be. bzr selftest eol filter --no-plugins -1 works fine for me with your patch ..13:22
igcand visually inspecting it, it looks fine13:23
lifelessigc: yea,  I can't see anything in this breaking it :(13:23
igcI got out of bed to help so I'll head back there now13:23
lifelessigc: I'm so sorry13:23
lifelessigc: where should I look if it still breaks13:23
igclifeless: np. email me if there's still an issue and I'll look into it first thing13:23
lifelessI'm staying up till this is landed13:24
lifelessI don't need you to fix it, just to point me at the code areas that are potentially implicated13:24
igcwell bzrlib/filters/eol.py is the starting point13:24
igcbeyond that, it depends13:24
igcsorry - that's not much of an answer13:25
lifelessthats ok13:25
lifelessI will follow my nose as needed13:25
lifelesssleep well, and sorry again13:25
igclifeless: good luck and I'll possibly be up early - hard to tell as the chemo makes me very both very sleepy and very awake depending on god knows what13:26
igcso please email any issues13:26
igcnight all13:26
lifelesswill do13:28
lifelessbombs away13:32
vilalifeless: your pending submission in pqm is the last I should backport to 1.14 right ? (It passes tests here)13:56
lifelessyes13:56
jelmervila: I'm wondering what to do with smtp as the current implementation asks pre-emptively14:02
jelmervila: ideally we wouldn't always be doing that but only in the cases where the server requires us to14:04
jelmervila: but that seems impractical (impossible?) for smtp14:04
vilajelmer: smtp starts by using its own smtp_username and smtp_password config options, I'd say it should use authentication.conf instead14:05
vilajelmer: iow, out of scope for your fix IMHO14:06
jelmervila: the problem is get_user() will now return getpass.getuser() rather than None if there's no user configured in authentication.conf14:06
jelmervila: and previously it would skip authentication if None was returned14:06
lifelessjelmer: can I ask a favour?14:06
jelmerlifeless: you can always ask :-)14:07
lifelessjelmer: ... say yes to my next request14:07
lifelessjelmer: may I kill your pqm job, its 11PM, want to land development6 and sleep14:07
jelmerlifeless: sure, go ahead14:07
lifelesstanks14:08
jelmerlifeless: please let me know when yours is done so I can requeue mine14:13
vilajelmer: I'm pretty sure lifeless will be asleep when pqm lands its patch :) But nothing forbids you to queue now, I think that was the last missing patch14:14
lifelessvila: I will be awake till it lands14:14
vilalifeless: sorry no offense intended :)14:14
lifelessvila: only way to be sure14:15
lifelessnon taken14:15
vilalifeless: good ! So you may have a look at lp:~vila/bzr/bcc-1.14 and tell me if everything looks fine so far14:15
vila:)14:15
vilalp:~vila/bzr/bbc-1.14 of course14:16
lifelessto your list above14:16
lifeless425714:16
vilaindeed, just merged it14:16
jelmervila: any idea about smtp?14:17
vilalifeless: errr, was about to merge it (not pushed)14:17
lifeless:)14:17
jelmervila: I could add a "return_non_if_default" boolean parameter but that just seems plain wrong14:18
vilajelmer: consistency is good, I think smtp should align to either http or getpass.getuser()14:18
jelmervila: but the new behaviour makes unauthenticated smtp impossible14:19
jelmeras get_user() will never return None14:19
jelmerlifeless: I just got a "success" message from PQM and my branch was merged14:21
lifelessjelmer: odd...14:21
vilajelmer: unauthenticated http is possible, do the same :-)14:21
jelmervila: yes, but in the case of http we only ask after the remote host gives a "Permission denied"14:22
vilajelmer: sure, I was trying to get some time to think :)14:22
awilkinsjelmer: That reminds me about svn+ prefixes14:22
jelmervila: :-)14:23
jelmerawilkins: what about them?14:23
awilkinsjelmer: I seem to think that if your web server refuses access to the locations that bzr probes to determine whether a web server is a repo, things just stop14:24
awilkinsI should make a more coherent report14:24
vilajelmer: so smtp._authenticate() says: """If necessary authenticate yourself to the server.""", so there should be a way to find if auth is necessary14:26
vilaIn the worst case it means: try to send, catch auth error, authenticate, send14:26
vilathere is smtplib.SMTPAuthenticationError ....14:26
vila... whose doc string says " Most probably the server didn't accept the username/password"... I love the most probably part :-/14:27
jelmervila: yeah, SMTP sucks14:28
vilajelmer: probably smtp servers requiring auth suck less :-)14:28
jelmervila: The annoying thing here is that we probably won't know whether we need authentication until we've tried sent a full email14:28
jelmers/sent/to send/14:29
vilajelmer: indeed, that's the way http achieve auth, try without and if it fails try with auth14:31
=== sabdfl1 is now known as sabdfl
vilalifeless: ha, 4259, the fun stuff :-(14:35
=== abentley1 is now known as abentley
jelmervila: what about an optional default= argument to get_user() that defaults to getpass.getuser() ?14:37
jelmervila: smtp could set that to None14:37
jelmerand keep behaving the way it does atm14:37
vilajelmer: if you add a FIXME in smtplib about converging and/or addressing the problem, that sounds perfect for your submission14:38
jelmerthat would keep smtp in the current state but at least support prompting for http14:38
jelmervila: cool, thanks14:38
lifelessyes :)14:39
lifelessvila: see the pyrex issues?14:39
lifelessalso: http://pqm.bazaar-vcs.org/ - the eagle is landing14:39
lifelessjam: ^ :)14:40
vilalifeless: not yet (but I suspected that when you mentioned the problem), I'm in Resolve confclits in NEWS14:40
jamlifeless:  /cheer /train14:42
jamThough your post about duplicate content was a bit concerning14:42
jamI have some thoughts about exploiting duplicate content within a group, but having this across .pack files ...14:43
lifelessjam: yes; it is rather pathological, but worth resolving in some way for production version14:44
jamlifeless: so... we could go with some sort of labels as an easy fix, or push more for getting text content into a chk structure14:45
jamI'm concerned about the CHK index exploding even further...14:46
lifelessjam: indeed14:55
vilalanded in bzr.dev14:58
lifelessvila: cool15:04
lifelessjelmer: go for it15:04
jelmerlifeless: thanks, it's already in though :-)15:06
lifelessvila: so are you good to get a passing testsuite version for 1.14?15:06
vilaI run selftest at each commit, I'm at bzr.dev@4261 so 3 more commits to go15:06
lifelesscool, I'll hang about a bit then15:07
vilaerr 2 even15:07
lifelessas I know you have fast tests :)15:07
vilaindeed, could not have afford to do that otherwise15:07
vilalifeless: yeah for the big fat NEWS entry  about bbc :)15:11
vilalifeless: ready to merge in 1.14 pushed at lp:~vila/bzr/bbc-1.14 care to have a look, jam too ?15:15
vilastill running the tests, will do a 'make check' after that15:15
lifelessvila: I'm shattered; the mainline is done, I'm happy to hand off15:16
vilalifeless: ok15:16
vilalifeless: good job, sleep well, no test failure to report so far :-)15:16
lifelessvila: cool, thanks.15:16
jamvila: so is that cherry-picking brisbane-core into 1.14?15:17
jamlifeless: is this the bug you were looking at with spiv:15:17
jamErrorFromSmartServer: Error received from smart server: ('error', "'AbsentContentFactory' object has15:17
jam no attribute 'get_bytes_as'")15:17
=== ubott2 is now known as ubottu
lifelessjam: yes15:17
jamk15:17
lifelessjam: I mailed the list the bug number15:17
jambecause I just failed to branch vila's code15:17
lifelessthe fix is to upload more content15:18
jambug 35403615:18
lifelessyes15:18
vilajam: yes, it should be: bzr-1.14 + (bzr.dev@4265 - everything not related to bbc)15:18
lifelessvila: apply the fix from bug 354036 to the bzr you use to push, remove the branch and push again15:18
jamwell, for now I can just branch from "http://bazaar..."15:19
lifelessindeed15:19
lifelesswell, I'm halting() or I'll be more than tired tomorrow15:20
vilalifeless: I use bzr.dev@4263 to push so the fix should already be included15:20
ubottuError: Could not parse data returned by Launchpad: Unknown host. (https://launchpad.net/bugs/354036/+text)15:20
lifelessvila: we haven'tlanded the fix for that bug15:20
ubottuError: Could not parse data returned by Launchpad: Unknown host. (https://launchpad.net/bugs/354036/+text)15:20
vilagrrr15:20
Peng_lifeless: There's an error in the docs for development-rich-root: It says it's interchangeable with pack-0.92, not rich-root-pack.15:21
vilaubottu you didn't help here ! That's the second time I cross the bugs and that you can't display them >-/15:21
ubottuError: I am only a bot, please don't think I'm intelligent :)15:21
vilaubottu: that wasn't exactly what I was thinking :-)15:21
ubottuError: I am only a bot, please don't think I'm intelligent :)15:21
lifelessPeng_: thanks. vila/jam if you could fix that oversight that would be grand15:22
* lifeless goes15:22
vilauuuurgh, can't pull ~spiv/bzr/stacking-inventory15:25
vilaok, pulled with bzr-1.1315:27
vilaand pushed with ~spiv/bzr/stacking-inventory  at lp:~bzr/bzr/bbc-1.1415:28
vilajam: can you pull that one ?15:29
jamvila: I already fetched it with http://15:29
jambut I'll try again on another machine15:29
vilajam: rats, I missed that one15:29
jamvila: bzr.dev@4265 still fails to branch lp:~bzr/bzr/bbc-1.1415:31
jammaybe you need some actual data transferred so it doesn't no-op the push?15:31
jamvila: you could try 'commit --unchanged' and uncommit it later if it works15:32
jam(commit --unchanged, bzr push, bzr uncommit lp:...)15:32
vilajam: it's a new branch ! The former one was lp:~vila/bzr/bbc-1.1415:32
jamah15:32
jamwell, it failed15:32
jamso it seems the stacking fix isn't sufficient/complete yet15:33
Peng_So, um, anyone want to fix the doc issue I just mentioned, or should I send a trivial patch or something?15:33
vilaPeng_: send a trivial patch so that it doesn't get lost15:33
Peng_vila: Okie dokie.15:34
Peng_Okey dokey? Whatever. Anyway.15:34
Peng_Wait, what should it be against? bzr.dev? bbc-1.14?15:34
vilabbc-1.14 will be merged in bzr.dev at some point so at least against it15:35
Peng_Whee, AbsentContentFactory traceback!15:35
beunoPeng_, downgrade to 1.13.1  :)15:36
beunoI had to do that yesterday15:36
Peng_\o/15:36
Peng_I don't have 1.13.1 anywhere.15:37
beunoit's stacked branches and bzr.dev not getting along AFAIK15:37
* Peng_ kicks the "Target directory already exists" error.15:38
vilaPeng_: bzr branch http://bazaar-vcs.org/bzr/bzr.1.13/15:38
Peng_vila: Well yeah.15:38
Peng_Tags would make it easier to figure out which revision is right, though.15:39
Odd_BlokeSo I just ran "bzr push svn+ssh://odd_bloke-guest@svn.debian.org/svn/python-modules/packages/python-whoosh/trunk" and got "bzr: ERROR: Prefix missing for branches/python-whoosh; please create it before pushing.".  How can I tell bzr-svn to actually push to where I'm telling it?  Would it make a difference if .../trunk already existed?15:39
Odd_Blokejelmer: ^ :)15:40
awilkinsOdd_Bloke: python-whoosh needs to exist15:41
awilkinsOdd_Bloke: Don't create trunk15:41
Odd_Blokepython-whoosh does exist.15:41
Odd_BlokeIt's talking about an as-far-as-I-can-tell-unrelated '_branches_/python-whoosh'.15:41
awilkinsAh, maybe it's branches that needs to exist (or you need to make it think something else about branching scheme)15:42
Peng_Are format help strings hardcoded in the tests anywhere?15:45
Peng_In other words, is bzrdir.py the only place you have to make changes to them?15:46
Odd_Blokeawilkins: Using 'bzr svn-layout'?15:46
awilkinsOdd_Bloke: I'm not entirely sure15:46
awilkinsOdd_Bloke: I've just resorted to conforming to expectations :-)15:46
vilaPeng_: running the tests should tell you :)15:48
Peng_vila: But you can tell me more quickly! ;-D15:48
Peng_Wait, so bbc is going to go in 1.14?15:49
vilaPeng_: I don't know that one by hearth, so I'll have to run the tests :)15:49
vilaPeng_: that was always the plan :)15:49
jelmerOdd_Bloke: hi15:50
jelmerOdd_Bloke: you need to use svn-push if you're running an older version of bzr15:50
vilaBasicOSX: ping15:51
Peng_Well, it looks like the tests weren't updated last time they changed, so I'll go with that.15:52
Peng_So should I send the patch to the mailing list? [1.14]?15:52
vilaPeng_: yup15:52
Peng_This process needs more magic. All I'd have to do is think "vila, fix this bug" and bang, it would be in bzr.dev 30 seconds later. :(15:53
vilaPeng_: when in doubt, use more magic15:54
Peng_Shoot, I branched from bbc-1.14, meaning a diff against bzr.dev includes lots of other stuff. :(15:55
Odd_Blokejelmer: Ah, cool, didn't realise how long it had been since I'd updated my bzr.dev/bzr-svn on this machine.15:56
Odd_Blokejelmer: Thanks. :)15:56
vilaPeng_: why are you diffing against bzr.dev ? Is your branch parent correct ? And the submit one ?15:59
Peng_vila: Well, when sending a bundle to the list, it's most convenient to have the parent be in bzr.dev. Which the tip of bbc-1.14 isn't. Or something.16:01
Peng_I don't want to expend more effort thinking about this! :(16:01
Peng_vila: So, you want the patch against bbc-1.14?16:02
vilaPeng_: it's indeed the most convenient when sending bumdles against bzr.dev :-) But here you want submit_branch = http://bazaar-vcs.org/bzr/bzr.1.14/16:02
vilaPeng_: whatever is easier for you, as I said, we don't want it to be lost, that doesn't mean you have to suffer :)16:03
Peng_So it looks like you and lifeless made the same changes (or at least the same commit messages) in different revisions, one for bbc-1.14 and one for bzr.dev.16:04
Peng_Hence my problems.16:04
vilaPeng_: I indeed copy/pasted a lot to cherry-pick16:04
Peng_If only we were using darcs. :(16:05
Peng_On a different subject, ice cream! See you later. :)16:10
Takice cream is always on topic16:26
Peng_What about cake?16:27
TakI suppose that's a matter for debate16:30
vilaice cream on top of cake ?16:34
vilapassed under a chocolate fountain ?16:35
Peng_And deep-fried!16:35
vilaubottu don't like chocolate :)16:35
Peng_With M&Ms and powdered sugar on top.16:35
Peng_Heh.16:35
vilachocolate16:39
vilaBasicOSX: ping16:39
vilaBasicOSX: I have a fix for bug #35545416:40
vilacome on ubottu, you should have that one in your cache, it's a hot one16:40
ubottuLaunchpad bug 355454 in bzr "$ make check-dist-tarball failure" [High,Fix committed] https://launchpad.net/bugs/35545416:42
Peng_1.14 is getting a *lot* of patches.16:43
vilaPeng_: 1.14rc1 is not out yet, at least because of the above bug :)16:45
tonyhello?17:15
vilajam: ping17:26
tonyhi17:26
jamvila: pong17:27
tonyheh17:28
vilajam: regarding fix for #355454, I think abspath is needed because we'll call stat, so my last remark is invalid17:28
jamI think I've tracked down the ambiguity, so we just need to decide on a fix17:30
jamspecifically17:30
jamwalkdirs()[4] ==> a path that you can pass to stat or open() to get the object17:30
jamwhich may be Unicode or may be an fs path17:30
vilayet, we may want to have both rel and abs available to avoid re-calculating rel from abs, I'm pretty sure we use the path that can be either utf8-encoded or unicode depending of what dir reader we use17:30
vilajam: exactly17:30
jamWe use this so that internal to dirstate, we don't have do .decode('utf8') every file17:30
jamsorry17:30
jamevery ptah17:30
jampath17:30
jamon UTF-8 filesystems, etc.17:31
vilayes, same page17:31
jamSo it sounds like you're finding that the _content_filter stuff *requires* a Unicode string?17:31
vilaso, do you agree that path is either unicode or utf8 encoded ?17:31
vilatree.relpath does17:31
vilaAFAIK17:31
jamvila: I think for current implementations, we do17:31
jamI don't think the api requires that17:32
jamso I think the problem is how stat_and_sha1 is intermingling with the walkdirs stuff17:32
jamI think we already have a reasonable relpath available17:32
jamwe just *also* need abspath to actually open the file from disk17:32
vilaso pass both ?17:32
jamsomething like that17:33
vilawith relpath=None as default ?17:33
jamLet me look at the code a bit17:33
vilajam: far more tests than actual code (and too much for me to fix it *today*, no problem if it can wait tomorrow)17:34
jamif we look at _walkdirs_utf8 we have a bunch of things that are "utf8_relpath" etc.17:34
jamvila: I just don't want "fixing" it on Mac to break it on Win3217:34
vilajam: I didn't fix it on mac, I fixed it on interpid17:34
vilaand I think BasicOSX is also on Linux17:35
jamvila: how was it breaking there? (and why wouldn't it have been breaking on PQM)17:35
vilajam: ha ha pqm, still the same LANG=C joke ?17:35
vilait broke here with python -Werror17:35
jamwell, supposedly lifeless fixed PQM's LANG issue17:36
vilalifeless filed a RT request, I don't know if it has been fixed yet17:36
jamhe mentioned the likelyhood that things may start breaking accidentally17:37
jamso I thought it had happened17:37
vilapython -Werror ./bzr selftest -s bzrlib.tests.tree_implementations.test_test_trees.TestTreeShapes.test_tree_with_merged_utf817:38
jamso certainly WT.relpath() is comparing the path with self.basedir17:38
vilajam: can you try that ?17:38
jamwhich should be a unicode string17:38
jamvila: well, on Windows the tests pass17:38
jambecause they use Unicode strings for that argument :)17:39
vilasee ? That's the right fix ! :-)17:39
vilalol17:39
jamwin32 walks in Unicode, because we get it directly from the FooW apis17:39
vilajam: doh ! It passes on OSX too !17:40
jamvila: interesting, I get d to convert both arguments to Unicode - interpreting them as being unequal17:40
vilaha wait, no extension built here17:40
jamvila: right, it will pass without extensions, because the global fallback path is to walk using Unicode17:41
viladid you use 'python -Werror' ?17:41
vilajam: sure17:41
jamvila: well with -Werror it fails, without it just warns17:41
jamanyway17:41
jamI would actually say the 'correct' fix is to do:17:41
jamif type(x) is not unicode:17:42
jam  x.decode(_fs_enc)17:42
jamhowever, at the moment17:42
jamthe code paths17:42
vilajam: That's the bug ! That's why make check-dist-tarball fails17:42
jamstate that the only time x isn't unicode17:42
vilabecause it uses python -Werror17:42
jamis when fs_enc == utf-817:42
jamso.... we have a utf-8 relpath already17:43
jamit is part of the walkdirs api, and we could pass it into the stat function17:43
jambut for ease...17:43
jamvila: BB:tweak ... for now your fix is fine, as long as we update the documentation on SHA1Provider.stat_and_sha1() to declare that abspath17:46
jammay be a filesystem encoded absolute path17:46
jamsince it is coming from walkdirs_utf817:47
vilaright, I'll then enhance the patch to provide relpath too and more importantly add some tests parametrization as discussed in brisbane17:48
jamvila: the one thing to be aware of... relpath *might* be from a subdir of a directory, I'm not 100% sure where the 'walkdirs' is starting from.17:48
vilajam: hmm17:49
jamI'm thinking it can be trusted17:49
jamI just need to poke around the code and make sure17:49
jamvila: it should be fine17:52
jamof course...17:53
vilajam: ok, I'll add tests for it :)17:53
jamthis means that we'll have to decode every path again, but perhaps only if they miss the sha hash17:53
jamwhich would be ok17:53
jamsorry, the stat fingerprint hash cache17:54
vilajam: what worries me more is that g_content_filter_stack queries for filters which may in turn result in IO...17:55
jamvila: what IO, you mean having to read config files to figure out if there is a filter for the given file?18:04
vilajam: things like that, I didn't dig that far to be 100% sure, just a bad feeling18:04
vilasince the SHA1Provider already cache the tree, I thought some more may need to be cached, but may be it's already the case and I should not worry18:05
vilajam: last thing before I quit, did you had a look or have comments about bbc-1.14 ? Can you make sure BasicOSX is aware of it ?18:09
vilas/did you had/did you have/ geee, why do I keep making that one...18:09
vila...is it correct ENglish or *not* ?18:10
jam"did you have a look"18:11
jamthough "did you look at" is easier18:11
abentleyvila: Isn't it very similar to a French construction where the past tense is used?  "As-tu eu.."?18:21
vilaabentley: that's where my error is coming most probably: As-tu jeté un coup d'oeil sur18:22
vilamy fingers and my brains walking at different speeds in parallel in French and English just mess things up :)18:23
vilabrain, mutli-core but still mon-brain :)18:23
vilamono argh, time to stop :)18:23
vilacooking time18:24
=== beuno_ is now known as beuno
alaa_hey guys. So am getting a stack trace every time i run "bzr st". It is bzr 1.13. The error is TypeError: run() got an unexpected keyword argument "verbose"18:41
alaa_I'll file a bug a bit later, but is there anything i can do now?18:41
james_walaa_: you need to upgrade your copy of the bzr-loom plugin18:44
alaa_james_w: ah yes. I was just looking at the trace, and i saw the loom reference. I'll try that and report back18:44
alaa_james_w: That worked. So this is a known problem then, right?18:49
Peng_alaa_: Yes. Hence it being fixed in newer versions of bzr-loom. :P18:51
james_walaa_: yeah, I would guess that it is the most frequently reported bug in the history of bzr :-)18:51
alaa_Right. It's amazing how it got through since it is in the most used command in bzr :)18:54
alaa_james_w: thank you for your help18:54
james_wnp18:54
catojohello guys18:57
Peng_Hi18:57
catojoHi Peng_18:58
catojoCan, do you know how much sites that supports the bazaar ?18:58
Peng_What?18:58
catojoSo, I'm from brazil, thus, I do not speak english correctly.18:59
catojoBut i want to know how many sites supports bazaar18:59
catojoI know launchpad only.19:00
Peng_catojo: Oh. SourceForge added support recently.19:00
catojoCool.19:00
catojoI will see.19:00
catojoThanks.19:00
catojoPeng_19:01
catojoA have a free software stored at sourceforge.19:02
catojoBut I'm use SVN.19:02
catojoI will try to migrate to bazaar.19:02
Toksyuryelbzr rocks19:02
Toksyuryel:)19:02
beunoIt sure does!19:03
beuno$19:03
Peng_catojo: You can use bzr-svn to convert. http://bazaar-vcs.org/BzrForeignBranches/Subversion19:03
catojohmm19:03
catojoI will see.19:03
catojoSome people will go to FISL 10 ?19:04
catojohttp://fisl.softwarelivre.org/10/www/19:04
Peng_beuno: So, which version of my Loggerhead YUI CDN thing do you like best?19:06
Peng_:D19:08
catojoPeng_ Yahoo library ?19:08
catojojavascript ?19:08
catojoYUI19:09
Peng_catojo: Yes.19:09
catojoPeng_ Javascript smells good.19:10
beunoPeng_, I have options?19:10
beunodid I not approve that branch?19:11
Peng_beuno: I made 3 different versions of my little patch.19:11
Peng_beuno: Sure, you did, and then I changed it again. :D19:11
beunoah!  hehe19:11
beunook19:11
beunoso19:11
beunoURL?19:11
beunoand19:11
beunowhat's your preferencec?19:11
Peng_beuno: http://bzr.mattnordhoff.com/loggerhead/loggerhead/yui-cdn/changes19:13
Peng_beuno: I think revision 322 is the prettiest, but revision 324/325 uses a single, combined JS file instead of half a dozen individual ones, so it should be faster.19:14
beunoPeng_, agreed19:16
beunoone comment19:16
beunohow about not using "yui" as a variable name?19:16
beunoie, use cdn generically19:17
beunoother than that, I'd love for that to be merged in19:17
beunodon't forget to update NEWS19:17
Peng_beuno: Wait, so do you prefer 324/325 or 322?19:19
beunoPeng_, I think 322, even though the URL is hardcoded19:20
beunoand I know I complained about that19:21
beunoI'm actually ok either way I think19:21
beunoboth are good, and both itch19:21
Peng_beuno: 324/325 just hardcodes it in the template, and in a more obfuscated way.19:21
beunoyeah, that's what itches me about that19:21
Peng_:D19:21
beunoso making the var names more generic, and landing 322 I think is a good compromise19:21
Peng_Which var names?19:22
beunouse_yui_cdn19:23
beunoand def yui_url19:23
beunoI'd use:  use_cdn, and cdn_url19:23
beunowe're using YUI, but we're not married yet  ;)19:23
beunomaybe even the --yui-cdn19:24
beunoto --use-cdn19:24
Peng_Hmm, I see your point.19:24
beunoso if we change js libraries, people don't have to update their start scripts   :)19:24
Peng_I kind of like the name "yui_url" for the function, though, since it *is* specific to YUI.19:24
beunotrue19:25
Peng_Well, it's just as specific as the rest of the code. Still, I'd prefer to make the other changes, but stick with "yui_url".19:25
beunoI'm fine with that19:25
Peng_I guess it would have to be changed if the JS library is ever changed, but Loggerhead doesn't guarantee internal API stability anyway, does it?19:27
beunonot for now, no19:27
beunoI'm more concerned about changing things to the users19:27
Peng_Right. Users shouldn't care about the name of that method.19:29
Peng_(Which means *somebody* will, of course. :P )19:29
beunoheh, exactly19:31
Peng_Why are lines in NEWS only about 70 characters wide instead of 79?19:34
beunono idea19:34
beunocrazyness19:34
beunolike a lot of the rest of the code  :)19:34
Peng_Heh.19:35
Peng_beuno: On a different subject, mind if I make LoggerheadConfig a new-style class? Can I do it directly in the trunk without getting reviewed? :D19:36
beunoPeng_, Go for it.19:37
Peng_Thanks.19:37
beunothis is why you got access to trunk!  lower barrier to JFDI stuff19:37
Peng_beuno: Yeah, but I'm still afraid to do it. How much am I allowed to JFD? Trivial things like that? Simple bug fixes?19:38
beunoPeng_, in general, it's small bits that don't change anything drastically19:39
beunovery small bug fixes, doc changes, etc19:39
beunoreviews are a fantastic safety net, and as we get more tests, we may even get a PQM19:40
Peng_Oh, neat.19:40
beunoso we can ensure tests pass as well19:40
Peng_Well, I just did it. Pushing to LP is slow!19:41
Peng_(The LoggerheadConfig thing, I mean.)19:41
beunois it?19:42
beunoit seems amazingly fast for me with 1.1319:42
beunoI use a checkout to commit to trunk19:42
beunomerge in changes from the branch, and commit19:43
Peng_It was like 19 seconds vs. 4. Actually, I'm not sure why. They should both be new enough. Maybe it's just because LP is farther away from me.19:43
beunomaybe it autopacked?19:43
abentleyjam: ping19:46
beunoPeng_, I've added 'debug_flags = hpss' to my bazaar.conf19:46
Peng_beuno: It didn't autopack. bazaar.lp seems just plain slow ATM.19:46
beunoso you can always look at the logs when these things happen19:47
beunoPeng_, could be. mwhudson was working on something with ssh auth19:47
Peng_beuno: Seems slow over HTTP too.19:48
LarstiQPeng_: mail wrapping is usually 72 or 70 characters.19:48
Peng_LarstiQ: Ah, good point.19:48
Peng_beuno: Yeah, but it'll make .bzr.log *really* spammy.19:48
beunoPeng_, yes, also called useful  :)19:49
Peng_beuno: So, the diff for yui-cdn currently looks like this: http://paste.pocoo.org/show/111505/ bb:approve?19:49
Peng_beuno: But it won't be useful very often.19:49
beunoand it tells you how many hpss calls where made19:49
Peng_Hmm, I *do* like weird statistics.19:49
LarstiQ:)19:49
beunoPeng_, where is yui_url called from now?19:51
Peng_beuno: macros.pt.19:52
beunoaha19:52
beunoPeng_, bb:approve19:52
beunoor lp:approve (?)19:52
abentleybeuno: " review approve"19:53
Peng_abentley: That's longer. :P And "Bundly Buggy" sounds cool.19:53
Peng_Makes me want to chew bubble gum.19:54
Peng_beuno: Can I land it?19:54
abentleyPeng_: Thanks.  I like the name, though it makes less sense now that it's primarily tracking merge directives.19:54
Peng_abentley: True, but cool > sensible.19:55
Peng_beuno: wb?19:57
beuno_yeah, my ISP is sucking big time19:57
=== beuno_ is now known as beuno
Peng_< Peng_> beuno: Can I land it?19:57
beunoPeng_, yes!19:58
beuno15:52 < beuno> Peng_, bb:approve19:58
beuno15:52 < beuno> or lp:approve (?)19:58
beunobut of course, that got eaten by the internets blackhole19:58
Peng_beuno: It came through, but I wasn't sure if we should wait on mwhudson or something. (Sorry for the highlight, mwhudson.)19:59
beunoPeng_, I think our policy is just 1 review19:59
Peng_Okay.20:00
bpierrehi20:01
Peng_beuno: Pushed to my server in 6.57 seconds and LP in 33.05.20:02
Peng_Isn't there some weird performance issue with certain versions of certain things?20:02
beunoPeng_, you've downgraded to 1.13, right?20:03
Peng_beuno: Nope.20:03
Peng_beuno: I used http to work around the AbsentContentFactory issue the one time I hit it.20:04
beunoah20:04
beunowell, ~1.14 works amazingly well with 1.1320:04
beunoso maybe it's the ssh problem20:04
beunorockstar, abentley, any ideas  ^?20:04
bpierreI'm trying to use the new code in bzr.dev for EOL handling, and so far nothing work: I've created a 1.14 format branch, added some files, then put '[name *]' 'eol = crlf' in ~/.bazaar/rules, so if I branch the initial branch I should get windows like EOL, right?20:05
rockstarbeuno, mwhudson was saying something about a regression between 1.13 and older versions of bzr on the client.  That's all I know though.20:06
abentleybeuno: Sorry, no.  Others are investigating slow username lookups, which may be related.20:06
rockstarabentley, ah, I forgot about that.20:07
Peng_abentley: Slow username looks? What does that impact? Regular old push to bzr+ssh://bazaar.lp.net?20:08
Peng_s/looks/lookups/20:08
abentleyPeng: any sftp or ssh access to bazaar.lp.net20:08
Peng_abentley: Ah. That could do it, then, I guess.20:09
Peng_Thanks for the hand-holding. :)20:22
fbondCan I pull without updating the working tree?20:46
james_wnot from the UI I don't think20:48
rockstarabentley, hey20:57
abentleyrockstar: hey20:58
rockstarabentley, get_rev_id seems to be confused.20:58
abentleyrockstar: how so?20:58
rockstarSo I pass in the revno, and it throws a NoSuchRevision exception, even though I navigated from the history listing of the branch by clicking that revno.20:59
rockstarabentley, I'm sure it's because I'm confused, but the documentation looks pretty plain that I just pass in a revno.21:01
abentleyrockstar: Is it an integer revno, or does it have dots?21:01
bpierredid you pass a string or a integer? I recently got a problem with buildbot because of that (after upgrading bzr)21:01
rockstarabentley, in this case, it's an integer revno.21:04
rockstarabentley, I can take it all the way back to revno 1, and it says it doesn't exist.21:04
abentleyrockstar: It works for me.21:06
rockstarabentley, :(21:06
abentleyrockstar: https://pastebin.canonical.com/16055/21:07
rockstarabentley, I think I figured it out.  The revno was actually '322'21:07
jelmer'evening abentley, rockstar21:07
abentleyjelmer: Hi.21:07
rockstarHi jelmer21:07
jelmerabentley: Do you know what the expected behaviour of revno's is when there are ghosts in the lhs history?21:07
rockstarabentley, so it doesn't handle strings that can be converted to integers.21:07
rockstarabentley, does this mean I can't get the dotted revnos then?21:07
bpierreexactly my problem!21:07
abentleyrockstar: No, it doesn't.21:08
abentleyrockstar: That's UI-level functionality.21:08
abentleyrockstar: Branch doesn't fold, spindle or mutilate its input.21:08
jelmerabentley: simply count the first known revid as revno 1?21:08
rockstarabentley, that's a good contract, I just needed to figure it out.21:08
abentleyjelmer: No, it should work backwards from the current revid/revno21:09
rockstarabentley, so if I get a dotted revno, how would I get that revid?21:09
abentleyjelmer: Due to ghosts, the revids for some revnos may not be known.21:09
jelmerabentley: ah, that makes sense21:10
abentleyrockstar: Branch.get_revision_id_to_revno_map21:10
abentleyrockstar: That operation is much more expensive, and makes sense to cache.21:11
jelmerabentley: so in the case that we don't have a reference revno when the revno is unknown, what is the expected behaviour? revno=-1, revno=None or is that simply not possible yet?21:11
abentleyjelmer: I don't think that case is possible.  If we had to handle that case, I'd probably assign the ghost to revno 1.21:12
jelmerabentley: ok, that makes sense. thanks21:12
Necorowow ... I just noticed that loggerhead now has syntax highlighting :)21:48
Necorothanks to the author :)21:48
lifelessNecoro: :)21:53
lifelessmwhudson: was that you?21:53
mwhudsonlifeless: it was originally a patch from peter bui iirc22:06
mwhudsonPeng_ and i improved it a big22:06
mwhudson*bit22:11
thumpera big bit?22:13
BluehornHrm, when branching, what does this error message tell me: KnitPackRepository('file://...') is not compatible  with22:14
BluehornKnitPackRepository(...) different rich root support22:14
BluehornI am branching bzr-builddeb from launchpad into a directory created using bzr init-repo.22:14
BluehornWhat worries me is that the message basically tells me, $foo is incompatible with $foo (same values for $foo ;-))22:15
cody-somervilleUpgrade your repo22:16
Peng_Bluehorn: They're both KnitPackRepositories, but one has the "rich root" flag on and one doesn't. Yes, the message is rather unhelpful.22:17
Peng_Bluehorn: Do you have any other branches in your repo?22:18
Peng_Bluehorn: What format did you create it in? The default (pack-0.92)?22:18
BluehornPeng_: yep, default22:20
BluehornPeng_: just bzr init-repo bzr-builddeb22:20
BluehornPeng_: Just created a new repo, bzr init-repo --rich-root bzr-builddeb22:20
jelmerhmm22:21
jelmer1.15 is going to be awesome22:21
BluehornPeng_: But I have to admit that the different formats (suggested by bzr help upgrade) are a djungle.22:21
lifelessBluehorn: we are working to remove them all22:21
BluehornPeng_: I'll go and read bzr help formats22:21
Bluehornlifeless: but you will need backwards compatibility, no?22:21
lifelessBluehorn: yes, but that doesn't mean showing you everything under the sun22:22
Bluehornlifeless: :)22:22
beunolifeless, I see brisbane-core has landed?22:22
Bluehornnice. bzr branch tells me that my repository is deprecated and I should run bzr upgrade. bzr upgrade tells me: bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack1>.  Does not support rich root data.22:22
Bluehornso what is the latest and greatest format for rich root repositories?22:23
james_w--1.6-rich-root would be recent22:23
=== samurai_ is now known as samiam
james_w--1.9-rich-root  is the shiniest22:24
james_w--development6-rich-root will eat your pets but will be very shiny indeed soon22:24
lifelessBluehorn: --default-rich-root is what you should use if you need rich roots;22:24
beunohow's the performance between 1.6 and development6-rich-root?22:25
lifelessBluehorn: note that rich roots are a *one-way* upgrade,so only use them if you know you need to, and don't branch other projects into the same repo22:25
lifelessBluehorn: once we make rich roots the default this advice will go away :)22:25
Bluehornjames_w: just upgraded to 1.9-rr. thanks!22:26
=== samiam is now known as release
Peng_Of course, one of the major reasons rich roots aren't the default yet is *because* they're a one-way upgrade. Yay chickens and eggs.22:26
lifelessmmmm omelete22:27
Peng_Or some other metaphor or whatever.22:27
lifelessjelmer: ah I remember why I pung22:28
lifelessI wanted to ask if its cool and accurate to say 'samba4 uses subunit'22:29
jelmerlifeless: yeah22:30
jelmerlifeless: so far it's mainly the subunit *protocol* though, not yet the subunit project22:30
lifelessjelmer: same thing IMO :)22:31
jelmerlifeless: I actually hope we can ship with a subunit parser that can do formatting for the buildfarm22:31
lifelesswould be good22:32
lifelessyou know I'm very happy to add a perl/ module to upstream22:32
jelmerlifeless: and allow developers to use the subunit projects' fancy tools if they have them on their system elsewhere22:32
jelmerlifeless: I might contribute back our perl parser at some point, but I need to make it a bit less hackish first22:33
lifelessjelmer: why? [less hackish] - I'm not qualified to critique perl code beyond simple readability22:33
Peng_jelmer: Is it a good idea for bzr.dev users to switch to bzr-svn 0.6 now? Will it be really unstable for a while or anything?22:36
jelmerlifeless: in particular the API should be hashed out, don't want to break it on people22:39
jelmerPeng_: yeah, that should be fine. the main thing atm is that you won't have dpush yet22:40
lifelessjelmer: you could put it up with a note saying clearly 'unstable api'22:40
lifelessbetter an unstable api than none22:40
jelmerlifeless: or I could just fix it and then contribute it rather than contributing it now, then fixing it, then sending updates :-)22:40
lifelessjelmer: up to you22:43
lifelessjelmer: just encouraging release early release often, where it seems possible without great risk22:44
lifelessjelmer: from my perspective you'd basically own a perl/ subdir; commit directly to it if you want22:47
james_wstatik: ooh, thanks :-)22:56
lifelessjames_w: ?22:56
james_win response to a mail22:57
lifelessI'm naturally nosey22:57
lifelessOdd_Bloke: how does whoosh compare to bzr-search in terms of performance?23:15
Odd_Blokelifeless: I've never used bzr-search, so I don't really know.23:18
Odd_BlokeFor that matter, I haven't used Whoosh in any performance-critical manner.23:18
lifelessok23:18
vilapqm announces: bbc landed in 1.14 :-)23:25
lifelessthanks vila23:26
vilalifeless: thanks BasicOSX (who manages to *avoid* that annoucement :-)23:26
lifelessdid you incorporate peng's doc fix for it?23:26
vilaI don't think so,23:27
Peng_\o/23:27
vilabut I also think that the doc fix was making unclear that non rich root format can be imported23:28
BasicOSXwhen will the 1.13.2 stuff be ready :-)23:30
vilabut the fix is available for all (especially those mastering English :) to comment23:30
* vila goes to sleep now23:30
lifelessBasicOSX: jam and vila had issues with it yesterday, spiv and I will tackle it more today23:31
Peng_vila: Hmm, you have a point.23:31
BasicOSXwoah... poolie ! :-)23:31
pooliehello!23:32
BasicOSXAnymore stuff to squeeze into 1.14rc1?23:32
lifelessBasicOSX: no, I think the 1.13.2 fix can go into whatever 1.14 we're up to when its ready - don't block on it23:32
pooliei literally just logged in to a computer for the first time in 12 days23:32
poolieso i presume you're not asking me :)23:32
Peng_poolie: Well, if you can think of anything... :D23:33
BasicOSXpoolie:  not asking you ;-)23:33
BasicOSXPeng:  >8-(23:33
poolieoh typing feels weird :)23:33
pooliehello lifeless, peng23:33
Peng_Hi! :)23:34
Peng_BasicOSX: But if there weren't dozens of things being squeezed in at the last minute, wouldn't you feel underutilized? :)23:34
lifelesswelcome back poolie23:34
BasicOSXPeng:  ironically, that would be the truth :-)23:35
* BasicOSX cheers23:36
BasicOSXAll test pass now23:36
james_whey poolie23:43
pooliehello james_w23:45
BasicOSXshould I just close the bugs listed as closed in the NEWS but are still listed as open by tools/check-newsbugs.py ?23:47
poolieBasicOSX: probably not just close them, but check whether they ought to be closed23:48
poolieit's possible some were eg reopened later, or not totally fixed23:48
poolieare there many of them?23:48
BasicOSXok, I opened bug on it,  bug 35498423:49
ubottuLaunchpad bug 354984 in bzr "./tools/check-newsbugs.py NEWS found issues" [Undecided,New] https://launchpad.net/bugs/35498423:49
thumperabentley: are you still waiting on a review for your big nested tree branch?23:50

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!