=== zyga is now known as zyga-afk
=== medberry is now known as med_out
=== AfC1 is now known as AfC
[06:12] <bignose> nnnggg
[06:12] <bignose> $ bzr update
[06:12] <bignose> Tree is up to date at revision 3418 of branch svn+ssh://benf@subversion/home/svn/empowered/trunk
[06:12] <bignose> $ bzr commit
[06:12] <bignose> bzr: ERROR: Bound branch BzrBranch7(file:///home/benf/projects/svn/empowered/) is out of date with master branch SvnBranch('svn+ssh://benf@subversion/home/svn/empowered/trunk').
[06:12] <bignose> To commit to master branch, run update and then commit.
[06:13] <spiv> That's weird.  It sounds a bit familiar though, perhaps someone else will recognise the bug.
[06:23] <vila> >-/ unbind/bind ?
[06:23] <vila> makes no sense
[06:26] <bignose> okay, it appears to be related to::
[06:26] <bignose> $ bzr merge --revision 1823 ../../devel/empowered.rt12430.confirm-reminder-email/
[06:26] <bignose> inconsistent details in skipped record: StaticTuple('719@58802371-0b19-4c69-acb7-7d0c5b422186:trunk%2Fwdyt%2Fsource%2Fwdyt%2Fprofile_modules%2Fmanagement%2Fcommands%2Fsend_profile_reminders.py', 'ben@benfinney.id.au-20110701043735-hyhpvogab661xpcz') ('4721568 342529 114092 114205', ((('719@58802371-0b19-4c69-acb7-7d0c5b422186:trunk%2Fwdyt%2Fsource%2Fwdyt%2Fprofile_modules%2Fmanagement%2Fcommands%2Fsend_profile_reminders.py', 'svn-v4:58802371
[06:26] <bignose>  M  wdyt/source/wdyt/reminder/tests/test_reminder.py
[06:26] <bignose> All changes applied successfully.
[06:33] <vila> bignose: as in: you're out of trouble but this is worth filing a bug ?
[06:37] <bignose> vila: as in, that's the consistent message that precedes the failure.
[06:37] <bignose> I'm madly trying to merge these branches
[06:38] <bignose> and it fails with that message
[06:39] <vila> what fails ? 'All changes applied successfully' does not sound like a failure (which is confusing)
[06:39] <bignose> or rather that message precedes the “ERROR: Bound branch BzrBranch7(file:///home/benf/projects/svn/empowered/) is out of date with master branch” message when I try to make a change
[06:39] <bignose> the sequence is: merge, get that “inconsistent details” message, then try to commit → ERROR
[06:40] <vila> which versions of bzr / bzr-svn are you using ?
[06:41] <bignose> $ bzr version
[06:41] <bignose> Bazaar (bzr) 2.2.4
[06:41] <vila> hmpf
[06:42] <bignose> (from Ubuntu Maverick)
[06:42] <bignose> bzr-svn 1.0.3-1
[06:43] <vila> 2.3.3 / 1.0.4 are available from the stable ppa, that would be my first line of defense
[06:44] <bignose> I'm not in a position to update this machine
[06:44] <bignose> or install packages
[06:44] <vila> I don't know the details but I know jelmer did a bunch of fixes (and he is out this week)
[06:44] <vila> hmm
[06:44] <vila> no other machine available to try ?
[06:44] <bignose> what should I try, though?
[06:45] <vila> same commands with upgraded bzr / bzr-svn
[06:45] <bignose> you're aware that I've reported problems with bzr-svn this week, that others here have said are repository corruption?
[06:45] <vila> if you can't upgrade it will be rather complicated to even get a fix (if it's not a known bug) :-/
[06:45] <bignose> so I am trying to keep straight what's happened to each repository
[06:45] <vila> hmm, no I wasn't :-(
[06:46] <vila> irc is not a reliable medium when it comes to tracking bugs...
[06:46] <bignose> no, I ended up reporting it to the mailing list
[06:48] <vila> huh ? Did I miss that one ? ....
[06:48] <vila> oh
[06:48] <vila> Crash in ‘bzr-svn’, but works with Subversion ?
[06:48] <bignose> that's the one
[06:49] <bignose> now I appear to be reaping the repository corruption, trying to merge my work from earlier this week
[06:49] <vila> you mentioned bzr-2.2.1, you did upgrade since then ?
[06:49] <bignose> how the heck can I get my work properly into the Subversion repository?
[06:52] <vila> see above, jelmer being away this week, I'll try with recent versions first, I know there have been fixes related to statictuple stuff but nothing more detailed :-/
[07:16] <bignose> vila: using bzr 2.3.1-1, bzr-svn 1.0.5dev
[07:16] <bignose> I get a crash trying to merge
[07:17] <bignose> File "/usr/lib/python2.6/dist-packages/bzrlib/repofmt/pack_repo.py", line 2171, in _commit_write_group "Cannot add revision(s) to repository: " + problems_summary)
[07:17] <bignose> BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing referenced chk root keys: [StaticTuple(…
[07:17] <vila> >-/
[07:18] <vila> bignose: can you pastebin a bit more details so I can paste it to the bug report ?
[07:19] <bialix> hi all
[07:19] <bialix> jam: hi
[07:20] <vila> bignose: missing chk root keys though... May be that can be worked around by pulling the right revisions in the right repo (if we can understand where they are missing that is...)
[07:20] <bialix> bonjour vila
[07:20] <vila> bialix: hi hi sir
[07:22] <bialix> vila: after the latest team changes initiated by maxb I left ~bzr and moed to ~bzr-core. But I didn't realize that bzr-windows-installer project maintained by ~bzr.
[07:23] <bignose> vila: <URL:http://paste.pound-python.org/show/9056/>
[07:23] <jam> morning all
[07:23] <bialix> so I can't land https://code.launchpad.net/~bialix/bzr-windows-installers/changelog_plugin/+merge/66760
[07:23] <bialix> hi jam
[07:23] <bignose> vila: thanks for the help so far
[07:23] <maxb> huh. If anything my changes were to enable people to move from ~bzr-core to ~bzr
[07:23] <bignose> I have to go now
[07:23] <bialix> maxb: I don't blame you
[07:24] <maxb> bialix: I'm just confused why you chose to do that move
[07:24] <bialix> it was my mistake, I guess
[07:24] <bialix> maxb: because of Olive
[07:24] <bialix> anyway all Bazaar projects are too big for me
[07:25] <bialix> bzr-core, qbzr, explorer and windows-installers -- those are areas of my expertise
[07:25] <vila> bignose: bug updated
[07:25] <bignose> vila: appreciated, thanks
[07:25] <bialix> jam: may I ask you to look and merge before 2.4 final this patch, please: https://code.launchpad.net/~bialix/bzr-windows-installers/changelog_plugin/+merge/66760
[07:25] <vila> jam: hello patch pilot ;-)
[07:26] <bialix> vila: topic/
[07:26] <maxb> bialix: ~bzr doesn't get any email about Olive
[07:26] <bialix> maxb: it did some
[07:27] <maxb> yeah, that was quicly reverted
[07:27] <bialix> I was quicker
[07:27]  * bialix is looking for jriddell
[07:34] <maxb> I think it's time for me to shout a bit more about my refactoring bugmail thread
[07:35] <maxb> The only tricky thing is that to get ~bzr down to receiving no more bugmail than ~bzr-core, we also need to remove structural subscriptions from:
[07:35] <maxb> ~bzr-gtk ~bzr-hg ~bzr-upload-devs ~qbzr-bugs
[07:38] <maxb> hmm, perhaps I should wait for a time when jelmer isn't away to propose this
=== hunger_ is now known as hunger
=== zyga-afk is now known as zyga
[09:07] <vila> YES ! Today is a good day :-D
[09:08] <vila> 1) My daughter got her baccalaureat
[09:08] <vila> 2) bug #805809 is almost dead
[09:08] <ubot5> Launchpad bug 805809 in Bazaar "merge fails with NoFinalPath" [High,In progress] https://launchpad.net/bugs/805809
[09:11] <jam> vila: btw, we decided that the stand-up tomorrow would be at 9am local time, right? Not 8am?
[09:12] <vila> jam: yup, poolie send an invitation update
[09:12] <vila> sent
[09:21] <maxb> oooh
[09:21] <vila> maxb: recognize the 31 failures ?
[09:21] <maxb> 805809 might make you a hero of udd
[09:22] <vila> maxb: just so you know (and because I didn't explain all the gory details in the bug nor the mp): this is partly due to debian and ubuntu branches having different root-ids
[09:22] <maxb> urgh
[09:22] <vila> this is quite messy as lenny branches tend to have the same root-ids as the ubuntu branches but not always
[09:23] <vila> probably lots of of merge -r0..nnn involved
[09:23] <vila> i.e. despite having different root-ids, a lot of file-ids are still common and even revids...
[09:23] <maxb> we may want to throw away and reimport some
[09:24] <vila> maxb: I thought a bit about that but that doesn't seem required (at least it's *not* required with this fix)
[09:25] <vila> having different root-ids for upstream, debian, ubuntu branches is a use case we want to support
[09:26] <vila> hacing different root-ids among debian branches (or ubuntu branches) is a bit more weird but still conceivable
[09:27] <vila> maxb: note that *this* bug is occurring when generating the ubuntu merges which we don't use (yet) so a related fix for udd *may* be to ~ignore them
[09:28] <vila> at least, this shouldn't block pushing to the lp packaging branches (and may be it doesn't already)
[09:28] <vila> ghaa, retry:
[09:29] <vila> maxb: I think the importer is pushing to lp and *then* failing to generate the ubuntu merges so these 31 failures are not blocking
[09:29] <vila> maxb: does that sound right ?
[09:36] <maxb> They are blocking
[09:36] <vila> rats
[09:37] <maxb> They were not blocking the first time it failed, but for every subsequent upload, the importer tries to finish off the push/merge stuff before importing anything new
[09:37] <vila> ratsss
[09:37] <vila> hmm
[09:40] <maxb> We may need to destroy and reimport these ubuntu branches anyway
[09:41] <maxb> We have several bugs filed by people who are finding out the hard way that bzr's merge behaviour is unhelpful when parallel imports happen
[09:58] <vila> maxb: my next target is to address parallel import in a very restricted way but still valid for udd (i.e. we damn well know the paths are the same even when the file-ids differ)
[09:59] <vila> maxb: I'm unclear about how the branches are created anyway and how we can ensure all packaging branches use the same root-id and even if we achieve that we may still encounter issues if upstream use yet another one (which is a valid use case)
[10:00] <vila> maxb: but I won't object about reimporting the branches if it helps (I'm not sure all cases will be addressed with that though)
[10:01] <maxb> Yes, I definitely agree that reimports will never solve the larger issue.
[10:01] <maxb> There may be places where they are an expedient solution though
[10:01]  * vila nods vigorously
[10:14] <vila> why is 2.3.3 still in natty-proposed ?
[10:15] <maxb> No one has verified any of the bugs, apparently
[10:16] <maxb> http://people.canonical.com/~ubuntu-archive/pending-sru.html
[10:16] <maxb> Also, wasn't there discussion of a potential regression?
[10:16] <vila> do we need that even with MRE ?
[10:17] <vila> oh, which one ?
[10:18] <vila> 2.3.4 is planned for 13 July...
[10:18] <maxb> bug 798688
[10:18] <ubot5> Launchpad bug 798688 in bzr (Ubuntu) "possible regression in natty-proposed" [Undecided,Incomplete] https://launchpad.net/bugs/798688
[10:21] <vila> <shudder> final slashes and ~/%7E ... madness
[10:23]  * vila off for lunch
=== zyga is now known as zyga-food
=== zyga-food is now known as zyga
[14:07] <ScottK> I have a directory in a bzr branch that I want to move to a different project (no common history).  How do I do that without losing the history for the files I'm moving?
[14:36] <LarstiQ> ScottK: this may not be the recommended way, but you could split and join. Drawback is that you carry all of the other history along.
[14:37] <ScottK> This is a tiny piece of the overall project it's leaving, so that would be a bit daunting.
[14:37] <ScottK> Thanks.
[14:39] <LarstiQ> ScottK: perhaps with fastexport and filtering inbetween?
[14:39] <ScottK> Perhaps.  I'll look into it.
=== deryck is now known as deryck[lunch]
=== beuno is now known as beuno-lunch
[17:00] <lvh> Hi. Is there an easy way to find the point where the current branch branched off from its parent branch?
=== deryck[lunch] is now known as deryck
[17:22] <maxb> lvh: It's not quite what you asked for, but there is "bzr find-merge-base BRANCH OTHERBRANCH"
=== med_out is now known as medberry
=== sidnei is now known as sidnei-away
=== beuno-lunch is now known as beuno
[18:50] <ChrisCauser> Hello #bzr
[18:50] <ChrisCauser> Is there anyone out there who can help me with a spot of trouble I'm having with bzr 2.4?
=== yofel_ is now known as yofel
=== medberry is now known as med_out