=== BasicOSX [n=BasicOSX@216.243.156.81.real-time.com] has joined #bzr === jelmer_ [n=jelmer@157pc196.sshunet.nl] has joined #bzr === jelmer_ is now known as jelmer === poolie [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr [12:29] hello === BasicOSX [n=BasicOSX@warden.real-time.com] has joined #bzr === ipkiss [i=ipkiss@nat/ecp/x-de0f73d1ca537c0b] has joined #bzr === keir [n=keir@206-248-134-7.dsl.teksavvy.com] has joined #bzr === fo2 [n=fog@213-140-22-78.fastres.net] has joined #bzr [12:59] morning [01:01] when I bzr push a branch to my webserver with bzr+ssh://, how can I tell it to create an up-to-date working tree as well? === cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr [01:02] mgedmin, hi, [01:03] i'm not 100% sure this will work, but have you tried running 'bzr checkout' on that location? === mgedmin finds a description in 'bzr help working-trees' [01:03] yes, bzr checkout . works, but bzr's help tells me I will have to manually ssh into the server and run bzr update in that directory after every push [01:03] (or look for some plugins to automate that) === jml [n=jml@dsl-210-15-197-192-static.TAS.netspace.net.au] has joined #bzr === pete__c [n=pete@032-463-246.area7.spcsdns.net] has joined #bzr === fo2 [n=fog@213-140-22-78.fastres.net] has left #bzr [] [01:28] bbiab [01:44] mgedmin: there is a plugin that will invoke update for you on the remote server === cprov is now known as cprov-afk [01:52] spiv, do you see the new bug about ^c in the smartserver? === spiv looks [02:07] lifeless: Assuming packs contain plain knits, how often are we expecting to be joining a plain knit source to an annotated knit target? === n2diy [n=darryl@wlk-barre-208-103-148-58.dynamic-dialup.coretel.net] has joined #bzr [02:19] igc: when we export a pack branch for a knit user [02:20] igc: its ok for it to be slow if thats your concern [02:20] yes it was [02:20] so command wise, we're talking pull or branch right? [02:20] push [02:20] and pull [02:20] and in rare cases upgrade [02:21] thanks [02:21] its not ideal for it to be slow, but its tolerable [02:21] New bug: #144627 in bzr "TooManyConcurrentRequests raised when bzr+ssh push is interrupted" [Undecided,New] https://launchpad.net/bugs/144627 [02:21] do you see why your logic was flawed ? [02:21] yes [02:21] cool === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr === jml_ [n=jml@ppp108-61.static.internode.on.net] has joined #bzr === jml_ is now known as jml [02:57] jelmer: oh btw, did you want to use the bzr pqm? pqm is totally happy to have multiple projects... [02:59] poolie: the index change in your branch - shoot that to bzr.dev directly please [02:59] lifeless, the docstrings? i thought i did [02:59] the __repr__ [03:00] I'm just checking for performance regressions in your patch [unlikely but needs to be done] [03:00] New bug: #144633 in bzr "KeyError for BzrCheckError.message" [Medium,In progress] https://launchpad.net/bugs/144633 [03:08] lifeless, cherrypicking addition of a repr is not going to be very high on my list [03:09] unless you particularly want it in main [03:11] I'll do it then [03:11] I want nothing in my branch [03:11] thats where I'm heading, and thats clearly 'done' as a piece of code, so no reason not to get it into bzr.dev [03:16] ok its on its way [03:23] poolie: your patch is about 1/2 second slower consistently [03:23] poolie: I haven't tracked it down yet [03:23] which one? === herzel [i=herzel@gateway/tor/x-7a7ae9847258843d] has joined #bzr [03:24] I just merged from pack-repository === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr [03:32] i'm glad you checked then === poolie reads bialix's second win32 patch [03:37] poolie: did you find all tests passing ? === metze_away is now known as metze [03:46] poolie: one thing I'm having some trouble telling with your patch is if it causes more index instances to be created [03:47] I think it doesn't === jml_ [n=jml@ppp108-61.static.internode.on.net] has joined #bzr === NamNguyen [n=namnt@203.162.163.50] has joined #bzr [04:00] will just finish this review then look [04:01] spiv, rise and shine :) [04:01] poolie: I'm here :P [04:04] :) === jml__ [n=jml@ppp108-61.static.internode.on.net] has joined #bzr === jml [n=jml@ppp108-61.static.internode.on.net] has joined #bzr === metze [n=metze@ip-217-172-181-76.mx-netz.de] has joined #bzr === Verterok [n=ggonzale@75-108-235-201.fibertel.com.ar] has joined #bzr [04:47] moin [04:49] Verterok, hi [04:49] lifeless, so do you know if there's a problem with that patch, or do you want me to look at it? [04:50] poolie: I've merged it [04:50] there's no performance problem? [04:50] its within the noise factor [04:51] it looked 1/2 sec higher, but its possibly just noise [04:52] there *may* be an issue with new indices being made when we should use existing ones, but its not showing up on incremental commit, and I alread knew of latent issues there === herzel [i=herzel@gateway/tor/x-ab92dd9f8374c7b4] has joined #bzr === marianom [n=marianom@ubuntu/member/marianom] has left #bzr [] [05:01] I hate the way everyone just assumes everything's on Launchpad. [05:02] Today I found out that people have been filing bugs on my branch of trac+bzr for months now. [05:02] With no one bothering to tell me about it. [05:03] igc: ping [05:04] hi lifeless [05:04] abentley: there is a flag to tell lp if it should consider itself to be the bug tracker [05:04] abentley: or not. Is that set for bzr-trac ? [05:04] How was I supposed to know trac+bzr was even in Launchpad? [05:04] igc: I replied to your review of moving weave code out; did you re-reply ? [05:05] abentley: oh hmm, thats a tougher one to answer :) [05:05] abentley, that is a good question === igc checks [05:05] however, it's supposed to make it hard for people to file bugs if it's not approved by the owner [05:05] if someone else claimed to be the owner though... [05:06] igc: cause I'd like to merge it :) [05:06] I'm yet to reply ... [05:07] we can cover it now if you like (i.e. here) [05:07] please [05:07] assume the first issue isn't ... [05:08] i.e. the duplication is ok [05:08] Looks like Yann Houdique registered it way back when. [05:09] I'd like the get_revision_graph API back there with just a docstring ... [05:09] relying just on interface tests feels ... [05:09] a bit of a stretch :-) === igc looks ar 2nd issue again === mlh_ [n=mlh@c211-30-211-232.belrs1.nsw.optusnet.com.au] has joined #bzr [05:11] lifeless: I'm ok with the 2nd explanations as well, altohugh it might to good to put a comment in to that effect in the ... [05:11] _get_revisions() method for weaves say. [05:11] that's it ... [05:11] igc: there is a comment there. [05:11] igc: that was my point on the second one :) [05:11] do you want an email summarising that? [05:12] igc: AIUI its 'put a stub NotImplemented get_revision_graph method on the base class' [05:12] yep [05:12] igc: I think I can get by without a mail :) [05:15] lifeless: that comment I was asking for ... [05:16] looking again, putting it in _get_revisions in repository.py would be good because ... [05:16] right now, the docstring says "without sanity checks" and ... [05:16] you then proceed to do some I think? [05:17] igc: mmm [05:17] its checked for being a revision id or not [05:17] but the results are not checked for sanity === mlh_ [n=mlh@c211-30-211-232.belrs1.nsw.optusnet.com.au] has joined #bzr [05:24] abentley, i suggest what you do now, if you haven't already, is claim the project and then tell it bugs are not tracked in lp [05:24] unless in fact you do want to track them there [05:24] Yeah, I might track it there. [05:26] But in fact, I wasn't aware that anyone even cared about trac+bzr [05:28] abentley: its one of the first questions people at conferences put to me [05:28] 'its written in python, cool. Does it integrate with trac?' [05:29] Well, my answer would be "Kinda. For it to integrate properly, either Trac or Bazaar would have to change architectures" [05:30] thats true [05:31] I usually just say 'there is a plugin for trac, but I don't have personal experience with it' [05:37] i'm going to take a lunch break [05:37] biab [05:37] good idea [05:47] I installed trac+bzr at one point out of curiosity. What sort of differences are you saying are really irreconcilable? [05:48] They want to know what was the last-modifying revision of a directory, even for directories that aren't even branches. [05:49] That's the sort of thing. [05:50] Oh cool. It's an abentley and he's talking trac+bzr stuff ;-) [05:51] Yeah, that sort of thing doesn't really bother me, either because I expect it could be reasonably easily made optional in trac or omitted/lied about by trac+bzr when it's difficult/impossible to get. [05:53] Yeah, but people bitch about the lie. [05:53] :) [05:53] lifeless: Yes, it would be very nice if we could use the bzr pqm. [05:54] Seriously. Look in Launchpad, and you'll see people filing bugs about the null: and current: revisions, even though they're documented in the README. [05:55] jelmer: Cool. Can you mail me a list of initial committers, and the build rule you want executed, plus where the writable location for the main trunk is (we could put that on bazaar-vcs.org if you like, I don't think poolie would object) [05:55] heh, abentley I commented on that bug and added a patch to make them slightly better. [05:56] abadger1999: if you look at the scrollback, you'll see that I was not aware that any launchpad activity was taking place. [05:56] Yep. I saw that. [05:56] lifeless, np here [05:56] I was looking for you earlier to ping you about it. === igc food [05:57] abadger1999: Sorry, I've been busy. [05:57] lifeless: ok [05:57] No problems, I fugred you were. [05:57] So what did you want me to look at? [05:58] with the current: and null: changesets, I had two issues. [05:58] the important one is that they're messing up the trac timeline RSS feed. [05:59] Since it uses time.time() as its timestamp, everytime an RSS reader looks at it, it thinks there's a new entry when it's just current: re-occurring. [05:59] I added a patch to the lp bug to have it use the same timestamp as the last revision. [06:00] That's bogus. This is why Atom has unique identifiers for postings. [06:01] Why not go the whole way and use the last revision instead of current:? And how much performance degradation did you see? [06:02] I'm subscrbing to the feed via mugshot. [06:03] So all the fedora developers were getting popups saying that there was new activity every time mugshot polled the RSS feed for the timeline. [06:05] Well, if RSS has unique IDS, that's bogus. If it doesn't, you should be using Atom. But my main concern about getting rid of current is the performance cost of determining the last-modified revision. [06:05] we could build a cache [06:06] Looking at the RSS feed, I don't see any ID :-( [06:06] annotate each dir by whether paths under it changed [06:07] Do you know how to get trac to serve atom? ?format=atom doesn't do it. [06:07] build a dict {revid:{dirid:changed_revision}} [06:07] Sure, but then you've got to do invalidation and stuff. [06:08] Which seems just as espensive as not having a cache. [06:08] abentley: no invalidation really, its static for a given revision [06:08] abentley: I was not proposing this for bzr itself btw [06:08] Hmm? I see a guid, but it looks like it has a timestamp on the end... [06:08] I'm talking about running trac against a repository with hundreds of branches. [06:08] abentley: long term we should make answering the question cheaper; this is a proposal for the trac plugin to work with [06:09] I'm not talking about the issue of last-modified-revision for versioned directories. [06:09] oh, perhaps I am confused [06:09] I'm talking about last-modified-revision for unversioned directories. [06:09] cory: Right [06:10] abentley: *blink*, is there such a thing? [06:10] For Trac's benefit, we pretend there is. [06:10] so any dir whether it exists or not ? [06:11] Not "whether it exists or not"-- whether it exists as part of a versioned tree, or is used for layout in the repository. [06:13] ah I get you [06:13] so reporoot [06:13] reporoot/project [06:13] reporoot/project/branch1 [06:13] noth reporoot and reporoot/project are given a 'last modified' [06:13] s/noth/both/ [06:13] Given the path a/b/c, 'a' may be a plain directory. Its last-revision is 'current:' 'b' is a branch directory. Its last revision can be the branch last revision. 'c' is a versioned directory, and is not physically present in the repo, just referred to by 'b' [06:14] lifeless: Right. [06:14] so the 'corect' last modification needs to move forward when any branch under an unversioned dir has its tip change [06:15] Yes, you could do it that way in theory. [06:15] fraught with holes doing it on push etc === jml_ [n=jml@ppp108-61.static.internode.on.net] has joined #bzr [06:15] just trying to understand the 'definition' [06:16] I see what you mean about the model mismatch [06:16] Yeah. [06:16] So now we have to define 'latest'. [06:17] We can't use the ancestry, because the branches may be unrelated. Do we use the revision timestamp? The time the tip was modified? [06:18] what about stat of the dir ? [06:21] This is vaguely relevant: http://trac.edgewall.org/wiki/VcRefactoring#SupportforMultipleRepositories [06:23] At least just as confirmation that they might work on refactoring things for things structured like bzr. [06:23] lifeless: I don't think that helps. [06:23] Because if we're trying to find the latest revision, we must examine branches, not the directories containing them. [06:25] if we accept that there is no well defined value [06:26] then we can just show a fake commit, no message other than 'last modified on xxx' etc [06:28] Right. I don't mind the lie, I just want the lie to remain the same between real commits. [06:28] Because trac does recursive comparisons, I don't know if that would work. [06:29] using the dir stat would mean that adding a new branch or removing one would change the date [06:29] It could make the directory look like its contained directories weren't changing. [06:29] (except when branches were added or deleted) [06:29] a commit id of date:secondssinceepoch [06:29] might be a half-decent way to represent this === BasicOSX [n=BasicOSX@warden.real-time.com] has joined #bzr [06:31] abadger1999: I think it could be harmful if the lie *didn't* change when commits happened. Which is I believe what lifeless is proposing. [06:32] That would be more confusing than now, true. [06:44] abentley: Is the current ancestry of current: to be trusted? ie: bzr_repo.previous_rev('current:') [06:45] I believe so. [06:45] Been months since I looked at the code though. [06:46] lifeless: a question about converting deltas between annotated and plain knits ... [06:46] sure [06:46] abentley: k. My patch takes the timestamp of that rev and applies it to current: [06:46] parse_linedelta returns something different to what ... [06:47] lower_line_delta accepts ... [06:47] it's works within ann-to-ann or plain-to-plain but ... [06:47] not across the two [06:47] ah yes [06:47] thats my fault, I specialised it somewhat [06:47] I'm concerned about ... [06:47] changing that because it will impact ... [06:48] perforamnce undoubtedly [06:48] should I change it? [06:48] so don't change it [06:48] abadger1999: So that means you potentially have multiple timestamps for current [06:48] write a converter [06:48] Actually, no, I guess not. [06:48] sure [06:49] You just don't have per-directory accuracy on that timestamp. [06:49] Yeah. It's definitely a lie. [06:52] bbiab [06:52] igc: ring me if you need more info/discussion - going for lunch [06:52] ok === orospakr [n=orospakr@bas4-ottawa23-1167863943.dsl.bell.ca] has joined #bzr [06:53] abadger1999: So the problem is that bzr_repo.previous_rev('current:') can be quite expensive. [06:53] Theoretically less so for branch format 6. [06:53] (aka dirstate-tags) [06:57] abentley: hmmm.... is bzr_repo.previous_rev() expensive in general or only when finding for 'current:'? [06:58] It's certainly more expensive for current:. It might not be cheap normally, either. [07:00] For current, it means scanning every branch in the repository. [07:00] I'm off to bed. [07:01] 'night. [07:02] Interesting. I think previous_rev() loads the history for the entire repo whenever it's called (unless history has previously been cached) [07:12] abadger1999: knits have no partial index facility [07:12] abadger1999: so accessing one revision loads the index of all revisions [07:13] Ah. === sevrin [n=sevrin@ns1.clipsalportal.com] has joined #bzr === liw [n=liw@a91-154-119-10.elisa-laajakaista.fi] has joined #bzr === arjenAU [n=arjen@ppp215-29.static.internode.on.net] has joined #bzr [07:59] igc: I've reinstated the stat cache on packs [07:59] igc: 4 second hit on initial commit (for now), but 10 second win on incremental commit [07:59] awesome! [07:59] I'll take the 10 sec win on incremental :-) [08:00] pfft [08:00] I figure that we don't need the stat cache when the fileid is new [08:00] so I'm going to add a special case for no_parents, passed into path_content_summary [08:00] sounds good [08:01] should take it back to 1m20 [08:01] and keep the 10 second win === liw [n=liw@a91-154-119-10.elisa-laajakaista.fi] has left #bzr ["It's] [08:01] so I now have 5 patches send in today [08:01] *sent* [08:01] (and not reviewed) [08:02] I'm getting there - just sending mine to the ML now [08:02] sent [08:02] I intent to review the transport put related one [08:02] I'll swap you - one review for >1 reviews :-) [08:02] and hi all [08:02] hi vila === jml_ is now known as jml [08:03] igc: np, if you take in your swap the project delivery I must do today ;P [08:03] igc: 1:M [08:05] about pycurl/urllib, what about making urllib the default for http and pycurl the default for https ? [08:05] I'm a bit hesitant about it for coherence reasons, but on the other hand, we had many reports recently where pycurl failed were urllib worked... [08:06] and I don't like dropping cretificate verification for https [08:06] cretans eh? [08:07] lol [08:07] yeah, better than greeks :) [08:10] lifeless: I'll do the path_content_summary review now unless you want a different one done 1st [08:10] any order is fine [08:15] igc: reviewed [08:16] thanks [08:16] igc: basically good; but you missed a large body of duplicate code in the tests [08:16] ok [08:17] if you move the assertions into your helper and rename it, you'll be good to go [08:17] np === pmezard [n=pmezard@nor75-4-81-56-59-92.fbx.proxad.net] has joined #bzr [08:21] igc: I've mailed you my current uncommitted-cause-its-experimental changes [08:21] if you want to see how it performs on real hardware [08:21] got those [08:21] bbiab === hdima [n=hdima@idealer.cust.smartspb.net] has joined #bzr === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr === matkor [n=matkor@EUROCZESCI.wbs.ssh.gliwice.pl] has joined #bzr === Lo-lan-do [n=roland@mirexpress.internal.placard.fr.eu.org] has joined #bzr [08:58] thanks for the review [09:06] me? [09:09] lifeless, poolie: looks like I'm 7 hours late to review the transport.put_file patch :-) [09:09] vila: is it ok? [09:09] is there a problem with it? [09:09] vila: or would you like it changed? [09:09] lifeless, yes, you [09:10] lifeless: no, at first read it's ok, it will break webdav again, but it's mentionned in NEWS (for other transport implementors) and land sufficiently early to be taken into account === Stevage [n=chatzill@mail.pfxcorp.com] has joined #bzr [09:14] hello [09:14] can anyone help me get TortoiseBZR to work? [09:14] It compiles, but it doesn't seem to create any icons [09:15] it does create shell extensions though - but they don't do much, and the 'diff' command seems broken [09:21] Stevage: pls fill bug report [09:23] but I have not seen much work recently in that area ... [09:24] hmm [09:24] pity [09:24] I'd love to have tortoisebzr going === pmezard [n=pmezard@dhcp26-226.enst.fr] has joined #bzr [09:26] so fill bugreport and keep presure on developers ;) [09:27] Stevage, alexander haro is the developer [09:27] lifeless: ping [09:27] yeah just reading the README [09:27] I don't see that I installed it wrong, so I don't get it [09:28] suggest you cc him on your mail to get his attention [09:28] also I think most of the shell extensions didn't appear [09:28] what's his email? [09:30] amduser29 at gmail [09:31] ta [09:44] hmm [09:44] it seems to be trying to find some method called CommitCommand === alla [n=alla@soy.cyber.com.au] has joined #bzr [09:45] which doesn't exist in bzr.dev/bzrlib === n2diy [n=darryl@wlk-barre-208-103-148-58.dynamic-dialup.coretel.net] has joined #bzr === lifeless [n=robertc@ppp245-86.static.internode.on.net] has joined #bzr === james_w [i=jw2328@jameswestby.net] has joined #bzr === jeremyb [n=jeremy@unaffiliated/jeremyb] has joined #bzr === meuh [n=meuh@pdpc/supporter/active/meuh] has joined #bzr === LarstiQ [n=larstiq@cust.7.157.adsl.cistron.nl] has joined #bzr [09:45] has bzr been radically reorganised recently? [09:45] no [09:46] perhaps that's a method in a plugin? [09:46] oh no, maybe I'm just confused [09:46] yeah it is [09:46] there's a CommitCommand.py [09:46] I don't know why it can't find it [09:46] :-) [09:46] (I don't really speak python) [09:46] command_mod = __import__('commands', globals(), locals(), [command_filename] ) [09:46] command_mod = getattr(command_mod, command_filename) [09:46] command_class = getattr(command_mod, command_filename) [09:46] one of those is failing [09:47] command_filename is "CommitCommand" [09:47] that seems a bit strange... [09:47] can you put the traceback in a pastebin? [09:48] ok it's the first line [09:48] there's no traceback [09:48] it's just an exception [09:48] um [09:48] maybe that's nonsensical [09:50] igc: yo [09:50] I don't know how to get debugging output from it [09:50] in the tests, where does the size "22" come from? [09:51] those three lines of code above look pretty weird to me though [09:51] especially #2 and #3 [09:56] igc: which test [09:56] test_file_content_summary_executable [09:57] oh, thats the number of bytes in the file [09:57] the content is generated by build tree - 'contents of path\n' IIRC [09:57] ok - thanks [09:58] not that easy to follow that in the code [10:00] got it now === mvo [n=egon@p54A67BA0.dip.t-dialin.net] has joined #bzr === mrevell [n=matthew@canonical/launchpad/mrevell] has joined #bzr [10:06] New bug: #144693 in bzr "remove {Branch,Tree}.print_file" [Low,Confirmed] https://launchpad.net/bugs/144693 [10:08] Hmpf. === Lo-lan-do gets bitten again [10:08] Is there a way of having "bzr status" display paths relative to the current directory? [10:08] What is network usage in bzr over sftp comparing to rsync over ssh ? More or less ? [10:09] It currently shows, f'rinstance, "foo/bar.txt" even when I'm in foo/ === fog [n=fog@debian/developer/fog] has joined #bzr [10:09] I mean doing rsync local remote vs bzr commit local, bzr push remote ? [10:09] So "bzr add foo/bar.txt" (cut and paste) fails [10:12] lifeless: that review sent to the list now fyi === poolie_ [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr [10:14] that knit join patch merged to bzr.dev now too [10:20] I have org-branch and branched from it modified-branch... now I want cherrypick some changes from modified-branch (I know which revisions) back to org-branch, what is easies way to do it ? === pbor [n=urk@host126-78-dynamic.5-87-r.retail.telecomitalia.it] has joined #bzr === allenap [i=allenap@nat/canonical/x-edc4d411a31e49a6] has joined #bzr [10:25] hi [10:25] not sure if it is on topic here, but if I branch from a launchpad import, will I be able to then push to the upstream svn repo with bzr-svn? === pbor tried to to a local branch directly from the svn repo but it totally killed my machine... it required 1,5 gigs of mem === igc food [10:32] mmm... I now realize that launchpad import is totatlly stale anyway, so nothing useful :/ [10:38] igc: thanks [10:43] pbor: no, launchpad imports are different from bzr-svn imports [10:44] pbor: which import is it? i can try to find out why it's stale [10:45] mwh: gedit === asabil [n=asabil@62.70.2.252] has joined #bzr [10:46] oh oops, that's still importing from anoncvs.gnome.org [10:50] mwh: just out of curiosity, how do launchpad imports and bzr-svn imports differ? [10:51] well, the glib answer is that they are created by different pieces of software :) [10:51] (launchpad imports are done by cscvs) [10:51] more technically, launchpad imports have random revids and bzr-svn imports have deterministic ones [10:51] okay [10:52] so if you run a cscvs import twice you'll get (as far as bazaar can tell) different histories [10:52] there are different trade offs [10:52] (roughtly speaking what bzr-svn does is harder and much more of a commitment in some ways) === gabe [n=gabriel@91.84.56.254] has joined #bzr === gabe [n=gabriel@91.84.56.254] has joined #bzr [10:59] mwh: btw, looks like this is my problem with yesterday's import https://bugs.launchpad.net/bzr-svn/+bug/54253 [10:59] Launchpad bug 54253 in bzr-svn "Excessive memory usage in bzr-svn" [Undecided,Confirmed] [11:01] you can often get away with killing the process and having it resume from some point [11:01] current thinking on that bug is that it's a problem in the python-svn bindings i think [11:01] mwh: how do I resume? [11:02] what stage had it got to when you killed it? [11:02] no idea, I had to hard reboot :/ [11:02] ugh [11:02] pbor: rather than doing bzr branch, do 'bzr init --dirstate-with-subtree', then do 'bzr pull svn://'... [11:03] lifeless: what does that give me? [11:04] if you hit ctrl-c [11:04] just do 'bzr pull svn://' again [11:05] and it will resume [11:05] ah === bigdo2 [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr === Mez [n=Mez@ubuntu/member/mez] has joined #bzr [11:24] mwh: you might like to start dogfooding packs for codeview; we're closing in on a first release of it in the next week or two === asabil [n=asabil@62.70.2.252] has joined #bzr [11:24] mwh: if it sucks for you, *now* is the time to hear. [11:24] lifeless: what's the status of packs? [11:25] mwh: there's two known issues may affect you; annotations will be no longer cheap in the first release (plain-knits always, and no cache implemented yet). Secondly partial index reading has not landed yet. [11:25] jrydberg_: good. [11:25] jrydberg_: initial commit is nice and fast :) [11:25] lifeless: what about push and pull? [11:26] initial push runs about 20% slower than rsync [11:26] ditto pull [11:26] needless to say this is hugely faster than knits. [11:26] how about incrimental updates? [11:27] they are ok, but not great because the text indices are read entirely still, and they are much larger than the individual indices that knit repos have [11:27] so we're reading more index data [11:27] though there is plenty of room to optimise that even before partial index reads come in [11:28] we don't do ghost filling automatically in packs [11:28] so we can examine just incremental data, and thats in the most recent (and smallest) packs, so checking them first for content will usually be a win [11:28] lifeless: makes sense [11:28] lifeless: i see [11:28] lifeless: can i get a bzr.dev [11:29] lifeless: can i get bzr.dev in packs somewhere? [11:29] fwiw, by nice and fast on initial commit, its 1m30 wall clock for me in my latest not-quite-committed stuff; thats the same as hg on this machine (well actually a little faster) [11:29] mwh: yes; see my dogfooding emails to the list [11:31] lifeless: subject? === Mez [n=mez@ubuntu/member/mez] has joined #bzr [11:32] lifeless: why do we have so large indexes then? can't we have a pack-index, and then have per-pack indeces (either as a separate file, or in the pack header) ? === sverrej [n=sverrej@pat-tdc.opera.com] has joined #bzr [11:34] jrydberg_: thats what we have [11:34] jrydberg_: its just that rather than N knit indices [11:34] where N is the number of file ids [11:34] lifeless: well, the pack index doens't have to be that big, does it? [11:34] pack: [11:34] we have one text index per pack, which has the data for all N fileids-versions in that pack [11:35] jrydberg_: we limit the number of packs to prevent latency explosion due to one pack per commit, which would be going back to the arch days [11:36] so you're doing auto repacking, is what you're saying? [11:36]