[00:01] DebbieWork: branch /proj/brA -> /proj/brAdev, hack on brAdev, comit (lather, rinse, repeat); then "push" brAdev->brA when ready [00:01] Good morning [00:02] for extra bonus points, brA can be "bound" to a remote branch, so when you push brAdev -> brA, it also pushes to the remote branch [00:04] TresEquis: Ok, that sounds the most straightforward. And do heavyweight chekouts @ remote locations? [00:06] GaryvdM: no, just delayed for silly reasons, should be out today [00:07] poolie: Ok - understand. [00:10] DebbieWork: the "bound" branch (/proj/brA) can be a checkout of the remote branch [00:12] making it "heavyweight", and inside a share repo, makes it possible to unbind if needed (e.g., while disconnected) [00:14] TresEquis: Sure thing. But @ my local box, that's remote to the source repo's origin, I'd *checkout* to my local machine, typically, right? [00:14] This sentence: Let's start by saying there is nothing you can do with a Checkout that you can't do with plain Branches. A Checkout just enables different defaults and workflow helpers. [00:14] has me trying to figure out the which/when bits ... [00:14] checkouts work by default like SVN / CVS [00:15] your commits get pushed to the remote server, and you have to be up-to-date to commit [00:15] you might check out the workflows doc: http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/bazaar_workflows.html [00:17] TresEquis: Yah, saw that. I can image using any/all of them :-/ I'm hoping to use what's typical in CivicSpace/Drupal land, so I can chat with them about stuff. Hoping emmajane will be able to share a comment/recommendation or two. [00:18] morning [00:18] TresEquis: @ #drupal I just learned that Drupal.org is "moving to git", but for my purposes, I don't think that matters at all. [00:20] TresEquis: it's not easy to run 'make html' in a given directory inside Explorer yet [00:20] TresEquis: Given your example, "then "push" brAdev->brA when ready" What would you typcally do, e.g., when it's time to publish to the web? publish brA directly? Or 'branch brA brAprod' and publish brAprod? [00:21] igc: I was looking to hack on the tools / commands stuff to make it easy. I just want to know where to start looking, rather than having to read the whole BE codebased [00:22] TresEquis: you can configure "local application" tools though so one option is to try writing a script that changes directory there before running 'make html' say [00:23] TresEquis: ah - ok [00:24] DebbieWork: remote server as the "canonical" / published branch and working dir; locally, I make a "heavyweight checkout" if it in my shared repo, then branch from the checkout for development [00:24] TresEquis: lib/extensions/tools.py is the core of the tool support [00:25] I can commit to the dev branch without touching the published side [00:25] TresEquis: see https://code.edge.launchpad.net/~simon-kersey/bzr-explorer/add-bzrexec-tool/+merge/22522 for a nice patch to improve things [00:25] when I "push" inside my dev branch, it updates the heavyweight checkout, which in turn pushes to the remote server [00:25] igc: thanks -- I didn't see code there to interpret command line, tc. [00:25] TresEquis: I'll hopefully review that patch today [00:27] TresEquis: hmm - why are you expecting to interpret the command line? [00:27] TresEquis: Bingo! That makes sense, and does what I think I want! And I didn't even have to make sens asking for it ;-) [00:28] hi igc [00:28] igc: I want to figure out how the %(foo)s expansions are done [00:28] e.g., to add new names if need be [00:29] for instance %(pool)s resolves to a file:///.... URL, which can't be passed to commands like 'cd' [00:30] TresEquis: see lib/app_suite.py [00:30] hi poolie [00:30] igc: thanks [00:31] Dinner-time! Thanks everybody! Helped a lot :-) [00:32] * GaryvdM -> bed. Bye all. [00:33] night all [01:03] After commiting changes in a checkout, what't the right way to delete the checked-out directory, if I don't want it around anymore? Just 'rm -rf' the dir? Do I need to do a 'bzr remove' or 'bzr remove-tree'? [01:04] bendj: just rm -rf [01:05] spiv No need to tell it's parent repo (if I've checked out into a shared repo for example ...) about the removal? [01:05] Oops, its. [01:05] bendj: nope [01:05] Great, thanks. Confusing keeping track of what's keeping track of what! [01:07] hello spiv [01:07] i'm going to start cutting 2.2b1 [01:12] poolie: yay [01:12] actually i really am [01:12] but it will help me concentrate if you can clear the new bugs [01:12] Ok [01:13] thanks [01:18] I've got a shared bzr repo containing multiple branches & checkouts. If I want to update to all the latest sources, I can certainly enter each branch/checkout and pull/update/whatever. Is there a *single* command that can update everything to the most current? [01:23] There's a multi-pull command in bzrtools. It's basically the moral equivalent of `find . -is-a-branch | xargs bzr pull` [01:25] fullermd: the /moral/ equivalent? [01:25] Well, immoral equivalent, maybe. [01:33] fullermd Got it. Took me a minute to figure out its an addition plugin ... Is that typically the approach used for "assembling" a project for final-publication ( a book, a website, whatever) from numerous, disparate sources? [01:34] Agh! it's [01:34] (always bass-ackwards!) [01:36] wow launchpadbugs (used by check-newsbugs) is strange [01:43] which is https://bugs.edge.launchpad.net/bzr/+bug/354985 [01:43] Ubuntu bug 354985 in bzr "check-newsbugs.py LaunchpadLoginError" [Low,Confirmed] [01:47] poolie: strange in what sense ? :-) [01:47] check-newsbugs should probably be ported over to launchpadlib now, it's more widely available [01:48] yes, it should be [01:49] just the object proxy abstraction in eg /usr/share/pyshared/launchpadbugs [01:49] for a moment i expected this had been ported to use the api [01:49] python-launchpad-bugs predates the API by quite a while. [01:49] mm [01:49] Any remaining users of it are wrong. [01:50] and was probably very useful before it existed [01:50] right, that bug says we should move away from it [01:50] Right. [01:50] i wonder if its ubuntu package description should be updated [01:50] It should probably be removed from Lucid. [01:50] Only two packages depend upon it, and they both also use launchpadlib. [01:51] And fixing that for five years isn't going to be fun. [01:51] k [01:51] bum de dum "please wait" [01:54] wgrant: but it would need upstream changes to detangle those packages? [01:54] poolie: Well, upstream for both is Ubuntu, but yes. [01:55] well, https://bugs.edge.launchpad.net/ubuntu/+source/python-launchpad-bugs/+bug/552953 if you want to say your piece [01:55] Ubuntu bug 552953 in python-launchpad-bugs "launchpadbugs should be deprecated or removed from launchpad" [Undecided,New] [01:55] title corrected [01:56] ubuntu-qa-tools should be easy to port -- it already mostly uses launchpadlib. bughelper will be harder, since it doesn't yet. But that might indicate that it's mostly abandoned. [02:10] jelmer, lifeless, it would be interesting, maybe next week, maybe in belgium, to look at making looms fit with jelmer's named branch work [02:17] poolie: yeah [02:28] igc: I was able to get my new command type added [02:28] just pushed the branch to LP and proposed a merge [02:29] TresEquis: cool. I'll take a look later today [02:29] thanks for the pointer [02:29] BTW, I couldn't figure out how to run the tests [02:29] TresEquis: no problem [02:29] how can I see the current revision number? [02:29] bzr revno [02:29] bzr log | head? is there an easier way? [02:30] ok, thanks [02:30] it might be good to have a HACKING file which tells how [02:30] TresEquis: Explorer don't really have any tests currently [02:30] ok, then I don't feel guilty for not adding any ;) [02:31] TresEquis: the current HACKING page is http://doc.bazaar.canonical.com/explorer/en/development.html [02:31] Heck, you added tons of 'em. At least doubled the previous total. Maybe tripled ;p [02:31] that page needs a "Running the Tests" link, once it is relevant ;) [02:32] yes :-) [02:45] * igc back in a few hours [02:50] lifeless, where does the python-testtools in the pqm chroot come from? the testtools ppa? [02:57] the sysadmin archive [03:00] oh of coursne [03:00] but as a custom backport from lucid or karmic? [03:09] no idea sorry [04:12] ping emmajane [04:13] DebbieWork, what's up? [04:14] emmajane: Hiya! Folks in here said I shoud ask you :-) Have a question about using bzr with CivicSpace/Drupal layout ... Can bzr do this: [04:14] (sec, typing ...) [04:14] DebbieWork, errr I'm not sure how useful I'll be. It's pretty late here. :) [04:17] can it, or should it? [04:17] emmajane: bzr init-repo ./TOP_DIR; cd ./TOP_DIR; brz branch DRUPAL_BZR_REPO ./myDrupal; cd ./myDrupal; bzr branch MY_FILES ./sites/mySite [04:17] What I'm trying to do , of course, is put together my drupal site tree from multiple branches, and manage it as one. [04:18] emmajane: Just looked up! Sorry, if it's late -- np! Another time. [04:18] I keep all sites as completely unique branches. [04:18] you mean the /sites folder, right? [04:19] emmajane: Yah, the /sites folder. How do you include them in the Drupal install tree, then? symlink? [04:19] i.e. I'm not sure what the advantage would be of merging www.example.com with www.foo.com. [04:19] just a sec [04:20] emmajane: Nah, I'm only talking about one site (for now). Just trying to understand how best to separate the branch pulls of drupal source and my files ... Seems like it should be two separate branches. [04:21] Don't know how to embed one branch UNDER another, since the /sites folder needs to be UNDER the drupa site install 'top' [04:21] DebbieWork, this is how I do it: http://www.flickr.com/photos/emmajane/4480852752/ [04:22] I remove /sites from the drupal folder and then symlink that back in [04:22] I don't version drupal core. [04:22] I let CVS take care of that for me. [04:22] when I'm hacking on core then I hvae that in a totally separate place from my live sites and I put core (but not sites) under version control. [04:23] http://horncologne.com/content/nice_server_setup_helps_streamline_upgrades that's sort of what I do. [04:23] (as far as the directory structure goes) [04:23] even sites I don't really put under version control though. Just themes. [04:24] (but I'm not a module developer) [04:24] i.e. I *only* version the stuff I will be editing. [04:25] emmaja Cool! Thanks for the reference, too! So when you CVS up your core, you've an ignore set for the symlink? [04:25] CVS ignores symlinks by default IIRC [04:25] CVS is stupid. :) [04:25] hello emmajane [04:25] rebooting, biab [04:25] DebbieWork, I also don't CVS up core. [04:26] I download a new version and adjust the symlink. [04:26] that's why there's drupal5.22 and random other older versions kicking around. [04:26] (also: yes, i ought to be shot for not upgrading my D6 installation) [04:27] emmajane: Hehe! Actually, I'm debating CivicSpace, or going with Pressflow (Just found that! Neat!) and rolling my own. Pressflow maintains in/with bzr, Iiuc. Same principle applies, I guess. [04:27] Although I'd like to follow the Pressflow repo. Thinking of some variation of http://xdeb.org/node/1249 [04:28] I don't have the capacity to follow links. :) [04:28] sorry. too tired. [04:30] emmajane: Np! You've been a help already :-) That link is ""Bazaar workflow for developing Drupal based web sites". Talks about multiple branching levels of Pressflow source, source+modules, source+modules+customizations etc. [04:30] if you're just deploying drupal you probably don't need to worry at that level. [04:32] poolie, hey :) [04:32] emmajane: I'm w worrier! :-) Lots of grey hair, doncha kno ;-) Anyway, I just got lost in all the options bzr presents. Really helpful to get your take on it. Seems that there are countless discussions about how to stage Drupal/CivicSpace/etc, but few best-practice recommendations. That I've found anyway. [04:33] emmajane: Hoping your book (which will arrive tomorrow, I hope :-D) will help with same on the themeing end of things! [04:33] Do you know the term "bike shedding"? ;) [04:34] I say: put the stuff you edit under version control and get on with life. :) [04:34] * emmajane is a minimalist though. [04:36] emmajane: "Bike shedding". Ha! My brother in law has a big one. Chock full of old motorcycles. But I get your point :-) [04:36] the point is arguing about what color to paint it ;-) [04:36] you can even do that after you already made a bikeshed, IRL ;-P [04:37] :) [04:37] What's to argue? Turquois, obviously. [04:39] Hm, since 'stupid' CVS nicely ignores symlinks, I'll presume that 'smarter' bzr doesn't. Does it follow symlinks and version-control the file under them, or simply version control the link itself? [04:39] bed time for me. [04:39] The link itself. [04:39] DebbieWork, g'luck with everything. :) [04:40] Thanks :-) [04:40] emmajane Nighty nite! [04:40] fullermd: Is there an option to follow the link? I've found requests in '08 for that capability, but haven't found a resolution yet. [04:41] Not AFAIK, no. That would get into all sorts of icky questions about what to do when it points outside of the branch, frex. [04:42] ok so i'm going to pull a bit more on lazy command loading [04:42] What a coincidence. I was going to go be lazy a bit more on pull command loading. [04:42] since that is paged in [04:42] fullermd: K, good point I suppose. Anyway, good to know. Thanks. [04:47] * Tak agree @ turquoise [05:13] wait a minute, someone just mentioned bikeshedding in a #haskell-unaffiliated channel? [05:13] * SamB_XP didn't realize that before ;-) [05:14] SamB_XP: http://haskell.bikeshed.com/ [05:15] bikeshedding predates haskell [05:38] lifeless: istm .testrepository should be ignored? [05:39] poolie: yep [06:09] back [06:20] hey igc [06:28] poolie: it might be good to announce 2.1.1 and 2.0.5 today [06:28] igc, yes, i think so [06:29] i think in general it would be good to announce the whole bundle of releases together [06:29] poolie: also, I'd like to find out why the website build script is failing [06:29] but in this case there is too much of a gap between them [06:29] I just tested it here and it worked fine for me [06:29] maybe it's a python2.4 thing [06:29] maybe [06:30] I guess we can guard against that field not being here and continue working [06:31] poolie: so, as discussed yesterday, a call now ? [06:32] give me a couple of minutes to file this rt [06:33] sure [06:41] igc: works [06:42] thanks [06:42] well, "doesn't crash" :) [06:42] :-) [06:43] poolie: hmm, the developer blog isn't rendering at all [06:43] poolie: so maybe it's a firewall thing accessing that location? [06:45] poolie: ring when you're ready [06:46] someone else called; ok [06:47] heh [06:49] igc, it says "fetching data from bazaarvcs....." [06:52] poolie: it's weird [07:16] hi all ! [07:37] hi vila! [08:09] wow http://xkcd.com/ today [08:11] whats your preferred comparison tool for the mac? I just discovered FIleMerge [08:18] lifeless: history navigation ftw ! (up and down arrows work :) [08:33] anyone here familiar with the bzr-email plugin? [08:40] jszakmeister: better ask your question anyway, familiar depends on the area your question is related to... [08:40] hello vila [08:40] hey poolie ! [08:40] hi poolie [08:41] I'm just trying to understand some of the documentation for bzr-email. In one section it says: [08:41] The URL of the branch is determined from the following checks (in order): [08:41] - If the configuration value 'post_commit_url' is set, it is used. [08:41] - If the configuration value 'public_branch' is set, it is used. [08:41] - The URL of the branch itself. [08:41] How does it determine the URL of the branch itself? [08:43] And I'm curious about why no emails get sent for push by default? [08:44] (I think I want to enable them, but I'd like to understand the philosophy behind it more before making that decision). :-) [08:45] And, I have one more: in the docs it says "if not supplied defaults to the email address reported [08:45] by ``bzr whoami``" but is that of the person doing the commit? Or is that the ``bzr whoami`` of the hosting provider? [08:46] (In my case, Apache) [08:48] on the last one, it would be whereever the plugin is actually running [08:48] isn't bzr-email normally client-side? [08:49] I dunno. :-) This is the first time I've ever looked at it. :-) [08:50] How do you ensure that an email always gets sent with a commit to a public branch then? [08:52] http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/hooks-plugins.html [08:53] Heh. Wonder how I missed that? I'll take a look at one of the other alternatives. :-) [08:55] poolie: jszakmeister bzr-email can be client or server side [08:56] I was just looking at that again, and getting ready to ask that question. :-) [08:56] no emails on push by default because if installed client side that results in emails on commit and then on push [08:56] Ah. [08:56] Makes sense. [08:56] on a server side install you want it set to send on push [08:58] How is this typically configured server-side? [08:58] Via the branch.conf or through locations.conf? [08:59] yes [09:00] ? [09:00] Is one preferred over the other? [09:00] not really [09:00] up to you [09:00] if one was preferred,t he docs would say so :) [09:01] Does the branch.conf follow the branch when cloned? [09:01] no [09:01] (or at least some of it's settings). [09:01] Okay. So I don't need to worry about things propagating unexpectedly. :-) [09:04] poolie: what branch did 2.2b1 come from? lp:bzr/2.2 is 6 weeks old [09:04] I think I need to look at that a little more. I'd like to avoid having an admin go and configure a branch every time a new one shows up (which kind of points to using locations.conf), but... [09:05] igc i'm confused why there would be a 2.2 branch [09:05] igc, also, my merge to 2.2 bounced because of a python2.4 issue, i think [09:05] then I don't want to have to edit the locations.conf by hand every time either. Screams for a script to help me. [09:05] poolie: not sure. I recall jam asking for one [09:07] poolie: also wrt the website, I think we should just revert index.html for now [09:07] and disable the build.py script from running [09:07] poolie: we an sort out the feed issue after you get back from leave [09:07] s/an/can/ [09:08] ok i'll do that now [09:15] jszakmeister: you could do locations.conf, though we don't supoprt bzr:// soft chroots all that well in there [09:15] johnf posted something about this a while back, I think [09:15] checkt he bzr-email bugs perhaps? [09:17] I'll take a look... [09:17] BTW, what does "soft chroots" mean? [09:17] inside bzr serve [09:17] we don't use the disk url for branches [09:18] we use a chroot:// url, which normal path traversal can't break out of [09:18] only code that explicitly unwraps it can - so it enforces configuration of writable/accessible roots [09:18] bbiab [09:23] And that's a problem because it may affect how the branch is looked up in locations.conf? [09:23] yes [09:23] I don't remember what johnf did to deal with this [09:24] Okay. I'll search around a bit... the initial searches haven't turned up anything though. [09:46] * igc dinner [10:26] hi all, does bzr allow giving access only to particular subtree of a repository, ala svn? I'm going to do a complete switch from svn to bzr, and I'm currently looking for the best fit [10:26] no [10:26] ok, thanks [10:26] you have to put every subtree into separate branch [10:27] Or put up with it and arrange your build system to cope with it [10:27] There are still advantages to atomically versioning co-dependant packages [10:28] both scmproj and bzr-externals has support of snapshots for achieving this goal [10:28] awilkins: not sure I understand... what I need is to give only a subset of my "whole thing" to some other developer [10:29] lelit: split your whole thing into components [10:29] lelit, Then that needs to be in a separate branch [10:29] then of course my "build system" (and deploy) take the whole thing into consideration [10:29] ok [10:29] and then assemble the whole thing in similar fashion as with svn:externals [10:29] ah [10:30] lelit: you may find bzr-externals plugin very useful for this [10:30] didn't know about bzr-externals (this will be my first serious use of bzr...) [10:30] there is also scmproj [10:30] but it seems people like bzr-externals more [10:30] ok, thank you [10:31] lelit: if you don't like to use command-line, then bzr-externals will be the best choice [10:33] another simple doubt: I'm a darcs guy, and am wondering about its interactive "commit" feature; I know about the shelves, but is there some kind of wrapper/plugin that simplify its usage? [10:33] bialix: that's not a problem for me [10:33] lelit: check interactive plugin [10:33] great [10:34] shelve has support of using external editor to edit hunks [10:34] I find this very cool === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell === nlisgo_ is now known as nlisgo [16:06] can I set submit branch for a branch on the command line? [16:07] jml, `bzr merge --remember` [16:07] or maybe push --remember [16:08] no, push branch is different from submit branch === Mantrid1 is now known as Mantrid [16:26] Hello, I'm trying to migrate a couple of HG branches to Bazaar, but I'm getting the following error: http://pastebin.com/A6CaLXfM [16:28] This is how I got there: http://pastebin.com/V5YAV4Yb [16:29] "cleanup" is a clone of "trunk", and it has ~100 revisions which haven't been merged into trunk === IslandUsurper is now known as IslandUsurperAFK [16:30] do you have shared repository there? [16:30] bialix: no, I set them up with "bzr init bzr-trunk" and "bzr init bzr-cleanup" [16:31] then execute following in the parent dir of bzr-trunk: bzr init-repo . [16:31] then: cd bzr-trunk; bzr reconfigure --use-shared [16:31] delete bzr-cleanup; bzr init bzr-cleanup [16:32] then try again last fast-import [16:32] bialix: will try that [16:32] bzr fast-import --import-marks=initial-trunk-raw-frontend.marks cleanup.fi bzr-cleanup/ [16:37] bialix: http://pastebin.com/7UTA5WtS [16:37] maybe i should start it all from scratch, using a shared repo? [16:37] mmm, you can [16:37] but it seems there is bug [16:38] yes [16:38] gustavonarea: can you try again with fresh shared repo, and don't create bzr-trunk / bzr-cleanup branches manually [16:38] jam: can you suggest something about this traceback? [16:39] bialix, gustavonarea: other than knowing that there is an open bug on bzr-fastexport wrt "_find_ancestors" I don't really have an answer [16:40] oops [16:40] bialix: you mean some thing like "bzr init-repo bzrrepos; cd bzrrepos; bzr init trunk; bzr init cleanup" ? [16:42] gustavonarea: without last two `bzr init xxx` [16:43] but as jam said there is open bug [16:43] bialix: ok, i'll try that [16:44] maybe you need to downgrade fastimport plugin [16:46] bialix: that wouldn't be a problem -- what version/revision should I use? [16:46] the one as in the Karmic [16:48] ok, i'll downgrade it [16:54] gustavonarea: ask in the bzr ML as well about fast-import issues. Author of fastimport is igc, he's in the AU timezone [16:54] bialix: good idea; thanks :) [16:59] * bialix disappears [16:59] gustavonarea: Have you considered using bzr-hg instead of bzr-fastimport? [17:00] Also, I know there's a bug in bzr-fastimport concerning marks export/import. I mean to try to fix it at some point. [17:01] maxb: not really, although there's no special reason, it's just that fast-import seems like the recommended method. I just want to convert all our Mercurial branches to Bazaar once and get rid of Mercurial. Is bzr-hg suitable for this? [17:03] I believe it is, though, I think it currently lacks support for importing mercurial tags properly. However, this should be trivially fixable afterwards even with a 10 line shell script, as the Bazaar revision-ids assigned are based on the hg hashes with a static prefix [17:04] So basically you'd just turn the .hgtags file into a series of 'bzr tag' commands using trivial text manipulation === salgado is now known as salgado-lunch [17:07] One bonus with bzr-hg is that there's no need to manipulate marks files, nor reprocess the common history for every branch [17:07] i wouldn't mind doing that if everything else works. Do you know of any pointers to start with? I couldn't find documentation in the branch, and http://wiki.bazaar.canonical.com/BzrForeignBranches/Mercurial and http://doc.bazaar.canonical.com/migration/en/foreign/bzr-on-hg-projects.html don't offer much information [17:07] And if you discover an extra hg branch later that was left behind, it will be easy to import [17:07] anyone know how to work around a pycurl cert error with bzr-svn .. ala http://gist.github.com/351996 [17:08] maxb: it seems like I can simply do "bzr branch my-hg-branch bzr-branch" -- am I right? [17:09] Yes, it really should be that simple :-) [17:09] maxb: whoa, I'll definitely give that a try then! Thank you [17:15] The tags should be fixable post-import with: cat .hgtags | while read sha tag; do bzr tag -r revid:hg-v1:$sha $tag; done [17:17] Anyone: Is 'bzr qlog' totally broken on Lucid at the moment? === deryck is now known as deryck[lunch] === salgado-lunch is now known as salgado [18:04] Investigating qbzr issue from bug #544928 with current bzr.dev, I find BZR_PLUGINS_AT doesn't work for me: within the plugin dir, running ``BZR_PLUGINS_AT="qbzr@$PWD" ../bzr.dev/bzr help'' prints usage instructions and "error: invalid command 'help'". Same for any other command. Did I miss something, or is this a bug in this great new feature? [18:04] Launchpad bug 544928 in qbzr "qlog fails with a special combination of PyQt4 and Qt" [Critical,Confirmed] https://launchpad.net/bugs/544928 [18:06] Is there any other way to override a per-site qbzr setup? === IslandUsurperAFK is now known as IslandUsurper [18:15] jam: hi [18:15] hazmat: hi [18:15] hi ctrlsoft [18:16] BZR_PLUGINS_AT? [18:16] hi jam, i was curious if you could send your loggerhead cache plans out to the bzr list [18:16] hazmat: can you work around that error by using svn+https:// [18:16] hazmat: pycurl doesn't support self-signed certificates afaik [18:17] morning [18:17] maxb: Yes, as documented in NEWS, from bug 82693. [18:17] Launchpad bug 82693 in bzr "want to run tests in a particular plugin without installing it" [Wishlist,Fix released] https://launchpad.net/bugs/82693 === deryck[lunch] is now known as deryck [18:19] hazmat: I can. I was hoping that *somebody* would give feedback before I send it to the primary list [18:21] ctrlsoft, cool, thanks that did the trick [18:39] jam: it looks like the inventory is the most significant slowdown in imports [18:39] jam: InventoryDirectory.children in particular [18:39] jam: is there anything I should/should not do? [18:41] ctrlsoft: 'most significant slowdown in imports'. Meaning when doing a conversion, the time spent seems to be in ID.children gathering [18:41] my guess... [18:41] any directory with > 200 children is going to page in all of the CHK pages [18:42] to get whatever subset it has [18:42] (one of the side effects of using 255-way hash mapping is that all children end up on random pages.) [18:42] Anyway, what are you doing with ID.children? [18:42] path2id checks? [18:42] id2path checks? [18:42] jam: comparing the children between the base inventory and the contents of a new tree in git [18:43] ctrlsoft: you don't get a delta from git? [18:43] jam: no, though I'm working on making dulwich produce a delta [18:43] by comparing the base tree and new tree in git rather than comparing the base inventory from bazaar and the new tree from git [18:44] that seems to have a *significant* impact [18:47] ID.children is known to be pretty bad in chk [18:48] as mentioned above [18:48] essentially, ID.children for a moderately sized directory will load the whole inventory [18:48] jam: right, which is pretty bad in this case :-) [18:49] I just changed the algorithm in bzr-git and now I can import 3k kernel revisions in 700 seconds [18:49] so, for bzr, the data is sorted by file_id [18:50] so you can generate the delta by file_id much faster than by directory [18:50] If you need to do it by dir, then it is going to probably be slow [18:50] Inventory.iter_changes(other_inv) should be pretty fast for CHK [18:51] except I don't yet have other_inv, that's what I'm trying to create :-) [18:51] ctrlsoft: you just have a tree? [18:51] yeah, so the data layout in git is by path, the data layout in bzr is by file_id [18:52] anyway, I'll try to eliminate more uses of ID.children - thanks for the hints [18:52] comparing the two is generally going to be O(tree) [18:52] so doing deltas in the same format whenever possible is a good idea :) [18:53] yeah, looks like it :-) === radoe_ is now known as radoe [19:24] jam: so it's faster to do path2id(path) than parent.children.get(name) ? [19:25] should be [19:25] but I'm not positive if we've actually improved it [19:25] it also depends [19:25] if we've already loaded children, then obviously the latter is faster [19:26] jam: but if I can avoid ID.children otherwise? [19:27]