[00:00] So operating directly allows you to use bzr:// instead of bzr+ssh:// ? [00:01] Correct? [00:01] TuxIce: yes, but the process runs as a specified user on the server [00:01] I see. [00:01] TuxIce: whereas with ssh it can run as the requester [00:02] Now, launchpad users obviously don't all have they're own physical account on the server, and by physical account I mean an /etc/passwd entry; How do you get around that? [00:02] Operating your ftp daemon to pull from a database? [00:02] TuxIce: sftp server written in python. :) [00:03] I see. [00:03] SSH keys are stored in a single account, w/ info about the "apparent" account passed to the bzr command [00:03] Oh man, so confusing. [00:03] I see. [00:03] or at least that is how I would set it up, having done that for CVS and SVN [00:03] awww heck,, what'd i do wrong here? This transport does not update the working tree of: bzr+ssh://me@hostname/path/to/push/repo [00:04] TresEquis: ssh keys stored in the database connected to the users [00:04] sure [00:04] NET||abuse: push doesn't update the remote working tree [00:04] NET||abuse: there is a plugin to do that somewhere [00:04] So really, every time you add a key in launchpad, its being added to one account on the lp server. When you branch/push, your essentially "proxying" (for lack of a better term, through this one account? [00:04] thumper, oh, ok, maybe i'm using the wrong repo type ont eh remote side then [00:05] And this one account allows sftp access, but not physical /bin/bash ssh access, correct? [00:05] TuxIce: yes [00:05] TuxIce: that's probably a reasonable metaphor [00:05] thumper, i was on remote, i did mkdir bzrrepo; cd bzrrepo; bzr init; then on my local i just pushed to that location.. it uploaded the first time.. will it not upload anymore? [00:05] I see [00:06] TuxIce: sort of like this: http://www.snailbook.com/faq/restricted-scp.auto.html [00:06] or do i have to create a different type of repo on the remote server? and pull from that server? [00:06] NET||abuse: I'm surprised that it did it the first time [00:06] thumper, well it did ;P [00:06] NET||abuse: you can either pull from the server [00:06] I see [00:06] NET||abuse: or add a plugin on the server [00:06] pull from server? but i want to push up to the server. [00:07] * thumper tries to remember the name [00:08] And then, when you connect to the lp servers using sftp, your ssh server essentially "rewrites" the URL [00:08] NET||abuse: http://doc.bazaar.canonical.com/plugins/en/push-and-update-plugin.html [00:08] i'd be happy to recreate a new repo, push the current server branch to there, then continue updateing from m ylocal copy to the new server repo, then wipe out the current server repo and branch at the same location as the just deleted old repo from the new server repo [00:08] AdamDV-iPod: yes [00:09] Makes sense now. So, would it be possible to get the code that does all this? [00:09] thumper, i did this before twice, and i didn't require any plugin, where i had a location i pushed to, that location was also active as a working tree, i would pull updates from the bzr pushes to that working tree on the server and those would be the live site files for my websites. [00:09] NET||abuse: pull updates the working tree, push doesn't [00:11] I'm assuming the user ssh key proxying is one piece of code, the rewriing and ssh server another? [00:11] yep [00:11] thumper, yeh i know, but the same location on the server, seemed to be both .. em .. would you call it a stub repository ? and the working tree, i would push from my laptop to the stub, in the same directory as the stub(.bzr directory) i would also update, this would populate the /path/to/dir/ with any pushed updates [00:12] I see. And this code is unattainable because non of the lp debs have seperated it into it's own project? [00:12] Err, debs [00:12] AdamDV-iPod: no, all this code is in the launchpad tree [00:12] lp:launchpad [00:12] It is? [00:12] yep [00:12] so on the server i had /path/to/repo/.bzr from the laptop, i would push to me@host/path/to/repo/ then on the server, i would cd /path/to/repo/ bzr branch; bzr update; bzr update; [00:12] Including the ssh server? [00:13] AdamDV-iPod: yep, all there [00:13] Hmmm, thAt's good then [00:13] thumper, that said, i dont' care if i have to create a new bzr repo taht is only for use as a repository, and not as a workign tree, and i bind the working tree that's now on the server to that location on the same host, and push to that location from my local laptop too. [00:13] Now, time to try and see if I can get a working copy of launchpad setup. [00:14] thumper, how do i set that up/ [00:14] ? [00:14] Thank you very much thumper :) [00:15] AdamDV-iPod: lib/lp/codehosting [00:16] That's the directory in the src where the code I'm referencing is? Or ..? [00:17] AdamDV-iPod: yep [00:17] and that's in the launchpad source that was open sourced a few years ago? [00:17] uh ha [00:17] Thanks :D [00:29] thumper: Launchpad builds on lucid, right? [00:30] AdamDV-iPod: it does, and we talk in #launchpad-dev === wgrant_ is now known as wgrant === AdamDV is now known as Guest44380 === Guest44380 is now known as AdamDV2 [01:51] james_w: still around? you register your commands in builddeb a bit strangely - bzr can't tell they are in a plugin as a result. [01:51] james_w: scratch that, grep broke me [01:53] hi davidstrauss [01:53] lifeless: hi [01:55] lifeless: what's up? [01:56] nothing particularly ;) just saying hai [01:56] :-) [01:56] sorry about the lag a couple of days back too [01:56] lifeless: it seems to be fixed now [01:56] yeah [01:57] should be [01:57] lifeless: you guys should look into the UEC for processing those heavy loads ;-) [01:57] hah [01:57] AIUI its database contention concerns that have us serialise everything [01:57] lifeless: I'd love to help you scale there. [01:57] lifeless: I do tons of work in the NoSQL space [01:58] davidstrauss: cool [01:58] davidstrauss: thumper: ^ is the team lead for launchpad-code. We've been having some conversations around e.g. cassandra internally [01:59] lifeless: launchpad should be easy to for things like branches [01:59] Right now we're not very good at doing controlled experiments though, so there is significant mgmt and technical concern that when we start doing nosql we choose The Right Tool [01:59] easy to shard, i meant [02:02] fairly, I'd say [02:29] So, to setup a bzr branch for checking out by fellow developers on my server, I would navigate to a directory do bzr init, add * and then commit, correct? [02:29] AdamDV2: just 'bzr init; bzr add; bzr commit -m "import"' [02:29] AdamDV2: you don't need to give paths to most bzr commands [02:30] I see, thanks [02:30] like 'ls', bzr knows that 'cwd is what you want' [02:44] Can bzr handle ftp:// ? [02:44] yes [02:44] Thanks [02:44] if you have a better protocol you should use it [02:45] I know, such as sftp or bzr or bzr+ssh [02:45] ftp servers are very limited and thus slow for hosting bzr branches on [02:45] How does the bzr:// protocol work? [02:45] Does it just work out of the box? [02:45] if you want to upload a website which you manage in bzr, ftp is fine - but use 'bzr upload' in the bzr-upload plugin instead. [02:45] I'm only using ftp to test. [02:45] I'm planning on using bzr:// [02:46] AdamDV2: bzr+ssh just works out of the box - install bzr on your server and you're good to go if you can ssh in. [02:46] HOw about just bzr:// ? [02:46] bzr:// is only really suitable for read-only access [02:46] I see. [02:46] it has no authentication or acl support [02:46] bzr+ssh or bzr+http can do authentication [02:46] Is there a plugin which handles bzr+mysql? [02:47] I'm not sure what that would do; I'm not aware of anything glueing the two together. mtaylor: may know. [02:47] Use mysql for user authentication? [02:47] mtaylor: Awake? [02:48] libpam-mysql might do what you want [02:48] Hmm [02:48] I'll have to fiddle with that [02:49] or any of the apache auth stuff for mysql [02:51] * AdamDV2 will look into [03:00] Gah. [03:00] I created a branch server side. [03:00] On my client I checked it out over sftp, changed it a bit, ran add, diff, then commit. [03:00] Then ran ls on the server, no difference. Whats wrong? [03:03] AdamDV2: does 'bzr log -l1' show your new revision? [03:04] On the server? [03:04] Yes, it does [03:05] dash: Any idea why the files aren't showing up? [04:37] Oh man, bzr is awesome [05:01] lifeless: good point on https://code.launchpad.net/~parthm/bzr/538868-message-for-heavy-checkout/+merge/24483 thanks for the review [05:02] lifeless: i am planning to fix the repo checkout message. will file a bug for the heuristics and branch part. [05:02] parthm: cool [05:03] lifeless: whats a good way to check if we are in a repository? [05:03] parthm: the underlying code does it [05:04] parthm: checking at the outer layer would be a mistake [05:05] lifeless: i am looking at bzrlib.branch.create_checkout and wondering where to put the test. 'if lightweight' is already present there. [05:05] is there something like is_repository or something? [05:06] parthm: deeper still [05:06] lifeless: ok. thanks .. will look. [05:06] parthm: create_branch_convenience will know; but pull is the one doing the fetching [05:07] parthm: [and this is perhaps why doing it as a heuristic in fetch is actually fundamentally easier] [05:08] * parthm is reading create_branch_convenience [05:10] AdamDV2: glad you're liking it [05:29] lifeless: this is what i have in mind http://pastebin.com/MB6F5UU0 . The change in inside bzrdir.determine_repository_policy. basic testing with branch and checkout (inside/outside repo) shows it works. [05:29] lifeless: does that look like a good approach. === AdamDV2 is now known as AdamDV|ZzZz [05:39] lifeless: nevermind. this shows the message for init also. need to look into it some more. thanks for the pointers. [05:41] no probs [05:54] -> city, finishing day on the train ;) [05:59] hi [05:59] anybody knows how to merge patches to lp:bzr/2.1? [05:59] GaryvdM was unable to merge there [06:00] vila: ? [06:30] Peculiar thing when going through polipo: Got a 200 response when asking for multiple ranges, does your server at 127.0.0.1:8080 support range requests? [06:46] twb: A range request should return only part of a file, if your server doesn't support it, performance will suffer, [06:46] twb: if bzr needs, say a few kbytes in a multi MB file, your server is returning the whole file anyway [06:46] Well, it's a proxy, and it definitely supports range requests [06:46] The server on the far side of the proxy is lp:dosage [06:47] twb: try using -Dhttp and look at .bzr.log you'll see what bzr is aksing and *receiving* [06:47] OK. [06:48] Of course, it would help if the problem was reliably reproducible :-/ [06:50] I can't reproduce it a second time, so I'll wander off until I can [06:57] Update: I couldn't reproduce the problem again with bzr, but a simple curl -r0-0,-1 shows that polipo doesn't handle *multiple* range requests. [06:57] (i.e. it groks Range: 0-0, but not Range: 0-0,-1.) [07:14] twb: bzr does a lot of multiple requests but... you can't read that unless you stay connected a bit longer... [07:24] vila: :-) [07:28] spm: yeah :) But a bit frustrating nevertheless :) [07:28] oh yes [07:34] my my my, babune is telling me a strange story, a doctest is failing in branchbuilder for hardy/jaunty/karmic but not for freebsd/gentoo, [07:35] digging a bit it seems it's not run on gentoo/freebsd and not on pqm either which is more of a concern [07:35] hmm, lifeless is gone ? [08:21] vila: hi [08:22] parthm: hey ! [08:22] vila: i was just going through the report. the changeset is https://code.launchpad.net/~parthm/bzr/549310-mandatory-whoami/+merge/24244 [08:23] yeah, so I guess the test pass if some env var is set, but which one ? [08:23] vila: i think the change that might have caused this is that setting whoami is now mandatory. but tests don't do this. so tests use 'EMAIL': 'jrandom@example.com' in tests.__init__.py [08:24] parthm: shouldn't we use EMAIL if it's set ? [08:24] vila: is possible to reproduce this on lucid? [08:25] vila: yes. EMAIL is being used. and hence the tests are passing. i am surprised that something failed. let me try this tests specifically. [08:25] parthm: the test pass on the lucid slave, weird, it's supposed to use the same setup as hardy/jaunty/karmic at least as far as env vars are concerned... [08:25] vila: is this doctests something outside of selftest? [08:26] parthm: no, you can run it with 'bzr selftest -s bzrlib.branchbuilder' [08:26] !paste [08:26] For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic. [08:27] parthm: failure on hardy: http://paste.ubuntu.com/428801/ [08:27] vila: interestingly the test is passing on my system. [08:27] parthm: I'm sure it is :) [08:28] parthm: that's why I mentioned a possible test isolation problem, if the env is correct (outside of bzr control) the test pass, if it's not, it fails [08:28] * parthm launches synaptic looking for python 2.5 [08:29] upgraded to lucid recently. "Package python2.5 has no available version, but exists in the database." :( [08:30] vila: could it be the python version? but it passed on pqm so i suppose 2.4 and 2.6 are ok. [08:30] parthm: gentto uses 2.6, I don't think python version is relevant here [08:30] well, my gentto slave use 2.6 (dunno what is available nor used generally on gentoo) [08:31] ha, looks like I have yet another source of typos there, hey, fingers, it's gentoo k? [08:32] parthm: what env vars are not used anymore with your patch ? [08:34] parthm: looks like config.username() docstring is not accurate anymore, it says: "If none is found, a reasonable default is (hopefully) created." but it seems it now raises NoWhoami instead [08:34] vila: the only change is setting EMAIL in tests/__init__.py .. _auto_user_id() is gone and replaced by errors.NoWhoami [08:34] parthm: oh, and I suspect the doctests ignores the EMAIL set by bzrlib.tests.__init__.py [08:35] Hi vila. [08:35] parthm: haaaa, setting EMAIL bingo :) [08:35] GaryvdM: Hi ! [08:35] GaryvdM, parthm: thanks so much for your work yesterday, the review queue looks so much cleaner ! [08:35] vila: re: https://code.edge.launchpad.net/~bialix/bzr/2.1-clean-tree-bzrdir/+merge/24669 [08:36] * parthm fixes config.username() docstring [08:36] GaryvdM: yes, bialix ping me earlier but quicly went after that, probably some auth setting missing on pqm, I'll submit that [08:36] vila: I don't have permision to push to bzr/2.1. Please could you submit [08:36] Thanks vila. [08:39] vila: for a moment there i though i had EMAIL set in my shell. but even without it the tests pass. hmm. [08:39] vila: any idea why the error is not reproducible? [08:40] GaryvdM: submitted [08:40] parthm: not yet, that's why I wanted to talk with you :D [08:41] parthm: so, on my karmic slave: ./bzr selftest -s bzrlib.branchbuilder.BranchBuilder fails, [08:41] but EMAIL=joe@example.com ./bzr selftest -s bzrlib.branchbuilder.BranchBuilder succeeds [08:43] vila: weird :) [08:44] vila: a simple fix could be just setting the EMAIL in the doctest but that still doesn't explain why its not reproducible [08:44] parthm: yup [08:44] parthm: a workaround one would be to set EMAIL in my slaves [08:45] parthm: but I don't see *where* EMAIL is taken into account [08:46] blah, stoopid under your nose: config.username() [08:46] vila: yes [08:47] should http://dpaste.com/191445/ be saying "running 0 tests..." at the top? [08:47] ensure_username docstring is wrong too (even if NoWhoami inherits from BzrCommandError, it's worth being more precise) [08:47] parthm: hehe, no patches welcome :) [08:47] parthm: kidding, don't spend too much time no this one [08:48] vila: not a problem. but this is very weird. [08:48] parthm: or file a bug with a 'papercut' tag [08:49] vila: i will attach the tag to the bug you filed along with the error log you put up. i will push the updated docstrings anyway. better to keep docs precise if possible [08:49] parthm: in retrospect, setting EMAIL *by default* is a bit weird [08:49] parthm: no, I meant the '0 tests' one [08:49] vila: ah :) [08:50] the doctest one is a real problem [08:50] ha, not real, both are reals, I meant more serious [08:50] we don't want reports that the test suite is now failing all over random places for no good reasons [08:51] vila: "setting EMAIL by default"? [08:51] vila: agreed. [08:51] parthm: in TestCase._cleanEnvironment() [08:51] except for doctests I'm pretty sure all our tests relies on this [08:52] vila: yes. i couldn't think of a better way. apart from each test doing a whoami or using a config file. any ideas? [08:52] parthm: that's why most of the vars are set to None [08:52] vila: i was reluctant to do that but wasn't sure there were other options. [08:53] parthm: let's try to barcktrack a bit, the goal here is to avoid people committing without a wrong whoami so they don't come back asking to fix old commits, [08:53] so your fix is fine [08:54] and since you added tests to check the behavior when the variable is explicitly unset, I think the tests are fine too [08:55] parthm: do you have EMAIL set ? [08:56] vila: i did have EMAIL in my zshrc but even after unsetting it tests pass. [08:57] parthm: meh [08:58] vila: does the test work for you locally? [08:58] parthm: hehe, what do you call 'locally' ? I have ~10 different configs to tests under :-) [08:58] (more problably 15, but I don't want to brag :) [08:59] vila: :D ... i just mean whatever system you are using currently. [08:59] * vila trying on karmic === AdamDV is now known as Guest31208 [09:00] vila: https://bugs.launchpad.net/bzr/+bug/576269 ... file it as tech-debt as there was no papercut tag. [09:00] Launchpad bug 576269 in bzr "verbose mode in selftest show "running 0 tests"" [Undecided,New] [09:00] vila: i am on lucid [09:00] vila, your windows bot seems to have been getting stuck before even getting as far as the first test of late [09:01] a212901390231901: shudder, yes, some weird setup bug, some network share not showing up when it should :-/ [09:02] a212901390231901: thanks for noticing ! [09:02] parthm: passing locally.... [09:03] * parthm wonders how to reproduce the error [09:03] vila: whats different about the env where the test is failing? [09:04] parthm: searching [09:04] heh, well done for filing that bug parth, I've been ignoring it for ages [09:05] a212901390231901: :) [09:06] what's the fallout from the nodefault whoami? I meant to review the change but didn't find the time. [09:06] * parthm starts reading bug #321320 [09:06] Launchpad bug 321320 in bzr "bzr's doctests are not isolated (branchbuilder doctests check global gpg configuration)" [High,Confirmed] https://launchpad.net/bugs/321320 [09:07] ah, got the the pastebin link in the log [09:07] I'll see if I get it here [09:08] parthm: found it, I'm sure you will appreciate the irony there: comment out your 'email' entry in .bazaar.conf [09:09] vila: hmm. weird http://dpaste.com/191454/ [09:10] * parthm checks if he has some other email set. [09:10] vila: yup. [09:10] passes here too. [09:10] pretty sure I don't have any email or config stuff in the test account [09:10] vila: reproduced it with EMAIL= and commented out email in bazaar.conf. phew! :) [09:11] a212901390231901: what does 'bzr whoami' says ? [09:11] say even [09:11] vila: thanks for finding this. [09:11] parthm: so, summary: people without whoami set will see a failure [09:11] I think it's a good thing in fact :) [09:12] vila: yes. :) [09:12] after all, your fix is about helping people falling into this trap, so... [09:12] vila: heh :) [09:12] parthm: thank you for helping me finding out a hole in my slave setups :-D [09:12] okay, nope, does fail indeed [09:13] vila: ooh :) ... yes. thats what this shows :) [09:14] vila: so the interesting question is what do we do about this. we could setup EMAIL for the doctest. or we could let this be as a failsafe. [09:14] vila: ideally doctests should use the same env as other tests as mentioned in bug #321320 that you linked to this report. [09:14] Launchpad bug 321320 in bzr "bzr's doctests are not isolated (branchbuilder doctests check global gpg configuration)" [High,Confirmed] https://launchpad.net/bugs/321320 [09:14] failsafe sounds ok, I still have to understand while the tests *succeeded* in some slaves [09:15] parthm: that sounds right (even if it will *remove* the failsafe here) [09:15] vila: if we keep these two setups separate eventually something else will be different and tests will behave weird. [09:16] vila: we can keep this as a tech-debt ticket. would you like to put a comment in or should i? [09:16] parthm: go ahead [09:17] parthm: you can also look at creating the papercut tag, I'm surprised you can't use it [09:23] vila: put papercut tag on the "running 0" bug [09:23] parthm: thanks [09:24] vila: thanks for your help with understanding the doctest issue. i have updated the bug with a comment. [10:34] vila: how much time should to take for a patch to pass tests on queue to status on lp changing to merged? [10:35] vila: https://code.launchpad.net/~parthm/bzr/181124-ls-short-opts/+merge/24414 passed tests quite some time back but hasn't shown up on trunk. [10:35] parthm: haha, a well known French humorist would tell you: precisely ? A certain amount of time [10:36] vila: :) ... would 'bzr pull' be more or less immediate? [10:36] immediate as in a few mintutes [10:36] oh,wait a minute, pqm sent a 'sucess' mail ? [10:37] vila: no mail yet. just that the tests passed quite some time back on pqm. the queue is empty now. [10:37] parthm: hmm [10:38] parthm: sounds like a failure somewhere to me [10:39] vila: yup. the success mails came out faster yesterday. maybe we are making pqm work too hard :) [10:39] vila: last commit on trunk is 14 hrs ago. [10:39] parthm: re-submit or run 'make check' locally (that's what pqm does IIRC) [10:40] vila: what does 'make check' do? [10:41] parthm: use the source Luke ! :-) It generate docs and run the full test suite with: $(PYTHON) -Werror -O ./bzr selftest --subunit $(tests) | tee selftest.log [10:42] vila: ah. i though it was something non-standard pertaining to pqm :) [10:42] vila: i will try to resubmit. [10:44] vila: i did a resubmit. http://pqm.bazaar-vcs.org/ ... lets see how that goes. thanks. [10:45] parthm: try to put (parthm) at the front for the next submissions, may people rely on that when scanning the commit messages :) [10:45] I want to file a bug about bzrlib.lsprof being weird code, but I might save it till next week when I can ask why it's like that. [10:45] vila: will do. i was wondering what the recommended practice was :) [10:46] parthm: putting (something) in front :) lifeless does it automatically in his hydrazine branch, but that's on hold currently [10:47] a212901390231901: jam is likely the best to answer that [10:47] a212901390231901: there are historical reasons which may need to be revisited [10:56] heya [10:59] parthm: oooh, he's gone :-/ [11:00] hey Alexander. [11:00] hey mister-with-very-long-nick! [11:00] :-) [11:00] :) [11:00] you don't have time today to do a test build the windows installer for me, do you? [11:01] a212901390231901: sorry, [11:01] have to finish urgent job and pack my bag [11:02] s'cool, can wait for next week. [11:02] but I will be ready to commit this next week [12:09] is there something happening on pqm ... i got a weird set of errors for https://code.launchpad.net/~parthm/bzr/181124-ls-short-opts/+merge/24414 [12:09] http://dpaste.com/191515/ the tests pass locally [12:11] meh, testtools tracebacks are so useless [12:11] I'll pull and try it here [12:15] hm, known failures under windows as they're old tests with bad locking [12:15] same basic result. [12:17] a212901390231901: thanks. i am running my tests again. this mp was submitted earlier this morning but pqm was silent. this was the second submit. [12:17] is -Werror catching you out? [12:17] not sure if any of the locking stuff will start pushing warnings, hard to see how the branch in question has made any change to that though [12:18] parthm: makes no sense to me either [12:18] a212901390231901: will try. i typically run only blackbox locally with selected tests from bt to avoid "new thread" errors. [12:19] * parthm needs more ram than 1GB [12:19] or -s bb.test_info -s bb.test_revert [12:21] a212901390231901, vila: no errors with -Werror for bb.test_[info|revert] [12:22] the patch is actually trivial ... short options. it should really be causing problems. [12:22] yeah, seems more likely to be something external [12:23] i will do a resubmit ... the 3rd :P [12:26] a212901390231901, vila: its in queue now. thanks for trying out the test guys. [12:28] heh, roundup is funny, "A problem was encountered processing your request. The tracker maintainers have been notified of the problem." = success, comment posted [12:32] hm, I think I'll give up on thinking of a smarter way to do this and just post the branch for review === mrevell is now known as mrevell-lunch === salgado-afk is now known as salgado [12:52] while trying to install loggerhead ./serve-branches is throwing an error like this: import bzrlib.foreign ImportError: No module named foreign [12:53] sangi: the version of bzr you're using is too old [13:06] Is there actually any point whatsoever to doing incremental packs *during* a 'bzr upgrade' ? [13:15] installing loggerhead throws an error like this : http://pastebin.com/ZDQp2Kea [13:15] bzr version is 2.0.3 [13:17] looks ok === jelmer is now known as Guest34328 [13:18] sangi: That's fine. [13:18] The bzr logging bit is a bug, but it's not a big deal... === Guest34328 is now known as ctrl === ctrl is now known as jelmer____ === mrevell-lunch is now known as mrevell === IslandUsurperAFK is now known as IslandUsurper [13:40] * luks hopes he won't get into trouble because of pushing to qbzr trunk after a long time of inactivity :) [13:41] hm, and loggerhead doesn't handle long lines in commit messages well [13:45] Hi luks [13:45] Luks: Np pushing to trunk.. [13:46] hey [13:53] luks: Are you still coming to UDS? [13:54] GaryvdM: no, I had to cancel :( [13:54] luks: :-( - I was looking foward to meeting you [13:56] me too... [13:56] I really wanted to go, but couldn't find anybody to take care of some things instead of me during that time [13:57] I see === radoe_ is now known as radoe [14:47] Why does tortoise-bzr keep throwing lock errors (seemingly for no reason) on using the pull command? [14:47] The identical command used at the cli then works [14:48] bad interaction with another shell extension [14:48] ? [14:52] cbz: what happens if you run bzr qpull? [14:53] That is what is having problems effectively. [14:53] Tortoise-bzr runs bzr qpull [14:53] Which occasionally complains about being unable to lock a file inside the .bzr directory [14:57] any reason why bzr-svn has to refetch all revprops on update... using bzr-svn against apache repo (shared project), means every update has to check/fetch against 1m total repo revs [14:58] i would have thought it could just iterate from where it last left off [15:04] its got a 3g cache file as well, so even after it fetches remote revsprops on every remote op (update, missing, merge) it still has to churn through its cache file for a few minutes [15:08] hazmat, it doesn't refetch all revprops as far as I know [15:08] hazmat, what version are you using? [15:08] jelmer_, bzr-svn 1.0 revno 3275 with bzr 2.0.2 [15:10] jelmer_, is it possible its just processing all the ones in cache, when it says its pull phase:discovering revprop revisions x/y ? [15:10] hazmat, What version of svn ? [15:10] 1.6.9 [15:12] jelmer_, i'm trying to use it against an apache repo http://svn.apache.org/repos/asf/hadoop/zookeeper/trunk the project only has 630 revs, but the repo has about 1m revs. [15:13] hazmat, it should only do that once and then just cache the results [15:15] jelmer_, does it display the discovering revpop revisions when it processing from cache? [15:15] * hazmat tries updating against bzr-svn 1.0 branch [15:17] hazmat: only for new revisions in the repo [15:18] hmm.. well its definitely processing from scratch on every remote cmd.. i'm gonna try updating to bzr-svn 1.0 latest on branch, and bzr 2.1, and see if it continues. [15:18] or at least processing every rev somehow.. its got a 2.7gb repo cache in ~/.bazaar/svn-cache [15:18] hazmat, I can't reproduce that with a current version of bzr-svn [15:19] hazmat, and launchpad doesn't appear to suffer from it either [15:29] hazmat, I think I have a copy of that repo also [15:29] awilkins, if you do an bzr pull on it, does process every repo rev? [15:33] Ack, I don't have the revision info cache on this machine [15:34] I do recall it doing quite a lot of looking through revision properties for certain operations but I've not really made any detailed study of it [15:35] It does have 941,754 revisions which is quite something [15:36] And I pulled my copy of it some time ago [15:36] so i made a new pristine bzr branch against the repo (existing rev cache), and updated and it works fine with (bzr 2.1, bzr-svn 1.0 (latest)) BUT only as long as the local branch doesn't have any commits, if it does then it tries to process every rev [15:36] jelmer_, ^ [15:37] Good afternoon chaps. [15:37] I'm back with bzr performance issues agin. [15:37] s/agin/again [15:40] Ever since I upgraded from ubuntu hardy/bzr 1.3.1 to ubuntu karmic and bzr 2.0.4 I've found bzr to be *really* slow when performing certain operations - status, diff, commiting. Branching and upgrading take an unthinkable amount of time (several hours, upgrades hang). [15:42] funkyweasel, across 1.3 and 2.0.4 Bazaar has moved to a new repository and branch format ; it sounds like your issues are mostly due to runtime on-the-fly conversions of the data. Not so sure about the upgrades (which should fix the problem). [15:42] The repo server is still on bzr 1.3.1, so I've tried upgrading local branches to pack-0.92. This gave a brief speed up back to old levels of performance, but has dropped back to dog-awful performance since. [15:44] awilkins: No conversion should be happening if I am using branches generated by 1.3.1 in 2.0.4 unless the newer version is sub-optimal for use with the older repo/branch format. [15:44]