[00:13] mwhudson: hey [00:13] mwhudson: yep (-: [02:37] Is there a way to invoke the 'bzr up' with local commits semantics without being bound? [02:38] ie. pull trunk and merge your current branch into it, in the one branch. [02:43] I'm sure you could do something involving "bzr log -r -1 --show-ids", "bzr pull --overwrite" and "bzr merge . -r revid:...", but... [02:44] Right, that's what it would have to do. [02:44] bzr rebase? [02:44] maybe not [02:44] wgrant: I often want the same thing, but haven't wanted it enough to write the plugin to do it yet [02:46] It'd be a trivial plugin, but it would be nice to have it easily available for everyone. Since Git people tend to do the 'merge trunk into branch, push branch over trunk' thing, because AIUI git parents are unordered. [02:47] And it would be nice to have a very similar bzr workflow which works unbound, and doesn't replace the mainline history. [03:11] wgrant: Yeah, I do that workflow, but I do it by always having a clean mirror of upstream handy to merge onto. [03:12] So do I. [03:12] But others don't like that requirement. [03:24] wgrant: git parents are ordered [03:25] wgrant: that'd be roughly equivalent to just bzr merge .../trunk && bzr ci -m "Merge trunk" && bzr push .../trunk, no? [03:31] jelmer: But that changes the LHS history. [03:32] If I bzr up on a bound branch, trunk's tip replaces mine, and my local commits show up as a pending merg.re [03:40] So I have a crazy question. Why does a 150 line change cause more than 360mb of transfer? (repacking texts) [03:40] (- 371561KB 114KB/s | Fetching revisions:Inserting stream:repacking texts:texts 6235/7200) [03:44] wgrant: it also changes the LHS history in Git, except Git folks don't seem to care about LHS history.. [03:44] Kraln: it would only take so much data every so often (bzr was repacking your repository apparnetly) [03:44] this was a tiny commit! [03:45] it's up to 400mb of transfer for 100 lines of changes, if that [03:45] jelmer: Ah, I see. [03:46] Kraln: Repacking happens every X commits or so [03:46] can I disable that? this is a *large* repo [03:46] Kraln: another 100line change right now won't require that much data to be transferred [03:46] Kraln I think you can disable it but it'll slow down your repository access in the long run [03:47] 400mb of transfer on a dsl line means it's been hours to make this commit [03:47] Kraln: an alternative is to use the smart server rather than sftp, in which case the repacking will happen on the server side [03:47] how do I set that up? [03:47] use bzr+ssh rather than sftp [03:47] that's it? [03:47] Kraln: I think so [03:47] As long as you have a recent bzr on the server. [03:47] it's 2.1 or whatever [03:47] wgrant: that said, I'm sure we'd welcome a patch to use the merge revision as the first parent rather than the previous local head [03:48] jelmer: Oh, so we could just switch the parents at commit time? [03:50] wgrant: yeah [03:50] jelmer: True. That sounds much easier. [03:51] http://dpb.pastebin.com/LaiDv5U1 [03:53] :| [03:54] hmm, the folder on the server is empty [03:55] not feeling too peachy-keen happy with bzr at the moment [03:59] try pushing with just sftp? [04:12] Hello, [04:12] wgrant just sent me a recent chat snippet from here, about replacing the LHS history with bzr merge / push [04:12] Versus Git. [04:13] Hi mgiuca. [04:13] "< jelmer> wgrant: it also changes the LHS history in Git, except Git folks don't seem to care about LHS history.." [04:13] I didn't know Git had LHS history at all. [04:15] Just thinking that in Bzr, if you have a local mirror of a branch, which has diverged, there's no simple way to 1. Merge, then 2. Push your changes up to the branch (eg on Launchpad) without reordering the LHS history on Launchpad. [04:15] Except if you were bound, you could do an update. [04:16] Maybe wgrant already discussed this before. === gnomefreak76 is now known as gnomefreak === ubuntujenkins_ is now known as ubuntujenkins [14:37] All greetings. A bit strange question: I can host on the local machine to deploy the system bzr only without web? === tro|| is now known as tro === lionel___ is now known as 5EXAAKZ44 [18:18] Hi. I'm trying to get my head around repos-in-repos ... Iiuc, I can pull an external branch into my local repo, e.g.: bzr init myrepo; bzr branch myrepo/extrepo. [18:18] Am i then supposed to 'ignore' the extrepo dir, managing it separately? [18:20] That sounds like it would work, but I've never done it. [18:21] Inside the extrepo directory it will find the extrepo/.bzr directory first and go by that, and outside that directory it's been told to ignore it so it doesn't care that it's there. [18:24] Kilroo: Ok, sounds reasonable. Now, can it be further extended to 'nest' another branch under /myrepo/extrepo/YArepo, and manage *it* from the top/parent, myrepo? I'm pretty sure I'm confused by this ;-) [18:24] Kilroo: More context might help ... what I'm trying to do it this -> https://lists.ubuntu.com/archives/bazaar/2010q1/067904.html [18:24] Has to do with, eventually, managing/staging Drupal sites ... [18:25] Kilroo: I suspect that I maybe approaching this wrong in the first place :-/ [18:25] Ah. [18:25] Step 1: avoid Drupal. [18:25] :-p [18:25] That's just my personal experience. [18:25] Kilroo: Actually, I'm using Pressflow ... that anybetter? [18:25] No idea. [18:26] Kilroo: Fair enough. Ignore that fact, then ....back to the bzr question :-) [18:26] right, reading [18:26] hehe ... [18:26] item the first: I think it's .bzrignore, you seem to have omitted the r [18:27] not sure I've ever ignored anything without doing it through bzreclipse though so I may be wrong [18:28] Ah. [18:28] Kilroo: sure, just a typo on my part for the post ... good catch [18:28] I'm pretty sure the answer is no. [18:30] I am not sure what would happen if you explicitly said to bzr add core/data/test.txt from /repos/site, but I'm fairly certain that once you've ignored core from in site, it never bothers to look at core or anything in it unless you specifically tell it otherwise. [18:30] I guess I'd just test it, if I were you. [18:31] Kilroo: Sound reasonable, too. So, likely that /myrepo/extrepo/YArepo would have to be 'bzr init'-ed as it's OWN standalon repo, and managed separately? [18:34] I honestly don't know. You're beyond my level of experience here. I haven't ever needed to deal with a nested repository or a nested tree or anything...I usually have something along the lines of /foo/bar as a no-trees shared repository, containing /foor/bar/trunk and /foo/bar/feature/{baz,wiz,woz} [18:34] and then /foo/checkouts/bar, which I switch among the relevant branches [18:36] Kilroo: Thanks, then. This all mostly (made) sense to me, until I was faced with this nesting bit ... then got a bit murky. Like you said, testing/monkeying probably a good-thing. [18:36] Good luck. [18:39] ta! === lionel_ is now known as lionel === jkakar_ is now known as jkakar === nlisgo_ is now known as nlisgo [20:51] hazmat: yay for https://code.edge.launchpad.net/~hazmat/loggerhead/speed-rules [20:59] hi [21:00] is there a web interface for bzr which is better than loggerhead and lighter than redmine or trac ? [21:00] (better = you can download folder for example and having color syntax) [21:01] rniamo: loggerhead has coloured syntax if you have pygments installed [21:01] and there's a patch for downloading a folder somewhere i think [21:01] mwhudson : ok ill try, thanks, [21:01] i didn't succeed to install the patch correctly [21:01] ah :/ [21:02] when i click on download i had an error, something like loggerhead/static/projectxxx.tgz doesn't exist [21:04] ..../static/? That sounds totally wrong. [21:04] mwhudson : i've installed pigments and i have no coloured syntax, where should i have to active it ? [21:05] Peng : yes, totally but i merge manually so i can have forgotten something. I installed loggerhead from ubuntu packages [21:06] rniamo: You don't have to activate it. Um, what version of Loggerhead? [21:07] Peng : 1.17 [21:08] Yeah, that should support it. [21:08] :( [21:09] do i have to set language somewhere ? [21:11] It auto-detects it, which usually succeeds, unless the file is non-tiny, but the alternative would be risking exponential runtime by Pygments, so... [21:15] Peng : ok, coloured syntax is ok, maybe the file was too tiny [21:15] or maybe i had to restart loggerhead [21:15] is there a simple solution to download a folder as tar/zip or anything else from loggerhead ? [21:27] how to install the "download" patch on loggerhead ? [21:32] i have this erreor when i want to install the download as tar patch : http://www.friendpaste.com/28UailBMDogGgC6q9AHuFm [21:32] rniamo: Yes, you had to restart Loggerhead. [21:32] Peng : it's ok for coloured syntax, thanks [23:18] how do I recursively ignore everything under a directory? [23:18] jelmer: hello [23:21] Something like this I believe: 'bzr ignore "dir/**/*"' === Leonidas_ is now known as Leonidas [23:23] mwhudson: moin [23:24] jelmer: some interesting seeming bzr-git commits over the weekend :) [23:24] jelmer: did you basically drop the trees table from the git.db file? [23:24] mwhudson: yeah [23:25] (bah) [23:25] jelmer: cool [23:25] jelmer: have you tested it with the kernel? [23:25] mwhudson: not yet, there's still some issues to work out [23:25] jelmer: what's the migration plan? is the file still called 'git.db'? [23:25] ah ok [23:25] i guess we shouldn't try to sneak a bzr-git update into the next launchpad release then :) [23:26] grr^2 [23:26] mwhudson: the file is still called git.db, but I've also worked on a BTreeIndex-based map [23:26] which is significantly faster [23:27] jelmer: ah ok [23:43] mwhudson: do you know the pydoctor maintainer for Debian/Ubuntu? [23:43] it seems it's out of date for python2.6.. [23:49] jelmer: no [23:49] i guess i could make a release or something and try and sneak that into lucid [23:50] mwhudson: that'd be great [23:54] jelmer: can you upload it to debian, or do we need to try to find the maintainer? [23:55] mwhudson: we need to find the maintainer, but it seems it's team maintained and I know the maintainer who's done most of the uploads so far [23:56] mwhudson: if you can get a proper release out I'd be happy to take care of getting it packaged and into debian [23:56] jelmer: http://people.canonical.com/~mwh/pydoctor-0.3.tgz ? [23:56] -? [23:57] sha1 5fb79e1d84cc729e5731ff5a69275e5087b3e59c fwiw [23:57] is there a quick way to determine at what bzr version a method got added? (specifically diff.get_trees_and_branches_to_diff) [23:57] mwhudson: wow, that was quick :-) [23:58] also, is anyone seeing issues using bzr with python2.6? (I'm seeing what appears to be filehandle leaks) [23:58] sdist doesn't take too long