[00:02] <lifeless> mtaylor: its the older form of shelve
[00:03] <lifeless> mtaylor: for folk with old shelves they need to get ack
[00:09] <Peng_> Or for people on Windows, right?
[00:21] <garyvdm> Hi - I'm getting an error trying to commit which is quite weird.
[00:21] <garyvdm> http://paste.ubuntu.com/202463/
[00:21] <garyvdm> Could not acquire lock "/home/garyvdm/qbzr/wd/qbzr/.bzr/checkout/dirstate": (11, 'Resource temporarily unavailable')
[00:22] <garyvdm> There is nothing that I am aware of that could be holding a lock.
[00:22] <garyvdm> Nothing running that is.
[00:24] <garyvdm> Ah - never mind - I had a bzr runinng in my ide that was stoped in pdb that was holding the lock.
[00:27] <poolie> hello
[00:31] <poolie> jam, thanks for the analysis of 390745
[00:38] <poolie> jml/thumper/mwh: I'm thinking about doing "reconfigure --stacked-on" or --unstacked soon
[00:39] <poolie> robert questions whether this is a good use of time or not
[00:39] <poolie> any opinions?
[00:39] <mwhudson> poolie: YES PLEASE
[00:42] <poolie> k
[00:42] <thumper> poolie: how would that interact with LP?
[00:43] <igc> morning
[00:43] <poolie> hello igc
[00:43] <poolie> thumper: um
[00:44] <igc> hi poolie, thumper
[00:44] <thumper> poolie: as in, reconfiguring a stacked LP branch
[00:44] <thumper> hi igc
[00:44] <poolie> it would work over hpss to let you configure branches to be either stacked or unstacked
[00:44] <poolie> not sure what you're asking
[00:44] <thumper> poolie:would it pull the necessary revisions from the stacked branch?
[00:44] <thumper> poolie: how about the ability to override the suggested stacking branch?
[00:45] <poolie> yes, it would potentially copy a lot of data when making the branch standalone
[00:45] <thumper> poolie: is incremental reconcile very hard?
[00:46] <poolie> lifeless estimates several days
[00:47] <lifeless> thumper: its tricky; gotta copy some data exclude others while simultaneously altering it
[00:48] <thumper> I'd say that is more important than playing with stacking right now
[00:48] <thumper> IMHO
[00:48] <thumper> or
[00:49] <thumper> some optimisations for reconcile on 2a formats
[00:49] <thumper> we're wanting to move more internal teams to the 2a format
[00:49] <thumper> and james_w's ubuntu branches
[00:49] <poolie> ok, that's useful feedback
[00:50] <poolie> though it's not necessarily either/or
[00:50] <thumper> heh
[00:50] <thumper> no
[00:50] <thumper> we want everything, and a pony
[00:50] <poolie> in that i'd need to page in a lot of robert's state to do renconcile
[00:50] <jml> delicious ponies.
[00:50] <poolie> but i can do the stacking thing fairly quickly
[00:51] <thumper> reduced swapping is always a win
[00:51] <thumper> I'd still like the ability to tell the bzr client not to stack no matter what LP suggests
[00:51] <thumper> which we can't do right now
[00:52] <lifeless> the streaming fetch bug is highest IMO
[00:52] <lifeless> reconcile is a pain, can't merge for lp developers is a blocker
[00:52] <lifeless> other teams have /way/ fewer devs per branch, which makes transition much easier. Also smaller history.
[00:53] <thumper> yeah
[00:53] <thumper> +1 on streaming fetch
[00:54] <spiv> lifeless: as in inventory deltas, or do you mean something else?
[00:54] <mwhudson> i was assuming reconfigure --unstacked/--stacked-on wouldn't be especially hard
[00:54] <poolie> me either
[00:54] <lifeless> spiv: https://bugs.edge.launchpad.net/bzr/+bug/390563
[00:54] <poolie> so easy a manager could do it
[00:54] <thumper> poolie: :)
[00:54] <thumper> poolie: also a definitive "don't stack" flag should be easy too right?
[00:55] <lifeless> mwhudson: the library call to change already takes care of fetch; more problematic is making a new repo when making a shared repo branch into a stacked branch
[00:55] <lifeless> thumper: don't stack may require smart server verb changes. FWIW
[00:55] <lifeless> thumper: but is a don't stack flag needed ?
[00:55] <thumper> lifeless: I thought we decided a while ago that stacking was determined entirely client side
[00:55] <poolie> so, seriously
[00:55] <poolie> i have to make some calls today
[00:56] <lifeless> thumper: I know the lp-code team have occasion to use it for testing, but outside that group?
[00:56] <poolie> i was hoping i could do one or the other of them in the time i do have today
[00:56] <thumper> lifeless: for unrelated branches, it is useful
[00:56] <thumper> although, perhaps limited use
[00:56] <thumper> poolie: pick one an do it!
[00:56] <thumper> :)
[00:56] <lifeless> thumper: /may/ require verb changes  ;)
[00:56] <lifeless> thumper: we have more verbs doing more things, now.
[00:57] <thumper> lifeless: is one "JFDI" ?
[00:57] <lifeless> for a small hack, I'd most like to see network activity not overwriting stuff when there is no progress bar. Or something like that. Its a very visible ugliness
[00:58] <poolie> lifeless: it's high on my list too
[00:59] <lifeless> mwhudson: the bzr log from codehosting
[01:00] <lifeless> mwhudson: is it safe to attach to the bug, or do you think there are things we'll want kept secret in them ?
[01:00] <mwhudson> lifeless: i think it's pretty unlikely there's anything sensitive in there
[01:04] <igc> poolie: ready for a call soon?
[01:04] <Peng_> Yep, pushing 2a -> 1.9rr over hpss isn't very fun. 22 seconds, while 2a -> 2a is 6.
[01:05] <Peng_> (For 11 revisions of loggerhead.)
[01:05] <poolie> igc, yes, let me get a couple of things closed here
[01:05] <poolie> will call you in 5?
[01:05] <Peng_> Still usable, of course, but it doesn't make dogfooding very fun.
[01:07] <igc> sure
[01:07] <lifeless> Peng_: indeed
[01:09] <Peng_> Well, I could upgrade lp:loggerhead to 2a when nobody's looking, and it would take them a while to figure it out... :D
[01:09] <lifeless> I wouldn't
[01:09] <lifeless> not till we fix the current set of critical bugs
[01:10] <Peng_> What is the current set of critical bugs?
[01:10] <Peng_> Absent factory, IDS being used for push, ?
[01:12] <lifeless> lp knows :P
[01:22] <Peng_> Yeah, that's mostly it, aside from some rich-root upgrade issues.
[01:25] <Peng_> The other one is cross-format inventory delta streaming.
[01:26] <lifeless> thats needed for cross format pushing to be pleasant
[01:49] <poolie> igc https://edge.launchpad.net/bzr/+milestone/2.0
[01:49] <poolie> Peng_: that url for you too
[01:49] <lifeless> spiv: what are you up to today? Could I request https://bugs.edge.launchpad.net/bzr/+bug/338561 ?
[01:49] <poolie> lifeless, spiv, can you tell me about bug 390563 too?
[01:51] <lifeless> poolie: I'm investigating it at the moment
[01:51] <lifeless> poolie: all I know for sure is in the bug
[01:51] <lifeless> I think
[01:51] <Peng_> poolie: Oh, thanks.
[01:57] <spiv> lifeless: hmm, I could have sworn I fixed that a couple of months back.  Sure, I'll look at that.
[01:58] <lifeless> spiv: lots of them in ~/.bzr.log on lp codehosting ;)
[02:00] <SamB> spiv: could be that someone unfixed them
[02:00] <SamB> or that the fix somehow got lost before being merged...
[02:01] <lifeless> SamB: thats what we have tests for; and lp/bb both track merge status by revids
[02:01] <lifeless> SamB: e.g. 'no' ;)
[02:02] <lifeless> poolie: is there more you want to know about 390563?
[02:02] <SamB> lifeless: depending on how forgetful you are
[02:02] <SamB> and/or whether you actually manage to write said tests
[02:03] <spiv> SamB: it's possible that I actually just fixed something similar but not quite the same, too :)
[02:03] <spiv> SamB: my memory of things I did a few months ago tends to be pretty hazy.
[02:03] <SamB> spiv: yeah, there's also that
[02:03] <lifeless> spiv: a few months ago, at my place, we looked at it and said 'lets file a bug and keep going on streaming'
[02:06] <spiv> lifeless: ah
[02:07] <spiv> Also, I think before that I fixed a similar issue to do with streaming bodies, perhaps.
[02:07] <lifeless> yes, that rings a bell
[02:21] <mwhudson> er
[02:21] <mwhudson> pqm seems to be getting absentcontentfactory errors with two non-stacked branches
[02:23] <lifeless> mwhudson: details?
[02:23] <lifeless> mwhudson: push or pull
[02:24] <lifeless> could be bug 365615
[02:24] <mwhudson> lifeless: merge, i expect, i don't really know details
[02:24] <lifeless> mwhudson: who does
[02:24] <mwhudson> dunno
[02:24] <mwhudson> lifeless: all i'm going in is failure mails to the launchpad list
[02:25] <mwhudson> it could be 365615 i guess
[02:25] <mwhudson> a traceback would be nice...
[02:35] <fullermd> igc: Nice timing results...
[02:36] <igc> fullermd: indeed. jam rocks!
[02:36] <fullermd> 's almost enough to make me wanna see how long importing ports would take...
[02:37] <fullermd> Though I don't think I'd want my system murdering me in my sleep for doing so.
[02:37] <igc> (I'm guessing his chk-map tweaks made a huge difference, together with his faster-commit stuff)
[02:37] <igc> fullermd: for *really* huge imports, there's still plenty of tuning to do I think
[02:38] <igc> fullermd: but probably in fast-import itself, more than the core
[02:38] <igc> fullermd: and I'm unlikely to get to tuning fast-import till after 2.0 reaches RC
[02:38] <fullermd> Yeah.  It'd be pretty huge.  Say around 200k revisions of 200k files.
[02:39] <fullermd> (well, files and dirs)
[02:42] <lifeless> fullermd: doit
[02:43] <lifeless> fullermd: generate a stream and save to disk ; then you can import incrementally or some such
[02:44] <fullermd> Yeah, the first step would be seeing if I have enough disk space to hold the fast-import stream...
[02:44] <fullermd> Certainly no time for it this weekend though; it's Field Day.
[02:45] <fullermd> (and the following few days will be "desperately catch up on sleep", as usual  ;)
[02:45] <lifeless> whats a field day?
[02:46] <fullermd> http://www.arrl.org/contests/announcements/fd/
[02:47] <thumper> lifeless: does the nightly ppa contain the autopack fix yet?
[02:47] <fullermd> (For some of us, hanging around an IRC channel about a version control tool just ain't nerdy enough, see...)
[02:49] <lifeless> thumper: I don't know
[02:50] <thumper> ok
[02:50] <thumper> lifeless: a pack of an already mostly packed 2a repo is taking quite a while
[02:50] <thumper> is that expected
[02:50] <thumper> ?
[02:50] <thumper> like 10 minutes
[02:52] <lifeless> thumper: do you have the C extensions?
[02:53] <thumper> lifeless: it is from the PPA so I think so
[02:53] <lifeless> thumper: and 'pack' has to recompress all history, so its a slow command to run (which is why you shouldn't ever run it unless you have specific reasons to do so)
[03:02] <lifeless> thumper: so why were you packing?
[03:03] <thumper> testing mainly, making my repo smaller, considering how to handle this on a large scale for LP
[03:06] <lifeless> thumper: bzr will pack as needed
[03:06] <lifeless> manual packing is generally a bad idea
[03:12] <Peng_> mwhudson or beuno: ping
[03:21] <jfroy_> jelmer: I just tried to diff two local branches which are both branches of remote svn branches
[03:22] <jfroy_> And bzr died with a missing revision / no such revision error
[03:22] <jfroy_> Is there any way to figure out, perhaps, where that revision is?
[03:22] <jfroy_> if anywhere
[03:22] <jfroy_> this is kind of an open question too, I suppose
[03:23] <jfroy_> wondering if there's a way to search a repository or a branch for a specific revision ID
[03:24] <lifeless> log -r revid:REVID
[03:24] <jam> igc: did you change fast-import to use _add_text instead of add_lines at least?
[03:27] <jfroy_> lifeless: ok I think I am screwed :/
[03:28] <jfroy_> well maybe
[03:28] <jfroy_> it's odd
[03:28] <lifeless> or cat-revision
[03:28] <jfroy_> that revision shows up in a branch in another repository
[03:28] <jfroy_> but does not show up in the same branch in another reposityr
[03:29] <jfroy_> *repository
[03:29] <jfroy_> it's clearly a bzr-svn bug
[03:29] <jfroy_> :(
[03:30] <jfroy_> actually, it looks like that revision was in a local branch I did not push to subversion
[03:30] <jfroy_> and have since deleted in the local repository
[03:41] <Peng_> mwhudson & beuno: unping. :)
[03:42] <mwhudson> Peng_: not-hi
[03:44] <Peng_> mwhudson: Heh, nice timing.
[03:45] <igc> jam: not yet - my figures are still with code calling add_lines()
[03:47] <lifeless> jam: hi
[03:47] <lifeless> jam: did you get anywhere with the stacking bug overnight?
[03:48] <jam> lifeless: I did not, other than to not be able to reproduce it locally, but to have the lp branch fail :(
[03:49] <lifeless> jam: lftp seems to be working again with lpp
[03:49] <Peng_> mwhudson: FWIW, I unpinged you because I decided to send a merge request.
[03:49] <lifeless> lp's sftp server, so you can just mirror down the branch
[03:49] <lifeless> you don't need all of lp
[03:50] <mwhudson> Peng_: oh ok
[03:54] <mwhudson> Peng_: ah, cool in principle at least, haven't read the diff yet :)
[03:54] <Peng_> mwhudson: The diff is the part I'm worried about. :P
[03:59] <jelmer_> jfroy_: hi
[03:59] <jelmer_> jfroy_: there's been another report of that as well
[03:59] <jelmer_> jfroy_: I suspect there's a regression since one of the 0.6 releases
[03:59] <jfroy_> is there anything at al to be done to salvage that revision?
[04:00] <jfroy_> I suspect push_merged_revision will help
[04:00] <jfroy_> since it will push merged revisions, even those of otherwise purely local branches I would not otherwise push myself
[04:00] <jfroy_> (which I do a lot, scratch branch, private feature branch, merge branches)
[04:01] <jelmer_> jfroy_: until we've figured out what the bug is about, no idea if push merged revisions will help
[04:03] <jfroy_> I think it will
[04:03] <jfroy_> the branch nick on that missing revision if from a branch that was purely local
[04:03] <jfroy_> I suspect that specific revision never got pushed to svn
[04:03] <jfroy_> so other people, starting from scratch, will have that revision as a ghost
[04:04] <jfroy_> push merged revision should avoid that situation
[04:04] <jfroy_> (purely local and since then deleted)
[04:06] <jelmer_> if you can confirm that is the case, please let me know
[04:06] <jelmer_> are you using "bzr branch" or "bzr svn-import" to fetch?
[04:08] <jfroy_> branch
[04:08] <RenatoSilva> Is there any documented problems with Novell filesystems?
[04:08] <lifeless> no
[04:08] <jelmer_> jfroy_: I need to get some sleep, again, if you find more info please let me know
[04:09] <jfroy_> will do
[04:09] <jelmer_> jfroy_: I hope to put some time into bzr-svn again at the end of the week
[04:09] <jfroy_> np
[04:09] <jfroy_> it's not a show stopper
[04:12] <RenatoSilva> I get an error about .bzr/branch/lock/[...].tmp/lock, something like that. I think it may be related to big dir names or so. Stupid Novell anyway.
[04:15] <mtaylor> lifeless:
[04:15] <mtaylor> >>> import cpuinfo
[04:15] <mtaylor> >>> cpuinfo.cpuinfo_processor_count(True)
[04:15] <mtaylor> 2
[04:25] <lifeless> mtaylor: cpuinfo.processor_count(True) would be nicer
[04:25] <lifeless> mtaylor: and for nonstrict mode (which scripts will want,
[04:25] <lifeless> cpuinfo.processor_count()
[04:25] <mtaylor> lifeless: indeed
[04:26] <lifeless> if you can :)
[04:26] <mtaylor> lifeless: totally
[04:26] <lifeless> mtaylor: don't you need perl first ?
[04:26] <mtaylor> lifeless: ew
[04:26] <lifeless> mtaylor: to be able to use this, I mean?
[04:26] <lifeless> isn't your test thingy that checks cpu counts perl?
[04:27] <mtaylor> lifeless: so - do you have any philosophical or other arguments about various ways to build python extension modules in the context of a larger autotools-run project
[04:27] <mtaylor> lifeless: yeah. I'll add perl in just a sec
[04:27] <lifeless> mtaylor: personally, I hate setup.py being mixed in with autotools
[04:27] <thumper> spiv: ping
[04:27] <lifeless> no point taking one half assed build system and mixing *another* half assed one in with it
[04:28] <spiv> thumper: pong
[04:28] <lifeless> mtaylor: but, working >> purity
[04:28] <thumper> spiv: I have a local lightweight checkout of a 2a branch
[04:28] <mtaylor> lifeless: k. I go back and forth on that... because I hate mixing the two - but I also hate telling automake all about python :)
[04:28] <mtaylor> lifeless: working bitshift purity?
[04:28] <thumper> spiv: bzr info -v tells me it is Branch format 7
[04:28]  * mtaylor is confused 
[04:28] <lifeless> mtaylor: working is more important than purity
[04:29] <thumper> spiv: pushing to LP says: Source branch format does not support stacking, using format:
[04:29] <thumper>   Branch format 7
[04:29] <mtaylor> lifeless: yes yes. trolling
[04:29] <thumper> spiv: what can I do to help diagnose
[04:29] <spiv> thumper: known bug, lemme get you the number
[04:29] <spiv> thumper: https://bugs.edge.launchpad.net/bzr/+bug/388908
[04:29] <lifeless> thumper: its filed as a bug already
[04:30] <thumper> ok, thanks
[04:30] <abentley> jam: branch push is complete.
[04:30] <thumper> spiv: I was wondering if it had something to do with the format 6 remote branch format problems
[04:31] <lifeless> thumper: what format 6 remote branch problems?
[04:31] <spiv> thumper: no
[04:35]  * igc lunch (and afk for a few hours)
[04:50] <mtaylor> lifeless: it would be great if ruby and perl had something like AM_PATH_PYTHON...
[04:57] <lifeless> wouldn't it just
[05:00] <jfroy_> hey, this may be a stupid question, but is there a difference between bzr shelve and looms?
[05:03] <lifeless> huge
[05:04] <Peng_> mwhudson: loggerhead/main.py should lose the exec bit, right?
[05:05] <mwhudson> Peng_: i thought i did that, so yes
[05:06] <Peng_> mwhudson: Mind if I do it?
[05:06] <Peng_> mwhudson: Err, yeah, you did do it. I misread the diff. Sorry!
[05:06] <mwhudson> Peng_: i just did
[05:07] <mwhudson> gar, didn't mean to commit that :(
[05:07]  * mwhudson uncommits
[05:07] <Peng_> Oh yay, one of my 2a branches just committed suicide.
[05:09] <Peng_> Oh, it was just bzr-search.
[05:10] <Peng_> ...Which doesn't really make a difference, because I usually bug lifeless about these sorts of things anyway. :P
[05:15] <Peng_> mwhudson: Hey hey, your revision makes bzr-search explode on 2a. :)
[05:21] <mwhudson> Peng_: hooray
[05:23] <mtaylor> lifeless: python. ruby. done.
[05:23] <mtaylor> lifeless: perl next
[05:27] <Peng_> Buggy bug filed, FYI -- https://bugs.edge.launchpad.net/bzr-search/+bug/391459
[05:28] <Peng_> "Ubuntu bug"?
[05:37] <Peng_> mwhudson: I like 'hi', 'ho', 'ha'. :) Today I used 'Hello' but it felt kind of silly and verbose.
[05:44] <lifeless> Peng_: thanks for the bug; will check later
[05:46] <Peng_> lifeless: :)
[06:30] <poolie> spiv, around? want a quick call in a bit?
[06:48] <bignose> bzr-loom crashes, no matter what I do (Debian bug #532947).
[06:48] <bignose> how can I un-loomify a branch so I can keep working on it?
[06:49] <poolie> bignose: can you branch individual threads out into separate branches?
[06:49] <bignose> poolie: using what command? whatever I do it crashes with the message as recorded in that bug report.
[06:50] <lifeless> bignose: I think its all fixed upstream
[06:50] <lifeless> bignose: I'm not sure the branch is corrupted; is it possible that you simply have a broken combination of loom + bzr?
[06:51] <bignose> anything's possible.
[06:53] <bignose> so how can I get back to a working state for that branch?
[06:54] <bignose> or, more relevant to today: a branch that has already been working fine with a loom, but is now unreadable as per that bug report?
[06:55] <lifeless> if it *is* a damaged loom, you might be able to get the thread tip ids out using hexdump on .bzr/branch/current-loom, and use the python api to fetch content from the repo
[06:55] <bignose> urk.
[06:55] <wgrant> I'd just try upgrading bzr-loom first, though...
[06:55] <lifeless> if, as I suspect, you just  have an incompatible loom, get your loom version matching your bzr version, and it should be fine
[06:55] <bignose> I'll wait for the Debian package to update, then.
[06:56] <lifeless> jelmer was asking for help on it
[06:56] <bignose> the "Debian Bazaar maintainers" (listed as the maintainer) have yet to give any response to that bug report, though :-(
[06:57] <poolie> igc, could you post your "IDE Integration..." message on the project blog?
[06:57] <bignose> is this related to the discussion on the Bazaar mailing list, about the systemic problem of plug-ins that *need* to be at the same version, but never *say* that in the corresponding OS packages?
[06:58] <lifeless> bignose: loom tries very hard not to be tied to specific versions
[06:58] <lifeless> but there have been a few API skews that affected it recently.
[07:29] <vila> hi all
[07:29] <lifeless> hai
[07:37] <igc> hi vila
[07:46] <vila> hi Ian !
[09:23] <Peng_> Does bug #390563 waste disk space in non-stacked branches or just bandwidth?
[09:23] <Peng_> ...S'pose I could check it myself.
[09:23] <vila> Peng: and tell us if you can reproduce it and how
[09:24] <Peng_> Oh, right, I forgot that that bug only affects certain branches.
[09:28] <Peng_> effects? eh
[09:28] <fullermd> Affects.
[09:28] <fullermd> Well, the bug may effect certain branches too, but that would be a really weird bug   :p
[09:29] <Peng_> Someday, I should learn the difference between those two words.
[09:29] <Peng_> Then I should verify "then" and "than". :P
[09:30] <fullermd> Generally, affect is a verb and effect is a noun.
[09:30] <Peng_> (OK, I just said that one for the punny thing.)
[09:30]  * Peng_ is obviously a linguistic master. :P
[09:31] <fullermd> Oh, you can sort them out.  Their knot that hard.
[09:34] <mwhudson> fullermd: you're a bad man
[09:36] <Peng_> mwhudson: Shouldn't that be "your a bad man"?
[09:37] <fullermd> Hey, the proof is in the pudding, just take a different tact.
[09:54] <Lo-lan-do> Hi all
[09:54] <Lo-lan-do> What's the status of the HistoryHorizon feature currently?
[09:55] <Lo-lan-do> (The use case I'm looking for is the "Old huge project" mentioned on http://bazaar-vcs.org/HistoryHorizon)
[09:56] <Lo-lan-do> Is it fulfilled by stacked branches?
[09:59] <Peng_> Lo-lan-do: They're not the same thing, but stacked branches let you store the repository on the server, similar to a lightweight checkout, only you've got a real branch.
[10:07] <lifeless> Lo-lan-do: we have decent performance and excellent compression even for huge old projects, in the 2a format.
[10:17] <Peng_> Users will just move the goalposts by making even huger projects. :P
[10:18] <Lo-lan-do> lifeless: Huge as in?
[10:18] <Lo-lan-do> I'm talking about a 16G CVS repo here.
[10:19] <Peng_> lifeless: Do you sleep?
[10:19] <Lo-lan-do> We need to do some cleanup in there, and it'll be smaller with bzr, but still, if the main repo could be limited in history that would certainly help.
[10:21] <Lo-lan-do> Could the main repo be stacked on a historical one, thus making day-to-day operations fast while keeping history?
[10:22] <Peng_> Lo-lan-do: What do you mean? Like, have a stacked branch pointing to another one on the same machine?
[10:22] <Lo-lan-do> I'm very glad to hear about 2a, too.  Do you think it'll be stable before the end of the year?
[10:23] <Lo-lan-do> Peng_: Yes.  So daily commits only add to the smaller "current" repo.
[10:23] <Lo-lan-do> But maybe 2a entirely removes the benefits of such an approach, in which case I'll happily recommend that.
[10:24] <asabil> hi all
[10:24] <asabil> is there a way to setup a configuration (bugtracker settings) that will be propagated during a bzr branch to all users ?
[10:26] <Peng_> Lo-lan-do: Having a larger repo isn't a problem. Stacking that would be pointless.
[10:27] <lifeless> Peng_: theory has that I do
[10:27] <Lo-lan-do> Having to replicate a large repo with file transfers could cause problems.
[10:27] <lifeless> Lo-lan-do: that could be massively smaller - perhaps even 1GB total, in 2a
[10:27] <Peng_> Lo-lan-do: Actually...a smaller repo would probably save a few ms here and there, but stacking would also cost a few ms here and there. :D
[10:27] <Peng_> Lo-lan-do: If the users do "bzr branch --stacked", they won't have to replace the entire thing.
[10:27] <Lo-lan-do> I fear that smart repo formats wouldn't be very good at rsyncing (but maybe I'm completely wrong)
[10:27] <lifeless> Peng_: but its only EOD, not time-to-sleep now
[10:27] <Peng_> Err, replicate*
[10:28] <Peng_> lifeless: Ah.
[10:28] <lifeless> Lo-lan-do: all our formats since pack-0.92 rsync very well
[10:28] <Peng_> lifeless: Except when they get packed...
[10:28] <lifeless> Lo-lan-do: old data is rarely moved on disk, so it rarely shows up
[10:28] <lifeless> Lo-lan-do: as long as noone runs 'bzr pack', which they shouldn't.
[10:28] <Lo-lan-do> Good to know.
[10:29] <Lo-lan-do> I guess bzr pack could be run monthly or so, if it's useful at all.
[10:29] <lifeless> I wouldn't even do that
[10:29] <lifeless> bzr incrementally packs as commits and pushes occur.
[10:29] <Lo-lan-do> More and more excellent.
[10:30] <lifeless> every power of 10 commits it does a full pack automatically
[10:30] <lifeless> so if you have 1M commits today, you'd need another 9 million to need another full pack ;)
[10:31] <Peng_> Running "bzr pack" occasionally *would* buy you a teensy bit of performance, but it's not enough to matter. Autopacking keeps things from getting out of hand.
[10:32] <lifeless> Peng_: actually, full packing when its not needed, with pack ordering, can decrease performance :)
[10:32] <lifeless> Peng_: (for a central repo thats only push/pulled with)
[10:32] <Peng_> lifeless: Oh? Why? I don't get it.
[10:32] <Peng_> Also, Firefox crashed. Arrgh.
[10:32] <Lo-lan-do> How do the new repo formats cope with thousands of branches?
[10:32] <lifeless> Peng_: by creating a single large btree that has to be read rather than a smaller one with the most recent data and a larger one that isn't read at all
[10:33] <Peng_> lifeless: Ahh.
[10:33] <lifeless> you'd need fairly extreme repos for this to show up
[10:33] <lifeless> as we get a 200:1 fanout in our indices today
[10:34] <lifeless> Lo-lan-do: should be fine; there isn't a single file listing all the branches or anything, so its much of a muchness
[10:34] <Lo-lan-do> Good.
[10:35] <Lo-lan-do> Last two questions: timeframe for format 2a being officially stable?  And possibility for repo-side hooks?
[10:35] <Peng_> Repositories don't really know about branches. They're just big bags of revisions.
[10:35] <Lo-lan-do> (The hooks can be done without, they use incron for now)
[10:36] <Lo-lan-do> (they=my current client)
[10:36] <Peng_> Well, I guess it could matter if you had a complicated history and bzr was bad at choosing compression parents, but it's not.
[10:36] <lifeless> Lo-lan-do: 2a is supported now; however you need https://bugs.edge.launchpad.net/bzr/1.16/+bug/365615 - we're still polishing the code around the format.
[10:37] <lifeless> Lo-lan-do: we'll be doing a 1.16.1 with that hotfix and possibly a couple of others (to do with stacking on 2a formats)
[10:37] <Lo-lan-do> I'm not in much of a hurry, they'll need time to think about it anyway.
[10:38] <Lo-lan-do> My current job is to find quickfixes to make the CVS repo a bit more usable than it currently is.
[10:38] <Lo-lan-do> ...and to provide recommendations for the longer term.
[10:38] <Lo-lan-do> I'm pretty sure bzr will be in that part :-)
[10:39] <lifeless> awesome
[10:40] <Peng_> Stupid question: how large is MySQL's repo?
[10:40] <Lo-lan-do> A bzr branch uses 600 MB (with working-tree)
[10:40] <mwhudson> Peng_: ~600 megs or so
[10:41] <Lo-lan-do> The .bzr is 467MB here
[10:41] <lifeless> Lo-lan-do: of mysql?
[10:41] <lifeless> Lo-lan-do: it shrinks by about 2/3rds going to 2a
[10:41] <Lo-lan-do> (Branched from lp:mysql-server sometime this week)
[10:42] <Lo-lan-do> format: unnamed, bzr 1.11
[10:42] <lifeless> info -v will show you the actual repo format
[10:42] <Peng_> In 1.11, it'll probably also spend a long time churning through the history, but you can Ctrl+C it.
[10:42] <Lo-lan-do> packs 6
[10:43] <Lo-lan-do> This 2/3 number is awesomely impressive.
[10:48] <Lo-lan-do> Sorry, crashed.  You were saying?
[10:48] <lifeless> nothing ;)
[10:48] <lifeless> 19:42 < Lo-lan-do> packs 6
[10:48] <lifeless> 19:43 < Lo-lan-do> This 2/3 number is awesomely impressive.
[10:48] <lifeless> 19:46 -!- Lo-lan-do [n=roland@193.252.149.222] has quit [Read error: 104 (Connection reset by peer)]
[10:48] <lifeless> 19:48 -!- Lo-lan-do [n=roland@193.252.149.222] has joined #bzr
[10:48] <Lo-lan-do> Cool.
[10:49] <Lo-lan-do> Anyway, will you be available for a beer at Debconf? :-)
[10:49] <Lo-lan-do> I think I owe a couple to jelmer too.
[10:52] <lifeless> I won't be at debconf
[10:52] <lifeless> sorry :(
[10:52] <Kinnison> You won't? Boo hiss :-(
[10:52] <Lo-lan-do> RMLL in Nantes maybe?
[10:53] <lifeless> Kinnison: where is it this year ?
[10:53] <Lo-lan-do> Western Spain
[10:53] <Kinnison> Cacéres, Spain
[10:53] <lifeless> yah. Wrong side of the world
[10:53] <Kinnison> About four hours west of Madrid
[10:53] <lifeless> when things line up, its awesome to get to such things
[10:53] <lifeless> but as it stands, its awfully hard to get there, and I've used all my conference leave this year already.
[10:54] <Kinnison> fair enough
[10:54] <Lo-lan-do> My plan is to develop the bzr plugin for fusionforge during debcamp/debconf
[10:54] <Kinnison> Lo-lan-do: coo. sounds amusing.
[10:55] <Lo-lan-do> (And git, and hg, and whatever VCS out there if there's a guru around to tell me what needs to be done for his preferred one)
[10:55] <Lo-lan-do> I'll probably implement a cpold plugin too, if only as a proof of concept after my refactoring.
[10:55] <Kinnison> lifeless: any plans for a UDS in the UK any time soon?
[10:56] <Peng_> cpold?
[10:56] <lifeless> next is US I think; beyond that no idea
[10:56] <Lo-lan-do> Peng: The oldest VCS of them all.
[10:56] <Lo-lan-do> Peng: "cp foo.c foo.c.old"
[10:57] <Peng_> Lo-lan-do: Oh. I use that one a lot!
[10:57] <Lo-lan-do> There you are :-)
[10:58] <Lo-lan-do> I'm wondering if I'll have the nerve to actually upload a gforge-plugin-scmcpold to Debian :-)
[10:58] <Lo-lan-do> Anyway, food calls.  Thanks for your answers!
[10:59] <Peng_> Lo-lan-do: See you later! :)
[10:59] <Peng_> Hmm, food. Good idea.
[12:01] <awilkins_> Is bzr 2 getting copy of files in inventories?
[12:02] <gioele> hello
[12:02] <lifeless> awilkins: no
[12:03] <awilkins> I suppose it would be yet another awkward format hump to drive over
[12:03] <awilkins> It's nice to see that not-rich-root is deprecated for 2a
[12:06] <gioele> do stacked branches require the master branch to support the staking in some way? Or this feature can be used with any published branch, regardless of its format?
[12:20] <lifeless> the formats must match
[12:20] <lifeless> and bzr won't honour default-stacking requests with very old branches because that would potentially leave the trunk unable to merge from feature branches
[12:23] <gioele> lifeless: anyway, is it possible to use stacking with lp:bzr?
[12:24] <lifeless> yes, and bzr should do that by default
[12:25] <gioele> lifeless: that = stacking? if I do a bzr clone lp:bzr I end up with a stacked branch?
[12:25] <lifeless> no
[12:25] <lifeless> and doing that isn't very useful or sensible anyway
[12:25] <lifeless> (stacking your local copy on the network version
[12:25] <lifeless> )
[12:26] <lifeless> if you do a bzr push lp:~gioele/bzr/foo, it will stack on lp;bzr automatically
[12:27] <gioele> lifeless: but then the remote branch is stacked, not the branch on my PC, if I understood that correctly
[12:31] <lifeless> right, but its not useful to stack branches on your pc
[12:31] <lifeless> a stacked branch doesn't have enough data in it to even create a working tree
[12:32] <gioele> I see
[12:35] <gioele> thank you for the explaination
[13:39] <ddaa> Hello.
[13:40] <ddaa> I have a collaborator, who is using Windows to write to some files in a linux-based bzr tree over the network (presumably SMB)
[13:40] <ddaa> This appears to cause the executable bit to turn on on every file he edits from the network. Which is kind of annoying to me.
[13:41] <ddaa> Is there a way to edit files in a linux bzr tree from windows over SMB that will not cause those files to be recorded as executable when committing from linux.
[13:42] <ddaa> Note that I do not really care about whether the becomes executable on the linux filesystem. I just do not want bzr to record a permission change.
[13:48] <matkor> Hi ! what is easiest way to apply changes (uncommited) from given branch to current one ?
[13:49] <Lo-lan-do> bzr merge --uncommitted $given
[13:49] <ddaa> bialix: Can I make my collaborator use the bzr-x-bit plugin on linux to solve this problem?
[13:49] <bialix> ddaa: no
[13:49] <matkor> Lo-lan-do: Looks great, thank you very much !
[13:50] <Lo-lan-do> matkor: Then you'll probably do "cd $given ; bzr revert" or so
[13:50] <bialix> x-bit plugin does reverse thing
[13:50] <Lo-lan-do> (Be sure to only do that afterwards)
[13:50] <ddaa> bialix: doh, any idea?
[13:51] <bialix> SMB settings maybe? I'm not Linux expert
[13:51] <ddaa> I know, but you're the expert of all things windowish around.
[13:51] <bialix> IIUC this is always problem: try to open USB flash disk on Linux and all files have x-bit set
[13:52] <bialix> ddaa: IIUC your situation: your collaborator working directly with files over the network?
[13:52] <bialix> so why he does not have separate tree on his local disk?
[13:52] <bialix> e.g. lightweight checkout
[13:52] <ddaa> Yup. As I said, I do not care much what the filesystem says, I just do not want this nonsense to contaminate my carefuly tended bzr branch.
[13:52] <bialix> lightweight checkout will help you
[13:53] <ddaa> bialix: out of convenience, he's editing, over SMB, files that are used by a live web server on linux.
[13:53]  * bialix out of ideas
[13:54] <bialix> I'm usually working via ssh in those cases
[13:54] <ddaa> I do not want to worry about running the web server on windows, but I would like him to be able to retain the convenience of editing files on his big-screen windows system while he's testing IE compatibility.
[13:54]  * ddaa contemplates how all evil in computing those days can be ultimately traced to Internet Explorer.
[13:55] <bialix> and Bill G. of course!
[13:56] <ddaa> I do not like to take things personally. It's fine to hate pieces of technologies, but not people.
[13:56] <matkor> Lo-lan-do: Sure, I will even commit first on current :)
[13:56] <bialix> as you wish, I've tried to make joke
[13:57] <ddaa> bialix: sorry :) I'm just annoyed about how it became fashionable to hate B. Gates and Microsoft over the past few years.
[13:57] <ddaa> I mean, they actually invented a few good things.
[13:57] <ddaa> Like the scroll wheel.
[13:58] <ddaa> Thinking of it... Microsoft is actually pretty good at making mice, keyboards and joysticks...
[13:58] <LeoNerd> MS mice are quite nice, yeah..
[13:58] <LeoNerd> Probably because Logitec make them?
[13:59] <garyvdm> When Bug 1 gets fixed people will be replace those with Mark S. and Canonical :-P
[13:59] <ddaa> LeoNerd: that might have something to do with it :)
[13:59]  * garyvdm ducks and runs
[13:59] <ddaa> garyvdm: a few people already have.
[13:59] <garyvdm> Is ubottu asleep/
[13:59] <garyvdm> bug 00001
[14:00] <ddaa> Not ubottu, but most of the time this page times out.
[14:00] <ddaa> something to do with insanely large amount of comments, dups, subscribers and so on and so forth.
[14:00] <fbond> Hi.  In the old bzr shelve, I could `bzr shelf show FOO`, I think, to see a diff representing that particular change on the shelf.  Can I do that with the new shelve/unshelve commands?
[14:01] <fbond> `bzr unshelve --dry-run` shows me a stat-like representation of the change, but not a diff.
[14:01] <garyvdm> bug 391471
[14:01] <garyvdm> bug #391471
[14:02] <garyvdm> https://bugs.launchpad.net/ubuntu/+bug/1
[14:02] <fbond> garyvdm: That bug has a lot of comments.
[14:02] <garyvdm> lol
[14:03] <garyvdm> oops - I've now cause to to try 3 times...
[14:03] <garyvdm> *caused it
[14:11] <ddaa> Okay it turns out there should be two ways of fixing it.
[14:11] <ddaa> 1. setting the "create mask" in smb.conf to something like "644", so files are not create executable
[14:12] <ddaa> 2. configuring the windows-side editor to save files in place (instead of doing the copy-rename thing).
[15:07] <asabil> jelmer: ping ?
[15:18] <jelmer> asabil: pong
[15:18] <asabil> jelmer: did you receive my filter-branch merge request for bzr-rebase ?
[15:32] <jelmer> asabil: no, I didn't see anything
[15:32] <asabil> jelmer: I did send it a while ago, maybe I should resend it ?
[15:33] <jelmer> asabil: please do
[15:33] <Lo-lan-do> Are pack files often modified?
[15:34] <Lo-lan-do> Or are they only generated once by a commit or a repack and not changed afterwards?
[15:34] <Lo-lan-do> I'm pondering about risks of filesystem fragmentation.
[15:42] <jelmer> Lo-lan-do: pack files are not modified themselves, but new pack files will be created regularly
[15:42] <jelmer> (e.g. by commit, repack, push/pull etc)
[15:50] <Lo-lan-do> Okay, so little risk for fragmentation increasing over time.  Good, good.
[15:53] <mxpxpod> jelmer: ping?
[15:56] <jelmer> mxpxpod: pong
[16:00] <mxpxpod> jelmer: I'm trying to mirror dojotoolkit.org's svn repository using bzr-svn's svn-import, but we have a strange branching and tagging method
[16:01] <mxpxpod> basically, each project (dojo, dijit, dojox) has it's own sub-repository (src/dojox/{branches,tags,trunk})
[16:01] <mxpxpod> but then when we release, we create a structure in src/branches/{release_version} that copies current trunk of each project into that directory
[16:01] <mxpxpod> same with tagging with the tags directory
[16:03] <mxpxpod> jelmer: if you want to take a look, it's at http://svn.dojotoolkit.org/src
[16:04] <abentley> jam: In case you missed it earlier, the push to /home/abentley/branches is complete
[16:05] <mxpxpod> jelmer: src/trunk is our old code-base
[16:07] <mxpxpod> jelmer: the problem is that when I did the svn-import, I specified branches=branches/*;*/branches/*;*/trunk and tags=tags/*;*/tags/*, but no tags showed up
[16:07] <mxpxpod> jelmer: am I going to have to tag things manually?
[16:11] <jelmer> mxpxpod: sorry, phone, back in a few minutes
[16:16] <asabil> jelmer: just sent it, you should receive it on your samba mailbox
[16:18] <jam> abentley: thanks
[16:18] <jam> robert says you can lftp the broken branch
[16:18] <jam> which works well, too
[16:21] <abentley> jam: was the lftp message for me?
[16:22] <jam> yes
[16:22] <jam> not that *you* need to
[16:22] <jam> just that it is another branch I can use
[16:23] <abentley> jam: I don't understand.  by "broken branch", you mean db-devel?
[16:23] <jam> cinnamon-and-spice, IIRC
[16:23] <jam> abentley: sorry, crimson-and-clover
[16:24] <abentley> jam: Oh, you'd like a copy of lp:~sinzui/launchpad/crimson-and-clover ?
[16:32] <abentley> jam: I've mirrored crimson-and-clover for you at /home/abentley/crimson-and-clover
[16:34] <mxpxpod> is there a way to register a directory service and have it create a shared repo for multiple branches for certain urls?
[16:37] <asabil> jelmer: did you get it this time ?
[16:37] <jelmer> asabil: yep, thanks
[16:38] <asabil> cool
[16:41] <jelmer> mxpxpod: re
[16:42] <jelmer> mxpxpod: that should've worked
[16:42] <jelmer> mxpxpod: did svn-import say anything about the layout being used?
[16:43] <mxpxpod> jelmer: Using repository layout: WildcardLayout(['branches/*', '*/branches/*', '*/trunk'],['tags/*', '*/tags/*'])
[16:43]  * awilkins thinks bzr-svn should have a layout option for "total freakin' mess"
[16:43] <mxpxpod> awilkins: :)
[16:44] <mxpxpod> jelmer: I think the problem is that we have src/tags/release-1.3.1/dojo
[16:44] <kirkland> jelmer: hi there
[16:44] <mxpxpod> and dojo resides in src/dojo/{trunk,branches}
[16:44] <kirkland> jelmer: i'm still getting a vcs import update failure for qemu's git
[16:44] <kirkland> jelmer: i was under the impression that LP's rollout this morning had your latest fixes?
[16:45] <kirkland> jelmer: http://launchpadlibrarian.net/28287607/qemu-git-log.txt
[16:45] <kirkland> jelmer: https://code.edge.launchpad.net/~vcs-imports/qemu/git
[16:47] <jelmer> kirkland: I'm not sure what version of bzr-git launchpad is using
[16:48] <kirkland> jelmer: is there any way that I can run this script/process locally, on my hardware
[16:48] <kirkland> jelmer: and push to a bzr branch in LP?
[16:49] <kirkland> jelmer: i'm happy to cut vcs-imports out of the loop, until they get that fixed
[16:49] <kirkland> jelmer: i need a bzr/git mirror up ASAP
[16:50] <jelmer> kirkland: yeah, just install bzr-git and run something like this from a cronjob:
[16:51] <kirkland> jelmer: what's bzr-git?  a bzr pluggin?
[16:51] <Jc2k> yes
[16:51] <jelmer> kirkland: "bzr svn-import git://git.savannah.nongnu.org/qemu.git qemu; bzr push -d qemu lp:~kirkland/qemu/git-import"
[16:52] <jelmer> sorry, git-import rather than svn-import obviously
[16:52] <kirkland> jelmer: s/svn-import/git-import/
[16:52] <kirkland> k
[16:52] <kirkland> jelmer: thanks
[16:53] <jelmer> kirkland: alternatively if you just need the main branch you can just use "bzr branch" / "bzr pull" with git URLs
[16:54] <mxpxpod> jelmer: I'm figuring for this strange layout that we have that I'll have to do some sort of custom import for this repo
[16:54] <kirkland> jelmer: and getting git-import ....
[16:55] <kirkland> jelmer: cd .bazaar/plugins; bzr branch lp:bzr-git ?
[16:55] <jelmer> kirkland: yep
[16:55] <jelmer> kirkland: you'll also need dulwich, which is a dependency of bzr-git
[16:55] <jelmer> mxpxpod: there don't seem to be any actual tags for dojo that bzr-svn could import
[16:56] <jelmer> mxpxpod: http://svn.dojotoolkit.org/src/dojo/tags/ is empty
[16:56] <kirkland> Unable to load plugin 'git'. It requested API version (1, 17, 0) of module <module 'bzrlib' from '/usr/lib/python2.6/dist-packages/bzrlib/__init__.pyc'> but the minimum exported version is (1, 13, 0), and the maximum is (1, 13, 1)
[16:56] <mxpxpod> jelmer: yeah, we tag dojo, dijit, dojox, and util at src/tags/{release_name}/{project_name}
[16:57] <jelmer> kirkland: the version of bzr you have locally is too old, you need at least 1.14 for bzr-git
[16:59] <kirkland> jelmer: best way of getting a newer bzr onto a jaunty machine?  a ppa, perhaps?
[16:59] <jelmer> kirkland: yeah, there's a bzr ppa (~bzr on lp)
[16:59] <kirkland> jelmer: cheers, thanks for your help, dude
[16:59] <mxpxpod> kirkland: https://launchpad.net/~bzr/+archive/ppa
[16:59] <jelmer> mxpxpod: so in that case it seems your tags setting is incomplete
[17:00] <mxpxpod> jelmer: right, but how do I tell svn-import that the tag is at tags/release-1.3.1/dojo rather than dojo/tags/release-1.3.1 ?
[17:01] <mxpxpod> and then how do I get it to translate the former to the latter for the conversion?
[17:02] <jelmer> mxpxpod: try tags/*/dojo
[17:02] <mxpxpod> jelmer: what if I'm importing the whole repo at one time?
[17:05] <jelmer> mxpxpod: shouldn't be any different
[17:06] <mxpxpod> jelmer: so, just put tags/*/{project_name} for each project?
[17:06] <jelmer> mxpxpod: yeah, that's how it's intended to work at least
[17:07] <mxpxpod> jelmer: same with branches?
[17:07] <jelmer> mxpxpod: yeah
[17:09] <mxpxpod> jelmer: welp, here goes nothing ;)
[17:55] <marianom> hi guys, can anyone tell me why I'm hitting this error? bzr: ERROR: Reserved revision-id {null:}
[17:55] <marianom> First time I see it
[18:02] <mxpxpod> jelmer: that didn't work :(
[18:05] <mxpxpod> jelmer: I did this: bzr init-repo --1.14-rich-root test; cd test; bzr svn-import http://svn.dojotoolkit.org/src .
[18:20] <kirkland> jelmer: http://pastebin.ubuntu.com/203025/
[18:20] <kirkland> jelmer: dulwich is installed
[18:24] <kirkland> never mind
[18:28] <kirkland> bzr: ERROR: exceptions.ImportError: bzr-git: Dulwich is too old; at least 0.3.1 is required
[18:28] <kirkland> i installed dulwich from the ppa
[18:38] <jelmer> kirkland: I don't think there's a current dulwich packaged in the ppa
[18:38] <kirkland> jelmer: okay, thanks.
[18:40] <jh> hi, I'm trying to get to the newest revsion of a branch on launchpad. I had already a local copy of the repository and changed some things (and committed it locally). how can I change to the current remote revision? ignoring all my local changes
[18:41] <dash> you want to remove your local changes?
[18:41] <dash> or merge the remote ones into your local branch
[18:41] <jh> I want to ignore my local changes
[18:42] <dash> bzr pull --overwrite <remote url>
[18:42] <dash> if by 'ignore' you mean 'remove'
[18:42] <jh> y
[18:42] <jh> thx!
[18:44] <ddaa> There's something annoying about shelve storing a pack in the shelf instead of a diff.
[18:44] <dash> yes
[18:44] <ddaa> Previously, I could go into the shelf, and modify the shelved diff.
[18:44] <dash> also the shelve plugin has more features than the builtin
[18:45] <ddaa> In this instance, I want to split a diff hunk.
[18:45] <dash> me too
[18:45]  * ddaa shakes dash's hand
[18:45] <ddaa> dash: so what is it you do you to satisfy you obsessive-compulsive need for clean commits?
[18:45] <dash> (I am trying to split up a very large diff into multiple unrelated ones via loom+shelve)
[18:46] <dash> ddaa: Nothing easy.
[18:46] <ddaa> that kind of sucks
[18:46] <dash> yes
[18:46] <dash> i think i am going to switch back to shelve1
[18:46] <ddaa> you mentioned a different between a plugin and a builtin
[18:47] <dash> yes, the 'shelve' in bzrtools is different
[18:47] <ddaa> I did not realize shelve was now a builtin
[18:47] <dash> so yeah, try 'bzr shelve1'
[18:48] <ddaa> Yay, happiness.
[18:48] <ddaa> bzr shelve1, manual diff editing, bzr unshelve1
[18:49] <ddaa> dash: thanks pal
[18:49] <dash> <3
[20:26] <mwhudson> jelmer_: hello, https://code.edge.launchpad.net/~vcs-imports/mnemosyne-proj/maemosyne still seems to be failing with bzr 0.4.0, i can't remember if i asked you about this one already :)
[20:26] <mwhudson> bzr-git, obv
[21:37] <poolie> hello
[21:37]  * beuno waves at poolie 
[21:37] <poolie> good morning beuno
[21:38] <beuno> how are you poolie?
[21:40] <poolie> good thanks
[21:40] <poolie> woke up a bit too early though
[21:40] <poolie> how are you?
[21:41] <beuno> pretty good
[21:41] <beuno> slow day for me today
[21:42] <poolie> how is 2a dogfooding going for you?
[21:42] <poolie> i realize bug 390563 is a big deal
[21:53] <beuno> poolie, that's really making things chaotic
[21:53] <beuno> but, apart from that, things seem much faster
[21:54] <beuno> I've upgraded about 30 branches at the office to 2a
[21:54] <beuno> and it's gone well
[21:54] <beuno> no problemas at all
[21:54] <beuno> something to note is that at least half the branches didn't go down in size from 1.9
[21:56] <poolie> ok, interestig
[21:56] <poolie> how about if you repack them?
[21:56] <beuno> I do, all of them
[21:56] <beuno> initially the branches are larger
[21:56] <beuno> and then they go down to about the same size after a pack
[21:57] <beuno> they are branches with heavy binary usage
[22:32] <lifeless> oh wow
[22:32] <lifeless> did all codeimports die overnight?
[22:32] <lifeless> mwhudson: ^
[22:32] <mwhudson> lifeless: no
[22:32] <thumper> lifeless: no, we've just now automatically failing imports that have failed lots
[22:33] <mwhudson> oh yes, that's a lot of spam in my codeimport folder...
[22:35] <lifeless> vila: still around?
[22:38] <poolie> hello mwhudson, lifeless
[22:38] <mwhudson> hi poolie
[22:49] <lifeless> mwhudson: you're going to cherrypick bug 365615 today, yes?
[22:50] <mwhudson> yeah, we should
[22:50] <mwhudson> lifeless: it won't hit prod until uk versions of 'today' of course
[22:51] <mwhudson> lifeless: is there any sense in waiting for a fix to the other absentcontentfactory bug to maybe appear?
[22:51] <mwhudson> lifeless: also, is the fix for that bug in the 1.16 branch?
[22:52] <mwhudson> seems no
[22:52] <mwhudson> i guess i should talk to the 1.16 release manager
[22:53] <mwhudson> who should be waking up around about now...
[22:56] <lifeless> mwhudson: its not in the 1.16 branch yet
[22:56] <lifeless> mwhudson: just cherry pick
[22:56] <lifeless> and no, no sense waiting
[22:59] <poolie> lifeless: did you talk to jam today (au time)?
[22:59] <poolie> i was just going to call him and say hello
[23:00] <lifeless> poolie: no; I'd like to to pickup the state on the bug
[23:00] <lifeless> he commented about 7 hours ago on the bug, but hasn't mailed a status note, nor has vila
[23:00] <lifeless> so AFAICT it hasn't advanced any
[23:01] <lifeless> which may just mean that a lot of work hasn't ruled anything out nor proven anything
[23:03] <lifeless> poolie: I'll be on m mobile; just grabbing a hot brekkie
[23:12] <poolie> lifeless: john's sending an update now
[23:17] <FibeRichio> Hi, I wanted to exclude a directory called 'webstats' from the revision, so I did 'bzr ignore ./webstats'. It told me that there already existed a directory in the revision and that I should use the remove command, but after I did 'bzr remove webstats', the entire directory dissappeared from my filesystem?
[23:20] <lifeless> back
[23:20] <lifeless> poolie: thanks
[23:21] <lifeless> FibeRichio: right, it did that because it was versioned
[23:21] <lifeless> FibeRichio: do this:
[23:21] <lifeless> bzr revert webstats
[23:21] <lifeless> bzr remove --keep webstats
[23:21] <FibeRichio> thanks, that looks bettter :)
[23:25] <lifeless> np
[23:28] <rocky> jelmer_: hey, does deleting tags not work with bzr-svn ?
[23:47] <poolie> jam, lifeless,  i filed bug 391851
[23:47] <poolie> jml that's what you mentioned last night
[23:47] <lifeless> oh that reminds me
[23:47] <poolie> i don't think there was a bug for it previously
[23:47] <lifeless> I'll file one on skinny networkin
[23:47] <lifeless> g
[23:47] <poolie> ok, refer back to this one
[23:47] <poolie> i mean put in a see also
[23:48] <lifeless> Actually
[23:48] <lifeless> I think yours really should just be turned into 'skinny on the network please'
[23:48] <lifeless> as the other aspects were all considered and balanced during design.
[23:49] <lifeless> single commit having a full text isn't a drawback, as it makes commit fast; and group size is dynamically tuned based on file size
[23:49] <lifeless> poolie: ok if I repurpose it? or should I close it and file a targeted one for networking?
[23:51] <poolie> either is ok
[23:52] <poolie> i'd like the other one perhaps open at least at low priority
[23:52] <poolie> so it has a handle
[23:53] <lifeless> poolie: I'm not clear what it is meant to be though - I don't see anything in 391851 as a bug or defect, other than networking not being skinny
[23:55] <lifeless> poolie: quick call?