[00:00] Well, I think with bzr:// your access-control options currently reside in your firewall... [00:00] and filesystem hopefully [00:02] time for bed today, time for bzr tomorrow :) - thanks for clarifications [00:02] Oh, I guess. I'd assumed you wouldn't have anything under bzr://'s root except what you wanted to serve. [00:03] bzr has a soft chroot facility [00:03] you can limit it to a branch/repo easily [00:03] and auth is done via the protocol [00:03] e.g. ssh, or http provide authentication [00:03] raw bzr:// does not currently have authentication, so its only suitable for anonymous access [00:09] abentley: ping [00:09] ping [00:09] looking at this graph thing [00:09] I'd like to change heads() to use a single parents() call each iteration [00:09] rather than having a set of searchers [00:11] So then how do you know when you're done? [00:13] I'm decoupling the points we're at search wise from the parents() lookup [00:13] so there would still be a searcher concept but its not being used to retrieve data [00:14] hey guys [00:14] this means that each iteration will have just one parents() lookup, rather than one per side [00:14] lifeless, do we need medusa to run the bzrlib tests? [00:14] the ftp ones yes [00:15] lifeless, were these enabled recently? [00:15] they auto enable if they can [00:15] if you' [00:15] odd [00:15] if you're running the tests via bzr selftest it won't error if its absent [00:15] bzr: ERROR: exceptions.UserWarning: You must install medusa (http://www.amk.ca/python/code/medusa.html) for FTP tests [00:16] bzr 0.18.0 on python 2.4.3.final.0 (linux2) [00:16] arguments: ['./bzr', 'selftest', '-v'] [00:16] ** please send this report to bazaar@lists.ubuntu.com [00:16] * kiko scratches head [00:16] if you're running make check, which we use for regression tests on pqm, then it requires all optional modules to be present [00:16] no [00:16] it's being run like this: [00:16] python -Werror ./bzr selftest -v [00:17] well [00:17] lifeless: Well, my inclination would be to have the searchers conspire to reduce lookups. [00:17] remote the -Werror if you want to be able to not have medusa installed [00:18] But I wouldn't oppose your approach. [00:18] ok [00:18] I'll spend some time grokking the code more [00:20] i.e. you do next(), and it causes all searchers to buffer their next output. [00:23] I think there are really three concepts here [00:23] A 'reachability cache' [00:23] or 'searched revisions' or something like that [00:23] 'getting parents' [00:24] 'choosing what revisions to examine next' [00:24] I'll fiddle somewhat. Firstly I'm going to instrument it slightly to figure out what its looking at at the moment [00:26] oh, hmm. just notced [00:26] KnitParentsProvider looks up single parents at a time [00:26] I'll fix this first [00:28] abentley: btw, a note on the api, if I might === kiko is now known as kiko-zzz [00:29] get_parents(["x", "x"]) seems to be awkward, it might be nicer to do the self-associating style of result I've done in the index layer [00:29] kiko, lifeless, that does seem to be a bug that it's giving a warning not a missing dependency - just old code i guess [00:30] yes? [00:31] lifeless, it looks like the packs megapatch still needs more reading, so i'm going to do that today [00:31] unless something else comes up... [00:31] abentley: yah, if you cast the query into a set, or want to gather answers by the best IO pattern, you have to buffer and do housekeeping in the parents provider; but the caller actually doesn't really care AFAICT. [00:34] I'm just doubtful that, in general, splitting the "searcher" part from the "parents retrieval" part is actually going to lead to more readable code. [00:34] I'll be careful ;) [00:34] for now, I'm just implementing _make_parents_provider and get_parents directly on PackRepository [00:35] Yes, that will be much nicer. [00:35] its a necessary step [00:35] it may not be sufficient, we'll see [00:40] much better [00:40] still kinda slow [00:40] but much better [00:40] (it was fast enough I didn't have time to ctrl-C it) [00:41] poolie: yes, reading the packs patch is good [00:42] morning all [00:43] hi igc [00:43] bbiab, getting food [00:43] hi lifeless [00:43] while this test runs === mw is now known as mw|out [01:32] poolie_: igc: incremental patch 2842 sent to bazaar-commits, and pushing now [01:33] thanks [01:42] hi nDuff , how are you ? [01:42] busy. [01:42] interesting times. [01:42] yourself? [01:42] You live in China ? [01:42] heh, no. [01:42] Busy - putting the polish on our new repo format. [01:44] Which also has a negative effect on times, one hopes ;) [01:45] New bug: #153774 in bzr "Unreachable network raises an AssertationError (bzr+ssh)" [Undecided,New] https://launchpad.net/bugs/153774 [01:47] How are 'yall doing performance-wise these days in comparison with mercurial? I'm looking for a way to track the upstream portage tree we're using to build our servers; it's over 100,000 files, there are lots of removes and adds of similar files on a regular basis, but we don't care about much in terms of functionality beyond basic snapshotting. [01:48] on my laptop [01:48] with crypted disk [01:48] committing a 55K tree with a few changes, without specifying those files, is 20 seconds [01:49] hmm. [01:49] I'll probably want to benchmark current bzr for my use case, then [01:49] we're working on bring that down by a factor of four in the next month [01:49] you'll want to benchmark with the packs repository format [01:50] this drops the number of files in your repository [for your scenario] from 200,000 to 5 * log10(commits) * 10 as an upper bound [01:51] specifically a 100000 file repo with 10000 commits will have 5 data files. 10001 commits will have 10, as will 10010 etc, 10002 will have 15 data files. [01:52] is that included in 0.91? [01:52] nope. [01:53] its what I'm polishing right now, the patch is being reviewed at the moment. [01:53] I can throw up a tarball easily for you [01:53] if you could do that, or just point me at somewhere I can pull from. [01:53] the place its hosted is in pack format already - I'm dogfooding :) [01:53] ahh. [01:54] a tarball, then, yes. [01:56] http://people.ubuntu.com/~robertc/packs.tar.bz2 [01:56] you need pyrex to build the C extensions, which you'll want for benchmarking [01:56] what else, oh yeah, committing a merge is currently pathologically slow; its a bug in the logic in the new format that I'm fixing right now. [01:57] (by pathologically, I mean 180 times slower than a non-merge commit) [01:57] you can run from source, just 'make' in the source dir, then symlink something to 'bzr' [01:58] oh, and the last thing is that we currently don't remove the obsoleted files - the .bzr/repository/obsolete-packs/ directory - in production this will be not used [01:59] to make a pack branch, do 'bzr init --experimental' [02:05] I'm not worried about merging, so that WORKSFORME. [02:05] I'll be sure to exclude the contents of obsolete-packs when determining space efficiency. [02:05] yah [02:05] we haven't optimised for space yet [02:05] thats probably another month or two down the track [02:06] we've got some very promising research figures though [02:10] jelmer: I think I've found one cause of additional reads [02:25] so, merge commits are improved lol ... 45 times slower [02:26] * lifeless codes some more [02:31] 15 times slower [02:31] Hm. I estimate that given your current rate, if you can keep that up for another 2 hours we'll be about 50x as fast as cp ;) [02:32] rofl [02:32] Extrapolation FTW! [03:22] I tried upgrading an ubuntu 6.06 system to the latest bzr using apt-get banned it only knows about version 0 .17. Is this the latest release supported for dapper or am I doing something wrong? [03:29] * igc food [03:29] * piedoggie tosses pizza [03:30] New bug: #153786 in bzr "pack repositories do not retry when concurrent operations pack" [Undecided,New] https://launchpad.net/bugs/153786 [03:35] New bug: #153787 in bzr "annotation is slow in pack repositories" [Undecided,New] https://launchpad.net/bugs/153787 [03:55] New bug: #153788 in bzr "pushing from packs to knits is slow and does not indicate why" [Undecided,New] https://launchpad.net/bugs/153788 [03:55] New bug: #153789 in bzr "old packs are kept indefinately" [Undecided,New] https://launchpad.net/bugs/153789 [04:22] abentley: still around ? [04:26] abentley: I've found the bug [04:26] abentley: find_seen_ancestors accesses 1000's of revisions [04:50] lifeless, to confirm, there's no good reason why our pqm needs to use https? === jdong_ is now known as jdonginator [04:52] poolie_: ack [04:52] hows the review going? [04:52] interruptedly, but getting more into it now [04:52] one more question, about the bug of problems when retiring packs [04:53] would it work better, i wonder [04:53] to not move the packs, but instead keep a journal of retired packs [04:53] and just exclude them from the index [04:53] two problems with that [04:54] one is reconcile/gc operations where you want to change the data clients see [04:54] the second is that it becomes a clock synchronisation problem [04:54] (if you do it by count of operations a fast client breaks slow clients, if you do it by clock a bad clock results in clients being broken) [04:55] not to say its the wrong solution [04:55] but I don't think its any more complete, just will have some impact on frequency [04:57] hm === jeremyb_ is now known as jeremyb [05:58] spiv: is the search order of a set stable in a single process? [05:59] spiv: that is if I have a set S, and do list(S) == list(S) is that guaranteed true ? [06:01] lifeless: I don't think so. [06:01] lifeless: because values with colliding hashes might come out differently, iirc. [06:07] lifeless: http://rafb.net/p/WV5cRP27.html demonstrates a case where s_a == s_b, but list(s_a) != list(s_b). [06:07] spiv: I don't care about different list instances [06:07] spiv: just repeated iterations of the same list. [06:08] I have an API to use that returns a list for the things in an iterable; if I pass in a set to it, I need the same iteration order to zip them back up again [06:08] If the two sets are constructed the same way, and are manipulated the same way (so have the same sequence of additions, removals, etc), then in CPython you're probably safe. [06:10] no [06:10] SAME INSTANCE [06:10] Or if you're asking about the same set object, with no changes to the state of that set object between listifications, that's probably safe as well. [06:10] sorry for shouting but it was clearly not getting through [06:10] But I don't think that's guaranteed. [06:10] I'm looking for more than "probably" [06:10] Shouting on IRC doesn't hurt ears, I'll cope :) [06:11] :) [06:11] still somewhat rude :0 [06:12] Your so polite lifeless, yet irc so vile.. [06:13] wait, ive been drinking with you before. I take it all back [06:16] lifeless: yeah, I cannot find any guarantees on that in the documentation (or source) for set or for frozenset. It strikes me as something that it might be uncontroversial for frozensets to guarantee, but I doubt python-dev would extend that to sets. [06:22] i386: :) [06:32] spiv: thanks [06:42] sabdfl: hi, man :-) [07:42] lifeless, hi, more than half done [07:42] lifeless, several of the methods changed to return tuples- can you remind me why? [07:44] two reasons [07:44] historical data isn't meant to be mutable, so tuples are a better fit [07:44] GraphIndex, which backs mapped knits returns tuples [07:45] so the test was broken as some repo's returned lists and some tuples, so I had to coerce it one way or the other [07:45] and I chose tuples [08:21] If I have some code that I'd like automatically contain the revision number of the bzr tree it's in, how would I do that? Should I add a call to "bzr revno" somewhere in my build system to save it, or is there something like CVS' magic $Revision$ markers or something entirely different? [08:23] i'm pretty sure there's nothing like $Revision$ [08:23] you could probably write a post-commit-hook to put it in a file somewhere, i guess [08:24] There's no $Revision$ magic at the moment. Keyword substitution leads to awkward problems that we haven't tackled yet. [08:24] Ah, bzr has post-commit-hooks? I did not even know that. /me blushes [08:26] at least, i think it does :) [08:29] soren, you should use the version-info command to write it into a file [08:30] poolie_: Ok. [08:30] poolie_: How about commit hooks? Does bzr have anything like that? [08:32] soren, yes, though at the moment they're exposed as python hooks not as shell commands [08:33] poolie_: Oh, ok. [08:33] basically, you should write a python module in ~/.bazaar/plugins/ [08:33] and have that call [08:34] Branch.hooks.install_hook('post_commit', your_hook_here) [08:34] we know many people would like to just specify a shell command and we will try to do that soon [08:35] poolie_: Right. I'd especially like the commit hooks to be part of the source repository so that anyone using the source tree will have them. [08:53] spiv: does your "speed up reconcile" patch also speed up check? [08:57] sabdfl: it does, but it would only speed up the new checks added by the reconcile work. [08:57] sabdfl: so I expect it will still be very slow. [08:57] thanks spiv. i had to ^C a check on LP yesterday after 5 hours when it hit 1.7GB RAM [08:57] Ouch. [08:58] any prospect of cutting that down easily? [08:58] I don't know of any good reason why it needs to consume unbounded memory, so quite possibly. [08:59] That does smell a bit funny. The check/reconcile code is a bit ugly, it has to delve into the sorts of details I didn't even know existed until quite recently :) [08:59] But I would not be surprised to find there's something grossly inefficient lurking in that code. === poolie_ is now known as poolie [09:10] Does seem like a section of the code that hasn't gotten much optimization attention. [09:10] After all, only pessimists would run check in the first place ;) [09:18] you would think that check could work one revision at a time and so that memory use shouldn't really grow [09:19] maybe that's naive though [09:20] * fullermd points and laughs at mwhudson's naivete. === ealden_ is now known as ealden [09:38] hi :) === mwh_ is now known as mwh [12:28] I checked out a Subversion repo using bzr. Then branched it to do some work. Now I can't remerge my work... apparently the repository formats are incompatible. Can anyone help me merge my code back upstream? [12:30] What's your error message? === kiko-zzz is now known as kiko [12:32] Would you guys have anything to do with this spam: Britney Spears poses nude in Bazaar === mrevell is now known as mrevell-lunch [12:34] bzr: ERROR: Repository KnitRepository('file:///home/scott/Projects/transit/move-to-paste/.bzr/') is not compatible with repository KnitRepository3('file:///home/scott/Projects/transit/transit-svn/.bzr/') [12:35] Lo-lan-do: Sorry, that was to you. [12:36] How recent is your bzr-svn? [12:37] You may have to do "bzr upgrade --format=dirstate-with-subtree" [12:45] Lo-lan-do: On which repo? [12:45] Lo-lan-do: Bazaar (bzr) 0.90.0 [12:49] no release this month? ;) [12:50] Lo-lan-do, the non-bzr-svn one [12:51] zerok: been delayed a bit in order to have packs (new, much faster, format) in [12:54] Grr. [12:54] Slant_Laptop: I think " Lo-lan-do, the non-bzr-svn one" was for you [12:54] Now it appears to have forgotten the common ancestor. [12:54] :-\ [12:55] Slant_Laptop, was the original branch created using bzr-svn 0.3? [12:55] jelmer: Will bzr-svn use that packs format, or will it keep its own non-documented format? [12:55] jelmer: I don't know. Whatever is in gutsy. How can I check? [12:55] Lo-lan-do: dirstate-with-subtree is not bzr-svn specific [12:56] it was meant to be the next format (as part of the move to nested trees) [12:56] jelmer: I know, but apparently only bzr-svn uses it... [12:56] Lo-lan-do: bzr-svn requires a format that supports subtree data [12:57] there will be a variant of packs that supports subtrees as well [12:57] Ok, so now I'm trying to merge the branch back into the svn checkout... [12:57] How can I manually specify the common ancestor? [12:57] (Which I happen to know is rev 80) [12:57] I think you should be able to do something like 'bzr merge -r80..' [12:58] but that will just do a cherrypick, not track history [12:58] It says "all changes applied succesfully" but no changes have actually been made. [12:59] perhaps "-r80..-1" or something [12:59] Wee. [12:59] Exception. [13:01] That was fun. [13:01] My X session died. [13:01] I missed anything that may have been said, sorry. [13:01] Slant_Laptop: You didn't miss anything [13:01] Darn. ;-) [13:02] Well, then it does seem I'm kinda screwed. There isn't any way to get these patches upstream? [13:02] Slant_Laptop: What exception did you get? [13:02] You can always try a bzr diff -rsomething and commit the patch to SVN by hand [13:03] jelmer: One sec, I'll pastebi. [13:04] jelmer: http://pastebin.com/d168541a8 [13:06] Slant_Laptop: if this is a public project, please file a bug.. that shouldn't happen :-) [13:06] jelmer: It's not, sorry. :-( [13:06] other than that, I'd recommend just using diff and patch like Lo-lan-do says [13:06] or perhaps version 0.1 of the rebase plugin [13:07] There's an awful lot of patches and logs. Darn. [13:07] Rebase? [13:07] jelmer: By the way, current bzr-svn refuses to work with bzr 0.91. Is that deliberate? [13:08] Lo-lan-do: I thought there was a way to export a series of patches with the version information attached to them, and then merge that into a tree? [13:09] That may be what's referred to as "bundles", but I haven't tried that yet. [13:10] Slant_Laptop: yes, but that uses the same mechanism as merge [13:10] Lo-lan-do: yes, there were incompatible changes so the next version of bzr-svn will only be compatible with 0.92 [13:10] I see. [13:11] jelmer: Oh, darn. [13:11] Slant_Laptop: rebase (a plugin) just replays the commits while retaining commit metadata [13:12] Slant_Laptop: You may be able to use 0.1 of that (http://bazaar-vcs.org/Rebase) [13:13] jelmer: Checking that out. [13:13] jelmer, cool :D (sorry for the late reply... too many windows open :S ) [13:14] faster is great ... on my 12" powerbook bzr is dead slow :( [13:14] mwh: your push bug should be fixed now [13:18] Is there a way to install plugins without needing root? [13:18] :-\ [13:19] sure. install them under ~/.bazaar/plugins/name_of_the_plugin [13:21] dato: Cool. Thanks. [13:22] Slant_Laptop: just note that the directory names should not contain hyphens. eg. install bzr-svn under plugins/bzr_svn or plugins/svn [13:23] jelmer: Umm. Haha, I'm getting the same error. :-D [13:24] abentley: ping [13:25] abentley: do you have any idea what could be causing the error at http://pastebin.com/d168541a8 ? [13:26] jelmer: How do you tell rebase the ... uh, base? [13:26] Slant_Laptop: sorry, I have a class to attend right now [13:26] jelmer: Ok. Thanks for your help thus far. [13:26] if you'd rather fix this than use diff+patch, please send me an email (jelmer@samba.org) [13:27] jelmer: I kinda need to commit several hours ago. ;-) So I'll be writing a script to diff+path now. Thanks, though. === mrevell-lunch is now known as mrevell [14:14] does one need to run bzr check before bzr reconcile, or can one just run bzr reconcile? [14:30] need some help with bazaar advocacy [14:30] discussing using it at work [14:30] been using it a while personally and don't have much experience with svn [14:30] some one mentioned atomic commits [14:31] zeasier: bzr has those as well [14:31] where if part of the commit goes wrong the whole commit gets rolled back [14:31] yeah i thought it did [14:31] zeasier: cvs had per-file revisions, which sucks since it can leave you in an inconsistent state afaik [14:32] yeah that's why i wasn't prepared for that question, never used cvs [14:33] zeasier: and you can also use bzr in a centralised way, i.e. you have to be up-to-date to the "main" branch before you can commit [14:33] zeasier: you can use it both distributed, and centralised like SVN [14:33] yeah i've heard of this [14:33] mostly been using it decentralized so far [14:34] making good progress though only our sys admin needs convincing [14:34] zeasier: server requirements are NONE. [14:34] bosses seem to be alright with it [14:34] yeah that's very apealing [14:35] zeasier: but you can run a smart server for performance [14:35] but sftp/ssh access is enough [14:35] i was pretty happy with the built in ssh support in the fiesty release [14:35] that's the recommended way to use it indeed [14:36] though looks like we'll be using the central bzr apt repo, because of days like today [14:36] where half of the office has time to upgrade and the other doesn't [14:37] don't know how picky bzr is about different versions [14:37] but don't want to push our luck [14:37] latest versions are pretty compatible with each other [14:41] small question regarding the centralized approach: when commiting to the central repo, are there some hooks that could be used on the server to for example send update mails or update a feed? === mw|out is now known as mw [14:46] that sounds like a plugin issue (don't know the answer) might try to find some docs on plugin apis [14:49] yeah, i was just wondering since i found some docs on the hooks but everything smelled very client-sidey ;) [14:49] one thing you could do is create a wrapper script [14:50] like zbzr or something [14:50] intercept commit commands and send what you want [14:50] then forward the rest to bzr [14:51] in anycase i'd imagine any solution you use would have to be client side [14:51] unless the smart server has hooks or something [14:52] yeah. tnx :) [14:52] (again don't take my words as authority) [14:53] ;-) [14:53] anyway: time to go home. cu later :-) === bac_afk is now known as babc === babc is now known as bac === cprov is now known as cprov-lunch === Solarion_ is now known as Solarion [16:54] bzr on windows is using builtin ssh client? [16:55] i need to setup public key auth [16:55] yes, it's using paramiko [16:56] it should be able to talk to pageant, for example [17:02] oh, it works [17:03] how to reference user home directory in sftp url? sftp://hsn@10.0.0.2/~hsn/java-devel/ dont works === kiko is now known as kiko-fud [18:22] * zerok wants to thank whoever insisted on making the api that simple :D http://dpaste.com/22802/ [18:29] zerok: we tried to stop them. [18:29] i can imagine :) [18:55] oh, dpaste.com is pretty [18:56] yeah, though it breaks all the indentation [18:56] dpaste.com sucks. When you reply to a paste, it doesn't link them together. [18:56] unless there isn't any [18:56] But it is a little weird to iterate over all entries just to take the last one [18:56] jam-laptop: really? that'd be, uhm, bad. [18:58] I suppose it is a little bit prettier than http://rafb.net/p/a6VXmd22.html [18:59] I use rafb.net, but it annoys me when I have to paste non-ascii stuff: always serves my utf8 as latin1 [18:59] http://paste.pocoo.org/ ? [19:00] jam-laptop, sure, it was just a quick-hack :) [19:00] rafb only seems to keep pastes for about a day [19:01] jam-laptop: indentation seems to work here? [19:01] dato: yeah, I just misread the initial post, it didn't indent anything [19:01] ok [19:01] jam-laptop, and i couldn't find a simple way to get the last changelog entry for that specified file without iterating over all the revisions in the first place ;) [19:02] I can't say I like the color scheme of: http://paste.pocoo.org/show/6556/ [19:02] but it seems to have the same level of syntax highlighting as dpaste [19:02] looks like the default pygments [19:02] zerok: try this one [19:03] zerok: http://paste.pocoo.org/show/6557/ [19:03] ie.revision is the last revision that modified the file [19:04] I think the difference between that and the log stuff [19:04] ah thanks :) [19:04] is that the log will also track down entries that merged it [19:04] (So if I change setup.py and you merge it without changing, ie.revision points to me, but log will also include your merge) [19:04] requires an explicit read-lock i guess :) [19:04] zerok: yeah [19:04] But i would do that anyway [19:05] http://paste.pocoo.org/show/6559/ [19:05] yeah sure, this was just more or less a quick hack to find out if this would end up like that expedition i had with hg in the same territory :P [19:05] Otherwise it has to read the working state for the path2id [19:05] and then read it again for the .inventory [19:05] zerok: was it better or worse ? [19:06] well, i'm still on the whole hg thing so bzr beat it by an hour so far :P [19:06] bzrlib.errors.InvalidRevisionId: Invalid revision-id {None} in KnitRepository('file:///Users/zerok/projects/rstsuite/.bzr/') :S [19:06] ... oh, that is because this is the working tree. [19:06] sorry, you want the basis [19:07] np, speed isn't really an issue with this project when it comes to determining that timestamp :) [19:08] http://paste.pocoo.org/show/6560/ [19:08] zerok: you could also look into "bzr version-info --all --format=python" [19:09] O_o [19:09] It dumps the state of the whole tree [19:09] well, it will be used inside of a python program :-) [19:10] and some basic information about the revisions to this poin [19:10] thanks again :) [19:10] point [19:10] There is also a --format=rio [19:10] and I think we are about to merge a --format=C [19:10] O_o [19:12] there shouldn't be any problem with unicode in changelog messages, right? [19:15] zerok: We support Unicode messages [19:15] Problems are up to you :) [19:15] ah ok, just wanted to make sure :) [19:15] For example, trying to commit a iso-8859-1 formatted message and your LANG=C [19:16] or LANG=en_US.UTF-8 [19:16] The one we see the most often is someone trying to use Unicode [19:16] but their system claims to be ASCII [19:16] :S [19:16] (thus we have no way to interpret it) [19:17] i had some problems a while back thanks to probably a broken bash or simply a missing font for my terminal and just switched to a VEDITOR ;-) === kiko-fud is now known as kiko [20:01] New bug: #154021 in bzr-eclipse "Reverse odering of revisions in Bazaar Log window" [Undecided,New] https://launchpad.net/bugs/154021 [20:05] What's the syntax to rolling back changes on a file using bzr merge? [20:08] gotgenes: you want to make the contents of a file the same as it was a few revisions ago? [20:08] or you want to remove the changes made by a commit a few commits back in the history? [20:08] james_w: that would be a bzr revert [20:09] yes [20:09] james_w: is there a way to strip out changes from a particular revision? [20:09] the second item [20:10] hey is this a good chanel to ask questions, or is it a dev channel? [20:10] gotgenes: bzr merge -r -3..-4 [20:11] and then bzr revert the files that you want to keep the same. [20:11]