[00:36] <igc> morning
[00:47] <jam> lifeless or spm: can you go ahead and create a 2.0.1 branch from 2.0 and a 2.1.0b1 branch from bzr.dev@4734 ?
[00:48] <jam> I'm going to be in and out a bit
[00:48] <jam> (i decided to not release my last two patches from bzr.dev, instead waiting for 2.1.0b2 for the static tuple stuff)
[00:48] <jam> I'd like to work on the releases tomorrow, though
[00:52] <mathepic> I'm doing an update on the format docs
[00:52] <mathepic> What should I change this to:  For example,
[00:52] <mathepic> you may need to select 1.9 instead of 1.14 if your project has
[00:52] <mathepic> standardized on Bazaar 1.13.1 say.
[00:55] <mathepic> Is this good? "For example, you may need to select 1.14 instead of 2a if your project has standardized on Bazaar 1.18 say."
[00:55] <mathepic> I'm going to delete the say, it doesn't fit in.
[01:01] <maxb> Doesn't 1.18 support 2a? (with efficiency caveats)
[01:03] <mathepic> Oops
[01:03] <mathepic> When was the version before 2a was released
[01:03] <mathepic> I'll fix that really quickly
[01:07] <mathepic> Do I mark myself as the assignee and the status of the bug "Fix Commited"
[01:07] <mathepic> I'm not sure how the bug-process works
[01:11] <mathepic> Should I change the status to "In Progress", "Fix Committed", or just leave in the way it is?
[01:33] <lifeless> jam: I can't anymore
[01:33] <lifeless> jam: and spm is sick today
[01:33] <lifeless> jam: you should mail RT
[01:33] <lifeless> 1.16 and above support 2a
[01:36] <igc> mathepic: thanks for working on that bug
[01:36] <mathepic> igc: No problem.
[01:37] <mathepic> Can anyone confirm that the info contained in it is correct? I don't know my history that well.
[01:37] <igc> mathepic: while working on a bug, mark it "In Progress"; once you've pushed a branch with the fix, mark as "Fix Committed"
[01:37] <mathepic> igc: Okay, thanks.
[01:38] <igc> mathepic: I'd drop all the text about selecting a format prior to 2a. We need to *strongly* encourage everyone to upgrade
[01:38] <mathepic> Okay.
[01:39] <igc> mathepic: as lifeless mentioned, 1.16 and above support 2a
[01:39] <mathepic> should I keep the paragraph about the rich-roots?
[01:40] <igc> you can mention rich-root in a footnote but not the main text IMO
[01:40] <igc> it tends to confuse more than enlighten
[01:40] <igc> most readers
[01:41] <igc> and after 2a, the issue effectively goes away because all future formats are rich-root implicitly
[01:41] <igc> (as is 2a)
[01:42] <mathepic> How about this: "The newest format, 2a, is highly recommended to use. If your project does not support 2a, then you should suggest to the branch owner to upgrade."
[01:42] <mathepic> (That replaces the whole list thing)
[01:43] <mathepic> Or simply nothing at all?
[01:45] <mathepic> I'll just remove that whole block of text.
[01:46] <igc> mathepic: "does not support" -> "is not using"
[01:47] <mathepic> Okay, added it back. "Branch owner" or "Project owner"?
[01:47] <igc> project owner
[01:48] <mathepic> Okay, I'm pushing it to my branch.
[01:49] <igc> cool. Then propose it for merging please
[01:50] <mathepic> Its been proposed.
[01:50] <igc> ah - then you may need to resubmit the proposal
[01:51] <mathepic> I sent another review request to bzr-core. Is that what you mean?
[01:52] <igc> yep. Thanks.
[01:53] <mathepic> Okay.
[01:57] <mathepic> Ugh, spotted a type
[01:58] <mathepic> igc: I pushed it again to fix a typo. Do I send a review request again?
[02:00] <igc> mathepic: hmm - forget what I said about requesting another review
[02:00] <mathepic> igc: Okay.
[02:00] <igc> you need to click "resubmit proposal"
[02:00] <igc> top right hand corner
[02:01] <mathepic> Okay, done.
[02:01] <mathepic> Well, I have to go.
[02:01] <igc> mathepic: thanks for your work!
[02:01] <mathepic> No problem. :)
[02:01] <lifeless> shouldn't need the resubmit anymore
[02:01] <lifeless> the diffs update
[02:01] <igc> lifeless: ah - ok
[02:02] <igc> lifeless: hi btw - welcome back to Oz
[02:02] <igc> lifeless: I hope the sprint when well
[02:02] <lifeless> yup
[02:40] <jam> lifeless: k. Also, I don't think pqm is running the test suite on python2.4 anymore. At least, I thought that was the problem so I installed 2.4, and found out it wouldn't build
[02:40] <jam> so I sent in a patch to make it build on 2.4, but the previous patch had been accepted.
[02:41] <lifeless> jam: rt that too :)
[02:41] <lifeless> jam: the chroot has been upgraded, probably the default python has been altered
[02:41] <jam> lifeless: is the fix just configuring pqm to do "make check PYTHON=python2.4" ?
[02:42] <lifeless> yeah
[02:42] <lifeless> force the version in the pqm config
[03:36]  * igc lunch
[06:14] <igc> bbl
[06:55] <eferraiuolo> I was curious why a Loggerhead Package for Hardy was never released?
[07:19] <vila> hi all
[07:28] <bialix> hello all
[07:44] <trondn> is there an equivalent of the hg export / import functionality in bzr???
[07:45] <trondn> (export a changeset that I may import into another workspace)
[07:47] <spiv> thumper: there's 'bzr send'
[07:47] <thumper> ??
[07:47] <thumper> spiv: tab fail
[07:47] <spiv> thumper: er, sorry, wrong nick :)
[07:47] <mneptok> tab-complte FAIL
[07:48] <thumper> mneptok: hey
[07:48] <spiv> trondn: There's "bzr send"
[07:48] <mneptok> thumper: ahoyhoy!
[07:48] <trondn> spiv:  and to apply it into the other one (and preserve commit id etc)?
[07:49] <spiv> trondn: bzr pull or bzr merge from the file, like you would with the branch.
[07:49] <trondn> spiv but that will make it a merge set??
[07:50] <spiv> If you use 'bzr merge', yes.  But you can 'bzr pull' if you don't want to merge (assuming the history hasn't diverged).
[07:53] <trondn> hmm...  bzr send -r -2 -o /tmp/foobar resulted in: Bundling 0 revision(s) ...
[07:53] <mneptok> "bzr oh_god_i_killed_us_all" should undo the previous push. kthx.
[07:54] <spiv> mneptok: bzr alias oh_god_i_killed_us_all="push -r -2 --overwrite"  ;)
[07:55] <mneptok> spiv: but then i can't tell others about bzr's intuitive, natural language feature set
[07:56] <spiv> trondn: oh, right.  "bzr send" really prefers to have access to the target branch so that it can bundle exactly the right set of revisions.
[07:57] <spiv> trondn: which is a bit annoying when you don't have the branch accessible :/
[07:58] <trondn> spiv I have both available... the one I want to put the one changeset in is ../mget... bzr send --help would be a lot more helpful with an example....
[07:59] <trondn> guess I should just try out the rebase thing.. that's the thing I really want to do...
[07:59] <trondn> (I just heard that it might not work the way I expected it to work ;-) )
[07:59] <spiv> trondn: oh, if you have the target available, just "bzr send /url/to/target -o somefile"
[08:00] <spiv> trondn: or, if the target is writeable, just cd to it and do "bzr pull /path/to/other/branch", you don't need the indirection of a merge directive file.
[08:02] <spiv> rebase isn't ever exactly "the thing I really want to do" AFAICT; it's a means, not an end.  What's the goal?
[08:02] <trondn> :( they have diverged so it tells me to merge :(
[08:02] <trondn> the goal: put my changeset at the _end_...
[08:02] <trondn> and don't fuck up the history with another merge set..
[08:02] <spiv> Why is merging so terrible for you?
[08:03] <trondn> it makes the history unreadable...
[08:03] <trondn> I'm working on implementing a feature committing multiple times... but I still want to bring in the work happening on trunk...
[08:03] <spiv> Hmm, I don't find that.  "bzr log" by default only shows the mainline commits.
[08:04] <trondn> and I want my changes to appear at the end in one bulk instead of a spagetti with the "merge from trunk"..
[08:05] <trondn> with git I normally just do git rebase, in Mercurial i use export / import... in bzr I currently apply each patch by hand and commits them again :(
[08:05] <spiv> So, if you want to squash things into a linear history when things have diverged, rebase is an alright way to do that.  I personally find the original history quite readable, though.
[08:05] <spiv> There is a rebase plugin.
[08:06] <spiv> But I suggest you play a little bit with "bzr log" and its options, you might be surprised.
 is the rebase plugin btw, in case you don't already have it.
[08:07] <trondn> I guess I could.. right now I find it terrible to track down a bug on let's say lp:drizzle.. bzr log mostly shows me merge "foo", so I run it with bzr log -n 0 -v, but then I see changes multiple times because multiple people merged the same changeset into their tree etc...
[08:07] <trondn> (downloading and installing now)
[08:09] <spiv> Normally I only want to see the mainline commits, I actually quite like that a long-running feature that took 30 commits to develop is shown as a single mainline commit, rather than as 30 separate pieces.  (But also that the individual pieces are still there when I need them.)
[09:09] <crisb> when I use bzr qlog it chops off the first digit of the revision number - anyone else seen this before!?
[09:13] <crisb> also, shouldnt qcommit be a resizeable dialog?
[09:13] <crisb> i swear it used to be...
[09:21] <davidstrauss> crisb: It is resizable. Change your monitor resolution.
[09:22] <crisb> davidstrauss: i'm at 1650x1080!  its not that it appears maximised, it just wont let me resize it or maximiseit
[09:23] <davidstrauss> crisb: No, I mean reducing your monitor resolution will make the window bigger. :-)
[09:23] <crisb> :)
[09:24] <crisb> so its not supposed to be resizeable in the same way as say qlog?
[09:24]  * davidstrauss actually has no idea.
[09:28] <crisb> sorted - dodgy qbzr.conf :)
[09:30] <crisb> revision number chopping still exists though :(
[09:37]  * igc dinner
[10:32] <igc> crisb: I'm seeing the first digit being chopped too in qlog if the re count is > 1000
[10:32] <igc> crisb: can you raise a bug for that please?
[10:33] <crisb> igc: sure, I already raised 450179 - looks like Alexander Belchenko has confirmed it too
[10:33] <igc> crisb: ah - I see you already have - thanks
[10:41] <bialix> is it possible to quickly/cheaply determines how many revisions in the repository? not in the mainline revisions, but in repository overall?
[10:41] <bialix> crisb: there si hardcode limit for 4 digits in qlog
[10:41] <bialix> crisb: there is hardcode limit for 4 digits in qlog
[10:42] <crisb> bialix: yes, I noticed that in logwidget.py - but changing it to more than 4 digits didnt help
[10:44] <bialix> there is custom painting code
[10:44] <bialix> without looking into code I'd say there is several places which require to be fixed
[12:04] <Anteru> Hi
[12:06] <Anteru> I'm importing a svn repo into bzr, with 2324 revisions, but bzr says copying revision x/2304 -- is this normal?
[12:11] <jelmer> Anteru: yeah, that could be correct
[12:11] <jelmer> Anteru: bazaar only imports branches, and some commits in svn might have been outside of actual branches
[12:11] <Anteru> err, I'm trying to import _the whole repo_
[12:12] <jelmer> Anteru: if you create a "branches" directory in svn that wouldn't show up in bazaar anywhere
[12:12] <Anteru> with /branches, /tags, /trunk
[12:12] <Anteru> hm ok
[12:12] <Anteru> I previously tried git, where you have to specify the layout
[12:12] <Anteru> and git imports everything, including branches from svn
[12:13] <jelmer> Anteru: Git doesn't import these commits either afaik
[12:13] <jelmer> Anteru: e.g. if you add a file called README in /, which branch would you expect it to end up in?
[12:15] <Anteru> well, I would expect an error
[12:16] <Anteru> btw what are the parameters for the repository layout?
[12:17] <Anteru> it says "Using repository layout: trunk0"
[12:17] <jelmer> Anteru: yeah, that means the standard /trunk, /branches, /tags layout
[12:17] <Anteru> and looking at the doc page, it lists none, trunk,, and default: auto
[12:18] <Anteru> Ok, I'm halfway through, but I still don't get why revisions are missing
[12:18] <Anteru> I had one branch or so in the past in /branches/, which has been deleted
[12:20] <Anteru> I simply don't want to loose history
[12:21] <jelmer> Anteru: are you using --keep ?
[12:21] <Anteru> nope, will try
[12:21] <jelmer> and --all?
[12:22] <Anteru> why would I use keep when I use all?
[12:22] <Anteru> I just want the whole history
[12:22] <Anteru> that is, being able to restore anything which was stored in the SVN (d'uh, missed --all)
[12:34] <Anteru> ah ok, looks good
[12:37] <Anteru> thanks!
[12:37] <jelmer> sorry, was aaway
[12:38] <jelmer> Anteru: np, glad it worked
[12:39] <Anteru> just double-checking, with --all, it says copying revisions x/2314
[12:40] <Anteru> du, which is still 10 too few :/
[12:40] <Anteru> even with --keep --all
[12:41] <Anteru> I guess tags are skipped?
[12:45] <Anteru> ah damn, the folder /branches was called /branch some time back in ancient history
[12:46] <jelmer> Anteru: it should follow that
[12:46] <jelmer> Anteru: tags are not versioned in bazaar, so they wouldn't count as revisions
[12:46] <Anteru> ok I got 8 tags
[12:47] <Anteru> so 2 revisions ... one might be the /branch -> /branches rename
[12:47] <Anteru> and one might be the initial commit
[12:49] <jelmer> igc: Does fastexport/fastimport follow renames?
[12:49] <jelmer> (looking at the samba import)
[12:52] <Anteru> I guess even if there is something missing, it can't be a lot
[12:54] <igc> hi jelmer
[12:54] <igc> jelmer: yes it does, though I think one needs to explicitly ask git-fast-export to detect them
[12:55] <igc> and export them
[12:55] <igc> (and I didn't do that)
[12:55] <jelmer> igc: that might explain the big repo size
[12:55] <igc> interesting
[12:56] <igc> not that we've implemented copy support yet
[12:58] <jelmer> igc: copy support would help too I suppose
[12:58] <jelmer> igc: samba trunk has two top-level directories that have a lot of code in common
[12:59] <Anteru> w00t, just managed to work with a SVN repo from bzr
[13:00] <Anteru> though the "push" speed is kinda slow
[13:00] <jelmer> Anteru: it should be faster the second time around
[13:01] <jelmer> Anteru: the first time it has to update caches, etc
[13:01] <igc> jelmer: fyi, I changed the file-id algorithm and the repo size dropped from 500M+ to 350M.
[13:01] <igc> jelmer: jam gave me the tip to do that
[13:01] <jelmer> igc: wow, I wouldn't expect it to matter that much
[13:01] <igc> jelmer: I was generating file-ids using the full-path - now I just use the basename
[13:02] <igc> jelerm: scary ah - one line change having that sort of impact!
[13:02] <jelmer> igc: Yeah, indeed
[13:03] <jelmer> I should remember to do a similar thing next time I update the mappings for bzr-{git,hg}
[13:04] <Anteru> jelmer: I tried twice, it says something about finding tags each time
[13:04] <jelmer> Anteru: what version of bzr-svn are you using?
[13:04] <igc> jelmer: btw, how easy/hard would it be for you to convert svn-fast-export.py to use subvertpy instead of the std bindings?
[13:04] <Anteru> jelmer: bzrlib 2.0.0, python 2.5.4 (latest stable installer for windows)
[13:06] <jelmer> igc: should be fairly easy
[13:06] <igc> jelmer: it would be sweet if you could take a look - bug 273361 is driving me nuts
[13:07]  * jelmer has a look
[13:07] <igc> jelmer: the all-but-identical C implementation works fine
[13:07] <igc> jelmer: so I suspect the bindings
[13:08] <igc> jelmer: and furthermore, using the same bindings you are makes it easier for Windows users because they don't need to install extra pieces IIUIC
[13:10] <Anteru> jelmer: well, gotta go for a mo', gonna test more thoroughly later, thanks for the starting help! I'm evaluating a switch from SVN -> git/hg/bzr, and right now, bzr is back in the race ;)
[13:13] <Tak> one thing that makes bzr a big contender in that regard - for commands that apply, `svn blah` almost always maps directly to `bzr blah`
[13:13] <jelmer> igc: ah, right
[13:13] <jelmer> Anteru: cool :-)
[13:14] <Anteru> ciao
[14:04] <vila> jam: ping
[14:40] <johnf> jelmer: ping
[14:42] <johnf> lifeless: ping
[14:55] <vila> jam: ping
[14:57] <igc> night all
[14:57] <igc> hi vila
[14:58] <vila> wow, Ian, still up ?
[14:58] <igc> vila: we should catch up soon - I'm heading to bed now
[14:58] <igc> vila: just packaging up explorer 0.8.3 in time for the 2.0.1 release
[14:58] <igc> night
[14:58] <vila> k
[15:08]  * fullermd sneaks up behind vila and ties his shoelaces together.
[15:08] <vila> 8-)
[15:30] <jam> vila: pong
[15:31] <vila> jam: I'm not sure if this is related to bug #449776, but babune failed hard
[15:31] <vila> and it's clearly related to not being able to run without extensions
[15:32] <vila> jam: so frebsd7. freebsd8. tiger and leopard all failed
[15:32] <vila> jam: can you have a look and tell me ?
[15:33] <vila> jam: search for the last midnight run on babune, I'm running on specific branches since
[15:33] <fullermd> I'd hope not.  pyrex is way newer than that on BSD...
[15:33] <vila> and not installed on my OSX slaves, so :)
[15:34] <jam> vila: It is giving me times in "CEST", should I look for 00:00 ?
[15:34] <vila> jam: yes
[15:34] <vila> jam: build36 for freebsd7
[15:35] <jam> yeah, looking now
[15:35] <vila> ok
[15:35] <jam>     self.assertIs(k1, obj.add(k2)) AssertionError: ('foo',) is not ('foo',).
[15:35] <jam> that is a bit strange
[15:36] <jam> it hints that the hashing may be putting objects in different locations
[15:36] <jam> I know I had a bug there, but I had fixed it before submitting.
[15:36] <vila> jam: looks like you have another then :)
[15:37] <jam> vila: are any of the others failing?
[15:37] <jam> note that I'm planning on cutting 2.1.0b1 from before those patches for now
[15:37] <vila> jam: hardy, jaunty and karmic are ok
[15:37] <jam> since if I can't land everything, it isn't worth releasing part of it
[15:37] <vila> jam: gentoo too
[15:38] <jam> vila: is this a 32/64 bit issue?
[15:38] <vila> it shouldn't, karmic is a 64bits slave while hardy is a 32bits one
[15:38] <jam> k, and do you know the versions of python there ?
[15:38] <vila> and jaunty is 64 bits too
[15:39] <vila> freebsd7 is 2.5.4, errr, you have a selftest output, everything is mentioned there :)
[15:40] <vila>    bzr-2.1.0dev python-2.5.4 FreeBSD-7.2-RELEASE-amd64-64bit-ELF
[15:40] <jam> mthaddon: ping (are you the LOSA online right now?)
[15:41] <mthaddon> jam: yep (but we all highlight on losa, so you can just ping losa)
[15:41] <jam> mthaddon: ah, good. I always have trouble tracking you guys down :)
[15:41] <jam> I need to cut 2 new branches for pqm
[15:41] <jam> can you help me?
[15:42] <mthaddon> jam: I can do, but it'd be ideal if you could put it all in an RT request
[15:42] <jam> mthaddon: I can, though the rt system honestly confuses me quite a bit
[15:42] <jam> I'm never really sure what I need to put into the request
[15:42] <jam> and "RT" isn't a great search term on the canonical wiki
[15:57] <jam> vila: do you have access to the freebsd machine, that I could try testing directly?
[15:57] <jam> The test suite passes for me on python2.5.2 on Jaunty
[15:58] <jam> also, do you know why tiger and leopard are failing the test suite?
[15:58] <jam> well, failing to build
[15:59] <vila> jam: not really, I think the MIN MAX are warnings only, the 'lipo: can't figure out the architecture type of: /var/tmp//cczgHHiH.out' is a bit puzzling
[16:01] <jam> so, warning "MIN" redefined is code I didn't touch., and as you say it is only a warning
[16:01] <jam> bzrlib/_static_tuple_c.c:32:33: error: bzrlib/_static_tuple_c.c:32:33:_simple_set_pyx_api.h: No such file or directory
[16:01] <jam> That fails because we need to compile _simple_set_pyx.pyx first
[16:01] <jam> as it auto-generates the api.h file
[16:02] <jam> and since you don't have pyrex...
[16:03] <vila> ..which is a conf we want to support
[16:03] <vila> ..no pyrex, no C files
[16:03] <vila> until we version the C files
[16:03] <jam> *I* don't care to support people building *from source* who don't have pyrex/cython
[16:03] <vila> ...which we won't do in the coming minutes as you and I know damn well :)
[16:04] <jam> Tarball is a little bit different
[16:04] <jam> though again, if you are building from scratch, install dev tools
[16:04] <jam> we require gcc
[16:04] <vila> hmm
[16:05] <vila> yeah right, this predates babune running explicitly without extensions, so indeed I should install pyrex there
[16:05] <jam> pyrex used to be a lot more rare...
[16:05] <vila> AIUI I should be able to easy_install it....
[16:06] <vila> let's check that myth...
[16:06] <jam> I believe so
[16:12] <vila> pffff, easy_install is for 2.5 not 2.6.... how do I install it for 2.6...
[16:15] <jam> vila: I use easy_install here w/ py2.6
[16:16] <jam> though there is a huge discussion on python-dev about how setuptools is not properly maintained, you should use "Distribute", etc.
[16:16] <vila> jam: it's a distro problem, OSX came with 2.5 and easy_install, I needed 2.6  and installed it from python.org, but no easy-install there :-/
[16:16] <jam> vila: http://pypi.python.org/pypi/setuptools#cygwin-mac-os-x-linux-other
[16:16] <jam> http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c9-py2.6.egg#md5=ca37b1ff16fa2ede6e19383e7b59245a
[16:35] <jelmer> jopong
[17:49] <jam> vila: https://code.edge.launchpad.net/~jameinel/bzr/2.1-pyrex-64bit/+merge/13292
[17:49] <jam> should fix your freebsd issues
[18:08] <jam> mthaddon: any progress on creating the pqm branches?
[18:08] <mthaddon> jam: I'm afraid I've been tied up with other things all day and am close to EOD - I should be able to get to it tomorrow if another losa hasn't by then
[18:10] <jam> k
[20:21] <davidstrauss> How can I get bzr-svn to not use the svn 1.4 client I have also installed?
[20:22] <jelmer> davidstrauss: make sure subvertpy is linked against the right vcersion of subversion
[20:22] <davidstrauss> jelmer: how can i do that?
[20:23] <jelmer> davidstrauss: when building subvertpy, make sure that it finds the deveopment files for the version of subversion you'd like to use
[20:23] <jelmer> you can override the svn prefix with the SVN_PREFIX environment variable
[20:23] <davidstrauss> jelmer: I'm not building it. I'm just using the Bazaar DMG installer
[20:24] <jelmer> davidstrauss: doesn't that come with its own copy of the svn libs then?
[20:24] <davidstrauss> jelmer: not sure
[20:24] <davidstrauss> jelmer: but it keeps complaining about needing a newer svn to use my working copies
[20:24] <davidstrauss> jelmer: I'm using svn 1.6 for my own work
[20:24] <jelmer> davidstrauss: I suspect you're out of luck in that case, I think a ndewer version of svn would have to be included in the DMG
[20:33] <lifeless> moinish
[20:39] <vila> . o 0 ( fullermd and his jokes...)
[20:45] <fullermd> Jokes?  Hm, I'm fresh out today.  Maybe there's one in the pantry somewhere...
[20:47] <vila> You tied my shoelaces earlier and when I stood up... all my PCs crashed (gee, even my macs....
[20:48] <vila> ... in fact the whole block suffered a power outage....
[20:48] <fullermd> Crap, you mean I missed the next block over?
[20:48] <fullermd> I'll try harder next time, I swear.
[20:48] <vila> ...so thank you very much all the same
[20:49] <vila> it took nearly an hour to get out of the power outage (ok 45 minutes, 4-5 m-i-n-u-t-e-s ! 2009 !
[20:49] <vila> :D
[20:49] <fullermd> http://www.absurdnotions.org/page18.html    :p
[20:49] <vila> add to that nearly an hour more to get an internet back
[20:50] <jam> hey vila, /wave
[20:50] <vila> url ? you think I can already use url ? All I have right now is a poor emacs irc client running on borrowed wifi (thank neighbour !)
[20:50] <vila> ha jam !
[20:50] <jam> ouch
[20:51] <vila> jam: Were you still connected ?
[20:51] <fullermd> Wait, you can use emacs?  I figure with your shoes tied together, you didn't have enough appendages available to use it...
[20:51] <jam> I went offline for the last... 30 min or so
[20:51]  * jam went to the coffee house
[20:52] <vila> jam: I crashed exactly 3 hours ago
[20:52] <jam> I saw your client go offline
[20:52] <vila> and 3 mintes
[20:52] <vila> jam: that was it, no more power
[20:53] <vila> jam: I won't restart the full monty until tomorrow, did you have anything important or was everything in your submission already ?
[20:53] <jam> vila: how big of an outage? (house/street/block/city)?
[20:53] <vila> block
[20:53] <jam> vila: I think everything is submitted
[20:53] <jam> no worries about babune et al
[20:54] <vila> jam: good, I won't be able to review it tonight either so if you need it for some release, nag the aussies :)
[20:54] <jam> no, I'm not releasing that code
[20:54] <vila> good
[20:54] <jam> I want it to bake in bzr.dev for most of a cycle
[20:55] <vila> so I can (untie my shoelaces first) enjoy my evening ;-)
[20:55] <jam> though I won't be releasing until a losa responds to my rt request for new branches anyway
[20:55] <jam> vila: absolutely
[21:06] <zsquareplusc> is there any good reason why "bzr explorer" does NOT open a view of the branch you started it in?
[21:13] <jam> zsquareplusc: 'bzr explorer .'
[21:14] <jam> igc knows why, my guess is that you have the option by specifying '.', that if you don't specify it, it is assumed maybe you want the generic start
[21:16] <mathepic> igc: Okay, I fixed that typo. Do I resend merge request or do I resend review request?
[21:16] <zsquareplusc> heh, i'd make an option for the generic start as i don't care --how-long-an-option-is-when-i-click-a-link. but ok, good to know about "."
[21:16] <lifeless> mathepic: just reply to the thread saying its fixed
[21:18] <mathepic> Okay, thanks.
[21:28] <mathepic> I accidently sent that second review request on my merge, can someone approve that?
[21:57] <mfer> hey folks. i was wondering if someone could point me to simple (one app install) for bzr explorer or another good mac gui
[22:01] <ToyKeeper> mfer: I've enjoyed bzr-gtk, but I don't know whether it works on a mac.
[22:02] <jam> mfer: it is 'being worked on'. PyQt is a major dependency on the Mac, because there isn't a pre-built version
[22:02] <jam> I'm not sure on the current state, but the 'bzr-mac' mailing list talks about getting one built
[22:03] <mfer> jam: PyQT is a huge pain of a dependancy
[22:03] <mfer> jam: thanks, i'll check out the mac list
[22:03] <ToyKeeper> Any idea how to merge revisions from a git repo?  Someone imported my head revision then made several changes, and I'd like to merge it without manually replaying each revision.
[22:04] <jam> bzr-mac@lists.launchpad.net
[22:04] <jam> I think it is a launchpad group
[22:04] <jam> https://edge.launchpad.net/~bzr-mac
[22:04] <ToyKeeper> bzr-git can browse and convert the repo, but I haven't had any luck merging.
[22:06] <ToyKeeper> 'bzr merge' by itself bails due to having no common ancestor, which makes sense.
[22:07] <ToyKeeper> 'bzr merge -r 1.. ../git-branch' does nothing and claims "All changes applied successfully."
[22:07] <ToyKeeper> 'bzr merge -c 2 ../git-branch' fails with a conflict (even though the patch applies cleanly).
[22:08] <beuno> ToyKeeper, why do you need to specify a revision?
[22:08] <ToyKeeper> This works, except for losing timestams, commit messages, and other metadata:  bzr diff -c 2 ../git-branch | patch
[22:09] <ToyKeeper> beuno: I'm specifying a revision because 'merge' by itself can't find a common ancestor.
[22:09] <ToyKeeper> I'd like to tell it "local rev 123 equals remote rev 1" somehow, then merge normally.
[22:09] <beuno> ToyKeeper, ahd, I *think* you can force it to merge with -r -1
[22:10] <beuno> or -r 0, I can't remember
[22:10] <jam> beuno: -r 0..-1, but he at least thought he was doing that
[22:11] <jam> ToyKeeper: you tried "bzr merge -r 1..-1" ?
[22:11] <mfer> jam: seems the mac ui isn't going to come soon from the main lists. Most are interested in bzr explorer for mac which is a pain to install with the 140MB/3 dependencies you have to install first. and, the mac ui is only slowly being developed.
[22:11] <jam> that *might* be equivalent to -r 1..
[22:12] <ToyKeeper> jam: Similar result as '-c'; it thinks there's a conflict.
[22:13] <jam> ToyKeeper: are you sure there isn't a conflict?
[22:14] <ToyKeeper> The resulting commit is basically the same as if I had just rsync'd the content; no metadata or record of any intermediate revisions.
[22:14] <jam> ToyKeeper: so if you did '-r 0..' then it would record a merge
[22:14] <fullermd> If merge can't find a common ancestor itself, you're probably going to end up with a bit of a mess...
[22:14] <jam> but by doing a named rage
[22:14] <jam> range
[22:14] <ToyKeeper> There isn't a conflict.  Everything applies cleanly if I "diff | patch" each rev.
[22:14] <jam> then we are considering that to be a cherrypick
[22:14]  * ToyKeeper tries again from 0
[22:14] <jam> ToyKeeper: diff + patch a series of patches can still conflict on the endpoints...
[22:15] <jam> but I won't say it has to here
[22:15] <jam> you might try just merging and rejecting the first revision, to create a common ancestor
[22:15] <jam> and then applying from there
[22:15] <jam> (bzr merge -r 0..1; bzr revert .; bzr commit -m 'sync at the first rev')
[22:15] <jam> then again
[22:15] <jam> my guess is you are getting conflicts because of file-id differences
[22:16] <jam> but I can't guarantee that
[22:21] <ToyKeeper> jam: The last approach worked: merge -r 0..1 ; revert ; commit ; merge
[22:22] <ToyKeeper> I don't think I would have tried that.
[22:28] <ToyKeeper> Other than that bit of weirdness with merging, the git support works impressively well.  :)
[22:48] <ToyKeeper> D'oh.  "different rich-root support" made my coworker give up and go back to git.  :(
[22:50] <ToyKeeper> Perhaps I'll wait until most people have bzr 2 before trying again.
[22:51] <fullermd> You can use rich-root-pack on anything newer than 1.0.
[23:38] <ToyKeeper> fullermd: Yes, it just didn't happen that way and I think the guy was looking for an excuse to stop using bzr.  I guess I can't expect much else from kernel devs.
[23:56] <lifeless> the rich root transition hurts