[00:01] <jelmer> hey poolie, fullermd
[00:02] <j1mc> hi - is there a bzr equivalent to 'git pull --rebase'?
[00:03] <LeoNerd> Possibly  bzr rebase ?
[00:03] <LeoNerd> Though not knowing quite what that  git pull --rebase  does I'm not sure
[00:04] <j1mc> git pull --rebase allows you to update your branch with the current commits before you push your own commits
[00:04] <j1mc> LeoNerd: unfortunately, there doesn't appear to be a bzr rebase command
[00:04] <LeoNerd> Well, the usual way to do that in bzr would be to merge trunk into your branch first
[00:04] <poolie> j1mc: the equivalent is 'bzr rewrite'
[00:04] <LeoNerd> You -can- rebase, but that's somewhat rude as it rewrites history
[00:04] <poolie> from the bzr-rewrite plugin
[00:04] <poolie> i don't know if there is a specific one-shot command to do that
[00:05] <LeoNerd> It's generally much nicer to merge from the trunk into the branch, so that branch merges back into the trunk afterwards
[00:05] <LeoNerd> It doesn't involve any history-rewriting that way
[00:05] <LeoNerd> But still, if you want rebase, you'll find it in the  bzr-rewrite  plugin
[00:05] <jelmer> j1mc: "bzr rebase" does the same thing as "git pull --rebase"
[00:05] <jelmer> as LeoNerd and poolie point out, that command requires the bzr-rewrite plugin
[00:07] <j1mc> thanks for your help, all. i will give the bzr-rewrite plugin a try.
[00:08] <maxb> jelmer: Hi. I have been bitten by the broken not-quite-dpushed commits in dulwich again.
[00:08] <maxb> I would like to suggest deleting lp:~dulwich/dulwich/trunk from existence so that they cannot propagate further
[00:09] <maxb> 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] <poolie> hi maxb
[00:10] <maxb> hello
[00:15]  * maxb hugs the lp api and lpshell
[00:16] <maxb> having just been able to do a loop over all ~bzr recipes calling r.distroseries.remove(karmic) on them all
[00:18] <maxb> hm
[00:18] <maxb> but it doesn't seem to have taken effect
[00:20]  * maxb is less impressed now
[00:21] <jelmer> poolie: Thanks for also looking at Vincent's config patches
[00:21] <jelmer> maxb: The same commits or different ones?
[00:21] <poolie> that's ok
[00:21] <poolie> do you want to talk about it?
[00:21] <poolie> i'm wondering if we should in fact do per-file configuration on the way i discussed in the overall mp
[00:21] <jelmer> maxb: please note that that branch is just a mirror of another one
[00:21] <maxb> jelmer: same ones causing problems in new scenarios
[00:21] <jelmer> maxb: So it's all old stuff?
[00:22] <maxb> jelmer: OK, let's delete all branches in the world with the dodgy commits :-)
[00:22] <knighthawk> I'm thinking a work around may be to just to add a working tree to A
[00:22] <knighthawk> but yeah fullermd that's my situation.
[00:23] <maxb> jelmer: 2011-01-14 is the most recent problem revision
[00:23] <jelmer> 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] <jelmer> maxb: That's old enough for me :)
[00:24] <jelmer> poolie: I think the idea of mixing config and rules is interesting
[00:24] <poolie> if they're going to stay separate, i'd like to have a clear idea of why they're separate
[00:24] <poolie> beyond just 'rules are per-file'
[00:24] <maxb> 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] <maxb> 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] <jelmer> poolie: My impression of it is that rules are things that could potentially apply to everybody accessing a particular branch
[00:26] <jelmer> whereas config is specific to a specific machine or user
[00:26] <jelmer> That's how I think of them at least, not sure if it necessarily makes sense.
[00:26] <maxb> knighthawk: Perhaps a pastebin of your console session would explain things best
[00:28] <knighthawk> maxb I did do a commit of new code in my branch before trying to do the pull from svn
[00:28] <poolie> that is true
[00:28] <jelmer> 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] <poolie> but perhaps they should just be different layers that stack together
[00:28] <maxb> knighthawk: In that case I think you misunderstand the nature of "pull"
[00:28] <poolie> perhaps it's too confusing if some are trusted and some not
[00:29] <maxb> 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] <knighthawk> 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] <jelmer> poolie: yeah, trust is indeed an interesting thing in this too
[00:30] <knighthawk> 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] <maxb> knighthawk: Right. "bzr merge svn+ssh://my.svn.server/svn/repository/project/trunk" for example
[00:32] <knighthawk> maxb can I just merge to a svn repo? (I don't know why but I assumed I couldln't do that)
[00:32] <maxb> No, because you can only merge into a working copy
[00:33] <knighthawk> 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] <jelmer> poolie: food for thought :)
[00:37]  * jelmer gets some sleep
[00:37] <poolie> :) sleep well
[00:52] <spiv> jelmer: I'd like to update news_merge to use rules, actually
[00:53] <poolie> hi there spiv
[00:54] <poolie> so spiv, what do you think of unifying them?
[00:54] <stewart> help help! "permission denied" using 'bzr switch' ? http://paste.drizzle.org/show/481/
[00:54] <poolie> hi stewart
[00:54] <stewart> poolie, hi!
[00:55] <poolie> the eperm is a distraction just meaning you don't have a /var/crash or something
[00:55] <poolie> looks like https://bugs.launchpad.net/bzr/+bug/623152
[00:56] <stewart> huh...
[00:56] <poolie> > That traceback suggests the .bzr/branch/last-revision file is corrupt, probably blank. What does it contain?
[00:56] <stewart> poolie, it's 0 bytes long
[00:57] <stewart> 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] <poolie> sorry, yeah
[00:57] <poolie> we should almost just fsync everything, except that would make things pretty slow for people whose machine aren't crashing
[00:57] <poolie> can you see if 'bzr reset-dirstate' fixes it?
[00:58] <stewart> poolie, unknown command... some plugin i'm missing?
[00:58] <poolie> ah it might only be in bzr 2.4
[00:59] <stewart> ahh.. .and i'm 2.3.1
[00:59] <poolie> do you have a lot of uncommitted work?
[00:59] <poolie> it might be faster to just make a new tree
[00:59] <stewart> poolie, no.
[00:59] <stewart> poolie, wiping away the checkout is fine.
[00:59] <poolie> i will update that bug to say there should be an easier way to recover
[00:59] <teratorn> does the windows installer support bzr+ssh urls out of the box?
[00:59] <teratorn> tortoisebzr?
[00:59] <poolie> teratorn: i think so yes
[01:00] <stewart> poolie, i have no problems with it fsyncing such things. nooo problem with that at all :)
[01:00] <poolie> maybe at least an option would be good
[01:00] <poolie> in fact an option that just globally fsync'd on close could be good
[01:00] <spiv> poolie: my understanding of the purpose of rules is the same as jelmer's
[01:00] <poolie> at least as 'fool me twice' prevention
[01:01] <poolie> that's my understanding too
[01:01] <spiv> well, versioned-in-tree config about that tree
[01:01] <poolie> however, i'm not sure we need a separate and somewhat parallel api to get it
[01:01] <spiv> It definitely has a lot in common with other kinds of config
[01:03] <spiv> 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] <stewart> poolie, attempted new lightweight checkout for my working dir... http://paste.drizzle.org/show/482/
[01:04] <spiv> 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] <poolie> stewart ah the problem is actually in the branch not the tree
[01:05] <stewart> poolie, oh yeah, last-revision is empty there too
[01:05] <poolie> if that's your trunk, delete the branch directory
[01:05] <poolie> and pull from the server again
[01:05] <stewart> poolie, i have a mirror of it on lp...
[01:05] <stewart> (of that branch)
[01:05] <poolie> it's actually lost its idea of what the tip is
[01:05] <poolie> you don't need to delete the repo, only the branch
[01:05] <poolie> so it should be quite fast to fetch
[01:05] <stewart> yep. branch going away.
[01:07] <stewart> poolie, FYI it left the lightweight checkout dir in an odd state...just wiping it and trying again
[01:09] <stewart> 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] <poolie> yes you would
[01:10] <stewart> poolie, I'm wanting to have various InnoDB data files in the tree for backwards compatibility testing.
[01:10] <stewart> without having people whine at me that the repo is now 400MB :)
[01:10] <poolie> one caveat is that compression only hppens within pack files
[01:10] <poolie> so if you successively commit 10 additions of those files, you will have 10 pack files each ~10MB
[01:11] <stewart> poolie, i can deal with that. (i gather a repack would reclaim a lot of space)
[01:11] <poolie> however, the compression on the 10th commit should shrink them all into one pack somewhat less than 100MB
[01:11] <poolie> right
[01:11] <stewart> 10x10MB files with only about 1MB difference should be closer to 20MB on disk than 100MB
[01:11] <lifeless> stewart: yes, thats right. Do an experiment :)
[01:11] <stewart> nice :)
[01:12] <stewart> we were discussing if we would gzip these in tree or not, rather convinced we should just store them in there now.
[01:12] <stewart> it turns out some people care not to have to sql dump and restore their database :)
[01:15] <poolie> bzr will be able to compress them better if they're not individuall gzipped
[01:15] <poolie> which will hide any similarities
[01:16] <lifeless> lp stores a SQL dump of some MBs of data in tree
[01:16] <lifeless> it compresses pretty well
[01:16] <lifeless> its a tad fugly, but if you need it you need it.
[01:17] <lifeless> I would suggest having it in a dedicated tree perhaps
[01:19] <poolie> that sounds like a good idea
 This fixes a bug that Mark Shuttleworth pointed out to me (bug #765881)
[01:43] <poolie> nice
[02:06]  * spiv gives his wireless router a kick
[02:36] <poolie> stewart also https://bugs.launchpad.net/bzr/+bug/766735
[02:36] <poolie> spiv do you have any ideas about https://bugs.launchpad.net/bzr/+bug/721163
[02:43] <spiv> poolie: hmm, no
[02:44] <spiv> poolie: I think we need the server-side log
[02:44] <spiv> 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] <poolie> so can you say so?
[03:36] <spiv> Sure.
[06:16] <johnf> Is it possible to find all the dangling revisions in a repository created by uncommit?
[06:18] <lifeless> bzr heads --all
[06:19] <KombuchaKip> Is there any way to setup a post commit hook for bzr to send an email when using it with Launchpad?
[06:20] <johnf> lifeless: cheers
[06:20] <lifeless> KombuchaKip: if your branch is on launchpad you can just click on subscribe in the UI
[06:20] <poolie> KombuchaKip: the people interested in the branch can just subscribe to it in lp
[06:20] <poolie> or you can use bzr-email
[06:20] <poolie> o/ johnf
[06:20] <lifeless> 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] <KombuchaKip> 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] <KombuchaKip> lifeless: Thanks. I think that's what I will do.
[06:21] <poolie> it runs on the client
[06:21] <poolie> sending it from lp seems easier
[06:24] <KombuchaKip> poolie: Thanks.
[06:39] <KombuchaKip> This is always a friendly and helpful channel.
[07:07] <poolie> thanks
[07:09] <maxb> 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] <poolie> o/ bialix
[07:12] <poolie> hooray
[08:58] <poolie> spiv, jelmer, jam, hi?
[08:58] <jam> hi poolie
[08:58] <jam> "Are you ready to Muuuummblllllllllleee" ?
[08:59] <jam> (said w/ a WWE announcer voice)
[08:59] <poolie> :) :)
[09:00] <poolie> be back in a sce
[09:08]  * jelmer is still setting up
[09:21] <spiv> poolie, jelmer, jam: damn, forgot what day it was
[09:22] <poolie> np, want to join us now?
[09:22] <spiv> Ok
[09:26] <jam> spiv: pack retry attacked back
[09:34] <jam> poolie: this one? https://wiki.canonical.com/Bazaar/Plan/2011
[10:02] <jam> spiv: yeah, we don't hear you
[10:33] <poolie> jam re bug 746237 i was just going to check if there's a new bug
[10:34] <jam> poolie: sure
[10:34] <jam> I don't think there is a new one
[10:35] <poolie> i'll do a pass over all of ~mbp inprogress today or tomorrow
[10:40] <jam> poolie: what is our current 'bug fix' policy
[10:40] <jam> it should always target 2.3?
[10:40] <jam> or 2.2?
[10:40] <jam> or ...?
[10:40] <jam> I have a fairly trivial fix for bug #760152 which I can backport as far as we want
[10:40] <jam> the main issue is just how much effort do we want to spend merging-up
[10:41] <poolie> serious bugs with safe fixes in 2.1
[10:41] <poolie> bugs worth fixing with safe fixes in 2.3
[10:41] <poolie> i guess
[10:41] <poolie> 2.0 basically dead except by request
[10:42] <poolie> iow i think the safety bar is equally high
[10:42] <poolie> 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] <jam> poolie: sure. I guess my issue here is how to handle the merge-up and the RELEASE NOTES
[10:42] <poolie> on lts
[10:42] <poolie> right
[10:54] <jam> Yay, closing a 4-digit bug
[10:54] <jam> bug #5135
[10:55] <jam> I tested it, and it works fine here
[10:55] <jam> ubot5: you're getting slow, man
[10:57] <poolie> way to go!
[10:57] <poolie> if there were badges, you would get at least a silver one
[11:05] <jam> poolie: well, closed because it has already been fixed. But still feels good.
[11:14] <jelmer> :)
[11:21] <poolie> maybe we should just make a web page with badges if we can't do it automaticaly
[11:33] <spiv> poolie: or a greasemonkey script?
[12:02] <jelmer> spiv: if you're still around and interested, we're having a udd meeting #ubuntu-meeting
[12:03] <jelmer> *in
[12:03] <poolie> jam: hi?
[13:50] <mrevell-lunch> Morning/nick mrevell
[13:51] <mrevell-lunch> sorry
[13:51] <mrevell> :)
[14:23] <jkakar> Hi ntoll! :)
[14:23] <ntoll> hi jkakar
[14:23] <ntoll> fancy seeing you in here ;-)
[14:23] <jkakar> ntoll and I have discovered something funky in our branches...
[14:23] <jkakar> 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] <jkakar> 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] <jkakar> So I ran 'bzr check' and got this:
[14:24] <jkakar>   3838 revisions
[14:24] <jkakar>   1360 file-ids
[14:24] <jkakar>      3 inconsistent parents
[14:24] <jkakar> I'm wondering what '3 inconsistent parents' means...?
[14:24] <jkakar> Could it be that some flummox in merging could have removed the content we expect...
[14:25] <jkakar> For example, I seem to remember reverting a revision could produce strange results when you merged it back...?
[14:26] <jkakar> abentley: ^^ Any ideas?
[14:39] <abentley> jkakar: No, inconsistent parents are mostly harmless.  They are usually due to ghost revisions or bzr bugs.
[14:39] <jkakar> abentley: Okay, thanks. :)
[14:40] <jkakar> abentley: I guess bzr bugs are mostly harmless? ;b
[14:40] <jkakar> abentley: Anyway, I think we figured out the issue is an EPEBKAC error. :)
[14:40] <abentley> Ah, okay.
[14:40] <jkakar> abentley: Thanks for your feedback, much appreciated... these kinds of "WTF?" moments are always a bit scary. :)
[14:42] <abentley> jkakar: no problem.
[14:43] <fullermd> I think 'reconcile' will often fix inconsistent parents.
[14:44] <jkakar> 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] <jkakar> fullermd: Neither of those things happened so I didn't run it.
[14:47] <maxb> What exactly is an "inconsistent parent"? Is this described anywhere?
[14:47] <jkakar> maxb: I was wondering the same... I couldn't easily find anything about it.
[14:49] <maxb> I gather it's something to do with consistency between the overall revision graph and the ancestry attributed to individual files
[14:50] <jkakar> maxb: I gathered the same, yeah.
[15:39] <diwic> What do I do about this: "bzr bd" gives error "Unable to determine the previous upload for --package-merge"?
[15:43] <james_w> diwic,  "bzr branch lp:bzr-builddeb /tmp/builddeb; BZR_PLUGINS_AT=builddeb@/tmp/builddeb bzr bd"
[15:44] <diwic> james_w, iow this is a known bug that is fixed in trunk?
[15:44] <james_w> diwic, indeed
[15:45] <diwic> thanks!
[17:56] <knighthawk> 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?
[17:57] <niemeyer> Hey there
[17:57] <knighthawk> looks like I'm running bzr 2.1.1-4
[17:57] <jelmer> knighthawk: rebase is in the bzr-rewrite plugin
[17:57] <niemeyer> Getting some issues with bzr-fastimport related to an AttributeError on _find_ancestors
[17:57] <knighthawk> jelmer thanks
[17:57] <niemeyer> On natty, specifically
[17:58] <niemeyer> Is that a known issue?
[17:58] <jelmer> hi Gustavo
[17:58] <jelmer> niemeyer: it sounds vaguely familiar - can you pastebin the backtrace?
[17:58] <niemeyer> jelmer: Hi!
[17:58] <niemeyer> Sure
[17:58] <niemeyer> jelmer: http://pastebin.ubuntu.com/596621/
[18:01] <jelmer> niemeyer: thanks
[18:01] <jelmer> niemeyer: it's indeed something I've seen before
[18:03] <jelmer> https://bugs.launchpad.net/bzr-fastimport/+bug/541626
[18:05] <jelmer> I'm not too familiar with the index code, perhaps John can comment on it tomorrow.
[18:05] <jelmer> it looks shallow
[18:07] <niemeyer> jelmer: Cool, thanks
[18:40] <mgz> 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] <jelmer> mgz: perhaps the branch that forbade using None as alias for "null:" in Branch.set_last_revision_info() ?
[18:42] <mgz> maybe. do you have a link? I meant to ask whether said variable should actually be bytes or unicode.
[18:42] <jelmer> mgz: that was inspired by some other code in bzrlib.revision that did the same thing IIRC
[18:43] <mgz> 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] <jelmer> tjatlp:~jelmer/bzr/testament-tree ?
[18:43] <jelmer> that's lp:~jelmer/bzr/testament-tree ?
[18:44] <jelmer> bzrlib.revision.is_reserved_id() checks against basestring
[18:46] <jelmer> mgz: it happens in more places, e.g. Repository._iter_revisions
[18:46] <mgz> must have confused two different diffs. I've not been keeping up with for coding. :)
[21:44] <ironmagma> does bzr require you to download the whole repository history, like git/hg do?
[21:45] <Odd_Bloke> ironmagma: You can use lightweight checkouts, which do not.
[22:06] <knighthawk> 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] <lifeless> push shouldn't even be destructive, unless you used --overwrite
[22:07] <lifeless> s/even/ever/
[22:07] <knighthawk> did *not* use overwrite
[22:07] <lifeless> jelmer: ^ around ?
[22:10] <knighthawk> 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] <knighthawk>  going to do it again.
[22:12] <lifeless> yeah, I can understand that
[22:12] <lifeless> 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] <jelmer> re
[22:18] <jelmer> hi lifeless, knighthawk
[22:19] <knighthawk> hey jelmer
[22:19] <jelmer> 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] <jelmer> knighthawk: The default of append_revisions_only=True is intended to prevent you from shooting yourself in the foot
[22:21] <knighthawk> 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] <jelmer> knighthawk: you can restore the old mainline using either "svn cp -r ..." or "bzr push --overwrite ..."
[22:22] <jelmer> knighthawk: right, rebase will preserve the upstream branch mainline
[22:22] <knighthawk> jelmer sorry I'm not sure what is meant by mainline is that the trunk?
[22:22] <jelmer> knighthawk: mainline are basically the revisions shown by "bzr log -n1"
[22:22] <jelmer> knighthawk: non-mainline revisions will be shown too if you use "bzr log -n0"
[22:31] <knighthawk> thanks jelmer that clears up a lot. but now did I just destroy my changes of restoring the mainline by running rebase?
[22:32] <jelmer> knighthawk: it depends on what exactly you rebased