[00:20] * ToyKeeper wonders if there is a way to make sftp://host/path resolve to host:path instead of host:/path [00:20] (so, a single slash after host would be relative to $HOME, and two slashes relative to root) [00:35] ToyKeeper: You can get that effect with sftp://~/ [00:35] i.e. sftp://host/~/ [00:36] Ah, I only tried that with bzr+ssh, which didn't work. [00:37] As sftp, it's fine. I wonder if the other host is just too old to support that syntax. [00:38] bzr+ssh doesn't support ~ yet [00:40] hello all [00:41] hi [00:42] I don't recall the last time I wanted to specify a repo path from root instead of ~ ... good to know it's not there yet. :) === BasicMac is now known as BasicOSX [00:59] Good morning. [00:59] good night [01:01] hello spiv [01:06] "bzr: ERROR: Transport error: Server refuses to fullfil the request" is a bzr error, correct? [01:06] (I'm just trying to do a sanity check on this script I'm writing) [01:08] awmcclain: yes [01:08] hello kiko [01:09] abentley: hi, how about a brief call? === LeoNerd is now known as LeoNerd_ [01:26] poolie: sure. [01:26] skype? [01:27] sure, it'll just take a few minutes to start that machine [01:36] hey poolie [01:37] poolie: Ok, I've sent that to PQM. [01:38] poolie: (James and Ian's Branch.set_last_revision_info hook) [01:41] spiv: do we both actually reading less than full records from streams at all? [01:41] spiv: I'm writing up the new streams api proposal in detail, and wondering whether to do the read() callable thing, or just slap bytes around [01:41] lifeless: I'm not sure. I remember doing some of the work to make that possible, I don't recall how far it got. [01:44] just saying 'here are the bytes' seems easier to me; once we have the interface in widespread use we could version it again. What do you think? === mw is now known as mw|out [01:45] I'm fine with what's easy. [01:46] ok [01:46] Hmm, there's a few fully-approved things lingering on BB. [01:47] I don't want to merge the inventory thing [01:47] aaron raised important concerns about it in London [01:47] that aren't addressed; for all that Ian has approved it. [01:47] (so its not been sitting there due to lazy robert; its deliberate) [01:47] lifeless: you also have " Fix the test HTTPServer to be isolated from chdir calls made while it is running" [01:48] that bounced with a spurious conflict I think [01:48] NEWS update or something. Be good to merge that. [01:48] abentley: btw, I sent a loom:Merge thing to the list yesterday; as the only other active loom dev would you like to approve/resubmit it? [01:49] (I don't actually see your inventory thing in the list) [01:49] sorry, http://bundlebuggy.aaronbentley.com/request/<1199746830.1954.76.camel@lifeless-64> [01:50] its resubmit [01:50] but doing the things it lists isn't enough, is what I meant [01:51] the problems are more conceptual than code [02:01] lifeless: well, I'm not too worried about the details of resubmit items, given the number of approved and conditionally approved items... [02:01] sure, my memory was glitchy [02:02] That's why we have BB :) === kiko is now known as kiko-zzz [02:06] ok [02:07] draft written, sending as MERGE hopeing for comments [02:35] Oh, I think I know a significant factor in the BB lockups-- the automatic merge detection seems to be triggering them. [02:36] ah [02:36] It's a fairly long process, possibly it can be sped up. [02:37] which reminds me [02:37] Or maybe I can reduce the period it takes out locks. [02:37] I really need to track down the slow index lookups bug [02:37] abentley: could you calculate the things you need to analyse, release lock, do the work, reacquire and insert results ? [02:37] That would be unspeakably awesome. [02:38] lifeless: Hard to say. The framework has hidden the fact that any locks are being acquired. [02:38] yes, they tend to do that. [02:38] I've become quite allergic to that behaviour as the years have gone by [02:39] In terms of the process, yes, I don't need to hit the database until I've calculated what's new. [02:42] about stacking: one case that worries me is when the owner of the stacked-on branch doesn't realize that it's stacked-on. [02:42] And deletes it, thinking it won't break anyone else. [02:42] right [02:43] Even though the person who stacked on it made an explicit choice. [02:43] This is why I punted on auto stacking initially, because then users are always explicitly accepting that risk. Obviously thats not viable for Just Works long term though. [02:43] But I don't see any good way of telling people [02:44] So you're okay with it, if the user explicitly chose to stack? [02:45] I don't see a way out [02:45] I have minor nightmares about what happened in arch [02:45] Make it a social problem? [02:45] It's rude to stack on someone who hasn't invited it? [02:45] yeah [02:46] bundles are a good example of a form of stacking that works quite well [02:46] Right. [02:46] I think it would be ok for me to branch from you, but stack on bzr.dev. For instance. [02:47] by ok, I mean 'pretty safe' [02:47] The policy stuff I'm working on would allow me to *recommend* that if you upload stuff to my site, you should stack on my copy of bzr.dev. [02:47] thats nice [02:47] I'm leaving out auto-stacking on the local host. [02:48] Unless the user configures it. [02:48] But no local stacking by default, since it proved controversial. [02:50] So I think we don't need a way for branches to declare that they can't be stacked on. Which means we don't need a new format for stacked-on branches. [02:50] abentley: yup. [02:50] (beyond it working of course :P) [02:53] Speaking of formats that don't work, if you decide supporting weaves is too painful, I'm definitely amenable to ditching them at this point. [02:53] have a read of the doc [02:53] I think it will be easy to work with [02:53] and not leak abstractions everywhere [03:00] One thing I notice is that you provide a way to ensure that the stream can reconstruct a fulltext. [03:01] the thing for inventories do you mean? [03:01] Yes, for inventories. Bundles don't do that-- they get the compression parent fulltext from the target repo, convert it to the right format, and apply the delta to it. [03:02] generally these streams will do the same. there is a case where that does not work though for fetch [03:02] if you look at the model1To2Helper [03:02] instead of copying inventories it does iter_rev_trees [03:02] tweaks the content, and serialises [03:04] Did you have more to say? [03:06] oh sorry; email distraction. damn thing. [03:07] so a line delta of an xml6 inventory is not safe to apply to an xml7 inventory, etc. [03:07] thats why the inventory option exists, because one needs to be able to construct the inventories to do iter_rev_trees in the model changing helper [03:08] But an xml7 inventory can be converted into an xml6 inventory. [03:08] And the delta can be applied to that. [03:08] so read in the inventory, parse, downgrade, serialise, then apply the delta [03:08] ? [03:09] Right. [03:09] You can do it however you want. Just thought I'd mention the option. [03:09] as long as we have deterministic serialisers that will work, but it feels like there is an element of risk we can avoid [03:10] If you don't have a strong opinion I'd rather avoid having to have the text storage layer adapt back through the parsed data like that [03:12] Sure. It looks fine to me. [03:13] (Aside from the fact that it doesn't fix bug #2:-) [03:13] *blink* [03:14] BB thinks you promised that this patch would fix bug #2. Perhaps the bug regex is too forgiving. [03:14] ah [03:15] I went to https://bugs.edge.launchpad.net/bzr/+bug/2 [03:21] lifeless, just for the record, I feel bad my command not found code ended up getting into the core with both you and abentley being against it :( [03:21] s/bad/not satisfied [03:22] so I'm open to go a different direction, if we can find one that makes everyone happier :) [03:23] beuno: that was a confusing message - not that my vote was 'approve' [03:23] *note* [03:23] beuno: The core code without a included database I am entirely happy with. [03:25] lifeless, yes, I saw the approve, I was referring to both of you being against it, even though I split it into two, so we could discuss the remaining part separately [03:25] beuno: If I felt strongly, I'd have vetoed. I just don't like the feature very much. [03:26] So changing approach wouldn't help. [03:26] But please don't take it personally. [03:26] beuno: thats why I'm saying my comment was confusing. The core I'm happy with. The remaining part I'm not. [03:26] and as abentley sayss, if we felt stringly we can veto [03:26] alright, feel less bad about it being piped through with "because poolie said so" :p [03:26] I wrote that two days ago [03:27] and thought it included the database at the time I wrote it [03:27] then I realised it didn't, but didn't clear the comment field when I changed the vote to approve. [03:27] lifeless, here for your confusion. [03:27] aaah, right, ok ok [03:28] I can continue the remaining steps as a plugin and try and find consensus along the way [03:38] ah, I can't reject my own stuff on BB [03:55] beuno: huh, that's odd. Oh, because you don't have voting rights on BB in general? [03:57] spiv, yup yup [03:57] but I though I could reject my own stuff [04:05] jelmer, BB still hates me :) my patches get approved automatically (one vote), but I can't vote on other patches [04:05] hmm, this isn't quite right [04:06] the delta closure stuff fits the api, but the api doesn't make it clear how to serialise [04:06] shrug; I think it will be more clear in the wash. [04:08] actually, no - the key thing is that we're going to want to be able to ask for a full text [04:08] * lifeless goes back to api design for a bit [04:13] spiv: reading your #213425 fix [04:18] poolie: ah cool. I'm just heading off for lunch [04:58] lifeless: I didn't realize 'till now that was a stale message. I'll look, but I very much doubt BB caused the delay. [05:15] Hmm, the set_last_revision_info hook failed to merge. [05:15] What the recommended CVS to Bazaar path (HEAD, branches and tags)? I know the cvs2svn does 'the right thing' as I've been through that process... Is the task of getting subvsersion changesets into bazaar straightforward? svn2bzr from a subversion dump dies on even the most trivial dumps I've tried. [05:16] there are versions of svn2bzr around that work, i don't know the details though [05:16] there is also cvsps-import, don't know if that does branches/tags though [05:16] spiv: that Subversion import is _still_ running. Seems to be going a bit faster, though [I have the shell script loop printing the date each cycle of 100 revisions]. [05:17] cvs2svn is amazingly good at ironing out those CVS inconsistencies. [05:17] It almost seems to imply that accessing newer revisions in an upstream Subversion repo is faster than older ones. {shrug}. It is such a travesty that the pain inflicted by this reflects poorly on Bazaar. [05:18] Talden: there is also bzr-svn of course [05:18] Talden: you're probably better off to go from CVS to Bazaar direct. The less intermediaries the better. [05:18] I had a look at there were mentions of svn 1.5 and patching python bindings... I'd rather not have to learn all about python to use the tool. [05:19] jamesh: your set_last_revision_info branch is failing: http://rafb.net/p/p2S39x21.html [05:19] jamesh: I'm looking into it now [05:19] the cvs2svn tool is adding git conversion, hopefully bazaar shouldn't be any harder. [05:21] It will be interesting to see what happens with repo size... CVS 2.1GB -> Subversion 1.6GB... hopefully Bazaars is a little tighter. If it's not we'll probably be forced to say bye-bye to a lot of the history to make it more manageable. [05:36] spiv: hmm. I wonder if the conversion code should use _write_last_revision_info()? [05:37] jamesh: yeah, I was just starting to think the same thing [05:37] jamesh: after all, we don't really want the hook to fire in this case anyway [05:38] spiv: and we don't quite have a valid branch at that point either. [05:38] Right. [05:38] So giving that branch object to a hook would definitely be a bad idea. [05:39] Using _write_last_revision_info fixes the test. I'll run the full suite and if it passes, I'll resubmit. [05:39] I suspect this is the only problem. [05:39] well, it might be a valid branch by the time the hook is called if it didn't throw an exception earlier :) [05:39] Heh :) [05:39] actually, it hasn't even written the branch/format at that stage [05:40] Right, so giving a branch 6 object that's pointing to a branch 5 on disk is asking for trouble. [05:40] Besides, the last_revision_info isn't being changed, so firing the hook is definitely the wrong thing to do. [05:52] jamesh: tests all pass locally, I'll resend to PQM with that one-line change. [05:52] spiv: thanks [06:31] spiv: paramiko fix looks good [06:31] i'm going to start doing 1.4 now [06:44] Okay, Bundle Buggy should never drop mail now. [06:45] Even if hung when the mail comes in (it will just build up until processed). [06:49] abentley: nice! [06:49] do you know why it dies occasionally yet? [07:02] is it just me or do we get a lot of lock warnings from the tests now? [07:05] thats what prompted me to do my patch [07:05] is it still awaiting review? [07:07] We do get a lot of warnings, yeah. [07:09] it looks like there were a lot more than before [07:14] abentley: it was in my browsers POST cache [07:15] abentley: I hit retry and it went in; I erroneously blamed BB for the queing [07:46] hi folks [07:47] can someone look what going wrong here: http://paste.ubuntu-nl.org/62805/? is this a known bug, or did I manage to fuck up my branch on launchpad? [07:48] UserWarning: file group LockableFiles() was not explicitly unlocked [08:01] New bug: #215522 in bzr "bazaar internal error on FTP push" [Undecided,New] https://launchpad.net/bugs/215522 [08:01] siretart: hi [08:02] hi poolie [08:03] i'll check it out [08:03] I'm trying to imort that into a an rich-pack-root shared repository, using bzr 1.3 [08:04] seems to be related to that, becuase local branching does work, though [08:06] ah ok [08:06] this rings a bell [08:06] siretart: i think abentley will be around in a few hours and i think he is working on a bug related to this [08:06] sorry but i really need to finish up and leave here [08:07] if you search lp for "revision not present" you may find the bug [08:15] siretart: in your local repo would you please run [08:15] cat .bzr/repository/format [08:19] poolie: Bazaar pack repository format 1 (needs bzr 0.92) [08:19] ok [08:19] https://bugs.edge.launchpad.net/bzr/+bug/215533 [08:19] Launchpad bug 215533 in bzr "Revision not present error pulling from knit to rich-pack-root repository" [Undecided,New] [08:21] poolie: wow. Thanks for filing the bug. Subscribing myself now [08:22] i suggest you should either upgrade the branch on launchpad [08:22] or upgrade locally and push up [08:22] assuming you are able to write to this branch [08:22] you should just make sure you have a backup first to be sure [08:22] :) [08:23] sorry for the interruption [08:23] when it's upgraded it should be much faster though [08:23] with 'pushing up', you mean rsyncing it over sftp? (does rsync support sftp at all?) [08:25] over sftp or bzr+ssh [08:25] New bug: #215533 in bzr "Revision not present error pulling from knit to rich-pack-root repository" [Undecided,New] https://launchpad.net/bugs/215533 [08:25] oh obviously you can write to it [08:56] ppas building now... === poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org/ | bzr 1.4rc1 up for testing now [09:08] good night === mwhudson_ is now known as mwhudson [09:23] poolie: hooray! [09:31] Still importing... === mwhudson_ is now known as mwhudson [09:37] Hm. Here's a stupid question. Anyone know if you can get an svn "dump" of a subversion repository with other than local filesystem access to it? Its gotta be faster to rsync that blob down locally and then pull revisions out of it directly. 9 minutes per 100 revisions is crazy. [09:38] svnsync [09:39] i doubt it's very fast though [09:51] Whoof. Bug report, I think: If bzr-svn is in the middle of a pull, and you try and branch from that repository, bzr breaks complaining index file blah .iix not found. Shouldn't the otherwise accursed locks be preventing this? === mtaylor is now known as mtaylor|away [10:23] hi, why does .bzr/branch/branch.conf have push_location but parent_location instead of pull_location? [10:40] hi [10:41] any idea on how to tunnel a bzr+ssh on windows? (windows->gateway->ssh-server) [12:06] Hm. I now have a pack that is 177.9 MB big === thekorn_ is now known as thekorn === mrevell is now known as mrevell-luncheon === mrevell-luncheon is now known as mrevell [13:50] hi, is it possible to do a partial push? like, i commit A and B, but I only want to push B. [13:52] clarby: are A and B two files or two revisions? [13:53] andrea-bs: ah, sorry, they are files (directories) [13:54] clarby: you can revert the changes made to A, push and recommit A [13:55] ah, too much hassle .. I can just finish what I'm not done with yet and push it all [14:05] New bug: #215674 in bzr-gtk "uncommit needs an option for saving commit messages" [Undecided,New] https://launchpad.net/bugs/215674 [14:07] New bug: #130372 in bzr-svn "Abandon branching schemes" [Medium,Triaged] https://launchpad.net/bugs/130372 === mw|out is now known as mw === mtaylor is now known as mtaylor|to-home [16:06] New bug: #215732 in bzr "bzr-buildpackage --native had an internal error" [Undecided,New] https://launchpad.net/bugs/215732 [16:08] Ok, I just had a massive all-nighter hackathon on my current horrible++ project (involving bzr). Someone give me something to do for the next 20 minutes that isn't hacking horrible Java code :-) [16:09] haha [16:09] THen I can POETS [16:19] is there a bzr-svn to go with bzr 1.4? [16:20] jelmer: ping [16:28] mw-home: no, according to jelmer in the mailing list [16:28] dato: ouch! I need to rollback to bzr 1.3 then. [17:24] mw-home: it's not 1.4 that's out yet btw, it's just the rc [17:34] <_MMA_> I don't know if this is a Launchpad or Bazaar question. Is there a way to keep specific files synced between branches? [17:35] Hi, are there any web based frontends for bzr similar to what is used on http://git.kernel.org ? [17:35] basically just a list of project / description / owner / last change [17:35] <_MMA_> "Automatically" synced that is. [17:39] jdahlin, so you don't consider bzr-webserve or loggerhead to be similiar? [17:40] :) [17:40] johnny: can I get such a view from them? [17:40] similiar is a very broad term for web viewers :) [17:40] oh, no, not similar enough! [17:40] you'd have to customize the code [17:40] patches are accepted i'm sure tho [17:41] eg, I have to do it myself! [17:41] what do you find lacking? [17:41] well some things are prolly more on the upstream developer todo than others [17:41] a "list of project / description / owner / last change" and being able to track on a per user basis [17:41] track on per user i'm sure is coming [17:42] sorry.. i'm not sure of the details 100% [17:42] i'm doing the same thing you are prolly :) [17:50] jdahlin: I think webserve has such a thing, but I'm nto entirely sure [18:08] New bug: #215797 in bzr "regression in annotate on mysql tree" [Undecided,New] https://launchpad.net/bugs/215797 [18:35] don't suppose there are gutsy packages for latest bzr-svn (0.4.9) and bzr 1.3.1 floating around? [18:36] <_MMA_> rocky: They might have been backported. [18:36] ppa has bzr 1.4rc1 and bzr-svn 0.4.6 ... which are incompatible with one another [18:37] rocky: I've just removed bzr-svn-0.4.6 [18:37] jelmer: that... doesn't help ;) [18:38] Hmm, every other time I try to push a commit it just halts. I log into the server I'm pushing to , run break-lock, and it re-push and it works. consistently. Anyone else get this? [18:39] rocky: at least it shouldn't complain about incompatible versions anymore.. [18:39] (and my cpu goes to 100% when it halts/hangs) [18:39] hrm, can't seem to access packages.ubuntu.com [18:39] rocky: there's no bzr-svn compatible with bzr 1.4 [18:40] didn [18:40] *didn't suspect there was [18:40] mostly i'm just interested in using the latest bzr-svn [18:40] whatever bzr comes with that is fine [18:41] debian sid and ubuntu hardy have the latest [18:41] don't suppose the src pkg for ubuntu hardy would just recompile on gutsy? [18:43] I think that should work, not aware of anything that may break it [18:45] Does anyone know if you're supposed to send recipients into send_mail() in chunks, or if the MTA chunks them up? (roughly 550 email addresses). [18:46] jelmer: needs a newer version of python-central it seems [18:48] ok, looks like i'm good [19:01] jelmer: don't suppose you have a "getting started with bzr-svn" link for people who need DVCS, never used bzr, but have to deal with a company's svn repo? :) [19:02] rocky: there's no specific documentation for bzr-svn other than the FAQ [19:03] rocky: bzr-svn makes svn branches feel like regular bzr branches [19:03] so "bzr branch http://mysvnurl.com/something/trunk" should work just fine? [19:03] rocky: yep [19:03] i'm getting a 401 error even tho svn has cached the credentials for my site [19:04] in other words, svn ls http://mysvnurl.com/something/trunk works fine [19:04] but branch on the same url does not [19:04] jelmer: do you know of a site that uses bzr-webserve, I couldn't trivally find an example [19:04] and you're using svn+http://... as the url? [19:04] no i'm not, lol [19:04] that's what i asked you above =P [19:05] rocky: well, the svn+ stuff is a workaround for a bug in bzr itself [19:05] gotcha [19:05] rocky: it's only necessary if you use authentication [19:05] i jus couldn't find any docs telling me that i need to prepend svn+ to the url any place [19:05] ah [19:05] jdahlin: no, not aware of any; sorry [19:06] jdahlin: bzr-webserve is derived from hgweb [19:06] jdahlin: http://code.bitlbee.org/hgweb/ contains an hgweb instance using bzr branches [19:07] I think the layout has changed since then though [19:09] jelmer: perfect [19:18] ping jelmer [19:54] hi! I haven't been able to find docs for something I think should be simple to do -- I want to have some kind of hook to run syntax checks before I do a commit for my tree. where should I be looking? [20:09] I can't create tags because my branch format is too old or something. "bzr upgrade --dirstate-tags", as suggested in the error message which is reported, doesn't fix the problem. [20:10] exarkun, what does bzr info output? [20:11] this http://rafb.net/p/POS2mv85.html [20:12] exarkun, and what version of bzr are you using? [20:12] New bug: #215872 in bzr-gtk "gtk.branchview.linegraph.linegraph() expets tuple but some functions still pass string" [Undecided,New] https://launchpad.net/bugs/215872 [20:12] I tried with 1.0.0.candidate.1 on one machine and 1.3 on another with the same results [20:27] anybody around with zen on bzr-cvsps-import [20:28] exarkun, I really don't know, I don't use tags at all :( [20:29] maybe a plain "bzr upgrade && bzr reconcile"? [20:29] (this is me guessing though) [20:29] hmm, bzr reconcile [20:30] exarkun, that's just to fix some problems that might arise on upgrade [20:31] It would be cool to have a 'pull' revision identifier that would behave somewhat like last, but based on the pull history. [20:31] For example, pull:1 would be the same as last:1. pull:2 would be the revision before the last pull, and so on. [20:31] jkakar, feel free to open a bug requesting it :) [20:32] you mean "after"? [20:32] I'm on revno 10 [20:32] bzr pull:1 would pull in revno 11 [20:32] ? [20:32] This would make reviewing changes easier. You could pull a branch, review some changes and make comments. Then, when comments are addressed do 'bzr pull && bzr diff -r pull:2' to see the changes made since your review. [20:32] beuno: Not quite. pull:N would be a history of revisions at the time bzr pull was called. [20:33] jkakar, hm, seems a bit more tricky, as you'd have to know what set of revisions you last pulled [20:33] beuno: Right, I suspect that's the hard part. Make bzr pull store a revision history somewhere. [20:33] jkakar, IMHO, having what revisions you pulled would be a step closer [20:34] or even how many revisions got pulled/merged in [20:34] "now at revno X" doesn't really say much to me [20:34] beuno: Well, I first thought I wanted exactly what you suggest, but that still means I need to remember an ID to do what I want. [20:35] beuno: A better UI is to offer a symbol that I can use consistently. [20:35] mtaylor: hi, I did several conversion with bzr-cvsps-import and it worked for me. [20:35] jkakar, right, it's a step closer and seems easier though :) [20:35] bialix: have you done any of those with rich-root-pack? [20:36] no, why for? [20:36] jkakar, I might give showing what revisions you pulled a try, so if you open a bug for that one I might give it a try [20:36] bialix: when trying to push to a rich-root-pack repo, or trying to upgrade, we're getting this: [20:36] the other one seems a bit over my head [20:36] bzr: ERROR: Revision {('cvs-1:mtaylor-20070503013257-q7msvneefnm8ft54',)} not present in "". [20:36] mtaylor: upgrade to rich-root-pack is currently broken [20:36] beuno: Cool, will do! :) [20:36] bialix: for cvs based things? or in general? [20:36] I promote importance of corresponding bug report to Critical [20:37] in general [20:37] upgrade to rich-root-pack being broken should be Critical... [20:37] jkakar, you can file them as separate bugs, maybe someone else can pick the other one up [20:37] Bug is aleady raised to critical [20:38] mtaylor: sorry for my english. I already promoted it. [20:38] good [20:38] :) [20:38] bialix: does that explain why pushing from a cvs-imported branch to a RRP repo would also break with the same error? [20:39] Aaron said that new format pack-1.4 should land soon, that's why this bug is not fixed still, IIUC [20:39] um, all the various incompatible formats is starting to get un managable [20:40] I'm trying to move an organization to bzr, and the formats and their inability to interoperate properly is causing various amounts of bitching... fwiw of course [20:40] mtaylor: I think some common codepaths from non-rich-root to rich-root is just broken and this is affect and cvs-import too. [20:40] ok [20:41] bialix: cool. thanks! [20:41] crazy format diversity problem ++ [20:41] currently rich-root needed only for bzr-svn [20:41] but packs are the good-and-efficient thing, no? [20:42] Yes, packs ++ [20:42] rich-root ++ also because good interop with SVN is a key adoption feature [20:42] packs is very carefully tested and widely used [20:43] bialix: by "packs", do you mean "--pack-0.92" [20:43] beuno: Bug #215903 filed. :) [20:43] Launchpad bug 215903 in bzr "'bzr pull' should report number of new revisions retrieved" [Undecided,New] https://launchpad.net/bugs/215903 [20:43] so if you don't need bzr-svn interaction it's better to not using rich-roots [20:43] IMO, of course [20:44] jkakar, confirmed and assigned to me ;) [20:44] mtaylor: yes. [20:44] see, this is the thing though... I even hang out in here alot, and I obviously can't figure out what format I should be using [20:44] beuno: Awesome, thanks! [20:45] mtaylor: better to use default format. pack-0.92 is default [20:45] I use rich-root-pack all the time because I have a lot of branches in svn [20:46] yes, of course [20:46] from an i'm-an-idiot standpoint, pack-0.92 sounds much less stable than rich-root-pack [20:46] something about that 0.92 in the name [20:47] that's why I called them simply packs [20:47] 0.92 is version number when they was landed to bzr [20:47] Hmph. With pack-1.4 coming up, "pack" as a format alias would be dicey [20:48] Are packs optimised for speed or size? [20:48] awilkins, both :) [20:48] for size and speed. but some operations is still too slow with packs [20:49] I've seen some papers where compressions formats got some serious performance boosts by sacrificing some size. [20:49] I'm still use knits for some cases [20:50] awilkins: there is plans about adding local cache for speeding things up. but still not. [20:50] New bug: #215903 in bzr "'bzr pull' should report number of new revisions retrieved" [Wishlist,Confirmed] https://launchpad.net/bugs/215903 [20:51] currently some operations much faster with packs, but others with knits [22:04] mwhudson: thanks for doing the stoqlib/stoqdrivers import and applying the pydoctor patch! [22:04] no worries [22:05] sorry for taking quite so long on the patch, it completely slipped under my radar [22:05] no worries [22:06] :-0 [22:06] :-) [22:43]