[00:01] hey poolie, fullermd [00:02] hi - is there a bzr equivalent to 'git pull --rebase'? [00:03] Possibly bzr rebase ? [00:03] Though not knowing quite what that git pull --rebase does I'm not sure [00:04] git pull --rebase allows you to update your branch with the current commits before you push your own commits [00:04] LeoNerd: unfortunately, there doesn't appear to be a bzr rebase command [00:04] Well, the usual way to do that in bzr would be to merge trunk into your branch first [00:04] j1mc: the equivalent is 'bzr rewrite' [00:04] You -can- rebase, but that's somewhat rude as it rewrites history [00:04] from the bzr-rewrite plugin [00:04] i don't know if there is a specific one-shot command to do that [00:05] It's generally much nicer to merge from the trunk into the branch, so that branch merges back into the trunk afterwards [00:05] It doesn't involve any history-rewriting that way [00:05] But still, if you want rebase, you'll find it in the bzr-rewrite plugin [00:05] j1mc: "bzr rebase" does the same thing as "git pull --rebase" [00:05] as LeoNerd and poolie point out, that command requires the bzr-rewrite plugin [00:07] thanks for your help, all. i will give the bzr-rewrite plugin a try. [00:08] jelmer: Hi. I have been bitten by the broken not-quite-dpushed commits in dulwich again. [00:08] I would like to suggest deleting lp:~dulwich/dulwich/trunk from existence so that they cannot propagate further [00:09] I am currently wondering if I should manually recommit the recent history of the dulwich bzr-ppa branches for hardy/jaunty/karmic to excise them [00:10] hi maxb [00:10] hello [00:15] * maxb hugs the lp api and lpshell [00:16] having just been able to do a loop over all ~bzr recipes calling r.distroseries.remove(karmic) on them all [00:18] hm [00:18] but it doesn't seem to have taken effect [00:20] * maxb is less impressed now [00:21] poolie: Thanks for also looking at Vincent's config patches [00:21] maxb: The same commits or different ones? [00:21] that's ok [00:21] do you want to talk about it? [00:21] i'm wondering if we should in fact do per-file configuration on the way i discussed in the overall mp [00:21] maxb: please note that that branch is just a mirror of another one [00:21] jelmer: same ones causing problems in new scenarios [00:21] maxb: So it's all old stuff? [00:22] jelmer: OK, let's delete all branches in the world with the dodgy commits :-) [00:22] I'm thinking a work around may be to just to add a working tree to A [00:22] but yeah fullermd that's my situation. [00:23] jelmer: 2011-01-14 is the most recent problem revision [00:23] maxb: if it's all old commits I'm happy to delete and repush those branches, if there are new commits involved as well we should probably investigate further [00:23] maxb: That's old enough for me :) [00:24] poolie: I think the idea of mixing config and rules is interesting [00:24] if they're going to stay separate, i'd like to have a clear idea of why they're separate [00:24] beyond just 'rules are per-file' [00:24] I'm currently trying to decide whether it would be quicker to manually recommit the history for the bzr-ppa branches, vs. hack up reconcile with "where you see this text parent, change it to that one" logic [00:26] knighthawk: If you'd followed the exact sequence of commands you mentioned earlier, I don't see how you could have diverged branches [00:26] poolie: My impression of it is that rules are things that could potentially apply to everybody accessing a particular branch [00:26] whereas config is specific to a specific machine or user [00:26] That's how I think of them at least, not sure if it necessarily makes sense. [00:26] knighthawk: Perhaps a pastebin of your console session would explain things best [00:28] maxb I did do a commit of new code in my branch before trying to do the pull from svn [00:28] that is true [00:28] poolie: I realize that doesn't entirely match our current use, as we don't currently allow you to declare "doc/en/release-notes/*.txt" as changelog files that should be processed with the custom changelog merger [00:28] but perhaps they should just be different layers that stack together [00:28] knighthawk: In that case I think you misunderstand the nature of "pull" [00:28] perhaps it's too confusing if some are trusted and some not [00:29] knighthawk: "pull" is for making a local branch be identical to some remote one. Once you've committed stuff locally, that's no longer possible. You want to merge, I guess, instead. [00:29] maxb quite possible, I went ahead and created a working tree in 'A' now I'm going to try to merge 'A' and 'B' [00:29] poolie: yeah, trust is indeed an interesting thing in this too [00:30] maxb I guess what I want to do is like a update of the local branch to the central repo before I try to commit my changes back into svn. [00:31] knighthawk: Right. "bzr merge svn+ssh://my.svn.server/svn/repository/project/trunk" for example [00:32] maxb can I just merge to a svn repo? (I don't know why but I assumed I couldln't do that) [00:32] No, because you can only merge into a working copy [00:33] ah. okay I just merged my changed from B into A so now I want to merge from the svn repo into A then do a commit (I think) [00:37] poolie: food for thought :) [00:37] * jelmer gets some sleep [00:37] :) sleep well [00:52] jelmer: I'd like to update news_merge to use rules, actually [00:53] hi there spiv [00:54] so spiv, what do you think of unifying them? [00:54] help help! "permission denied" using 'bzr switch' ? http://paste.drizzle.org/show/481/ [00:54] hi stewart [00:54] poolie, hi! [00:55] the eperm is a distraction just meaning you don't have a /var/crash or something [00:55] looks like https://bugs.launchpad.net/bzr/+bug/623152 [00:56] Ubuntu bug 623152 in Bazaar "ValueError: need more than 1 value to unpack in _last_revision_info" [Undecided,Expired] [00:56] huh... [00:56] > That traceback suggests the .bzr/branch/last-revision file is corrupt, probably blank. What does it contain? [00:56] poolie, it's 0 bytes long [00:57] poolie, so probably something that wasn't written out during one of the "damn laptop hung... probably due to intel wireless drivers" events last week [00:57] sorry, yeah [00:57] we should almost just fsync everything, except that would make things pretty slow for people whose machine aren't crashing [00:57] can you see if 'bzr reset-dirstate' fixes it? [00:58] poolie, unknown command... some plugin i'm missing? [00:58] ah it might only be in bzr 2.4 [00:59] ahh.. .and i'm 2.3.1 [00:59] do you have a lot of uncommitted work? [00:59] it might be faster to just make a new tree [00:59] poolie, no. [00:59] poolie, wiping away the checkout is fine. [00:59] i will update that bug to say there should be an easier way to recover [00:59] does the windows installer support bzr+ssh urls out of the box? [00:59] tortoisebzr? [00:59] teratorn: i think so yes [01:00] poolie, i have no problems with it fsyncing such things. nooo problem with that at all :) [01:00] maybe at least an option would be good [01:00] in fact an option that just globally fsync'd on close could be good [01:00] poolie: my understanding of the purpose of rules is the same as jelmer's [01:00] at least as 'fool me twice' prevention [01:01] that's my understanding too [01:01] well, versioned-in-tree config about that tree [01:01] however, i'm not sure we need a separate and somewhat parallel api to get it [01:01] It definitely has a lot in common with other kinds of config [01:03] We have perhaps slightly different concerns about versioning the format of rules vs configs, but in terms of API it sounds reasonable to have as much commonality as possible. [01:03] poolie, attempted new lightweight checkout for my working dir... http://paste.drizzle.org/show/482/ [01:04] There is also a difference that in practice rules are used for per-file stuff, or at least 'per-thing in tree as matched by globs', and mostly other configs don't do that. [01:04] stewart ah the problem is actually in the branch not the tree [01:05] poolie, oh yeah, last-revision is empty there too [01:05] if that's your trunk, delete the branch directory [01:05] and pull from the server again [01:05] poolie, i have a mirror of it on lp... [01:05] (of that branch) [01:05] it's actually lost its idea of what the tip is [01:05] you don't need to delete the repo, only the branch [01:05] so it should be quite fast to fetch [01:05] yep. branch going away. [01:07] poolie, FYI it left the lightweight checkout dir in an odd state...just wiping it and trying again [01:09] poolie, question, is there any efficiency in packing binary data in the repo apart from simple compression? e.g. if we had X number of 10MB files that were *mostly* the same, would we get anything better than X*10MB disk usage? [01:10] yes you would [01:10] poolie, I'm wanting to have various InnoDB data files in the tree for backwards compatibility testing. [01:10] without having people whine at me that the repo is now 400MB :) [01:10] one caveat is that compression only hppens within pack files [01:10] so if you successively commit 10 additions of those files, you will have 10 pack files each ~10MB [01:11] poolie, i can deal with that. (i gather a repack would reclaim a lot of space) [01:11] however, the compression on the 10th commit should shrink them all into one pack somewhat less than 100MB [01:11] right [01:11] 10x10MB files with only about 1MB difference should be closer to 20MB on disk than 100MB [01:11] stewart: yes, thats right. Do an experiment :) [01:11] nice :) [01:12] we were discussing if we would gzip these in tree or not, rather convinced we should just store them in there now. [01:12] it turns out some people care not to have to sql dump and restore their database :) [01:15] bzr will be able to compress them better if they're not individuall gzipped [01:15] which will hide any similarities [01:16] lp stores a SQL dump of some MBs of data in tree [01:16] it compresses pretty well [01:16] its a tad fugly, but if you need it you need it. [01:17] I would suggest having it in a dedicated tree perhaps [01:19] that sounds like a good idea === wallyworld___ is now known as wallyworld [01:43] This fixes a bug that Mark Shuttleworth pointed out to me (bug #765881) [01:43] nice [01:43] Launchpad bug 765881 in Bazaar "newly added files always trigger IN_MEMORY_MODIFIED" [High,In progress] https://launchpad.net/bugs/765881 [02:06] * spiv gives his wireless router a kick [02:36] stewart also https://bugs.launchpad.net/bzr/+bug/766735 [02:36] Ubuntu bug 766735 in Bazaar "people get confused by apport messages" [Medium,Confirmed] [02:36] spiv do you have any ideas about https://bugs.launchpad.net/bzr/+bug/721163 [02:36] Ubuntu bug 721163 in Bazaar "bzr crashed with ErrorFromSmartServer: ('error', 'bytes must be a string')" [Undecided,New] [02:43] poolie: hmm, no [02:44] poolie: I think we need the server-side log [02:44] I can't think of any likely causes, and I don't think any hooks are triggered by insert_stream so it's unlikely to be a buggy plugin [03:06] so can you say so? [03:36] Sure. [06:16] Is it possible to find all the dangling revisions in a repository created by uncommit? [06:18] bzr heads --all [06:19] Is there any way to setup a post commit hook for bzr to send an email when using it with Launchpad? [06:20] lifeless: cheers [06:20] KombuchaKip: if your branch is on launchpad you can just click on subscribe in the UI [06:20] KombuchaKip: the people interested in the branch can just subscribe to it in lp [06:20] or you can use bzr-email [06:20] o/ johnf [06:20] KombuchaKip: if you want the mail sent to a list, you can subscribe a team with a contact address of the mailing list (or the team itself if its a launchpad hosted list) and LP will mail that directly. [06:21] poolie: I'd like to use bzr-email, but not sure if you can use that with launchpad since you won't have access to server? [06:21] lifeless: Thanks. I think that's what I will do. [06:21] it runs on the client [06:21] sending it from lp seems easier [06:24] poolie: Thanks. [06:39] This is always a friendly and helpful channel. [07:07] thanks [07:09] poolie: Thanks for the pointer to deryck's bzr issue. As it turned out, it was actually a launchpad-specific bzr plugin that was at fault, so no problem for us on the #bzr side of things :-) [07:11] o/ bialix [07:12] hooray [08:58] spiv, jelmer, jam, hi? [08:58] hi poolie [08:58] "Are you ready to Muuuummblllllllllleee" ? [08:59] (said w/ a WWE announcer voice) [08:59] :) :) [09:00] be back in a sce [09:08] * jelmer is still setting up [09:21] poolie, jelmer, jam: damn, forgot what day it was [09:22] np, want to join us now? [09:22] Ok [09:26] spiv: pack retry attacked back [09:34] poolie: this one? https://wiki.canonical.com/Bazaar/Plan/2011 [10:02] spiv: yeah, we don't hear you [10:33] jam re bug 746237 i was just going to check if there's a new bug [10:33] Launchpad bug 746237 in Bazaar "Documentation markup bugs" [High,In progress] https://launchpad.net/bugs/746237 [10:34] poolie: sure [10:34] I don't think there is a new one [10:35] i'll do a pass over all of ~mbp inprogress today or tomorrow [10:40] poolie: what is our current 'bug fix' policy [10:40] it should always target 2.3? [10:40] or 2.2? [10:40] or ...? [10:40] I have a fairly trivial fix for bug #760152 which I can backport as far as we want [10:40] Launchpad bug 760152 in Bazaar "bzr merge --pull --preview BRANCH does not always honor the --preview option" [High,In progress] https://launchpad.net/bugs/760152 [10:40] the main issue is just how much effort do we want to spend merging-up [10:41] serious bugs with safe fixes in 2.1 [10:41] bugs worth fixing with safe fixes in 2.3 [10:41] i guess [10:41] 2.0 basically dead except by request [10:42] iow i think the safety bar is equally high [10:42] but, merging into 2.1 is a bit more work, so we should only do it when we specifically think it'll please someone [10:42] poolie: sure. I guess my issue here is how to handle the merge-up and the RELEASE NOTES [10:42] on lts [10:42] right [10:54] Yay, closing a 4-digit bug [10:54] bug #5135 [10:55] I tested it, and it works fine here [10:55] Launchpad bug 5135 in Bazaar "bzr diff -r X..Y path/to/branch fails if path/to/branch is a symbolic link" [Medium,Fix released] https://launchpad.net/bugs/5135 [10:55] ubot5: you're getting slow, man [10:55] Error: I am only a bot, please don't think I'm intelligent :) [10:57] way to go! [10:57] if there were badges, you would get at least a silver one [11:05] poolie: well, closed because it has already been fixed. But still feels good. [11:14] :) [11:21] maybe we should just make a web page with badges if we can't do it automaticaly [11:33] poolie: or a greasemonkey script? [12:02] spiv: if you're still around and interested, we're having a udd meeting #ubuntu-meeting [12:03] *in [12:03] jam: hi? === mrevell is now known as mrevell-lunch [13:50] Morning/nick mrevell [13:51] sorry === mrevell-lunch is now known as mrevell [13:51] :) [14:23] Hi ntoll! :) [14:23] hi jkakar [14:23] fancy seeing you in here ;-) [14:23] ntoll and I have discovered something funky in our branches... [14:23] We have trunk, staging and production branches, each of which is meant to be older than the last (and we're careful with merges). [14:24] We have a situation where production doesn't contain content in a file that, after carefully analyzing the logs, we think should be there. [14:24] So I ran 'bzr check' and got this: [14:24] 3838 revisions [14:24] 1360 file-ids [14:24] 3 inconsistent parents [14:24] I'm wondering what '3 inconsistent parents' means...? [14:24] Could it be that some flummox in merging could have removed the content we expect... [14:25] For example, I seem to remember reverting a revision could produce strange results when you merged it back...? [14:26] abentley: ^^ Any ideas? [14:39] jkakar: No, inconsistent parents are mostly harmless. They are usually due to ghost revisions or bzr bugs. [14:39] abentley: Okay, thanks. :) [14:40] abentley: I guess bzr bugs are mostly harmless? ;b [14:40] abentley: Anyway, I think we figured out the issue is an EPEBKAC error. :) [14:40] Ah, okay. [14:40] abentley: Thanks for your feedback, much appreciated... these kinds of "WTF?" moments are always a bit scary. :) [14:42] jkakar: no problem. [14:43] I think 'reconcile' will often fix inconsistent parents. [14:44] fullermd: Yeah, I was wondering about it... but 'bzr help reconcile' says, "You should only need to run this command if 'bzr check' or a bzr developer advises you to run it." [14:44] fullermd: Neither of those things happened so I didn't run it. [14:47] What exactly is an "inconsistent parent"? Is this described anywhere? [14:47] maxb: I was wondering the same... I couldn't easily find anything about it. [14:49] I gather it's something to do with consistency between the overall revision graph and the ancestry attributed to individual files [14:50] maxb: I gathered the same, yeah. [15:39] What do I do about this: "bzr bd" gives error "Unable to determine the previous upload for --package-merge"? [15:43] diwic, "bzr branch lp:bzr-builddeb /tmp/builddeb; BZR_PLUGINS_AT=builddeb@/tmp/builddeb bzr bd" [15:44] james_w, iow this is a known bug that is fixed in trunk? [15:44] diwic, indeed [15:45] thanks! === diwic is now known as diwic_afk [17:56] I've seen a few places that mention rebase. perhaps as a solution to my problem committing to svn. But when I try to run 'bzr rebase' or 'bzr help rebase' it says it doesn't exist. am I doing something wrong? === abentley is now known as abentley-lunch [17:57] Hey there [17:57] looks like I'm running bzr 2.1.1-4 [17:57] knighthawk: rebase is in the bzr-rewrite plugin [17:57] Getting some issues with bzr-fastimport related to an AttributeError on _find_ancestors [17:57] jelmer thanks [17:57] On natty, specifically [17:58] Is that a known issue? [17:58] hi Gustavo [17:58] niemeyer: it sounds vaguely familiar - can you pastebin the backtrace? [17:58] jelmer: Hi! [17:58] Sure [17:58] jelmer: http://pastebin.ubuntu.com/596621/ [18:01] niemeyer: thanks [18:01] niemeyer: it's indeed something I've seen before [18:03] https://bugs.launchpad.net/bzr-fastimport/+bug/541626 [18:03] Ubuntu bug 541626 in Bazaar "'BTreeBuilder' object has no attribute '_find_ancestors'" [High,Confirmed] [18:05] I'm not too familiar with the index code, perhaps John can comment on it tomorrow. [18:05] it looks shallow [18:07] jelmer: Cool, thanks [18:40] jelmer, did you have a branch that had some code doing isinstance(revision_id, basestring) up for review? I now can't find the mp and think I may have imagined it. [18:41] mgz: perhaps the branch that forbade using None as alias for "null:" in Branch.set_last_revision_info() ? [18:42] maybe. do you have a link? I meant to ask whether said variable should actually be bytes or unicode. [18:42] mgz: that was inspired by some other code in bzrlib.revision that did the same thing IIRC [18:43] I thought it was one of the ones removing the inventory stuff and switching a param to be a tree or something instead [18:43] tjatlp:~jelmer/bzr/testament-tree ? [18:43] that's lp:~jelmer/bzr/testament-tree ? [18:44] bzrlib.revision.is_reserved_id() checks against basestring [18:46] mgz: it happens in more places, e.g. Repository._iter_revisions [18:46] must have confused two different diffs. I've not been keeping up with for coding. :) === abentley-lunch is now known as abentley [21:44] does bzr require you to download the whole repository history, like git/hg do? [21:45] ironmagma: You can use lightweight checkouts, which do not. [22:06] svn users aren't too happy with me right now, somehow I blew away the svn history for a few days with my push. is this because in my ~/.bazaar/suvbersion.conf I added append_revision_only = False? [22:07] push shouldn't even be destructive, unless you used --overwrite [22:07] s/even/ever/ [22:07] did *not* use overwrite [22:07] jelmer: ^ around ? [22:10] I did a bzr merge to merge my working tree to what was supposed to be the latest version of the svn repo (only it seems it wasn't) then I commited my changes and tried to do a push that didn't work until I added append_revision_only = False but then it seems I blew up some stuff. I've since installed bzr-rewrite and now I'm trying rebase instead of append_revision_only = False. but since I'm not *sure* that's what created the problem I'm not sure if I'm [22:10] going to do it again. [22:12] yeah, I can understand that [22:12] sadly, I've only used bzr svn a very few times myself, so I don't really have a clue about whats up there [22:17] re [22:18] hi lifeless, knighthawk [22:19] hey jelmer [22:19] knighthawk: yes, if you set "append_revisions_only = False" that means bzr-svn will push even if that removes existing revisions from the mainline (the revisions are still in the repository, just not in the mainline of the branch) [22:20] knighthawk: The default of append_revisions_only=True is intended to prevent you from shooting yourself in the foot [22:21] jelmer, okay it *sounds* like now that I have bzr-rewrite working I can use rebase and don't need append_revision_only=False anymore (I think) [22:21] knighthawk: you can restore the old mainline using either "svn cp -r ..." or "bzr push --overwrite ..." [22:22] knighthawk: right, rebase will preserve the upstream branch mainline [22:22] jelmer sorry I'm not sure what is meant by mainline is that the trunk? [22:22] knighthawk: mainline are basically the revisions shown by "bzr log -n1" [22:22] knighthawk: non-mainline revisions will be shown too if you use "bzr log -n0" [22:31] thanks jelmer that clears up a lot. but now did I just destroy my changes of restoring the mainline by running rebase? [22:32] knighthawk: it depends on what exactly you rebased === foocraft is now known as [1984]