[00:00] randomnewguy: no, revisions just show the flow off changes in time, not the version [00:00] randomnewguy: since versions are arbitrary, they are tags, a marked revision number which we assign a version number to [00:01] im only just starting with bzr, are tags a feature? [00:01] Yes. [00:01] ok thanks [00:01] As opposed to a bug? :] [00:02] i didn't know the option to tag a revision existed [00:02] bpeterson: Why are we referencing a spring from last May? [00:02] randomnewh [00:03] There are over 16,000 revisions in Bazaar's Bazaar branch. Usually a couple a day. A couple releases a day wouldn't be very nice... [00:04] fullermd: opps [00:04] fullermd: oops === bpeterson changed the topic of #bzr to: "Bazaar version control system discussion (http://bazaar-vcs.org)" [00:05] Isn't there a new sprint right now? [00:05] s/new // [00:05] Peng, yeap, at this exact moment [00:05] Peng: do you know the url so I can get it right [00:05] (well, we're suppose to be sleeping now, but bleh) [00:05] The topic should make a note what the latest version is [00:06] Peng: i guess its a little more practical when you only have 6 like me === bpeterson changed the topic of #bzr to: "Bazaar discussion | Latest release is 1.2" [00:06] Yesterday, the topic was: http://bazaar-vcs.org/ | Bazaar 1.2 is out! | https://launchpad.net/bzr/1.2/1.2 | Sprint wiki page: http://bazaar-vcs.org/SprintLondonMarch08" === Peng changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.2 is out! | https://launchpad.net/bzr/1.2/1.2 | Sprint wiki page: http://bazaar-vcs.org/SprintLondonMarch08" [00:07] Peng: that should do it... thanks [00:08] that looks good :) [00:09] should set +t and turn on topiclock, then only the correct people can set the topic instead of it being able to be screwed up by anyone [00:11] Toksyuryel, it hasn't been a problem until now [00:11] it's much less work to leave it open I think [00:12] basically all you do is put a /msg chanserv in front of the topic command and it's otherwise the same [00:12] and this is why I don't like the squeaky wheel mentality, it's always better to stop problems before they happen if you find yourself in a situation to be able to do so :) [00:13] but it is of course your decision [00:13] * Toksyuryel is just throwing it out there [00:14] Toksyuryel, but then you have to give access to people [00:14] and only those can change the topic [00:14] and they would get bugged to do so by others [00:14] anyone knows why bzr somehow doesn't have problems with line endings when you work with unix <-> windows merges, but hg does? [00:14] it's not so straight forward ;) [00:14] don't they already have access? [00:15] Wait, what? [00:15] Bzr doesn't handle line endings, but hg optionally can. [00:15] I'd say you're just lucky that your text editors aren't screwing around with line endings. [00:16] * Toksyuryel hates DOS line endings =/ what is wrong with those people [00:16] hm.. i'm using emacs here and there, the editors are the same, so maybe the problem was that i had some type of filter configured... happy now anyway :) [00:16] HTTP uses DOS line endings. I wonder how much bandwidth that wastes? [00:17] tons probably, people all over the world download millions of multi-kibibyte html documents every day [00:18] the individual user may not notice anything but the ISPs have a lot of extra strain they don't need because of that [00:21] * Verterok sleeps [00:26] estimating extremely conservatively, let's suppose an ISP that serves five million customers that each download 1000 HTML documents every day averaging 100 lines per file. Calculated out that ends up costing the ISP 4tbits per day. [00:27] the actual amount wasted in reality is probably a lot higher [00:27] For that matter, anyone who properly indents their HTML would waste loads more in leading spaces [00:27] gzip FTW :) [00:28] indeed ^_^ [00:29] yes.. gzip.. [00:29] gzip is a great solution and I know at least firefox supports that [00:30] there would still be some waste in the HTTP headers but that would be minimal compared to what it would have been otherwise [00:30] unfortunately we probably can't force everyone to gzip their pages any more than we can force them to use UNIX line-endings =/ it's too bad [00:32] hmm.. we force unix line endings in your pre commit hooks :) [00:32] our* [00:32] but anyway, getting back on topic, bzr rocks <3 [00:32] now if only we could make sure they are using the pre commit hooks :) [00:33] that is on topic tho.. [00:33] sorta [00:35] * beuno is off to bed === bpeterson changed the topic of #bzr to: “http://bazaar-vcs.org/ | | https://launchpad.net/bzr/1.2/1.2 | Sprint wiki page: http://bazaar-vcs.org/SprintLondonMarch08"” [01:23] why...? === bob2 changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.2 is out! | https://launchpad.net/bzr/1.2/1.2 | Sprint wiki page: http://bazaar-vcs.org/SprintLondonMarch08 [01:45] retupmoca: line endings. can bzr handle them or would i have to write a pre-commit hook? [01:45] I think "neither" is the current answer... === mw is now known as mw|out [01:48] I believe line ending stuff (and I/O filters in general) is on the topic list for the current sprint, but I'm not sure. And of course that doesn't help anything at the moment. [01:59] um....what? [02:00] someone set off my highlight [02:01] * retupmoca fades back into the darkness [04:49] hi all [04:49] when I am trying to run loggerhead, I am seeing an error message [04:50] http://pastebin.ca/927304 [04:50] what does error message mean? [04:50] thus i am not able to start loggerhead [04:51] It means UART gettin' online! [04:51] I don't know, Google it. [04:51] You need to set autoreload.package, even if to an empty value. [05:02] but, yesterday it was working without any problem Peng [05:02] after some time, only it started showing this problem [05:03] Well, I have no idea. [05:03] I've never used TurboGears. [05:04] Peng, have u used loggerhead ? [05:04] Nope. [05:04] I'm on shared hosting so I've been afraid to try it. [07:33] Morning. [08:00] hi there [08:00] anyone give a hint what i'm doing wrong? [08:01] I've setup a central branch as per Team collaboration, distributed style [08:01] where you can have local bugfix branches [08:01] when I create a pristine branch of the central trunk, it has no files in it, even though the repo has files in it [08:03] DataShaman: what is the command you use to create the branch? [08:04] anyone? [08:12] anyone here want to help me with a problem using bzr? [08:12] please [08:16] 02:03 DataShaman: what is the command you use to create the branch? [08:16] the local branch? [08:16] Whichever one has no files in it. [08:16] std bar branch bzr+ssh:.... [08:16] bzr branch bzr+ssh://blah... [08:17] the central repo has files in it [08:17] when i pull in the branch, it says 35 revisions are branched [08:17] but no files are created in the pristine copy [08:18] Try info. [08:18] shared repo is the parent folder, which makes sense [08:18] repository branch is . [08:18] parent branch is the remote repo [08:19] Pastebin the whole output. [08:22] k [08:23] http://pastebin.com/d28708aa5 [08:23] with -v [08:24] do a info on the central repo as well? [08:25] central repo: http://pastebin.com/d776df7b5 [08:25] No, that's enough. Shows the expected. [08:25] You don't have a WT, which means you created the repository with --no-trees. So, nothing's "broken"; it's doing just what you asked. [08:25] Run a "bzr co" in the branch to instantite a WT for it. [08:27] Any good way to turn --no-trees off? You can rm .bzr/repository/no-working-trees. [08:28] I think it's one of those things to slot into reconfigure. [08:30] ok [08:30] i get it [08:31] my pristine copy of the central repo shouldn't have a working tree, ideally correct? [08:31] when I create a feature branch off the pristine copy, how do i get it to create a working tree with the branch command? [08:32] DataShaman: ... rm .bzr/repository/no-working-trees. === Odd_Blok1 is now known as Odd_Bloke [08:34] Odd_Block? :) [08:34] Well, it shouldn't if you don't want it to :) [08:34] :) [08:34] Peng: Ping? ;) [08:34] It depends on the details of how you want to work. [08:34] let me give you a brief rundown [08:34] central repo, with trunk [08:35] me at remote site, with pristine branch copy, and local branches for bugfixes, features, etc [08:35] Sprint People: I was denied access to the Executive Lounge (No Executive Lounge?! DENIED!) so will hang around in the lobby until ~quarter to. [08:35] the pristine branch copy with no WT, since it seems wasteful to have one there [08:35] but local bugfix branches obv must have WTs :) [08:36] How do you intend to land the bugfix branches when they're completed? [08:36] i assume that in my case, the pristine copy MUST have a WT? [08:36] hmm, point [08:37] it has to merge into the local i suppose [08:37] The way I do such things is to use a checkout of the trunk for my "local pristine" copy. [08:37] DataShaman: You can use "bzr remove-tree" and "bzr checkout" ("bzr co") to switch a branch between having a WT and not. [08:37] ok [08:37] Then when I need to land a bugfix branch, I can go into it and "bzr up ; bzr merge ../bugfix ; bzr ci" to land it into trunk. [08:37] moin [08:38] (actually, I also often do trivial stuff straight on trunk too, but that's all up to your workflow choices) [08:38] fullermd: ok, thanks for your help, it makes sense now [08:38] viola, all there now :) [08:40] Lazyweb: Can "bzr up" show a log of the revisions it's pulling, like "bzr pull -v"? [08:41] bzr up -v perhaps? [08:41] ah, no, sorry, you want log, rather than file changes, I don't think that's possible. [08:45] I'll stick with avoiding checkouts then. [08:46] (Except for the occasional lightweight checkout.) [08:52] I've never found pull -v useful myself... [09:41] This is a few days old, but an interesting post from elijah: http://blogs.gnome.org/newren/2008/03/01/happenings-in-the-vcs-world/ [09:42] hi afc [09:42] you've landed in london? [09:43] that is interesting [09:45] poolie: yeah. His section on Bazaar was a bit of a ramble (perhaps that's a bad sign) but his comments on Subversion, Mecurial, and Git seemed insightful. [09:50] AfC: it'd be interesting to know what the "several features of git not present in other systems that [he is] absolutely addicted to" are [09:51] ah. he's elaborated in a comment [09:51] the various ways of destrying your history with rebasing/filtering/etc.? :) [09:51] "speed[1], repository container[2], the index[3]" [09:53] "and history rewriting[4]" [09:57] abentley: BB is down. [10:15] lifeless: I've written up the network performance stuff at http://bazaar-vcs.org/SprintLondonMarch08/Brainstorms === weigon__ is now known as weigon [10:26] poolie: At the bottom of http://bazaar-vcs.org/SprintLondonMarch08/Brainstorms [10:42] Odd_Bloke: thanks [10:57] jelmer: I've added the stuff on the board re: bzr-gtk to http://bazaar-vcs.org/SprintLondonMarch08/Brainstorms [10:58] Odd_Bloke, w00t, thanks! [11:13] poolie, at some point in the sprint, I'd like to chat with you about the "command not found" spec if you can [11:17] yes, we should [11:45] vila: http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/37768 === doko_ is now known as doko === mw|out is now known as mw === pmezard_ is now known as pmezard [12:32] hi guys.. are you in london now? [12:49] Zindar, yeap, we're all in London [12:50] so am I today/tonight [12:51] just wanted to see if anyone feels like meeting up, drinking bear, etc tonight... if there is time [12:53] bear = beer.... [12:53] strange if not :) [12:54] Zindar, not sure what happens after we finish, but you can re-check at ~6pm and see [12:54] I might not have internet this afternoon though.... [12:54] sms possibilities to someone? :) [12:55] Zindar: hi [12:55] +31645516686 [12:55] thank you :) [12:55] +46730808013 if you need me [12:55] thanks [12:55] or somehting [13:08] * awilkins fancies a nice drop of bear [13:20] awilkins: TMI. ;) [13:23] You can get bear online. [13:28] * Peng wanders off. [13:43] mm, bear [13:43] though I think I'd prefer some venison [14:08] what do I do if I accitently added a symlink to my repo? [14:08] bzr remove doesn't seem to work [14:29] luris: it ought to. [14:29] luris: you could always just [14:29] $ rm linkname [14:29] and see what `bzr status` [14:29] reports [14:29] AfC: I ended up running bzr rm --new && bzr add [16:03] is igc in London? [16:06] yes [16:06] He's over there --> [16:09] indeed, --> [16:10] dato: ping [16:10] lifeless: pong [16:11] did you write something to watch a branch and email out changes observed on it? [16:12] could somebody ask him if by «your thoughts will give us things to keep in mind when developing bzr-fastexport soon» he meant that he's going to write it? [16:12] while true; do bzr log | mail ..... LOL [16:12] lifeless: yes, though it's a bit rough. [16:13] dato: url ? squid3 is mocving to bzr :) [16:13] dato: he says 'yes ian will write it if noone else does' [16:13] lifeless: ok [16:14] lifeless: https://launchpad.net/bzr-hookless-email [16:14] hi dato [16:14] hi igc [16:14] dato: syou should put that on the plugins page or osomething [16:14] lifeless: ah yes, I forgot to do that. [16:14] perhaps we should have a 'extensions' page or something that lists all the not-a-plugin ut works-with-bzr stuff [16:16] dato: can local_bzrlib be deleted now ? :) [16:17] lifeless: actually no. it has a patch that I didn't manage to submit yet. (also because I wasn't very sure it would be ok) [16:18] (code for setting the envelope-sender and smtp recipients) [16:19] lifeless: anyway this program could be rewritten as something that just calls the configured plugins as if they were being called by the committer. so that it'd be also able to send stuff to CIA and else. [16:21] dato: right, but I needed something now :> [16:21] right. it'll do the job. [16:21] igc: so, ooi, do you have an estimate of how much code bzr-fast-export.py would be? [16:24] wasn't there a revspec or so to get the working tree state? [16:24] * LarstiQ wants to diff his workingtree state against the top pending merge [16:25] or perhaps I mean just diff against a pending merge [16:31] dato: I think a simple implementation of bzr-fast-export could take as little as an hour or so [16:32] dato: I would like to include one in bzr-fastimport [16:32] I'll read that as "igc time" ;) [16:32] dato: the key word is "simple" [16:32] it's one thing to dump stuff out [16:33] it's another to think through all the issues needed to make bzr-fast-export and bzr-fast-import "round-trip" [16:34] in other words, I want to get a fast-export that is useful to our community, not just other communities :-) [16:35] yah :) [16:35] my first driver for fast-export though is as a QA tool to show that fast-import works [16:36] my second driver is making some funky 'filter' branch' style functionality possible [16:36] dato: there are also some implementation options to consider ... [16:37] the easiest fast-export is to walk the repo and print stuff as you go [16:38] a slower, but maybe more useful way?, is to generate Command objects and add __str__ to each [16:38] what is fast-export? [16:38] the latter is more object-oriented, but might suck performance wise [16:39] LarstiQ: git implemented a tool called git-fast-import that accepts a stream of comands/data [16:40] tools that generate that stream are called *-fast-export [16:40] I've written a plugin that takes the same import stream as git handles [16:40] so we can reuse all the existing exporters [16:40] ookay [16:40] but we're yet to have an exporter that dumps that format [16:41] after all, no-one ever wants to use another VCS having used bzr :-) [16:41] * LarstiQ swallows the switching to git stories [16:42] * dato confesses he has temptations at times. [16:42] not because I'm unhappy, which I'm not [16:43] seriously though, it's actually a feature being able to get from bzr to other tools in that ... [16:44] some teams want to be confident that picking bzr wouldn't lock them in [16:45] New bug: #198417 in bzr "bzr diff -r ancestor: should use parent branch if not specified" [Undecided,New] https://launchpad.net/bugs/198417 [16:45] New bug: #198418 in bzr "bzr send gives incomplete help on error" [Undecided,New] https://launchpad.net/bugs/198418 [16:46] igc: which entirely makes sense [16:56] LarstiQ: for more info, see http://bazaar-vcs.org/BzrFastImport [16:58] igc: thanks [17:04] hi all - how can I tell if bzr thinks a file's binary? [17:05] New bug: #198422 in bzr-gtk "Annotate doesn't show active revision" [Low,Triaged] https://launchpad.net/bugs/198422 [17:20] tbnorth: the only way I know is to edit the file and run bzr diff. binary/not binary isn't much of distinction in bzr currently though, why would you like to know? [17:21] I use an IDE that changes the EOLs, I have a script that changes them back (i.e. makes working copy EOLs match last revision) I don't want the script tripping over binary files [17:21] New bug: #198425 in bzr "bzr info should not say "shared repository" unless it is actually a shared rather than colocated repository" [Low,Confirmed] https://launchpad.net/bugs/198425 [17:24] james_w: so perhaps I should do my own test for binariness === pmezard_ is now known as pmezard [18:00] New bug: #198441 in bzr "Windows XP install nit: missing new program highlight on start menu" [Undecided,New] https://launchpad.net/bugs/198441 [18:14] jelmer: fwiw, there's no python-subversion update in gutsy-backports, but the dependencies to take it directly from hardy aren't too bacd. [18:14] s/bacd/bad/ [18:18] spiv, ah, ok [18:18] jelmer: svn-import of Twisted seems to be stable at ~79MB, which is a dramatic improvement :) [18:19] Hmm, spoke too soon. It just jumped to 145MB... still doing much better than before though. === ferringb is now known as he-man === he-man is now known as ferringb [19:00] is there a way to grab source from a repository but not the .bzr directory? [19:01] I'm grabbing a project now and the .bzr directory itself is over 300MB, that's overkill considering I just want to build the project [19:02] cr3: I believe you could do a lightweight checkout (bzr branch --lightweight) [19:02] er, bzr co --lightweight rather :) [19:02] TFKyle: I'm not convinced that it's really much faster. [19:02] TFKyle: thanks, I'll try that [19:02] it might involve downloading fewer bytes but I don't think it'll actually be "faster" per se [19:03] cr3: the real feature you want is shallow branching *cough* *cough* (looks at jelmer, lifeless , and those at the bzr sprint) [19:03] possibly, not sure exactly how it works [19:22] jdong: branch compared to co --lightweight was 5 times bigger, significant difference. thanks! [19:23] cr3: I know it's gonna be bigger, but I didn't know whether or not it's gonna be faster [19:24] cr3: slight disclaimer, I've got a gigabit internet pipeline so YMMV :D [19:24] cr3: and I'm not sure if it works, but bzr export might be able to operate on a branch URL and be even faster? [19:30] bzr export DEST [BRANCH] [19:44] <_flx> hi [19:45] <_flx> what is the migration procedure for a bzr server 1.1 to 1.2 ? [19:46] I believe just do the upgrade? Nothing broke backwards-compatibly [19:46] (I think) [19:50] <_flx> jdong: Thx it worked [19:50] great to hear [19:50] New bug: #198479 in bzr "crash: "bzr branch https://code.launchpad.net/~bzr/bzr/trunk"" [Undecided,New] https://launchpad.net/bugs/198479 === n2diy__ is now known as n2diy [20:46] hi mwhudson_. It's good to see loggerhead still getting standalone releases. Thanks. === mwhudson_ is now known as mwhudson [20:46] james_w: news travels fast :) [20:47] james_w: are you at the bzr sprint? [20:47] mwhudson: I arrive on Thursday. Are you there> [20:47] james_w: sadly, no [20:48] having flown half way around the world moving from the uk to new zealand, my response to "hey! do you want to fly back to the uk again in a few weeks?" was, perhaps, predictable [20:48] :-) [20:48] I think you got the better end of the deal though. [20:50] New bug: #198519 in bzr "'Connection timed out' on lp branch attempt shouldn't result in a crash" [Undecided,New] https://launchpad.net/bugs/198519 === thumper_laptop is now known as thumper === hexmode`` is now known as hexmode [22:35] hi [22:35] New bug: #198552 in bzr-gtk "Doesn't apply bzr metadata-only changes to files" [Medium,Triaged] https://launchpad.net/bugs/198552 [22:36] i'm trying to branch a https:// repo but get a curl error: [22:36] curl.perform() [22:36] error: (60, 'server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt') [22:36] philn__: If you're on Ubuntu or Debian, make sure your ca-certificates package is up-to-date. [22:37] hi radix ;) [22:37] yo :) [22:37] using gutsy here plus pinned hardy .. ca-certificates is up-to-date [22:37] philn__: And you have the -updates repositories enabled? [22:38] 20070303 [22:38] hmm lemme check [22:38] hmm, yeah, that's what I have on Hardy. [22:38] i have gutsy-updates yes [22:39] should i try some bleeding bzr edge? [22:39] I dunno, I'm not sure what the problem is. It doesn't sound like updating bzr would make a difference. [22:39] philn__: oh, wait, what's the https:// server you're trying to branch from? [22:40] it didn't, had exact same error with gutsy version [22:40] philn__: maybe it really doesn't have a certificate that is registered with your system [22:40] it's a seecreet server ;) [22:40] philn__: and is it signed by a "normally trusted" CA? [22:41] or is it some self-signed cert? [22:41] how can i know that? [22:42] philn__: Well, does your browser complain when you visit the site with it? [22:43] (or did it complain and did you permantly accept the certificate anyway, some long time ago? ;) [22:43] you can also try using bzr branch https+urllib://whatever/... [22:43] ah. is that the way you get around verification :) [22:44] i get a warning in my browser yes [22:44] mwhudson: tries that; didn't work [22:44] what happened ? [22:44] SubversionException: ("PROPFIND request failed on '/blahblah') [22:45] wtf, it's not a svn repo ;) [22:45] oh dear, so you're also trying to branch an svn branch? [22:45] oh. [22:45] * radix looks at mwhudson [22:46] looks like that /svn_path comes from my ~/.subversion directory btw [22:47] oh er what? [22:47] I got no idea. [22:47] philn__: i guess you could try --no-plugins too [22:48] mwhudson: dude, it works :) [22:49] cool [22:51] thx mwhudson and radix [22:52] the subversion exception is some kind of bug, clearly [22:52] don't know if it's reported yet... [22:54] i can report it if needed [22:55] Would that be #192743? [22:58] i have a $HOME/.svn .. so could be yes [22:58] Bug #192743 [22:58] Launchpad bug 192743 in bzr-svn "bzr-svn is irritating when in a (non-svn) subdirectory of an svn working tree" [Wishlist,Invalid] https://launchpad.net/bugs/192743 [22:59] how do i do a get without having any of the .bzr directories? [23:00] heading bed, gn8 [23:00] nslater: Could you expand on your problem a little? [23:01] i would like to do "bzr get -r 666 http://example example" but not have the .bzr dirs [23:01] i thought export would do it, but alas no [23:01] nslater: Where do you not have the .bzr dirs? [23:02] can you rephrase please? [23:04] Odd_Bloke: ? [23:04] nslater: Which location does not have the .bzr dirs? [23:04] im not sure what that means, i want to create a local directory of the repository with no .bzr directories [23:05] nslater: in what way does 'bzr export' not do what you want? [23:05] nslater: Do the bzr get and then bzr export locally. [23:05] bzr export -r 86 http://intertwingly.net/code/venus/ planet-venus-0~bzr86.orig [23:05] bzr: ERROR: Not a branch: "/home/nslater/svn/python-apps/packages/planet-venus/trunk/planet-venus-0~bzr86.orig/". [23:06] do i really have to do two operations to get a "clean" version of the repository? [23:06] nslater: arguments go the other way round [23:06] Odd_Bloke, is there coffe up there? my gf keeps kicking her adsl modem, so the conversation is taking a bit longer than expected [23:06] s/coffe/coffee [23:06] beuno: Yeah, there is. [23:06] Nice hot choocolate too. [23:06] nslater: bzr export -r 86 planetblah http://... [23:06] Verterok, mate? [23:06] trying with reversed arguments [23:07] beuno: yeap [23:07] Verterok, be up in ~15 then [23:07] bzr export -r 86 planet-venus-0~bzr86.orig http://intertwingly.net/code/venus/ [23:07] bzr: ERROR: Connection error: while sending GET /code/venus/.bzr/branch-format: (111, 'Connection refused') [23:07] * Verterok 'll be waiting [23:07] it works fine for a "get" [23:08] it's really slow, is that normal? [23:08] another error: [23:08] bzr export -r 86 planet-venus-0~bzr86.orig http://intertwingly.net/code/venus [23:08] bzr: ERROR: Connection error: while sending GET /code/venus/.bzr/repository/knits/eb/%254c%2549%2543%2545%254e%2543%2545-20060830201635-546cbbdb8a049f22.kndx: (111, 'Connection refused') [23:09] I''m having intermittent trouble reaching that website in my browser [23:09] nslater, the first thing to do would be to upgrade your storage format (although it's unrelated) [23:09] as well as with bzr [23:09] beuno: what do you mean storage format? [23:09] beuno: nslater is branching someone else's branch [23:10] bob2, aaah, right. nslater nevermind than, carry on [23:10] :) [23:10] hmm, i am also getting general errors from that site [23:10] weird, it was working before [23:11] nslater: Try pulling into a shared-repo, you'll be able to do it in segments (i.e. resume when the connection fails). [23:11] sorry, i dont know what that means [23:11] also, this needs to work reliably with no assistance [23:12] bzr init-repo blah ; bzr branch htp://... blah/blah ; bzr export foo.tar.gz blah/blah [23:12] bzr export should do what you want, it just seems that intertwingly is having network issues [23:13] okay, thanks [23:13] the init-repo thing is what Odd_Bloke was sugesting, since the "branch" command will resume if rerun [23:19] okay, thanks for all the help guys! [23:34] so hm [23:34] Verterok, on my way up [23:34] i want to know the set of revisions that are introduced by the revision [23:34] * Verterok hopes so :P [23:35] i.e. those revisions which are ancestors of revision X but not of X's left-hand parent [23:35] oh er [23:35] find_difference! [23:45] mwhudson: Unfortunately, that method's not completely accurate. [23:46] abentley: ah [23:46] The accurate way is to use get_ancestry on both revisions and then do set operations. [23:47] We are strongly interested in making find_difference accurate, since it scales much better. [23:48] Good night. [23:49] seems pretty slow [23:49] good night