=== medberry is now known as med_out [01:12] where can I read about the unit test case categorisation done in Bazaar? [01:12] I'm on a team that has noticed a rapid growth in unit test suite size, and are worried about the incentive against adding new tests because they might slow the test suite down [01:13] I recall Bazaar dealing with the issue by marking (decorating?) test cases to run the more resource-intensive ones less often. right? [01:15] is it part of ‘testtools’? we use that and like it [01:16] hi bignose [01:16] poolie: howdy [01:16] poolie: still looking for a new Bazaar developer? [01:17] I failed to use the recruiter's website (but can't remember the failure) [01:18] i am: http://bit.ly/ubuntu-vcs-job - though as the url suggests the remit is broader than just bzr [01:18] hm [01:19] if you hit it again please let me know what the failure was [01:19] or, perhaps forward it to someone else you know who could be interested [01:21] the app is not all that great but it's an improvement on ad hoc spreadsheets and email [01:23] bzr? Yeah, it works a lot better for my versioning needs than spreadsheets :-D [01:23] poolie: did you catch my question re. Bazaar's unit tests of about 15 mins ago? [01:23] nup, i had a late start [01:23] what was it? [01:23] I'm on a team that has noticed a rapid growth in unit test suite size, and are worried about the incentive against adding new tests because they might slow the test suite down [01:24] I recall Bazaar dealing with the issue by marking (decorating?) test cases to run the more resource-intensive ones less often. right? [01:24] wrong :) [01:24] we talked about that but we've never done it [01:24] okay. how does the Bazaar team deal with a large number of tests in the suite? [01:24] we have made a distinction between benchmarks and tests [01:24] we added selftest --parallel [01:24] run them less often? divide them into different categories somehow? suck it up and wait? [01:25] wow [01:25] that's a really kind of interesting question actually; perhaps i should write about it [01:25] heh. “I don't have a solution, but I admire the problem”? [01:25] developers can run only a subset of tests, and can reorder them to run the tests guessed most likely to fail first [01:25] we have a partial solution [01:26] we run the tests on every commit [01:26] and the commit fails if the test suite fails? [01:26] it takes single-digit minutes to run them all on my 1 year old laptop [01:26] in pqm, yes [01:26] right [01:26] oh, i should have said every mainline commit [01:26] you can commit locally without running them [01:26] ah okay [01:27] i think robert has a subunit hack to run tests remotely [01:27] --parallel=ec2 [01:27] its a bzr plugin [01:27] mm, also we just look at the times and occasionally look hard at the slowest tests or group of tests [01:28] lifeless, does it spin up new machines every time? [01:28] I don't think so [01:30] jml has some reporting tools that take a subunit stream and tell you test timing info [01:30] so the Bazaar solution involves the Patch Queue Manager robot being the only one authorised to commit to trunk [01:30] right? [01:31] well, it involves all tests run for things to get to trunk; separately we've made that hard to avoid by using a robot to do the landings [01:32] i was amused to see 'thelove' still cropping up in places [01:32] okay. so currently we allow commits to trunk by any developer, and a build robot reports failures [01:33] but that's after the commits. [01:33] in part this is because the test suite has over time gone from taking hours to run, down to twenty minutes, down to a few minutes. [01:34] now that it's feasible to run the tests without breaking development flow, we're loath to let it get out of hand again. [01:34] how did you accomplish that huge improvement? [01:35] for those who read my question, it seems nature of line-based merges [01:35] mostly by finding horrible inefficiencies [01:35] also by getting the database to run in memory [01:36] I always have to watch upstream changes so I can see an unusual change will be required in a merge [01:36] during the same periof the test suite has increased from a few hundred to nearly two thousand and still rising rapidly [01:37] so we don't want to see the suite become slower by the exact behaviour we're trying to encourage: add more test cases [01:37] just keep watching it, i suppose [01:38] for example upstream refactors some duplicated code into a function, and I have a new function which is using that exact duplicated code. It's not easy to realize you need to replace it with the function call during a merge, unless you have followed all commits since your last sync with upstream [01:38] oh, also try to add test suite infrastructure that makes it easy to write expressive tests the right, fast, way [01:38] RenatoSilva: yes merges need manual review and tests to be run [01:39] poolie: what is the right, fast, way? [01:39] well, for instance, it's easy for people to test from the ui all the way down across the entire stack [01:39] RenatoSilva: yes, it's deliberate that a merge requires manual action later to commit [01:39] this is one reason for merging as often as possible [01:39] but, this may be slow [01:40] it also may be imprecise compared to the kind of test you can write directly to an api [01:40] poolie: does Bazaar have non-unit tests automated? how are they done? [01:40] bignose: yes, I just thought it was just about the conflicts, but it's not! [01:41] poolie: we've recently had the “unit tests should be small and focussed and shouldn't require instantiating half the entire application” discussion [01:41] we have some whole-stack tests [01:41] some of these are old and crummy and would be a good target for people wanting to make the suite faster [01:41] bignose: you can get a no-conflicts yet broken merge, I didn't know that [01:41] poolie: using what to run them? the ‘unittest’ library doesn't fit very well [01:42] RenatoSilva: worse, you can get a fine merge that fails your automated tests [01:42] some are worthwhile integration tests [01:42] in some cases it's a tradeoff against a blackbox test being easier for a new developer to write [01:42] bignose, unittest just runs code.. [01:43] bignose: well, that's better not worse, no? you'll actually *notice* the merge is broken through these tests [01:43] RenatoSilva: so it's essential to (a) have good unit test coverage, (b) run all the tests every commit – including especially a merge commit. [01:43] we have wrappers to connect it to something that looks like a command line [01:43] http://doc.bazaar.canonical.com/developers/testing.html#shell-like-tests [01:44] RenatoSilva: heh. if your tests don't notice what you call a “broken merge”, then either you have code which is useless or you have insufficient code coverage of your tests :-) [01:44] bignose: I mean, it's good the tests fails, it's worse if you don't have them or they pass (*that* is silly) [01:44] poolie: thanks [01:45] bignose: or a bug with the tests [01:45] * fullermd has highly insufficient code coverage of his tests :p [01:46] bignose: LP has huge-time problems [01:46] bignose: actually I'm not sure how tests would detect the example I presented [01:46] bignose: and there is a social pressure to write less/bigger tests. [01:46] * bignose wants to investigate Pester for mutating code to find poorly-tested code branches [01:47] who tests the test tester [01:47] it's a pity it's Python-using-Java, I'd prefer a pure-Python implementation [01:48] bignose: I'm planning to solve this by more aggressive factoring out of stuff into separate packages, which would be tested independently, and provide a test contract back to the main / integration codebase [01:48] bignose: part of that is moving to a service based design as well: https://dev.launchpad.net/ArchitectureGuide/Services [01:50] bignose: I mean, the tests would be no help in that example! If upstream refactored duplicated code your branch is using in a function foo, the test for foo will still pass! [02:01] thanks all, poolie I've pointed our team to for ideas :-) [02:04] http://i.imgur.com/mvBLR.png [02:07] brb [02:17] poolie: I may have been mistaken about the recruiter's app failing me. either way, my application is now submitted. [02:18] good to hear === poolie changed the topic of #bzr to: current topic is: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jelmer === AuroraBorealis is now known as aurora|starcraft [07:50] hey [07:50] could somebody help robert_ancell to fix the lightdm vcs? [07:50] it's broken in a way similar to bug #772935 [07:50] Launchpad bug 772935 in Bazaar "ErrorFromSmartServer: Absent factory for StaticTuple" [High,Confirmed] https://launchpad.net/bugs/772935 [07:52] seb128: Does someone have an old branch? [07:52] The original that it was stacked on has apparently been deleted. [07:53] well, people have checkouts [07:53] not sure about "old" [07:53] Ah, no, the branch is there, I was just looking in the wrong place. [07:53] Let's see. [07:53] morning all [07:53] hi wgrant [08:02] seb128: You've not tried fetch-all-records? [08:02] seb128: I just grabbed the broken branch locally, and it works fine. [08:03] Once I've run fetch-all-records against robert_ancell's branch, that is. [08:03] what arguments do you use? [08:03] how do you fix the online version? [08:04] seb128: bzr fetch-all-records -d lp:lightdm lp:~robert-ancell/lightdm/trunk [08:04] I don't have privileges to do that, but anyone in lightdm-team can. [08:04] (you'll need to 'bzr branch lp:bzr-repodebug ~/.bazaar/plugins/' first) [08:05] Erm. [08:05] The branch is unbroken now? [08:05] how unbroken? [08:05] http://bazaar.launchpad.net/~lightdm-team/lightdm/trunk/files [08:06] Someone has fixed it. [08:06] Possibly someone pushed over it or something. [08:06] It was broken 10 minutes ago... [08:07] wgrant: it was just broken again? We 'fixed' it last week sometime [08:07] not a good sign... [08:07] _raise_smart_server_error [08:07] raise errors.ErrorFromSmartServer(error_tuple) [08:07] ErrorFromSmartServer: Error received from smart server: ('error', "Absent factory for StaticTuple('language.sgml-20100710032117-i0kdmrwf93qvp5j8-1', 'robert.ancell@gmail.com-20100710034239-8eysy1lpccerztec')") [08:07] wgrant, it's still broken for me [08:07] that looks ~ like the same failure, so maybe it wasn't actually changed before [08:08] should I ask robert to 'bzr fetch-all-records -d lp:lightdm lp:~robert-ancell/lightdm/trunk' [08:08] ? [08:08] Then why can LP scan it now :/ [08:08] And why can loggerhead see it... [08:08] Unless it depends on just what files are touched. [08:08] seb128: I think so. That looks right to me [08:08] seb128: You, or anyone else in ~lightdm-team. [08:08] jam: then what? what will that do? [08:08] wgrant: You probably can't scan it, because it is old history that is missing [08:08] jam: But the last scan worked. [08:09] what are the argument doing? [08:09] seb128: lp:lightdm used to be stacked on ~robert-ancell... [08:09] but then someone removed stacking, *without* filling in the history [08:09] how can that happen? [08:09] seb128: 'bzr fetch-all-records' fills in the history [08:09] Someone must have altered branch.conf manually. [08:09] seb128: I don't really know, but ".bzr/branch/branch.conf' has 'stacking_location = ""' [08:09] I don't think bzr would set it to an empty string [08:10] I imagine the original bug was a stacking cycle when they switched lp:lightdm from pointing at ~robert-ancell/... to ~lightdm-team/ [08:11] There wouldn't have been a cycle; the initial ~lightdm-team/ push would have stacked on ~robert-ancell/, then everything afterwards stacked on ~lightdm-team/. [08:11] jam, wgrant: that doesn't work it seems [08:11] robert_ancell: What goes wrong? [08:11] wgrant, I get "TooManyConcurrentRequests: The medium 'SmartSSHClientMedium(bzr+ssh://robert-ancell@bazaar.launchpad.net/)' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request. [08:11] " [08:11] jam: And I only know of one API that breaks on transitive stacking. [08:12] wgrant: if you look at ~robert-ancell, it says it is stacked on ~lightdm-team [08:12] !? [08:12] ah, I take that back [08:12] it is empty [08:12] http://bazaar.launchpad.net/~robert-ancell/lightdm/trunk/.bzr/branch/branch.conf [08:12] What evil is this... [08:12] It is supposed to be empty, so no problems there [08:13] Oh, I thought you meant it said it was stacked on ~lightdm-team on LP anyway. [08:13] Despite the empty branch.conf. [08:13] right, no, it is not stacked [08:13] robert_ancell: What if you try 'bzr fetch-all-records -d lp:lightdm http://bazaar.launchpad.net/~robert-ancell/lightdm/trunk'? [08:14] wgrant, running now [08:15] robert_ancell: it is possible that fetch-all-records is accidentally sharing a connection, and it is trying to read and write to the same connection [08:15] It's only ~600KB, so should be fairly fast. [08:15] wgrant, same error [08:15] Hrmph. [08:18] Indeed, reproducible. [08:18] hi jam [08:18] jam: Perhaps it would be best to reset stacking_location in branch.conf, and do a real unstack. [08:19] wgrant: sounds like something to try [08:19] I know I used hitchiker to bit-wise copy lp:lightdm and setting the stacking_location allowed me to branch from it [08:19] hi poolie, hope you're not working too late again :) [08:19] hi, no, i'm fine [08:20] jam: I grabbed it over sftp and tried a few things with it, yeah. [08:21] re [08:21] conference internet is not really reliable [08:21] robert_ancell is still getting issues with the new command, not sure his messages went through though === seb128_ is now known as seb128 [08:21] just back now [08:22] robert_ancell: With your favourite SFTP client (eg. nautilus), could you edit sftp://robert-ancell@bazaar.launchpad.net/~lightdm-team/lightdm/trunk/.bzr/branch/branch.conf, setting stacking_location to "~robert-ancell/lightdm/trunk" instead of ""? [08:22] last I heard was "wgrant: Hrmph." [08:22] 18:15:23 < wgrant> Hrmph. [08:22] 18:18:16 < wgrant> Indeed, reproducible. [08:24] It's unclear how it got set to "" in the first place, but we suspect someone changed it manually. [08:24] poolie: sometimes, facebook is a bit... odd. I just saw your politics post (via twitter), read it, went back to my page to "like" it, and it was now gone from my page. So I had to track it all the way back to your own page, etc. [08:24] the 'ethereal' nature of FB posts is good and bad [08:25] huh [08:25] i think you don't always get repeatable reads either [08:25] of the same page [08:25] I remember reading that they had tons of knobs to scale with load, which included reducing what is shown, etc. [08:26] so yeah, I tend to spawn pages that I want to read, and come back to them by closing tabs [08:26] which leads to lost state, I guess [08:26] wgrant, ok, modified [08:27] robert_ancell: I suck. Should be "/~robert-ancell/lightdm/trunk" [08:27] Forgot the leading /. [08:27] wgrant, ok, fixed [08:28] Yet apparently still broken... [08:28] Hrm. [08:31] jam: This is odd. It seems to not work on LP. [08:31] wgrant: I see "/+branch-id/..." eleswhere [08:31] jam: Perhaps the hpss does odd things. [08:31] Yeah, but both work. [08:31] +branch-id is only a few months old. [08:31] wgrant: I believe Launchpad's codehosting rewrites the stacked location to clients. [08:31] sure= [08:32] http://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/.bzr/branch/branch.conf [08:32] lp-hosted:///~... [08:32] ah, that is parent location [08:32] /+branch-id was rewritten for many branches [08:32] 7.242 hpss call: 'BzrDir.open_branchV3', '~robert-ancell/lightdm/trunk/' [08:32] 7.242 (to bzr+ssh://bazaar.launchpad.net/%2Bbranch/lightdm/) [08:32] 7.577 result: ('branch', 'Bazaar Branch Format 7 (needs bzr 1.6)\n') [08:33] well, you certainly need an opening '/~robert-ancell/...' === seb128_ is now known as seb128 [08:33] Hmm? [08:34] When branching lp:lightdm, it successfully opens lp:~robert-ancell/lightdm/trunk as the stacked-on branch. [08:34] Oooh. [08:34] I wonder. [08:34] Could we need to force LP to scan it? [08:35] It's possible it won't use the fallback unless the DB knows about it. [08:35] I forget exactly how this works. [08:40] wgrant: push --overwrite -r -2; push ? [08:41] jam: Probably easiest. [08:41] But I need to go and organise dinner. [08:43] wgrant: sure. if you're still here, what is failing, since branching seems to be succeeding [08:59] jam: Sure you didn't accidentally use a shared repo? [09:00] wgrant: I'm sure I wasn't locally [09:00] it was a plain recursive cp [09:00] It works fine locally, yes. [09:01] Hmm, broken over HTTP too. [09:02] $ bzr branch http://bazaar.launchpad.net/~lightdm-team/lightdm/trunk [09:02] bzr: ERROR: Revision {StaticTuple('language.sgml-20100710032117-i0kdmrwf93qvp5j8-1', 'robert.ancell@gmail.com-20100710034239-8eysy1lpccerztec')} not present in "". [09:03] Er. [09:03] stacked_on_location has reverted to "? [09:03] "" [09:03] hum, timeouted :-( [09:03] wgrant, jam: did you guys figure what is needed? [09:03] sorry we keep timeouting there so it's a bit hard to keep track of the discussion [09:04] seb128: THe change that robert_ancell made has apparently been reverted. [09:04] Which is slightly odd. [09:07] wgrant, oh, I reverted it so I could push some changes [09:08] Ahh. It prevented you from pushing changes? [09:09] What was the error? [09:09] That's rather unexpected. [09:09] wgrant, I wasn't sure, but I thought you'd gone to dinner so I put it back just in case [09:09] and then the network dropped out so I didn [09:09] 't get to push them anyway [09:10] Could you put the real path back and retry the push, if you haven't already pushed? [09:10] The current suspicion is that forcing Launchpad to rescan it (by pushing) will make everything see the correct path. [09:11] Then we can properly unstack it, and everything will be happy. [09:11] wgrant, set back to "/~robert-ancell/lightdm/trunk" [09:12] why are those issues happening in the first place? was there a user mistake there? [09:12] pushing changes... [09:12] seb128: It looks like someone may have tried to unstack the branch by editing branch.conf directly, but it's not entirely clear. [09:12] 9kb [09:12] ... [09:12] * robert_ancell smacks head on desk [09:13] 18kb... [09:14] We did do a mass-rewrite of stacked_on_locations on LP 2.5 months ago, but nothing since then. [09:15] So, HTTP now works fine. [09:16] bzr+ssh still does not, but that may be because the push isn't done yet. [09:17] 34kb [09:18] That's quite a connection you have there. [09:50] 'morning poolie :) [09:51] hi thar [09:51] i'm off to squash [09:52] squash something or other [09:52] have fun :) === Mkaysi_ is now known as Mkaysi [10:06] re [10:07] wgrant, ok, managed to push now. Branch still doesn't work, fetch-all-records has same error [10:08] robert_ancell: Indeed... over bzr+ssh it's still broken, but HTTP works. [10:08] I am in over my head here; I may leave you to jelmer and jam :) [10:09] ok [10:12] jam, jelmer: hey ;-) [10:29] ok, lunch time there [10:29] see you later [10:29] could somebody try to pick on that issue? [10:30] oneiric feature freeze is this week and having the lightdm vcs broken is blocking distro work [13:57] bzr branch ubuntu: should resolve binary packages, if it doesn't already [13:58] jml: It doesn't [13:59] apt: does though, but isn't always correct [14:00] why are there two ways? [14:01] jml: One looks at the Vcs-* field in the source package [14:01] jml: Which is the right thing to do in Debian [14:02] jelmer: ah === med_out is now known as medberry [15:24] hi jelmer. re: merge 70691, what's the UDD importer? also having trouble finding docs on "merge-upstream" ... [15:25] GRiD, "bzr merge-upstream" is a part of the bzr-builddeb plugin [15:25] ok [15:26] GRiD, basically, I'm wondering if the tree implementation should do the warning or the command-line layer that lies on top of that [15:27] jelmer, ok i got that much. if it lives in the command-line layer, does that mean the various other (non CLI) clients have to implement it as well? [15:27] GRiD, yes, but I'm not sure if they would want to implement it this way [15:27] GRiD, e.g.I imagine graphical frontends to simply interactively prompt you whether you are sure [15:28] jelmer, yeah that probably makes more sense. if it were done in the tree, how would these other clients handle it now, anyway? they capture warning output? [15:29] GRiD: it varies; I think qbzr captures and displays it, bzr-gtk simply ignores it [15:30] jelmer, hm. ignoring it would surely baffle users. [15:31] jelmer, i think you may be right then. this particular change is probably better off in the front end. [15:59] what happened to pqm ? 40% of the test suite in ~100 mins ? [16:01] yeah, something seems to be slowing it down [16:12] jelmer: is your XXX at the end of bzrdir.py still valid ? [16:12] vila: somewhat; there is probably still some code relying on it [16:13] vila: +1 on removing it for 2.5 though, fixing the fallout shouldn't be too bad === deryck is now known as deryck[lunch] [16:32] I often start working on something on my laptop by doing bzr init in a folder. Later I decide I want to backup that directory to a shell machine that has ssh. [16:32] What is the correct way of doing this? [16:32] bzr push sftp://... [16:33] does create a directory for me on the remote machine? [16:33] Or maybe bzr+ssh if that machine has bzr installed as well [16:33] vila: I guess we should also deprecate using some of the class methods on BzrDir, and instead encourage the use of ControlDir [16:33] push --create-prefix will [16:33] jelmer: /me nods [16:34] jelmer: I was mostly wondering if your later refactorings had already addressed the issue [16:35] thank you === medberry is now known as med_out [16:47] I have a repository in my home directory [16:47] it has to say there for legacy reasons [16:47] but I'd really like to make some local branches [16:48] my thought was that I'd do 'bzr branch . .upstream', then hack on some stuff, and still have a handy local copy of upstream to revert to / compare with [16:49] (not to mention pull into without merging) === beuno is now known as beuno-lunch [16:49] but the branch itself isn't a shared repo, apparently [16:49] is there a way to make a directory be _both_ a branch _and_ a shared repo? if there is, is that a terrible obscene thing to do that I will regret forever? [17:16] It's a bit weird, but not terrible afaik === deryck[lunch] is now known as deryck === beuno-lunch is now known as beuno [18:20] maxb: ... OK, so how do I do it? [18:43] I'm not sure there's an actual UUI [18:44] * UI [18:44] I tend to cheat and just run "touch .bzr/repository/shared-storage" [19:11] maxb: you do this regularly? :) [19:12] maxb: my concern is that 'bzr init-repo .' raises an exception [19:24] I have, in the past, used "rm -fr .bzr/branch && touch .bzr/repository/shared-storage" to destroy a branch and turn it into a shared repository keeping the old branch's revision data, into which I can then rebranch other related branches [19:24] bzr init-repo . does error, but I'm not sure there's any logic to it doing so [19:27] * jelmer waves [19:36] maxb: Hiya. What do you think the chances of hardy packages for bzr betas would be? [19:54] Okay nevermind, I guess I don't care about that. [20:09] So I'm trying bzr 2.4b5 [20:10] As far as I can tell, it is ignoring my already-initialized svn metadata cache [20:10] which means it takes about 4 hours to check out what I want to check out [20:11] are there known issues with bzr-svn and bzr 2.4b5? [20:13] exarkun: not in particular [20:13] exarkun, did you perhaps uninstall python-tdb since you last used bzr-svn? [20:13] nope [20:18] Can I provide some other information to help track down the problem? I have no idea what's going on. [20:20] according to python -vv, it found the tdb module [20:27] maxb: Hiya. What do you think the chances of hardy packages for bzr betas would be? [20:27] Zero. Given bzr 2.4 requires python 2.6, which hardy has not [20:33] exarkun, that might actually be the issue with your bzr-svn cache, too [20:34] What might be? [20:34] python-tdb is only built for a single python version, perhaps your bzr is now using a different python version. [20:34] according to python -vv, it found the tdb module [20:34] Also according to lsof, the tdb sos are in memory [20:35] hmm, no idea in that case - did it say anything about creating the cache directory? [20:35] /usr/lib/libtdb.so.1.2.9 and /usr/lib/pyshared/python2.7/tdb.so and /var/lib/buildbot/.cache/bazaar/svn/bbbe8e31-12d6-0310-92fd-ac37d47ddeeb/cache.tdb is also open [20:36] maybe the svn metadata cache is a red herring, I dunno [20:37] it's "copying revision 6141/8348" now [20:37] ~25 minutes in [20:38] I hoped sticking some extra --verbose flags onto the command would make it report something more interesting, but it seems not [20:38] nothing aside from the progress indicator on stdout, nothing interesting in .bzr.log [20:39] exarkun, ahh [20:39] exarkun, is it just copying more revisions that usually? [20:39] exarkun, because it might be unrelated to the cache [20:40] exarkun, in 2.4b5 bzr automatically fetches all revisions referenced by tags, even if they are not on the mainline [20:40] I don't know how many revisions it usually copies, but it usually completes the checkout in a handful of seconds instead of half an hour or more [20:41] I don't entirely understand how tags get mapped from svn to bzr. I suppose it could be that. [20:41] is it a one-time thing? after this completes it will have the extra revisions and not need to repeat this? [20:41] exarkun, yeah [20:41] exarkun, and there's a bug open about making this behaviour optional for 2.4.0 [20:43] 8348 seems like a lot of extra revisions to have been hiding under a tag. I don't suppose there's any way to learn what revisions it's copying? [20:45] On a tangent, why is copying revisions out of svn so slow? Would it be possible to pipeline requests? Or open multiple connections? Or is this just as fast as svn servers can go? [20:46] exarkun: svn servers aren't really made for fetching multiple revisions [20:46] there are some tricks we don't do yet, that will improve the performance, but it's not going to be significantly faster until the server side is improved. [20:47] eyeballing this progress meter, I'd say it's doing about 1 revision every 6 seconds [20:48] it was much faster than this at the beginning of the operation [20:48] is the svn server worse at serving newer revisions than at older revisions? [20:50] is there a command line parameter to make bzr run without progress bars and be noninteractive? [20:50] exarkun: it depends on the backend being used; for fsfs I think newer revisions are generally faster [20:51] This repo is fsfs [20:51] bzr help global-options don't show anything interesting and so does a google search for bzr noninteractive [20:52] santagada, I think there is an environment variable [20:52] jelmer: probably more than one... but I can't find any docs on this, surely someone is using bzr in semi-batch mode [20:52] done, real 39m31.917s [20:53] santagada: if you don't have a pty, it doesn't display those things [20:53] santagada, bzr help env-variables [20:54] santagada, looks like BZR_PROGRESS_BAR=none should help [20:54] jelmer: mine doesn't have this one [20:54] santagada, bzr's command-line commands are already noninteractive, with the exception of "bzr uncommit" [20:55] jelmer: So the reason the svn cache wasn't updated by that is that "copying revisions" goes from the svn server into the repository? And the cache probably already had all of those only-on-a-tag revisions? [20:55] exarkun: Are you sure it was updating the cache? It seems like it was just copying a lot of revisions. [20:55] exarkun: when it updates the cache it always updates the cache for the entire repository [20:55] jelmer: no, it didn't update the cache at all. [20:55] jelmer: BZR_PROGRESS_BAR is not on my help env-variables [20:56]