[00:00] thrope: sure, probably just use a file:// URL [00:00] got it with the svn+file [00:04] how can I push to a seperate branch with no shared histroy [00:04] I'm trying to push to an empty branch [00:15] hi [00:15] how do you delete a project in launchpad? [00:30] meoblast001: you have to request it in launchpad answers [00:30] there's no way to do it yourself [00:31] ok [00:31] thanx === bac is now known as bac_afk [00:31] #launchpad would be the place to ask though [00:31] ;) [00:33] beuno: ping [00:34] jfroy|work, thanks, just replied [00:34] jelmer: and I sadly just spammed you with the same merge bundle... [00:35] Apparently send -r respec doesn't mage a merge bundle for the specified revisions... [00:35] I'm not sure how to send you a separate merge bundle for the foo fix, and another one with the test suite changes. [00:36] jfroy|work, you probably have to recommit the changes on separate branches [00:36] :sigh: [00:42] i always forget this specific bazaar command when i dont commit changes often [00:42] i think it's bzr -ci but im getting error [00:42] bzr ci [00:42] ah thanx [00:43] oops.. how do i register a folder as a branch.. havent done that in a long time [00:44] meoblast001, bzr init [00:56] Peng_, pong [00:56] beuno: Hi. [00:56] Err, wait, I wanted to go watch TV in 3 minutes. === kiko-afk is now known as kiko-zzz [00:57] beuno: Anyway, I wanted to poke you about the traceback Googlebot likes causing. [00:59] beuno: Ignoring the part about how Googlebot found a bad link (and if it really should be a bad link), there's a second traceback that looks to me like a bug, but I dunno. http://paste.pocoo.org/show/91709/ [01:00] ...Bye. [01:00] Peng_, thanks, enjoy [01:00] Thanks. [01:05] why am i getting Launchpad user 'braden' doesn't have a registered SSH key [01:05] it works on my other projects [01:06] this makes no sense [01:07] meoblast001, can you ssh into bazaar.launchpad.net? [01:07] ok [01:07] wait.. i think i figured it out [01:07] i forgot meoblast@ [01:07] right [01:07] you can set that up in .ssh/config [01:08] set a rule for the bazaar.launchpad.net host [01:08] nah its ok [01:09] beuno: would you be interested in helping out with my day old project? [01:09] with many bugs [01:09] welll... 1 bug [01:10] uhm, I should probably try and keep up to date with my current projects before getting into new ones ;) [01:10] With bzr 1.9 you don't need the user in bzr+ssh://bazaar.launchpad.net/ URLs (and in previous versions, you can probably edit authentication.conf to set it up.) [01:12] spiv, hi, are you around? [01:12] I am. [01:13] abentley: I'm having problems with bzrtools with the nightly bzr ppa [01:13] abentley: 'module' object has no attribute 'diff_writer_registry' [01:14] are you busy today? i'd like to talk about the Ideal hpss stuff [01:14] thumper: it sounds like your bzr is too old. [01:14] abentley: it says 1.10 dev [01:15] poolie: I'd like to talk this afternoon about it [01:15] poolie: perhaps in an hour or so? [01:15] thumper, sure, together with the three of us, or pairwise? [01:16] poolie: sorry, I thought you were talking to me :) [01:16] I'd be happy to chat about ideal hpss stuff. [01:17] Although I'm starting to get hungry, so perhaps after lunch? [01:18] ok so the three of us in one hour at 2:00 utc [01:18] thumper: you need revno 3838 [01:18] poolie: or 2:30 utc [01:18] abentley: how can I check the revno? [01:18] is the nightly ppa building? [01:18] I haven't seen an update for a few days [01:19] thumper: I see it when I do bzr --version [01:19] abentley: mine just says 1.10dev [01:20] thumper: if you installed from a PPA, I guess look at the version of the package, and/or maybe the changelog in /usr/share/doc/bzr [01:20] thumper: Sorry, I don't use a PPA. It might be in the description or something. [01:21] abentley: package says 3837 [01:22] Yeah, 3838 is from Nov 17 [01:23] :( [01:25] abentley: how can I downgrade my bzrtools branch a few revisions? [01:25] abentley: as I use a bzrtools from trunk [01:26] thumper: bzr revert -r 681 [01:27] abentley: that leaves me with modifications in the tree [01:27] abentley: then just plain revert? [01:27] thumper: no, if you want to unpull, do bzr pull -r 681 --overwrite . [01:28] * thumper tries that [01:28] abentley: dude, you are a walking bzr man page [01:29] abentley: notice I didn't ask "could it be done", I just assumed that it could and I didn't know how [01:30] hehe [01:35] what's the complement of 'bzr revert --forget-merges'? [01:35] * jml remembers: "bzr revert ." [01:35] jml: right === mw is now known as mw|out === meoblast001 is now known as meo|away === meo|away is now known as meoblast001 [03:02] Heh, using "pull --overwrite" like that is a bit of an evil way to avoid "uncommit"s prompts and verbosity. [03:10] markh: I wasn't, but I'm around a bit now [03:12] hi jam - in bug 298013, the reporter notes "When adding new plugins to the standalone version of the installer many expect certain python modules to be available. Be they are not due to the fact that the standalone ships only a minimal python distribution" Do you have any thoughts on that? [03:12] Launchpad bug 298013 in bzr "latest release of tbzr spoils command line" [Undecided,New] https://launchpad.net/bugs/298013 [03:12] markh: I believe xmloutput has that "solved" [03:12] in that it packages the stdlib it expects to have available [03:13] I'm not 100% sure on that, though [03:13] I don't *think* we want to include a complete python install [03:13] and it doesn't address plugins that go outside the stdlib anyway [03:13] (bzr-gtk, for example) [03:14] jam: you mean xmloutput nominates the set of the stdlib it includes rather than ones that are strictly needed by it? [03:14] markh: no, that the packaging for xmloutput (as a separate installer from bzr-setup.exe) also includes the stdlib it needs [03:16] I think the point of that report might be that if you try and add a plugin to the plugins directory in the win32 standalone binary installer, it is likely to fail as some module it uses, but we don't, isn't packages in py2exe [03:17] I expect xmloutput finds itself in the same basic situation? [03:18] markh: the original point of the bug report was for people that use a plugin by putting it in BZR_PLUGIN_PATH [03:18] often don't find it works [03:18] because it doesn't have the necessary stdlib [03:18] or even 3rd party [03:19] xmloutput, IIRC, needed more of the XML parsing and generating libs [03:19] from stdlib [03:19] basically, it ends up that if you use the standalone installer [03:19] you need to have "proper" installers for the plugins as well [03:20] contrast that with when you install things into C:\Python25 [03:20] then it becomes much more straightforward that a plugin can run [03:20] please come up with different ways to say branch(n) and branch(v). kthxbye [03:20] and where you need to install any dependencies. [03:20] jml: branch'n branch'v ? [03:21] jam: I'm a little confused - that bug report doesn't make any reference to BZR_PLUGIN_PATH or xmloutput. IIUC, our windows installer explicitly leaves plugins on the file-system rather than in the .zip so additional plugins can be plonked there. Am I misunderstanding? [03:21] jml branches a branch to make a new branch branched from the old branch. [03:21] markh: they can also plunk them in APPDATA/bazaar/plugins, IIRC [03:21] but the point is plonking them somewhere that gets auto-loaded [03:22] correct - but if they fail due to some stdlib module not existing, how should they proceed? [03:22] APPDATA/bazaar/plugins and $INSTALL/plugins are both on the default BZR_PLUGIN_PATH [03:22] markh: if you use a standalone installer for bzr, you need an installer for your plugin [03:22] I don't think we can do better than that [03:22] We *could* package all of python [03:22] we could even just bring in the python .msi file [03:22] so what would we recommend that installer do? [03:23] I wouldn't necessarily change the bzr installer [03:23] aside from helping plugins build their own installers [03:23] possibly just documenting how to do it [03:23] as it seems that xmloutput "solved" the problem for plugins [03:23] but if the "official" answer is "you can't use a plugin on windows unless it ships with bzr, or the author has made a special installer for it", I'll be happy to spread that word. [03:24] markh: well, what are our alternatives? [03:24] I would rather see a python-based installer, but it is hard to make that slick [03:24] I'm still not clear how that plugin installer would install a missing stdlib module - I guess they could ship it - but many plugins shipping copies might be somewhat strange. [03:25] and not necessarily better than documenting how plugins can install the stdlib they need [03:25] jam: an easy alternative may be to nominate parts of the stdlib we include - possibly even all of it. What is your concern there? [03:25] size? [03:25] obviously we sould avoid the subdirs that don't make sense [03:26] well, "du -ksh" seems to say that stdlib is approx 22MB [03:27] but that includes .py, pyc, and .pyo [03:27] It also says my site-packages is 97MB [03:28] interesting, bzrlib is 2x the size of PyQt4, but I bet it compresses a lot better [03:28] :) [03:30] its a cost-benefit tradeoff - istm the benefit of having more plugins work is greater than the cost of including the stdlib - especially given the number of plugin authors who would create a special installer will be approx. zero. [03:30] however, the installer is already getting enormous (14MB so far?) what's another 5MB or so [03:31] just before you disconnected I said: [03:31] its a cost-benefit tradeoff - istm the benefit of having more plugins work is greater than the cost of including the stdlib - especially given the number of plugin authors who would create a special installer will be approx. zero. [03:31] and yeah, for 5mb, that cost isn't high at all [03:31] (I'd rather see a 5MB installer *total*, but that seems to not be possible.) [03:32] yeah, long term there are a few nice things we could do [07:01] hi all [07:04] hi vila - sorry to hear about your lousy trip home [07:04] Hi Ian ! [07:05] Bah, don't worry that much, it makes for some nice memories and I learned a few lessons :-) [07:06] I'm looking to understand something about checkouts compared with svn [07:06] in SVN you can do a checkout of a sub-directory [07:06] in bzr is seems you can only checkout a branch [07:06] but what if I just wanted to checkout a sub-folder in a branch? [07:07] for ex. in my local repo --no-trees I have a /trunk/ branch with two folders /trunk/foo and /trunk/bar [07:08] I want to bzr co /trunk/foo . [07:08] eferraiuolo: You can't really right now. Or at least, last time I checked; this _may_ have changed with bzr 1.9. [07:09] It may have changed in 1.9? [07:09] RAOF: anyone using some combination of branching? [07:09] ...I'm using 1.9 and can't seem to get this work [07:09] Peng_: I know there's _some_ work on support for subtrees like this, and I haven't followed 1.9 dev... [07:10] I don't think anything new happened. [07:11] eferraiuolo: There's the 'bzr split' command, which goes about half way to what I guess you want. [07:12] That takes a subtree of a branch and converts it to a separate branch. [07:13] so I would first have to create a new branch outside my shared no-trees repo to run the split cmd on [07:13] Oh, tell a lie. As long as you don't mind hitting buttons marked "experimental", a combination of bzr split and bzr join --reference looks like it'll do what you want. [07:15] You split out trunk/foo and trunk/bar into two separate branches, then join foo & bar into trunk; if the documentation doesn't lie, you'll have a trunk/ with sub-branches foo and bar, and commits on trunk will recurse into foo & bar. [07:15] hmmm... interesting. I'll give it a try [07:16] I suspect you'll need to upgrade your branch to the latest-greatest-experimental subtree variant first. [07:17] it's on --1.9-rich-root already, which seems it should work [07:18] Looks like I will have to branch my trunk outside my repo since my repo is set to no-trees [07:18] If it doesn't work first time, I'd guess you'll need to upgrade to whatever the relevant -subtree variant is. rich-root gets you the ability to 'bzr split'; I think you need -subtree to 'bzr join', though. [07:19] eferraiuolo: If a branch doesn't have a working tree, you just need to use "bzr co" to create it.. [07:38] It's odd... bzr split is create the sub-branch, but I can't checkout or branch against the newly created sub-branch, it pulls down the whole parent branch (trunk) [08:08] eferraiuolo: I think it's by design that the sub-branch produced by the split command will include the entire history of the parent branch. [08:13] I have a repo with empty inventory sha1s 8-/ Thoughts ? [08:14] eferraiuolo: That way, if someone commits new stuff to a pre-split version of the parent branch, you stand a reasonable chance of having "bzr merge" just do the right thing. [08:15] * hmeland . o O ( Oops, that doesn't sound good. ) [08:21] So I ended up just splitting my repo for that project into to main, but separate branches and dealt with the issue that way. [08:21] thanks all for the help and insights [08:21] poolie: did you want ~mbp/bzr-usertest/277376-strict reviewed & merged? [08:21] poolie: it looks ok to me at first glance [10:54] Oh my god! "bzr check" finally finished! [10:54] Nothing was wrong. : [10:54] \ [11:12] you sound disappointed [11:20] jelmer: Well, it was an anticlimactic ending. [11:34] hey how can i ignore specific files. I have added .DS_Store to my .bzrignore file and that shows up under bzr ignored but the other lines e.g. database.php don't get picked up [11:39] Maybe database.php is already versioned? [11:43] yeah it is already versioned [11:43] so i have to remove it first? [11:44] Yes. [11:44] Ignore rules don't apply to things that are already versioned. [11:45] You could "bzr rm --keep database.php" to stop versioning it without physically removing the file. (commit too, of course) [11:59] Peng: thanks :) [12:13] jelmer: Who's building the python-flavoured 1.9 windows installers, because it doesn't have the C extensions for bzr-svn ? [12:13] awilkins, jam or markh I think [12:13] or maybe Alexander [12:14] Hmmph, maybe LP should list who uploaded a given file :-) [12:25] Is there any way to do something like svn:externals with bazaar? and point to a web address or a subversion repository something similar? [12:26] googling didn't yield anything obvious and there were a few references to "when the stacked branches" lands [12:27] That's not what stacked branches are for. [12:27] there is ConfigManager, but it seems a bit abandoned with no checkins since march 2006 [12:27] ok, then I have searched for the wrong thing :-) [12:27] That's what, uhh, by-reference subtrees (or by-reference nested trees? I forget the terminology) are for, and they've been in an experimental state for ages. [12:28] not sure I follow [12:29] There's work on stuff similar to svn:externals, but I don't think there's been any progress for ages. [12:29] anyway, what I would like is a way to point to a file in subversion so that it is updated when a user branches or that I can automatically keep it up to date in my own branch. [12:38] only 2 more failing tests away from bzr-svn 0.5rc1 \o/ [12:41] Congrats :) [12:44] \o/ \o/ \o/ [12:50] jelmer: Does 0.5 still carry the "eek, metadata may change" warning (esp for branches managed on 0.4 series) ? === awilkins is now known as awilkins_food [12:52] awilkins_food: yaeh, it does at the moment (though it's pretty stable) [12:53] jelmer: The "pretty stable" part is the best ; I'm more interested in the actual risks rather than the warning message per se :-) [12:54] jelmer: So can it operate on branches with 0.4 bzr:properties? [13:02] awilkins_food: still there? [13:02] awilkins_food: it will fetch 0.4 branch correctly [13:03] awilkins_food: I would recommend using the v3 (0.4) mappings for now though [13:03] awilkins_food: by settings the default mapping to 'v3' in mapping.py [13:09] jelmer: Using the v4 mappings presumably is the secrete sauce that makes it work better with truly horrible repository histories and layouts though? [13:10] awilkins_food: yep [13:10] awilkins_food: and which allows not using file properties when roundtripping === awilkins_food is now known as awilkins [13:11] jelmer: I think I'll build it up and try it on my "monster repo" here -this one always kills 0.4 just before it finishes branching trunk [13:12] KeyError [13:12] oh, that should never happen, not even with 0.4.. [13:12] is there a bug open about that? [13:12] yes [13:12] I've mailed you stack traces in the past [13:13] Specifically for this one ; opening the repo would not be practical alas, it's about 1.5GB as SVN FSFS I think [13:18] jelmer: I'm not certain there is a bug for it ; stack trace is in a mail dated 6th September [13:20] awilkins, any chance you can forward it to me again? [13:21] Sure, no problem. [13:24] I'm going to built the tip of 0.4 and try it out on the branch that throws it ; but not necessarily a good test, because the branch might be in a bad state which is causing the error (it has most of the revisions pulled into it by now). [13:26] For a rigorous test I'll have to pull the branch from scratch I suppose ; but that isn't fast, it takes at least 10 hours. I'll have to dump the repo and unload it at home because the IT drones have imposed a "drop into standby" policy on all desktop machines here unless you push the right button at 1900 [13:26] So I can't leave it going overnight [13:26] Because I leave at 1700 :-) [13:27] re [13:27] it should be a lot faster these days, maybe that helps.. [13:27] how many revisions is it? [13:28] Around 10,000 revisions and 1.5GB [13:28] Of revisions [13:28] Medium to large binary files, enormous number of paths [13:30] And horrible branch layout ; I tried pulling a branch that should have been a v.small revision size but it turned out to generate a rather large revision (I stopped it before it finished as it was clearly not right) [13:31] Hence enthusiasm for 0.5 [13:31] The prospect of this repo actually switching to bzr is slim but it would be nice to have options :-) [13:32] And I like to use it for the other, more reasonably sized, repos that I access. Being able to cope with a horrible monster improves my confidence :-) === bac_afk is now known as bac === thekorn__ is now known as thekorn [13:32] :-) [13:32] This repo has upward of 42,000 paths [13:32] Would split inventories improve it's performance characteristics? [13:36] awilkins: yeah, that would certainly help I think [13:36] awilkins: 10k revisions isn't that much for bzr-svn anymore these days [13:36] especially for local repositories [13:37] Is split-inventory in --1.9 ? === mw|out is now known as mw [13:37] * awilkins reads release notes [13:37] awilkins: no, not yet [14:03] awilkins: with which version of bzr-svn did that KeyError last occur? [14:08] jelmer: The version in the log is the last version I tried it with [14:10] jelmer: I'm packing up that repo so I can take it home and test it there. [14:10] jelmer: I still have the partialluy-pulled branch lying around, do you think a newer version may fix it? [14:12] awilkins: I would rather just try a new pull [14:13] awilkins: It may well be significantly faster than two months ago.. [14:13] I'm going to try a new pull tomorrow (via the ra-local layer rather than http or svn) [14:13] I could try it here as well. [14:14] I'll try both - a pull on top of that partial pull, and then a new one (I'll trash the branch, and the svn metadata cache first) [14:16] Given a diff generated by "bzr diff". How can I apply that diff to a source tree? [14:16] balor: gnu patch ? [14:17] awilkins: bzr diff is in a different format AFAIK [14:17] no, it isn't [14:17] ah, ok [14:17] AFAIK it's udiff [14:17] If it's a bundle, it's easier to use "pull" or "merge" [14:18] As long as your target is a bzr branch ( I presume it is not) [14:18] awilkins: My target is a bzr branch [14:18] why not use bzr send then? [14:19] Yes, use send or bundle [14:20] luks: I should have used bundle. But I can make do with the diff. Thanks. [14:21] don't use bundle, it's a hidde command not meant to be used anymore [14:21] hidden [14:22] My bad advice ; I hadn't noticed it was hidden [14:25] luks: So diff is my only option on a Windows machine with no network connection? [14:26] balor: no, bzr send -o thing.patch [14:27] balor: well, I assume you can get the patch of the machine, if not typing over the diff is probably the least work :) [14:27] LarstiQ: thanks === vednis is now known as mars [14:30] jelmer: Upgrading to tip of 0.4 has 2 obvious effects i) It seems to be working, it pulled that revision it got stuck on previously ii) The "determining changes" stage was a lot faster [14:32] I'll try it fresh and see how it does when it catches up with the tip [14:32] Does it still repack every revision? [14:33] no, only every 500 [14:37] Is it just me, or does the "determining changes" step often run twice, the second time much slower than the first? [14:37] Why is that? [14:38] * LarstiQ on occassion sees it running much more than two times [14:38] Peng_: I assumed it was per-file [14:38] Oh? [14:39] Meh, I can't use "1.9-rich-root" as a format [14:40] What? Why not? [14:40] Ah, that's better [14:40] I think it may be a "quirk" of my shell [14:40] Oh. [14:40] It wasn't taking the parameter [14:42] morning vila, how was your night? [14:43] jam: hi ! Pretty good, woke up at 5h30 only :) [14:43] otherwise, slept like a baby :) [14:46] well, my son woke up at... 2130, 0030, 0130, 0530 [14:46] so I hope you slept better than that :) [14:46] but I guess you got up together :) [14:46] (and no, that isn't actually UTC) [14:46] vila: have you had a chance to look at the merge issue? [14:47] jam: ouch, poor daddy :-/ [14:47] jam: yes, ready to chat about that and also about empty inventory sha1s... [14:48] and running the test suite under a solaris VM with my third hand :) [14:51] 'morning Vincent, John [14:52] LarstiQ, Peng_: "determining changes" runs once to find the branch history and then once per tag === kiko-zzz is now known as kiko-fud [14:58] jelmer: Oh, okay. [15:02] jelmer: what tag, svn tags and branches? [15:02] moin vila, jam [15:02] LarstiQ: yeah [15:02] hi LarstiQ ! [15:04] jelmer: right, that could explain it. We have more of those than I'm fond of :) [15:49] ok, with bzr-svn 0.5 importing vala (2319 revisions) over the svn:// protocol takes 258 seconds now [15:50] doesn't seem to bad to me? [15:51] yeah, that's pretty good [16:03] Heya [16:03] I'm getting errors when committing to launchpad [16:03] bzr: ERROR: Repository KnitRepository('bzr+ssh://uws@bazaar.launchpad.net/%7Euws/winwrangler/winwrangler.uws/.bzr/repository/') is not compatible with repository KnitPackRepository('file:///home/uws/Computing/Projects/winwrangler.uws/.bzr/repository/') [16:03] ... [16:04] uws: rich-root vs non rich-root? [16:04] guess so [16:04] how do I fix it? [16:05] uws: upgrade repository that is not yet rich-root to rich-root(-pack) [16:05] jelmer: how? I tried [16:05] bzr upgrade lp:~uws/winwrangler/winwrangler.uws/ doesn't work [16:05] bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format. [16:06] same for bzr upgrade --rich-root-pack lp:~uws/winwrangler/winwrangler.uws/ btw [16:07] uws: unfortunately, try sftp:// instead of lp: [16:10] LarstiQ: ok, seems to do something [16:19] LarstiQ: thanks, worked [16:32] jelmer: 0.4 isn't exactly slouching [16:32] It's done 6000 fairly hefty revisions in a couple of hours so far [16:33] Pretty much CPU limited, I'm sure using the SVN protocol as opposed to HTTP wouldn't help much [16:35] 0.5 should be better in that regard [16:35] * jelmer starts a KDE import [16:35] I'll be trying it later, barring any nasty surprises trying to build it on win32 [16:35] I'll be interested to see if it passes the "branching a tag should produce a tiny increase in pack size, not 100MB" test [16:38] awilkins: ? was there anything that didn't pass that test then? [16:38] jelmer: This repo has a somewhat horrible branch layout and some moves as well [16:39] jelmer: I tried it with an older version and branching a tag that the repository should already have had the parent revision for made a rather large new pack. [16:39] A few hundred K for the inventory, yes, over 100MB, no. [16:40] in that case, it would just end up using a different branching scheme and copying most of the history again [16:40] I messed about with the branching config a bit but never really got a satisfactory result (again, this repo is horrible) [16:40] Since 0.5 does not use the same mechanic, I shall see how it works :-) [16:41] allrightey... so i'm moving from svn [16:41] is there a way to have a svn-esque authentication system on a central bzr server [16:42] ie: bob has hsi own password, joe has his own password [16:42] rather than a shared ssh account where everyone pushes to [16:42] Kobaz: You can use HTTP methods of auth if you use the HTTP server [16:43] Kobaz: Whatever IIS and Apache support at a minimum [16:43] ah [16:43] it would be apache.. okay, that makes sense [16:43] Kobaz: No path-based auth like SVN but it's rather silly in a DVCS because everyone can commit to the whole tree if they can commit at all [16:44] Kobaz: You could probably arrange matters so that distinct ssh accounts could all push to the same repo - after all, Launchpad does this [16:45] Bazaar itself has no authentication but the transports it uses may do, is the quick answer [16:46] k [16:48] I'd like to see it do client-certificate auth over http, but I can't grok how to get curl to do it. [16:52] Kobaz: the ssh is just a method. you don't have to have a shared account [17:00] Kobaz: in fact, at work we use multiple shared repositories over bzr+ssh, with everyone using their own account. [17:00] Kobaz: and acl (setafcl \o/) to control who has access to which branch. [17:01] Kobaz: (which boils down to: everybody, but it could be more complex :) [17:02] * LarstiQ hops off to jitsu [17:09] nifty === bac is now known as bac_lunch [17:34] In CVS I can run a diff against the last update... cvs diff -up original.php > filename.patch in bzr I would have to check my revision numbers first to see what "original" was? I read bzr --help diff, but I didn't see a syntax that matched what I use in CVS. [17:34] emmajane, bzr diff -r -2 [17:35] that's "two revisions ago"? [17:35] I don't quite know the rationale for -2 instead of -1 [17:35] actually [17:36] I think it's, "show me the difference between the end of 2 revisions ago and now [17:37] Let's say, for example, I was working on a branch and when I downloaded it was at revision 159... and now I'm at revision 178... I want to send a patch back because politics are weird... james_w suggested bzr send as well. [17:37] (and the branch is 500M because of images so pushing will not be fun) [17:38] "bzr send --mail-to person@place.com" [17:38] bzr send is *the* tool to send a patch for the differences between branches, yes [17:38] another is "bzr diff -r ancestor:http://server/path/to/branch" [17:38] james_w, and it's just the diff that gets sent? [17:39] no, it sends the diff + bzr meta-data. [17:39] james_w, what does bzr diff spit out? is it like the patch file that cvs diff gives? [17:39] emmajane, diff + bzr metadata (commit information) [17:39] * emmajane nods [17:39] * beuno waves at james_w [17:39] you can "bzr merge" from the file that "bzr send" produces, much like if you pushed this to a branch [17:39] hey beuno, how are you? [17:40] that popping noise? that was my brain exploding... just a second. :) [17:40] ok. I'm back. [17:40] james_w, pretty good, how are you? [17:40] beuno: good thanks. [17:40] emmajane, bzr send generates a file which is the diff plus bzr data, so you can "merge" in the file with all its commits [17:41] *nod* [17:42] so it's different than a plain diff, because you can send them around, and you'll get branches with the same revisions in them (sort of, but let's say yes) [17:42] james_w, will I see you at UDS? [17:42] beuno: of course :-) [17:42] it's a diff on bzr steroids. :) [17:42] james_w, fantastic, looking forward to it. I want to talk to you about package branches over beer! [17:42] emmajane, you got it! [17:42] gotcha. [17:43] beuno: of course :-) [17:45] How are the email addresses configured? [17:45] i.e. if the mailing list is subscriber posting only... [17:45] do I have to change my whoami? [17:45] well, that's kinda out of bzr's realm [17:45]