[00:15] <lifeless> thewrath: did you install bzr using cygwin's setup.exe?
[00:15] <jml> lifeless, yesterday, you suggested that there were bugs for 1.16.1 other than bug 365615 and bug 390563
[00:15] <jml> lifeless, can you please point me to them?
[00:15] <lifeless> jml: did I? I thought I said I was flat out :P
[00:15] <lifeless> jml: and I recall talking about 2.0 in terms of what bugs there were
[00:16] <lifeless> anyhow, I'm not aware of other 1.16 worthy cherrypicks
[00:16] <lifeless> once abentley's skip-dupes patch lands in trunk that might be worth putting in 1.16 too; though I thought lp devs ran off nightlies
[00:19] <jml> lifeless, we do run off nightlies.
[00:20] <lifeless> in which case there are no other patches for 1.16 that I know of
[00:20] <jml> ok.
[00:20] <jml> what about things to cherrypick to Launchpad?
[00:21] <lifeless> mwhudson has them in hand
[00:21] <jml> sweet.
[00:21] <jml> thanks.
[00:32] <igc> morning
[00:33] <lifeless> hai
[00:33] <igc> hi lifeless
[00:49] <poolie> jml, re your "branches that fix bugs"
[00:49] <poolie> there are some more cases like that in devnotes 3.0-ui document
[00:49] <poolie> http://doc.bazaar-vcs.org/devnotes/bzr-2009-ui-refresh.html
[00:50] <jml> poolie, ahh thanks.
[00:50] <jml> poolie, I'd been meaning to refresh myself on the devnotes branch but let it slip my mind.
[00:51] <poolie> np
[00:51] <poolie> i don't necessarily want that document to become a laundry list of every possible thing you could want to do with bzr
[00:51] <poolie> but these are at least a bit related
[00:51] <poolie> also airing them on the list may atract more thoughts
[00:53] <jml> well this has a specific focus I guess
[01:15] <poolie> jml, could you send a short metronome mail re 1.17?
[01:17] <jml> poolie: yep, it's already on my list for today
[01:17] <poolie> oh cool
[01:17] <poolie> maybe i should send one about 1.17 vs 2.0
[01:18] <jml> that's probably a good idea
[01:21] <jml> my list for today is perhaps slightly too long, but I know only one way of making it shorter.
[01:24] <jml> poolie: I'm also going to cut 1.16.1 today, if I can.
[01:24] <poolie> delete things? or do things?
[01:24] <poolie> i was planning to do both :)
[01:24] <jml> do things.
[01:32] <lifeless> igc: I'm working on iter-changes today
[01:32] <lifeless> igc: now that the crisis with fetch is fixed
[01:32] <igc> lifeless: cool
[01:32] <lifeless> igc: I'd appreciate your holding off your other landing ;)
[01:33] <igc> lifeless: I'm doing reviews and clearing the desks to work on bug 374735
[01:33] <igc> sure
[01:34] <poolie> hello igc, lifeless
[01:34] <lifeless> hi poolie
[01:34] <poolie> i'm planning today to: send a coscup abstract, (re)send a blog acct to igc, write up a patch explaining the 2a format, do the minimal activity-tied-to-pb fix, order a new disk
[01:34] <igc> hi poolie
[01:35] <poolie> talk to spiv
[01:35] <poolie> and hopefully get other uifactory fixes done
[01:35] <poolie> they have a tangle-of-string quality - fixing each test makes for larger changes
[01:36] <poolie> all good, but it's not converging
[01:36] <poolie> so sometimes i take a step back and try something smaller
[01:36] <poolie> but still
[01:48] <poolie> thanks for the review igc
[01:54] <jml> another unusual error from our systems: https://devpad.canonical.com/~matsubara/oops.cgi/2009-06-25/SMPM01
[01:55] <jml> http://paste.ubuntu.com/203878/
[01:55] <lifeless> it would be nice if that was openid
[01:55] <jml> when mirroring http://bzr.malept.com/avant-window-navigator
[01:55] <jml> yes.
[01:55] <lifeless> didn't you file a bug on that 3 weeks ago?
[01:56] <jml> I don't think so.
[01:56] <lifeless> https://bugs.edge.launchpad.net/bzr/+bug/377453 ?
[01:57] <jml> oh good.
[01:57] <lifeless> hmm, different but similar
[01:57] <lifeless> add it to the same one I think
[01:59] <jml> done.
[02:00] <lifeless> so, iter_changes tests existing now
[02:00] <lifeless> time to fix implementations
[02:13] <lifeless> can anyone confirm: setup.py build_ext -i is putting the so files in bzrlib/bzrlib/ ?
[02:14]  * fullermd hasn't seen it...
[02:16]  * igc school visit & lunch - bbl
[02:17] <lifeless> bug 392355
[02:17] <mwhudson> lifeless: no
[02:17] <lifeless> mwhudson: python version? bzrlib version?
[02:17] <lifeless> mwhudson: are you on karmic?
[02:17] <mwhudson> lifeless: no
[02:17] <mwhudson> python2.6 jaunty 4477
[02:17] <lifeless> jml: you're on karmic aren't you... could you check for this (in 1.16 and-or bzr.dev)
[02:18] <mwhudson> 4479 sorry
[02:18] <fullermd> I just did a fresh branch of lp:bzr and they're all in bzrlib/ where they belong.
[02:19] <lifeless> fullermd: when you run setup.py build_ext -i ?
[02:19] <fullermd> Yah.
[02:19] <fullermd> Well, ./setup.py [...]
[02:19] <lifeless> fullermd: so bzrlib/*.so, not bzrlib/bzrlib/*.so
[02:19] <fullermd> Right.
[02:19] <lifeless> ok
[02:19] <lifeless> thats good data
[02:19] <lifeless> It could well be setuptools
[02:19] <fullermd> (py 2.6)
[02:19] <lifeless> sorry distutils or something
[02:20] <thewrath> (9:17:33 PM) thewrath: hey guys with bzr or svn any way to find the number of modified lines
[02:20] <thewrath> (9:17:50 PM) thewrath:  svn diff | grep "^+" | grep -v "^+++" | wc -l  gives you added lines
[02:20] <thewrath> (9:18:00 PM) thewrath:  svn diff | grep "^-" | grep -v "^---" | wc -l is removed
[02:20] <thewrath> (9:18:13 PM) thewrath: but i need modified lines and unmodified lines
[02:20] <lifeless> what are you trying to calculate
[02:21] <jml> lifeless, the bug refers to 'make build' -- I don't even have a build target in my copy of bzr.
[02:21] <lifeless> jml: I fabricated. just 'make', or setup.py directly
[02:22] <thewrath> i need to find the total number of added, removed, modified and unmodified lines from revision a to revision b
[02:22] <lifeless> the first three are easy
[02:22] <lifeless> the last one is much harder
[02:22] <fullermd> 'modified' can be pretty tough to quantify...
[02:22] <lifeless> I'm not aware of any simple way to do it
[02:22] <thewrath> lifeless: how u calculate the modififed
[02:23] <lifeless> thewrath: I'd use some of the existing python libraries to parse the diff and turn added and removed into modifications when they are adjacent
[02:23] <lifeless> thewrath: be a couple of hours work top, at most.
[02:23] <lifeless> thewrath: anyway, why do you want this?
[02:23] <poolie> igc, re the revert patch
[02:23] <thewrath> lifeless: its for work
[02:23] <poolie> can you try to add a blackbox test?
[02:24] <fullermd> I actually thought diff(1) had an arg to show the whole files, which would help with the last, but it doesn't seem to.
[02:24] <poolie> there's a slim nonzero chance it'll break
[02:24] <fullermd> You could fake it by asking for 99999 lines of context, I guess.  Would work on all those sub-100kLOC files.
[02:25] <jml> lifeless, https://bugs.edge.launchpad.net/bzr/+bug/392355/comments/1
[02:25] <lifeless> fullermd: we don'tsupport that argument, I don't think
[02:25] <fullermd> Well, but we could use the external diff, instead of the internal one.
[02:25] <lifeless> jml: so its broken for you too
[02:26] <jml> yep.
[02:26] <thewrath> lifeless: can i sent you a pm
[02:26] <lifeless> thewrath: I guess
[03:02] <jml> lifeless, does this critical bug mean I should use a chroot to rollout 1.16.1?
[03:02] <jml> I guess I could always experiment.
[03:03] <lifeless> jml: the so's don't go in the tarball
[03:03] <lifeless> jml: so no special actions required there
[03:03] <lifeless> however johnf probably needs to know to build debs properly
[03:04] <jml> and all the C files go to the correct place, I see.
[03:24] <lifeless> just popping out to the chemist
[03:24] <lifeless> brb
[03:45]  * spiv pops out for food
[04:18] <lifeless> deep hack time
[04:19] <lifeless> SMS or ring if you need me
[04:30] <poolie> lifeless: (realize you're away) fix for progress bar droppings pushed
[04:31] <poolie> yay hacks
[04:47] <lifeless> poolie: yay
[04:47] <lifeless> poolie: do you need a review?
[04:47] <poolie> yes
[04:47] <poolie> is easy
[04:48] <poolie> i also need a lunch
[04:48] <lifeless> is it 'if count < 1: return' ? or something like that?
[04:48] <poolie> close
[05:22]  * jml sends a metronome email
[05:25] <fullermd> Oh, good, the RC is on my mother's birthday.  Now I'll remember to call her.  Just don't slip the date!
[05:31] <lifeless> igc: may have found other latent commit bugs with this work :)
[05:33] <igc> lifeless: I recall raising one or two when I was last looking in there
[05:44] <poolie> thanks lifeless
[05:51] <jml> ok. time to cut 1.16.1.
[05:51] <jml> it's going to look a _lot_ like the current launchpad branch of bzr :)
[05:59] <glyph> jml: yay releases!
[06:04] <jml> lousy internet :(
[06:04] <jml> glyph, Twisted should do time-based releases!
[06:05] <glyph> jml: you know what else
[06:05] <glyph> jml: Twisted should have a release manager
[06:06] <glyph> jml: and a hundred billion dollars.
[06:06] <jml> glyph, and a pony
[06:07] <jml> maybe I'll steal the RM job from radix
[06:07] <jml> if only I were less of a bum.
[06:10] <glyph> jml: well, relatively speaking
[06:11] <jml> :)
[06:12] <jml> has skip-dupes landed in bzr.dev?
[06:13] <jml> hmm. computer says no.
[06:13] <jml> there's no bug associated with it either
[06:13] <lifeless> its not needed for 1.16.1 anyhow
[06:13] <lifeless> because 2a is not popular, and you're landing a separate fix that means skip-dupes isn't needed anyway.
[06:14] <lifeless> (needed in terms of 1.16.1 as a server, or locally)
[06:14] <jml> ok.
[06:18] <jml> still love merge --uncommitted.
[06:24] <jml> when doing a point release...
[06:24] <lifeless> ?
[06:24] <jml> should I change the introductory paragraphs?
[06:24] <fullermd> I make use of it in nasty and evil ways on many occasions.
[06:24] <jml> in the NEWS file, that is.
[06:24] <lifeless> the whichwhat?
[06:24] <lifeless> its a new release
[06:24] <lifeless> it should get its own intro
[06:25] <jml> OK. That's not how 1.14 & 1.15 were done, but it is how 1.13 was done.
[06:31] <jml> can someone please look over the release announcement?
[06:31] <jml> http://paste.ubuntu.com/203968/
[06:34] <jml> poolie, lifeless: ^
[06:42] <lifeless> new codename needed I think
[06:42] <lifeless> and the top line should say 1.16.1
[06:42] <lifeless> this is a new release; 1.16 is the series
[06:43] <lifeless> personally, I don't htink you should be moving the bug block
[06:43] <lifeless> big block*
[06:43] <lifeless> that was the 1.16 release
[07:02]  * jml tries to find prior art to copy from
[07:02] <lifeless> use case for you
[07:02] <lifeless> 'I am a debian user and I have 1.16 already'
[07:02] <lifeless> they should see the new changes they are getting.
[07:14] <vila> hi all
[07:14] <lifeless> hai
[07:14]  * vila stares at the restart button (triggered by the ssl update) :-/ What the hell these days !
[07:15] <vila> back in a restart
[07:19] <vila> re-hi
[07:28] <vila> poolie: ping
[07:39] <jml> I'm off. Back later to finish the bzr 1.16.1 release.
[07:43] <vila> jml: excellent metronome mail !
[07:43] <jml> vila, thanks.
[07:46] <vila> lifeless: still around for a quick chat ?
[07:47] <lifeless> vila: sure
[07:47] <lifeless> whats up?
[07:47] <lifeless> jml: when you return, testresoureces has branches that need your personal touch
[08:23] <igc> night all
[08:24] <poolie> hello vila!
[08:24] <poolie> jml, yes, really nice mail there
[08:25] <poolie> i mean the metronome one
[08:25] <poolie> jml, if you're still here, the release mail draft confuses me
[08:26] <poolie> it almost looks you you're marking all of the trunk changes as being in 1.16, which would either be inaccurate or a mistake
[08:37] <Adys> I got a centralized repo to which I was the only committer. someone has an --unchanged commit on it since a few hours. I try to push my work but I keep getting "branches have diverged"
[08:37] <Adys> bzr merge tells "nothing to do". bzr pull tells "no revisions to pull". bzr up tells "Tree is up to date"
[08:37] <Adys> what am I supposed to do?
[08:38] <vila> Adys: You can either 'push --overwrite' or 'merge; commit; push'
[08:38] <Adys> merge doesnt work =/
[08:38] <Adys> I dont know if its a bug
[08:39] <Adys> ill try push --overwrite
[08:39] <vila> Adys: wait
[08:39] <Adys> Ok
[08:40] <vila> 'push --overwrite' will ignore the --unchanged commit and make it hard to get back to, while 'merge; commit;push' will take into account
[08:40] <vila> Adys: what do you want to do ?
[08:40] <Adys> vila, merge doesnt work
[08:40] <Adys> it tells "nothing to do"
[08:41] <vila> Adys: It works then, doing nothing is sometimes the Right Thing :)
[08:42] <Adys> hm
[08:42] <Adys> hold on i screwed something up ...
[08:42] <vila> Adys: What does 'bzr info' says ? Are you working with a standalone branch, a checkout ?
[08:42] <Adys> standalone
[08:42] <Adys> uh, is there some way to undo a pull? =P
[08:43] <vila> Adys: 'pull --overwrite'
[08:43] <Adys> Yeah I just did that, it had an old location saved
[08:44] <Adys> think I lost some code.. not a big deal
[08:45] <vila> Adys: committed or not ?
[08:45] <Adys> yes
[08:45] <Adys> committed but not pushed
[08:45] <vila> then it's not lost
[08:46] <Adys> How do I get it back?
[08:46] <vila> you have to find the revid you're interested in and pull it somewhere safe first (aka, not in your current branch)
[08:47] <Adys> okay
[08:49] <Adys> vila: I need to grab rev 525, but when I branch it it updates to rev 524
[08:49] <vila> use 'bzr heads --all' and see if you can find it back
[08:51] <Adys> found it, what do I do now?
[08:51] <Adys> HEAD: revision-id: adys@azura-20090626072855-ze3ykij2nuraihhe (dead)
[08:55] <vila> Adys: bzr branch <orig> -rrevid:adys@azura-20090626072855-ze3ykij2nuraihhe <recover>
[08:56] <vila> Adys: replace <orig> and <recover> by valid and appropriate values
[08:56] <Adys> Ah great stuff, thanks. :)
[08:58] <jml> hello hello
[08:59] <jml> poolie, had a chance to sanity check?
[08:59] <Adys> vila: got it all sorted, thanks a lot!
[08:59] <vila> Adys: Always happy to help (TM)
[08:59] <Adys> ™
[08:59] <jml> gasp
[08:59] <jml> unicode
[08:59] <Adys> gasp, customized keyboard layouts :D
[09:04] <jml> bazaar-vcs.org appears to be down :(
[09:04] <poolie> jml, i don't think it is present...
[09:04] <poolie> still checking
[09:04] <poolie> jml, srsl?
[09:04] <poolie> srsly*
[09:05] <jml> poolie, yes, srsly.
[09:06] <Peng_> Indeed. Cool! Can't connect.
[09:07] <jml> fixed
[09:07] <jml> (thanks elmo)
[09:08] <Peng_> That was quick. What was wrong?
[09:08] <jml> buggered if I know :)
[09:09] <poolie> jml, it certainly looks like it's not in there
[09:09] <poolie> i wonder how the text got into news?
[09:09] <poolie> jml i guess launchpad got fixed?
[09:09] <jml> which bit of launchpad?
[09:10] <elmo> apache upgrade didn't restart cleanly; sorry about that
[09:10] <elmo> peng: ^--
[09:10] <Peng_> Oh.
[09:11] <poolie> jml, the appserver outage?
[09:11] <jml> poolie, yes. that got fixed
[09:14] <jml> poolie, what's the number of the bug that appears in NEWS that isn't fixed?
[09:15] <poolie> bug 376478
[09:15] <poolie> you cherrypicked trunk r4470
[09:15] <poolie> which claims to fix that
[09:15] <poolie> ah
[09:15] <jml> https://bugs.edge.launchpad.net/bzr/+bug/376748
[09:15] <poolie> it might just be lack of cherrypick tracking...
[09:16] <poolie> normally people tend to merge the bugfix branch into the release branch rather than cherrypicking
[09:16] <poolie> but it's a reasonable enough thing to do
[09:18] <soren> Can I fake the timestamp on a bzr commit?
[09:18] <jml> yes.
[09:18] <soren> (without changing my system clock)
[09:18] <poolie> of course in this case you couldn't because it was based off too late a version of trunk
[09:18] <poolie> soren, yes
[09:18] <soren> Cool. How?
[09:19] <jml> Python!
[09:19] <jml> (looking up the api)
[09:19] <soren> I was afraid you'd say that.
[09:19] <soren> Oh, well.
[09:22] <soren> Hm... Doesn't look to hard at all.
[09:22] <soren> (famous last words)
[09:24] <jml> soren, yeah... I think I'd just hack something up based on cmd_commit().
[09:24] <jml> possibly even add an option to cmd_commit for the timestamp.
[09:26] <jml> poolie, so where were we?
[09:26] <poolie> i'd be ok with an option to cmd_commit
[09:27] <poolie> jml, it's in, and it seems like a reasonable thing to put in
[09:27] <poolie> so i think we're good to go
[09:28] <jml> rock'n'roll.
[09:29] <poolie> spiv, still around? how did you go today?
[09:37] <Wyvern> I have a question: I do bzr status and I get a lot of modified files, even though they haven't been touched. But they have an * at the end. What does that mean?
[09:38] <bialix> help form bzr hackers needed
[09:38] <bialix> see http://pastebin.com/m40991c66
[09:38] <bialix> why I've got error?
[09:39] <soren> jml: Oh. I was thinking of just calling bzrlib.commit.Commit.commit() from python with the right arguments. This is (hopefully) just a one-off thing.
[09:40] <soren> jml: Oh, that is what you're suggesting as well.
[09:40] <jml> soren, basically, yes.
[09:40]  * soren has not had sufficient coffee today.
[09:41] <jml> soren, although tweaking the commit command is probably even less work, as long as you don't bother with user-friendly parsing & data validation.
[09:41] <jml> which you won't, because it's a one off thing :)
[09:41] <soren> True, true :)
[09:45] <Peng_> Wyvern: The executable bit probably changed.
[09:47] <Wyvern> Indeed! Thanks.
[10:05] <Peng_> jam: FYI, mail2.domainpeople.com yelled at me when I tried to send an email to you. (Nothing important, I just used Reply All on a mailing list post.)
[10:06] <jelmer> is CommitBuilder.record_entry_contents() going to be removed before 2.0 ?
[10:19] <jml> *mutter mutter*
[10:20] <jml> conflicts are teh suck
[11:07] <soren> How do I specify a base revision during a merge?
[11:08] <soren> I'm trying to merge two trees that have no common ancestry (bzr-wise, but in the real world, they do), and "bzr merge" suggests that I can somehow do it anyway if I specify a base revision for the merge, but I don't see how to do that.
[11:11] <spiv> soren: "bzr merge -r0..-1" will allow you to merge unrelated (bzr-wise) trees
[11:12] <spiv> soren: because 0 is common to histories, in a sense.
[11:13] <soren> Yeah, I was hoping that would be the case (0 being everyone's grandparent).
[11:13] <soren> haha..
[11:13] <soren> spiv: YEs, that seems to do the trick. Lovely. Thanks!
[14:44] <awilkins> abentley:
[14:44] <abentley> awilkins:
[14:44] <awilkins> abentley: How easy would "parallel" support be in bzr-pipeline?
[14:45] <abentley> awilkins: Not terribly hard, but if the parallels ever met, that would cause criss-cross merges.
[14:47] <awilkins> abentley: I posted to the list about supporting something similar in loom ; the idea of having a web of patch branches that all converge on a single "work" branch, with UI assistance for committing the correct hunks to the appropriate branch
[14:47] <awilkins> Like Mercurial pbranches (only they don't have that UI support)
[14:47] <abentley> awilkins: If by converge, you mean A -> B -> C, A ->D -> C, that would be very, very bad.
[14:48] <awilkins> abentley: Because each branch would be receiving the same merges from the base branch?
[14:50] <abentley> awilkins: Well, let me think about this.
[14:50] <awilkins> For reference : http://arrenbrecht.ch/mercurial/pbranch/
[14:51] <abentley> awilkins: You get criss-cross when you merge in an inconsistent order, and thereby repeat the merge of revision X with revision Y in two places.
[14:51] <abentley> awilkins: It may be that a pipeline can prevent that, but I'd have to think about it.
[14:54] <awilkins> abentley: I have this mental picture of a commit dialog in qbzr where the patch is on the left and there is a radiobutton column on the right for each patch branch and you select which hunk goes where.
[14:55] <abentley> awilkins: I've never been a fan of selective commit, but I can envision adding it to the uncommitted changes of that pipe.
[14:56] <awilkins> abentley: Does each pipe have a working tree?
[14:56] <abentley> awilkins: No, each pipe has a shelf.
[14:57] <awilkins> abentley: That sounds like the implementation I had in mind ; shelve the changes and switch-unshelve-commit for each branch
[14:58] <awilkins> abentley: I just don't have the time to actually write it though
[14:58] <abentley> awilkins: I'm suggesting that the user would still commit the changes, rather than having it happen automagically.
[15:01] <awilkins> abentley: I can see that working as long as you're not allowed to commit to a branch that depends on branches with shelved changes
[15:02] <abentley> awilkins: I think that restriction would not be workable.
[15:03] <awilkins> abentley: How do you cope with the scenario when you want to commit C, and B has changes in it's shelf ; the changes are presumably in the working tree of C also, and you've just committed them?
[15:03] <kfogel> abentley: how can I tell if a given installation of bzr is built with the C extensions?
[15:03] <awilkins> kfogel: Presence of .pyd files
[15:04] <abentley> awilkins: It would be unusual for the changes to be in the working tree of C also.
[15:04] <kfogel> awilkins: thank you.  where would they be?   (some python path on my system?)
[15:04] <awilkins> abentley: I thought A -> B -> C ... doesn't that imply that the changes from B are in C and C may even be dependant on them
[15:05] <awilkins> kfogel: They should be in the bzrlib folder
[15:05] <kfogel> awilkins: thanks
[15:05] <awilkins> kfogel: "lib" on Win32 bzr.exe, %PYTHON%/lib/site-packages/bzrlib for win32/python
[15:05] <abentley> awilkins: No, it doesn't imply that.  When you want that to be true, you run the "pump" command.  That merges from A->B->C, but it doesn't do anything with uncommitted changes.
[15:06] <awilkins> abentley: I'll have a play with bzr-pipeline for a bit and think some more
[15:06] <awilkins> abentley: It sounds like I'm not totally grokking the way it work
[15:08] <awilkins> abentley: Is there a good source of documentation besides the help? I've only found the launchpad page (after seeing it mentioned o the mailing list)
[15:08] <abentley> awilkins: The way it works is, you're hacking on something in A, then you realize you need to fix B.  You switch-pipe B, which automatically stores the uncommitted changes in A.  You fix B and commit.  You switch-pipe back to A, which restores your changes.  You finish hacking in A.  You pump, which applies the changes in A to B, and the changes in B to C.
[15:10] <abentley> awilkins: "bzr help pipelines" is the main documentation.  There's also a comparison with looms in pipeline-and-loom.txt in the source tree.
[15:10] <kfogel> awilkins or abentley: if I have done a long-running 'bzr upgrade --2a' to get a tree to 2a format, and I *think* it completed (but for various reasons am not sure), is there some command I can run to verify, other than 'bzr info -v' ?
[15:10] <awilkins> abentley: That help topic doesn't seem to be in the lp:bzr-pipeline trunk
[15:10] <abentley> awilkins: Sorry, "bzr help pipeline"
[15:11] <awilkins> kfogel: On the same topic, I've been running --2a conversions and getting segfaults on windows where it just fails silently, so I'm no help here
[15:11] <kfogel> awilkins: ugh.  no useful trace?
[15:11] <jam> Peng: I believe my mail host no longer allows direct emails from people, you have to go through official ISPs
[15:11] <abentley> kfogel: bzr info -v won't tell you whether it's well-formed.  You would need to run "bzr check" for that.  (Which takes a verry long time)
[15:12] <awilkins> kfogel: Just a minidump and an offset in the groupcompress extension
[15:12] <kfogel> abentley: 'bzr check' time comparable to the original 'bzr upgrade' time?
[15:12] <awilkins> kfogel: I'd make a trivial branch and upgrade it to 2a to see what the successful log output looks like
[15:12] <kfogel> (because that was almost 4 days)
[15:12] <abentley> kfogel: worse.
[15:12] <kfogel> abentley: holy cow
[15:14] <awilkins> abentley: Ok, it still sounds compatible with my intentions as long as the criss-cross merge is dealt with
[15:15] <awilkins> abentley: Because you would actually be working in C, you know how the merged output should look because it's what you actually wrote, so does that make it easier?
[15:16] <abentley> awilkins: I don't know what you mean by "you would actually be working in C".
[15:16] <awilkins> abentley: You have pipes   A > B | D > C
[15:17] <awilkins> So when you pump, changes in A are merged to B and D and then C
[15:17] <awilkins> So you end up with two merge revisions being merged to C and they are a crisscross merge
[15:18] <awilkins> If you are editing in C and your "chunk selective commit" has directed some changes to go to A, some to B and D (and none to C because it's just a convenient tip to amalgamate patches)
[15:18] <abentley> A > B, D > C does not lead to a criss-cross merge.
[15:18] <abentley> awilkins: Why would changes from B be merged into D?
[15:19] <awilkins> abentley: Not from B to D
[15:19] <abentley> That would be a linear pipeline of A > B > D > C
[15:19] <awilkins> A to B and D
[15:19] <awilkins> B to C, D, to C
[15:19] <abentley> awilkins: So you really men A > B,  A > D > C?
[15:20] <awilkins> abentley: And B > C also
[15:20] <awilkins> Including an additional revision of changes to B and/or D
[15:21] <abentley> awilkins: As long as the parallel lines don't merge from one another, I'm not sure that leads to a criss-cross.  But I still need to think about that.
[15:22] <abentley> awilkins: In any case, if you pump from A, you're not necessarily "working in C".  That would only happy if conflicts were encountered merging into C.
[15:23] <awilkins> abentley: I'm thinking ; edit with the lightweight checkout aimed at "C" ; commit chunks to A, pump
[15:24] <awilkins> abentley: Because you're editing in a checkout of C, you know how the end state of the tree should look, so you either don't have conflicts or you know exactly how to resolve them before you start the merge
[15:24] <awilkins> I'm not sure you don;t have conflicts 100% of the time
[15:24] <abentley> awilkins: If you're in C and you pump, that will do nothing, because you pump from the current pipe to the following pipes.
[15:24] <abentley> awilkins: If you're in C, you can't commit chunks to A.
[15:25] <awilkins> abentley: Edit in C : special-multi-pipe-commit to A (shelve ; switch A ; commit ; pump)
[15:25] <abentley> awilkins: You're now in A.
[15:25] <abentley> Not working in C.
[15:26] <awilkins> abentley: Automating this is what I'm driving at ; all the dancing up and down pipes handled in software
[15:27] <awilkins> So after, switich to C (which got your changes merged upward by the pump)
[15:28] <awilkins> So the intent is "I always want to work in a tree that looks like it would with all my patches applied, but I want to be able to commit to each of my patches separately"
[15:28] <abentley> awilkins: I'm not in favour of committing changes to A without even having looked at A with those changes.
[15:28] <awilkins> I agree that there is potential hairiness there
[15:30] <awilkins> I think the add-to-shelf approach has merits too
[15:30] <awilkins> It makes things a little less quick, but I agree it adds safety
[15:32] <awilkins> My concern with it was that if you have a bunch of changes hanging around in a shelf, they are not committed in the branch you intend them for, they are in it's shelf. You may commit the changes to descendants of that branch ; not entirely a disaster because if you merge them from beneath later they are just a no-action merge.
[15:33] <abentley> awilkins: I don't think it's likely that you would commit the changes to descendants of that branch.
[15:34] <awilkins> abentley: Have you removed them from the tree when you shelved them to that branch?
[15:34] <abentley> awilkins: yes.
[15:34] <dash> hmm, i have not heard of bzr-pipeline before. is it a thing like loom?
[15:34] <awilkins> abentley: So now your work cannot continue until you visit A and commit/pump yes?
[15:35] <abentley> awilkins: Your work would only be unable to continue if all the changes you wanted to make depended on the shelved changes.
[15:35] <abentley> dash: yes.
[15:36] <dash> i've been using loom a lot this week
[15:36] <dash> i've been wondering if something better was possible. :)
[15:37] <awilkins> dash: Looks like you walked into the right discussion ; I'm likeing pipeline so far in that I have the impression that it implements the features of looms by manipulating standard branches (?)
[15:38] <abentley> dash: As a contributor to loom and heavy user, I think something better is possible, and pipeline is my attempt to achieve it.
[15:39] <abentley> awilkins: It does manipulate standard branches.  The feature parity is not exact, and that's deliberate.
[15:39] <lifeless> pipeline is interesting; If I read the code right it has strong parallels to topgit
[15:40]  * awilkins adds another mental bookmark to review
[15:40] <lifeless> dash: have you been liking loom?
[15:40] <dash> lifeless: Mostly.
[15:41] <awilkins> lifeless: I've shied away from using it because of the stacked branches design
[15:41] <dash> My use case lately has been dealing with code at work where a snapshot of a public SVN repository was taken, checked into a company-internal SVN repo, and both were modified independently for about three months
[15:41] <dash> and now I am trying to reconcile the changes
[15:41] <lifeless> awilkins: sit in top tree, commit to arbitrary 'patch' - thats a goal I have too, for both generic bzr and looms; but requries care because it is conceptually bad (committing untested code). Howver some folk really do want it
[15:42] <dash> and, in particular, stratify them into independent patches
[15:42] <awilkins> My use case is a software project in an SVN repo which I sync periodically
[15:42] <awilkins> I tidy the code and document it and also write patches
[15:42] <lifeless> dash: I find shelve very useful there
[15:42] <dash> lifeless: yes. using shelve a lot too.
[15:42] <lifeless> dash: commit -i and a split-commit command would be nice
[15:42] <dash> yeah
[15:42] <awilkins> But I don't want things to be dependant on each other (in terms of DAG)
[15:43] <lifeless> anyhoo, its past midnight
[15:43] <dash> shelve is a little awkward when dealing with 200+ diff hunks :)
[15:43] <lifeless> -> sleep
[15:43] <dash> I find myself alternating between diff-based and pack-based shelve
[15:45] <awilkins> "conceptually bad (committing untested code)" ; I don't think committing untested code is bad, as long as it's plain you're not committing to a branch that will be shipped untested ; AFAIK the Bazaar development process handles this by testing merged revisions before it commits them and that's the place to be
[15:45] <awilkins> EAch time I try pack-based shelve on win32 it's failed so far
[15:46] <awilkins> The merges I've submitted to Bazaar have included revisions that definitely didn't pass testing because I separated the commits into one revision for the tests that exposed a broken feature, and one that fixed it.
[15:46] <awilkins> But the merge revision is the one that counts for testing purposes
[15:47] <dash> awilkins: yeah, that's the workflow i'm familiar with from svn
[15:48] <awilkins> Anyway ; so, I want to be able to submit patches to my foreign SVN repo without cherrypicking out changes from branches lower in the loom
[15:58] <dash> hm.
[15:58] <dash> i'm not familiar with doing that
[15:59] <dash> so far i've just used 'bzr diff -rthread:' to create patches to send in
[16:00] <awilkins> dash: I created a branch from HEAD of trunk, cherrypicked the patch into it, and pushed it to trunk using bzr-svn
[16:03] <awilkins> dash: Does each thread only list the changes it introduces when you do that or do you get the threads beneath it?#
[16:05] <dash> it's the diff between the thread and the one below
[16:06] <awilkins> I suppose that works, in a pinch
[16:06] <awilkins> Doesn't account for diffs to things that were changed by the thread below with respect to trunk though
[16:07] <dash> well right
[16:07] <dash> but i've always envisioned a loom as a stack of patches
[16:07] <awilkins> The topgit README also makes it sound like the feature I seek!
[16:08] <awilkins> Yes, that's the thing that puts me off using it - I have no idea what order I want to put patches in
[16:08] <dash> a diff against the bottom thread would include all the changes of the intervening thread
[16:08] <dash> well, they have to go in some order :)
[16:08] <awilkins> Yes, but I don't want to have to decide what order before I merge them, before I've even started writing them
[16:11] <awilkins> TopGit readme is very dry and needs more pretty ASCII art like Mercurial pbranches
[16:15] <abentley> awilkins: changing the order of pipes would not be easy, but it's theoretically possible.
[16:19] <awilkins> abentley: Would that involve a lot of rebasing?
[16:19] <abentley> awilkins: No.
[16:21] <awilkins> abentley: I can't think of a way to do it without rebasing ... but now I have to go and pick my wife up from the station, so I'll think about it on the way.
[16:21] <abentley> awilkins: Merging.
[16:21] <awilkins_train> INcluding reverse merging?  (now I'm really gone)
[16:36] <infinity> So... At the risk of looking like an idiot, has anyone else noticed bzr 1.16 spamming "unsupported locale" warnings when running under any locale other than en_GB.UTF-8 or C?
[16:36] <infinity> (And yes, I have several other locales generated and usable by everything else)
[16:43] <mneptok> infinity: WFM in Klingon. but then, i always challenge such error messages to personal combat with bat'leth.
[16:48] <infinity> Reproduced here on an up-to-date karmic (times two), and a jaunty with the PPA 1.16 installed.
[16:49] <infinity> To be fair, didn't test EVERY locale, but en_US and en_CA are both grumpy and both quite obviously working in other apps.
[16:55] <radix> is there a way to apply shelved changes without removing them from the shelf?
[16:59] <radix> I guess not, since there's no parameter that indicates that possibility.
[17:10] <Tak> hmm, a `bzr branch` from an svn repo seems to have gotten me some ancient files
[17:18] <radix> Tak: which don't show up in "svn ls <svn-branch>"?
[17:19] <Tak> no, I mean they're not current
[17:25] <radix> oh, I see
[17:36] <Peng_> jam: Oh, OK. It was an ISP, though. A stupid cheapo shared host, but they still count. :D
[17:39] <jam> Peng_: I don't really know the answer, but I've gotten similar messages emailing vila from my home machine
[17:39] <jam> I had to proxy through my ISP to get it to work
[17:40] <jam> I don't know why they would reject you
[17:41] <Peng_> jam: Well, okay. Anyway, I just wanted to alert you if necessary. :)
[17:41] <jam> I didn't want your email anyway :)
[17:42] <jam> I'm just hiding behind my mail host
[17:43] <Peng_> Heh.
[17:44] <jam> LarstiQ: I don't see jelmer around, but I had a question about what I should be bundling in the win32 installer
[17:44] <jam> jelmer mentioned something about changing bzr-rebase => bzr-rewrite
[17:44] <jam> and I don't really know what the latest versions of
[17:45] <jam> rebase/rewrite, svn, subvertpy etc are
[17:45] <jam> any ideas?
[17:47]  * Peng_ runs them all from source. :P
[17:47] <Peng_> s/source/bzr/
[17:54] <jam> *arg***
[17:54] <jam> It seems the project is now called "bzr-rewrite"
[17:54] <jam> but the *tag* is "bzr-rebase-0.5.1"
[17:54] <jam> bad jelmer, no biscuit
[17:55] <jam> ah well, I can cheat easily enough
[17:58] <kirkland> when using bzr export ../foo.orig.tar.gz ... is there any way to --exclude a file from being exported?
[18:07] <jam> hmm... seems "cd bzr-rewrite; py setup.py install" still installs itself as 'rebase' as well.
[18:08] <jam> weird
[18:14] <Peng_> jam: FWIW, I still call it "bzrlib.plugins.rebase" and it doesn't mind, so maybe you should stick with rebase for now.
[18:14] <Peng_> jam: Obviously it would be best to ask jelmer. :D
[18:14] <jam> yeah, I'm sticking it where it wants to be
[18:14] <jam> just seemed wrong
[18:14] <jam> probably just an incomplete conversion at this point
[18:49] <Peng_> Stupid question: Have enough 2a bugs been fixed that it's reasonably to dogfood it, and interact with different formats over the network?
[19:05] <bpierre> hi
[19:39] <rellis__> Anyone know what the right path is to obtain loggerhead 1.2.1?
[19:42] <Peng_> ...1.2.1? Isn't that from the 1990s?
[19:42] <rellis__> yeah im thinking the same
[19:42] <Peng_> Why?
[19:42] <rellis__> my boss asked me to do this so im sort of flying blind
[19:42] <rellis__> disregard my question
[19:42] <Peng_> Wouldn't you want something...modern?
[19:42] <rellis__> yeah indeed i do
[19:42] <rellis__> i want absolute current
[19:42] <Peng_> rellis__: bzr branch lp:loggerhead :D
[19:42] <rellis__> hehe alright
[19:43] <rellis__> thanks
[19:43] <Peng_> Guaranteed to partially work at least 14% of the time!
[19:43] <rellis__> what more could i ask for?
[19:46] <flvr8> does 1.16 work more than 14% of the time :) ? we're seeing a couple bugs with 1.10
[19:47] <Tak> upgrading to 1.16 seems to have fixed my issue with the svn branching
[19:49] <rellis__> Tak: Do you know the path to checkout 1.16 specifically?
[19:49] <rellis__> or is it just trunk?
[19:49] <Tak> eh, I used the release download
[19:50] <rellis__> huh i missed that on the site i guess
[19:50] <Peng_> OK, are we talking about Loggerhead or Bazaar now?
[19:51] <rellis__> loggerhead
[19:51] <rellis__> yeah that's exceptionally confusing =p
[19:51] <Peng_> rellis__: 1.16 hasn't been released yet. It's just the trunk.
[19:51] <rellis__> okay nifty
[19:52] <Tak> oh, yeah, I'm talking about bzr, sorry
[19:52] <Peng_> flvr8: Are you talking about Loggerhead or Bazaar? If LH, which bugs? Have you filed reports?
[19:52] <rellis__> np :)
[19:53] <Peng_> The trunk has a tendency to randomly break sometimes (cough test suite cough), but it fixes lots of things.
[19:53] <flvr8> peng - loggerhead as well. (i work with rellis). haven't yet filed a bug, but when we browse to one of the repositories we get an error (for which i haven't yet filed a bug):
[19:53] <flvr8> An unexpected error occurred whileproccesing the request: KeyError: ....
[19:54] <Peng_> flvr8: I think some KeyErrors have been fixed, but my memory is fuzzy.
[19:54] <flvr8> ok, we'll check out trunk and see
[19:58] <Peng_> I know an *IndexError* was fixed a while back, but that bug was introduced in the trunk. :P
[20:01] <rellis__> So  bzr branch lp:loggerhead should give me current 1.16 development work right?
[20:02] <rellis__> The readme says 1.10 so it's a little confusing..
[20:03] <Peng_> rellis__: Yeah. Seems nobody updated the version number
[20:03] <rellis__> fair enough :)
[20:14] <rellis__> Peng: I'm seeing ImportError: No module named main trying to fire up the new serve-branches from trunk... do i need to install some prereq's?
[20:16] <Peng_> rellis__: Yeah. See the README. Uh, Paste, SimpleTAL and simplejson (on Python <2.6) are the necessary ones.
[20:16] <rellis__> hmmm thought i had those
[20:16] <rellis__> i'll reverify
[20:16] <Peng_> rellis__: Oh, crap. I didn't see the "main" bit.
[20:16] <rellis__> yeah that threw me
[20:17] <rellis__> made me think it was something internal
[20:17] <Peng_> rellis__: It is. ISTM serve-branches is finding an old copy of the "loggerhead" package.
[20:17] <rellis__> ahh gotcha
[20:17] <rellis__> hmmm
[20:20] <sanjays> Hi
[20:26] <sanjays> looking for a seeming python dependency issue at Loggerhead / Bzr
[20:46] <rellis__> When I try to use loggerhead against one of my projects I get this error.. KeyError: 'someguy@somebox-20090314122230-5ds8oco7g27p9ukx'
[20:46] <rellis__> any idea what causes this?
[20:49] <rellis__> This is the full error from the loggerhead log file.. http://www.pastebin.ca/1475807
[20:52] <Peng_> sanjays: Aye?
[20:53] <sanjays> ya
[20:53] <Peng_> sanjays: What's the issue?
[20:53] <sanjays> had a particular problem with loggerhead as frontend  of BZr repository
[20:54] <sanjays> after import by developers it cannt show the trunk
[20:54] <sanjays> i will tell u the exact error if that helps
[20:55] <Peng_> rellis__: That error isn't familiar to me. Upgrading is all I can suggest.
[20:55] <rellis__> fair enough peng
[20:55] <rellis__> it's the same erro sanjay's refering to
[20:55] <Peng_> Oh.
[20:56] <rellis__> Peng would you expect the python module for loggerhead to still register as 1.10 like the readme file?
[20:57] <rellis__> We did a trunk checkout then installed and we see 1.10 listed everywhere..
[20:57] <Peng_> rellis__: Yeah, it still thinks it's 1.10.
[20:57] <rellis__> cool
[21:16] <jh> hi, I did a 'bzr pull --overwrite' and get a text conflict... how is that possible?
[21:24] <beuno> jam, hi
[21:24] <beuno> still around?
[21:25] <beuno> I've got an interesting traceback where check blows up, and reconcile finds nothing
[21:25] <beuno> https://pastebin.canonical.com/19049/
[21:25] <beuno> lifeless, maybe you're around and bored on a saturday ^
[21:25] <beuno> I'm probably going to file a bug, but I'd like to see what's interesting to add to the bug info
[22:16] <jam> beuno: yeah
[22:16] <jam> was afk for a bit, though :)
[22:16] <beuno> jam, filed as 392698
[22:16] <jam> bug #392698
[22:17] <jam> beuno: and it dies on upgrade as well?
[22:17] <jam> at least it looks like you have a missing text in your repository
[22:17] <jam> the inventory wants "(file_id, revision_id)"
[22:17] <jam> but the repository says "I don't have that"
[22:17] <jam> AFAIK, there isn't much reconcile can do
[22:17] <jam> as it can't *create* the file for you
[22:17] <jam> now, if we have the sha1 sum, we could probably fake it
[22:19] <beuno> jam, it dies on both upgrade and check
[22:20] <beuno> it's odd that *this* branch is broken, since there hasn't been anything fancy done to it
[22:20] <beuno> I'm less interested in fixing it, and more in debugging why it happened
[22:20] <beuno> it's history isn't terribly important to me
[22:23]  * beuno is in the process of upgrading the remaing ~60 branches at the office to 2a
[22:23] <beuno> only that branch failed up to now
[22:23] <beuno> and it has to be something that happened from 1.9 to now, which I upgraded a few months ago
[22:24] <beuno> so it's a bug in bzr 1.13+
[22:29] <jam> beuno: see my comment
[22:29] <jam> It was probably a bug in a really old version
[22:30] <jam> that generated a slightly bogus inventroy
[22:30] <jam> and bzr 1.12 or so wouldn't have fetched the data properly
[22:30] <jam> to handle the really old problem
[22:30] <jam> 1.13+ should handle it more correctly now
[22:31] <jam> I'm not 100% sure when the fix landed, but the fix was written by lifeless at rev: robertc@robertcollins.net-20090310065003-a57qlol97z6ohczi
[22:32] <beuno> jam, so is there anything I can do to provide useful information here?  or just delete, init, and move in with life?
[22:33] <beuno> *on
[22:33] <jam> beuno: I have a theory about what happened, but it is pretty difficult to prove or disprove...
[22:34] <jam> beuno: is this a branch with a separate repository?
[22:34] <jam> It might be interesting to see what "bzr log -r revid:'martin@pentacorp.net-200705250025002205-ybn9m9tqnxu122qo'" says
[22:34] <jam> or even "bzr log -v"
[22:34] <jam> or bzr log -v --show-ids
[22:34] <jam> to see if 'wiki_icon.gif-20070525002152-lu3yrapgr7a4d8dp-75' was modified in that rev
[22:34] <beuno> jam, it's a standalone branch
[22:35] <beuno> let me try that...
[22:35] <jam> beuno: do you have more branches of this project?
[22:35] <jam> Note that the dates are ~ the same
[22:35] <beuno> jam, probably not anymore, no. It hasn't been touched in a while, so developers likely deleted them locally
[22:35] <jam> and that -75 means this was the 75th file to be added in this commit
[22:35] <jam> which means it sounds a lot like something that was approximately the initial commits
[22:36] <jam> Amazing what info you can glean from non-random revision ids :)
[22:36] <beuno> bzr: ERROR: Requested revision: u'revid:martin@pentacorp.net-200705250025002205-ybn9m9tqnxu122qo' does not exist in branch: BzrBranch7('file:///var/www/ellatinoamericano/')
[22:37] <jam> beuno: interesting, sounds like a ghost rev then
[22:37] <jam> wonder how that happened
[22:37] <jam> beuno: there is something weird about 200705250025002205
[22:37] <jam> are you sure that was cut & pasted correctly?
[22:38] <beuno> yeap
[22:38] <jam> 2007-05-25 00:25:00: 2205
[22:38] <beuno> KeyError: ('wiki_icon.gif-20070525002152-lu3yrapgr7a4d8dp-75', 'martin@pentacorp.net-200705250025002205-ybn9m9tqnxu122qo')
[22:38] <jam> still too many digits
[22:38] <beuno> bzr log doesn't blow up
[22:38] <jam> 2009-06-26 18:03:31
[22:39] <beuno> bzr revision is from 2007-07-11
[22:39] <jam> 20090626180331
[22:39] <jam> 20070525002152 => 20070525002152
[22:39] <jam> 2007-05-25 00:21:52
[22:39] <beuno> neither does bzr log -v -n0
[22:39] <jam> looks like we generally used date to seconds
[22:39] <jam> which would be:
[22:40] <jam> 2007-05-25 00:25:00
[22:40] <jam> or
[22:40] <jam> martin@pentacorp.net-20070525002500-ybn9m9tqnxu122qo
[22:40] <jam> beuno: can you try "bzr log -v --show-ids -r revid:martin@pentacorp.net-20070525002500-ybn9m9tqnxu122qo" ?
[22:40] <beuno> jam, I can upload the repo for you, it's private-ish, but not critical, so it's ok for you to look at it
[22:40] <jam> beuno: devpad would be fine
[22:40] <beuno> malbisetti@pentaserv:/var/www/ellatinoamericano$ bzr log -v --show-ids -r revid:martin@pentacorp.net-20070525002500-ybn9m9tqnxu122qo
[22:40] <beuno> bzr: ERROR: Requested revision: u'revid:martin@pentacorp.net-20070525002500-ybn9m9tqnxu122qo' does not exist in branch: BzrBranch7('file:///var/www/ellatinoamericano/')
[22:41] <jam> beuno: alternatively "bzr log --long --show-ids | less" and search for 22qo
[22:41] <jam> but I can do that
[22:41] <jam> I want to know who this latin american is... so yes, please upload :)
[22:42] <beuno> heh
[22:42] <jam> alternatively, create a tarball, gpg sign it to my pub key
[22:42] <jam> and upload it wherever you want
[22:42] <beuno> it's about 14mb
[22:42] <beuno> uploading...
[22:45] <beuno> it should be about 6 minutes
[22:50] <beuno> jam, https://devpad.canonical.com/~beuno/ellat.tgz
[22:52] <beuno> jam, I'm also curious as to why it failed now, and not when I upgraded it to 1.9
[22:52] <jam> beuno: upgrade to 1.9 doesn't do much but change the indexes, IIRC
[22:52] <jam> as in, it doesn't have to check every text, etc
[22:52] <jam> it just rewrites what is there to be a btree rather than a KnitIndex
[22:52] <jam> beuno: *especially* if you used the fast-path writer that I had written
[22:53] <beuno> ah
[22:53] <beuno> I didn't
[22:53] <beuno> but I see what you mean
[22:53] <jam> beuno: it is also possible that the upgrade itself is the part that broke things
[22:53] <jam> it just didn't care that the text was missing
[22:53] <jam> beuno: I get "not in gzip format"
[22:53] <jam> is it encrypted?
[22:54] <jam> or is it bzip2 ?
[22:54] <beuno> uhm, no, should be tar.gz
[22:54] <beuno> argh
[22:54] <beuno> seems broken
[22:54] <jam> it is just tar
[22:54] <jam> no gz
[22:55] <beuno> did you manage to unpack it?
[22:55] <jam> beuno: "tar xvf ellat.tgz" worked
[22:55] <beuno> cool
[22:55] <beuno> I missed a flag then  :)
[22:56] <mzz> I think I've had firefox automagically decompress things for me when downloading from some servers. I tend to just always use "tar xf" to extract, modern versions of gnu tar don't need the j or z flag, they autodetect if you omit
[22:57] <jam> beuno: something very weird
[22:57] <jam> ah just a sec
[22:57] <jam> missed a flag
[22:57] <jam> forgot you now need -n0
[22:57] <beuno> yeah  :)
[22:58] <jam> beuno: so something very strange after all
[22:58] <jam> according to 'bzr log' the first revision is
[22:58] <jam> 2007-07-11
[22:58] <jam> but your error is on a file with
[22:58] <jam> 20070525
[22:58] <beuno> ha
[22:58] <jam> and a commit around
[22:58] <jam> 20070525
[22:58] <jam> so somehow your branch has a revision that existed... 1+ months before the branch
[22:58] <beuno> well, FWIW, that branch was re-inited at some point due to breackage
[22:59] <beuno> but the bzr dir was probably killed, and init + added everything
[22:59] <beuno> maybe someone merged it in that had the old branch?
[22:59] <jam> I do see a revision present:
[22:59] <jam>  ('martin@pentacorp.net-20070525002205-ybn9m9tqnxu122qo',),
[22:59] <beuno> it wouldn't of let them I guess, since there's no common ancestors
[23:00] <jam> which probably isn't in the ancestry of the branch
[23:00] <jam> but is present in the repo
[23:00] <beuno> this is getting stranger as we go  :)
[23:01] <jam> beuno: so I can do "bzr branch -r revid:'martin@pentacorp.net-20070525002205-ybn9m9tqnxu122qo' . ../ellat2"
[23:01] <jam> and then I see
[23:01] <jam> $ bzr log ../ellat2/
[23:01] <jam>     1 Martin Albisetti  2007-05-24
[23:01] <jam>       inicio
[23:01] <jam> so *my* guess is that *you* are responsible :)
[23:02] <jam> beuno: and if I look at "bzr log -v --show-ids" for that revision
[23:02] <jam> I also see what I expected
[23:02] <jam> namely, the file
[23:02] <jam> the file-id matches
[23:02] <jam> only notice that the revision id is different than what you gave as an error
[23:02] <jam> 2007 05 25 00 22 05
[23:03] <jam> where you had 2007 05 25 00 22 00 ...
[23:03] <beuno> heh, it was 2007, I was doing all kinds of crazy things (?)
[23:03] <jam> beuno: I see the same error
[23:05] <beuno> wooo, finished upgrading all branches, that was the only one that exploded
[23:05] <beuno> pretty impressive considering we've been using bzr since 0.12
[23:06] <jam> beuno: so my guess is that the original commit was bogus
[23:06] <jam> which is why you started over
[23:06] <jam> if you do "bzr branch ellat ellat2"
[23:07] <jam> you should probably be able to upgrade ellat2
[23:07] <jam> as it will have pruned out the bogus revision
[23:07] <beuno> cool, easy peasy
[23:08] <beuno> is there anyway reconcile could tackle this in the future?
[23:10] <beuno> jam, you're right
[23:10] <beuno> oddly enough
[23:10] <jam> beuno: so... something still strange. In that I get the same failure
[23:10] <beuno> check finds 81 revisions on the borked one
[23:10] <jam> but I don't see any way yet for it to occur.
[23:10] <beuno> and 57 on the branched one
[23:10] <jam> so maybe it is a different rev which is broken
[23:11] <beuno> jam, upgrading went fine on the newly branched one as well
[23:12] <beuno> the 81 vs 57 revs is intriguing
[23:12] <jam> beuno: anyway, I'm off for now
[23:12] <jam> but I find the bogus text in the inventories of 20 revisions
[23:13] <jam> beuno: https://pastebin.canonical.com/19053/
[23:13] <beuno> jam, cool. Hope it helps at all, and thanks for the workaround
[23:13] <beuno> have a nice weekend
[23:13] <jam> which is probably the 20 or so that aren't in the branch anymore :)
[23:39] <abeaumont> vila: ping
[23:52] <lifeless> beuno: ?