[00:00] <maxb> Do we know the estimated release date of bzr 2.4 yet?
[00:01] <maxb> aligned with Ubuntu o-series?
[00:02] <poolie> maxb: yes, ~2 months before Otty
[00:02] <abentley> jelmer, ping
[00:02] <poolie> so august
[00:03] <poolie> maxb: nod for 2.1
[00:03] <poolie> on the phone at the moment
[00:07] <lifeless> jelmer: I'm curious what adding tags like ssh to bugs with ssh in the title helps with
[00:17] <jelmer> abentley: hi
[00:17] <jelmer> lifeless: being able to find bugs that are related to ssh (as opposed to bugs that happened to occur over ssh)
[00:18] <abentley> jelmer, I was having trouble testing bzrtools under 2.7 due to https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/654826 but I think I've got it licked.
[00:19] <jelmer> abentley: ah, cool
[00:21] <poolie> maxb, thanks for your mail; that's fine with me
[00:27] <dOxxx> anybody familiar with qt around here?
[00:27] <dOxxx> and pyqt?
[00:27] <dOxxx> I have a very perplexing error with a most unhelpful traceback: TypeError: 'sip.methoddescriptor' object is not callable
[00:34] <maxb> poolie: great - when the change lands on 2.1, I'll put up a MP for merging 2.1 into 2.2, and so on and so on
[00:35] <spiv> dOxxx: sounds like something somewhere is trying to invoke a method on a class rather than an instance.
[00:35] <dOxxx> spiv: so this is where the traceback is unhelpful or, very weird:
[00:36] <dOxxx> Traceback (most recent call last):
[00:36] <dOxxx>   File "C:\dev\qbzr\mergetools\lib\commands.py", line 175, in run
[00:36] <dOxxx>     ret_code = getattr(main_window, "return_code", None)
[00:36] <dOxxx> i.e the getattr is triggering the error
[00:36] <spiv> Perhaps main_window.return_code is property?
[00:36] <spiv> s/is/is a/
[00:37] <dOxxx> spiv: the only mention I can find of it assigns it as a normal instance attribute
[00:37] <dOxxx> I suspect that this is due to a recent change in sip
[00:37] <dOxxx> "Added support for the __getattribute__, __getattr__, __setattr__ and __delattr__ methods."
[00:37] <spiv> Hmm, could be.
[00:40] <dOxxx> SubProcessWindowBase(object) sets the return_code field, but then getattr is being called on SubProcessWindow(SubprocessWindowBase, QBzrWindow). So I'm guessing mixing in the Qt class is breaking the getattr
[00:40] <dOxxx> ugh
[00:40] <dOxxx> and naturally RiverBank Software doesn't provide older versions of PyQt for download.
[00:40] <dOxxx>  /facepalm
[00:44] <poolie> hi spiv
[00:47] <spiv> Hi poolie
[01:02] <poolie> spiv, is there an RT for the production changes for bug 702024?
[01:02] <ubot5> Launchpad bug 702024 in Launchpad itself "Restarting codehosting SSH server drops existing connections" [High,In progress] https://launchpad.net/bugs/702024
[01:07] <lifeless> poolie: yes
[01:07] <lifeless> poolie: its 4th from top
[01:07] <lifeless> 40480
[01:10] <poolie> got it thanks
[01:10] <poolie> just talking to spm about making it more concrete
[01:11] <lifeless> poolie: FWIW I'll be driving it through
[01:12] <lifeless> its right in the middle of the nodowntime project
[01:12] <poolie> great
[01:13] <poolie> i'm just trying to make sure things don't drop
[01:13] <poolie> there is a gap between the code train and the losa platform
[01:13] <lifeless> I'm glad you're interested
[01:13] <lifeless> I don't really see that gap
=== AfC1 is now known as AfC
[03:59] <lamont> https://launchpad.net/~bzr/+archive/beta <-- why no dapper love here?  it's still got 4 months of support left.....
[04:01] <lamont> so... given 2.3.0~beta5... how can I tell if someone has already run "bzr whoami --branch" ??
[04:06] <poolie> lamont, cat .bzr/branch/branch.conf
[04:06] <lamont> poolie: my fallback was: if grep -q "^email " .bzr/branch/branch.conf
[04:06] <poolie> lamont, do we still have dapper machines active?
[04:07] <lamont> no
[04:07] <lamont> that was mostly troll
[04:07] <poolie> k
[04:07] <poolie> "why no hppa builds? :-("
[04:08] <lamont> they were running hardy
[04:08] <lamont> bzr init causes branch.conf to be created, yes?
[04:14] <poolie> yes
[04:16] <lamont> see /pm?
[06:35]  * spiv wonders if doc.bazaar.canonical.com is slow because of connectivity woes or if it's actually just really slow
[06:41] <spm> spiv: i think something funky with au internets is up tbh. I'm seeing odd slowness and pauses... everywhere.
[07:25] <vila> hi all !
[07:29] <fullermd> 'morning.
[07:32] <vila> yeah, Open bugs # went below 1900, well done jelmer :)
[07:33] <fullermd> Ooh.  Does that mean I need to break more things?
[07:33] <vila> Not necessarily :) But we should be able to catch you faster :-p
[07:40] <vila> spiv: pfew, I'm glad this was relevant, somehow I felt I was using only bad medias to convey this piece of wisdom to you (IRC while you were asleep, bug comment during jelmer flood, etc ;)
[07:55] <spiv> vila: I cope ok with message floods, apparently :)
[07:56] <spiv> Open bugs below 1900?  Way to go robot^Hjelmer!
[07:57] <vila> ;)
[08:15] <maxb> https://code.launchpad.net/~maxb/bzr/launchpadlib-service-root-api-compat/+merge/47885 is "review approved" but not "merge approved" - anyone got a moment to click it over to approved and send to pqm?
[08:17] <poolie> sure
[08:18] <poolie> maxb, do you have access?
[08:18] <maxb> pqm? no
[08:18] <poolie> if you're sure the consensus is it's approved, feel free to set it yourself
[08:18] <poolie> i'll feed it in now
[08:18] <maxb> well, I'm basing the conclusion on your irc comment :-)
[08:21] <poolie> ok, it's running
[08:21] <poolie> thanks for persisting
[08:26] <maxb> np :-)
[08:27] <maxb> Just want to get started on the 3 subsequent merges to higher series whilst it's all fresh in my mind
[08:27] <maxb> and thanks for the reviewing
[08:27]  * maxb returns to monster bugmail inbox :-)
[08:29] <vila> . o O (monster... says the user from jabberwock...)
[08:30] <poolie> hi vila
[08:30] <poolie> indeed
[08:30] <vila> hey poolie,so, 2.2.3 is in -proposed ?
[08:30] <vila> :)
[08:30] <poolie> sadly not today
[08:31] <poolie> the rts moved along a lot though, as did my understanding of how that would work
[08:31] <vila> ELINK
[08:31] <poolie> we have some rt tickets open asking for deployment of a few things
[08:31] <poolie> like forking lp-serve
[08:32] <vila> ha !
[08:32] <poolie> i think they are now more likely to ascend into heaven
[08:32] <vila> the holy bitbucket ?
[08:33] <poolie> so that plus weeding out a thousand mails
[08:33] <jelmer> hey poolie, vila
[08:33] <vila> Look at the bright side: this bits will reincarnate in even better software :-}
[08:33]  * jelmer ducks
[08:33] <poolie> i hope you have a good view of them in your head now
[08:33] <poolie> if you do, that's great
[08:34] <poolie> i don't know if retagging for the sake of it is all that good
[08:34] <poolie> finding dupes is good though
[08:34] <poolie> and already-fixed bugs
[08:34] <poolie> and our open-bugs graph dipped noticeably
[08:34] <jelmer> poolie: The flood of email is a bit unfortunate :-/
[08:35] <poolie> that's the only problem with it really
[08:35] <poolie> a web dashboard would be better
[08:35] <poolie> especially if it had a concept of a 'seen' bit
[08:37] <vila> yup, nice dips on the graphs
[08:39] <vila> as a rough estimate I think if jelmer can continue at this rhythm, he should finish in ~1 month ;D
[08:39] <maxb> Actually as a result of the flood of email I've noticed one bug is closable and another is probably easily fixable by me
[08:39] <maxb> So it has its upsides too :-)
[08:39] <poolie> it's kinda useful to see old bugs again
[08:39] <poolie> i'm not sure if the ratio is worthwhile
[08:39] <poolie> i'm getting to the bottom of my mailbox and seeing robert's preceding flood
[08:39] <poolie> i am Queensland :)
[08:44] <jelmer> :)
[08:46] <poolie> ok i'd better go
[08:46] <poolie> have a good day
[08:47] <jelmer> thanks, have a nice evening :)
[08:47] <vila> have a nice evening poolie
[09:31] <maxb> oh headdesk
[09:31] <maxb> this maverick SRU is having a cursed life
[09:32] <maxb> 2.2.3 has a regression in the launchpad plugin
[09:35] <jelmer> maxb: :(
[09:43] <vila> maxb: which one ?
[09:44] <vila> I was pretty sure I ran all the tests for 2.2.3...
[09:49] <maxb> vila: But there are no tests that exercise talking to launchpad, are there :-/
[09:50] <vila> maxb: shudder.. no :-/
[09:50] <vila> maxb: what is the regression ?
[09:52] <maxb> it doesn't work. period
[09:53] <lifeless> that sounds like a regression
[09:53] <maxb> AFAICS, anything that tries to talk to the launchpad web service just fails, because the URLs are wrong
[09:55] <vila> maxb: check your settings, the babune maverick slave uses 2.2.3 and pull from lp every day
[09:55] <lifeless> vila: pull != web service
[09:56] <vila> lifeless: with launchpad_username set ?
[09:56] <maxb> launchpad_username is not relevant here.
[09:57] <maxb> We mean "bzr lp-propose" and friends, which authenticate over oauth
[09:57] <vila> then be more specific, lp: is resolved by the lp plugin
[09:57] <maxb> yes, but not via the web service :-)
[09:57] <maxb> that goes via the xmlrpc service :-)
[10:01] <vila> then what goes via the web service ?
[10:02] <maxb> lp-mirror, lp-propose, lp-find-proposal
[10:03] <maxb> The launchpad plugin is a bit scary
[10:03] <maxb> There's the legacy bits which go via the xmlrpc interface in lp_registration.py
[10:04] <maxb> Then there are the new bits going via the lazr.restful service
[10:04] <maxb> And then there is the checking of lp-login, which goes via the web *site*
[10:05] <maxb> Oh, and for further confusion, any attempt to use the lazr.restful service first starts by instantiating an xmlrpc service object in order to obtain the launchpad instance name from
[10:05] <maxb> mad mad mad
[10:05] <fullermd> All we need to do is add an EDI interface now...
[10:07] <vila> lp-propose seems to be working from here
[10:09] <maxb> that's odd. Is it possible that it's only obtaining a new oauth token that's broken?
[10:09] <vila> ha, no, the infamous '1.0'
[10:19] <vila> maxb: bug #707075, err wait, you're already the assignee
[10:19] <ubot5> Launchpad bug 707075 in Bazaar "lp-propose fails with a 404 error" [Undecided,In progress] https://launchpad.net/bugs/707075
[10:21] <vila> maxb: but then it's not a regression, the bug has been there for quite some time no ?
[10:22] <vila> maxb: or was it triggered recently by some lp change ?
[10:25] <vila> maxb: in any case, this doesn't sound like a good reason to delay 2.2.3 SRU, this *won't* be fixed in 2.2.3, this *can* be fixed in 2.2.4
[10:27] <vila> maxb: ha, right, just got your mail for the mp
[10:37] <vila> maxb: I can reproduce the bug with 2.2.2, so that's not a regression
[10:37] <maxb> *blink*
[10:37] <maxb> what?
[10:37] <maxb> But, the edge service root was correct?!
[10:38] <vila> hence the suspicion against lp itself
[10:38] <maxb> no, the bug does not reproduce with 2.2.2 here
[10:39] <vila> *blinks*
[10:39] <vila> Oh ! wrong terminal :-/ Sorry
[10:39] <maxb> The bug always existed in the url config within bzr for talking to lp production - but not edge. Therefore, it only became a problem when we switched to talking to production
[10:40] <vila> ha !
[10:40] <maxb> Ultimately I blame launchpadlib for doing a sucky job of api compatibility
[10:42] <vila> maxb: approved with a tweak. ping me when I can land
[10:43] <maxb> vila: hmm. I kind of said that in the NEWS already?
[10:43] <vila> maxb: not the bit about *production*  url config being broken
[10:44] <vila> but not edge
[10:44] <vila> I didn't understand until you mentioned that
[10:44] <maxb> "This was a regression exposed by the switch away from Launchpad's edge platform, in bzr 2.2.3." was my attempt to explain that difference
[10:45] <vila> yes, but at first I was wondering why edge has been working but not production
[10:45] <vila> the answer is that production never worked but wasn't used
[10:46] <vila> which in turn explain why switching away from edge exposed the bug
[10:46] <maxb> ok, how about "This was a latent bug in bzr's communication with Launchpad's production instance, which only became a problem when the default instance was switched from edge to production in bzr 2.2.3." ?
[10:46] <vila> perfect !
[10:48] <vila> maxb: and this can't be fixed in 2.0 why ? (I'm sure you mentioned it but can't find it back)
[10:49] <vila> lp_api didn't exist in 2.0
[10:50] <maxb> yup
[10:50] <maxb> plus, the bug doesn't trigger with the launchpadlib in karmic, either
[10:50] <vila> >.<
[10:50] <vila> yeah for early adoption ;)
[10:51] <maxb> vila: pushed, though lp is being sluggish about updating the mp diff
[10:51] <vila> yup
[10:52] <vila> but good enough to feed pqm
[10:52] <vila> done
[11:09] <maxb> woot, thanks
[11:10] <maxb> i'll do 2.2 -> 2.3 at lunch
[11:24] <vila> maxb: cool
[12:11] <jml> jelmer: hi
[12:12] <jml> jelmer: if you have commented on a bug in the last day or so and have desired me to read it, can you let me know explicitly? I've been a little bit zealous in archiving bug mail from you recently.
[12:45] <AfC> Why is everyone complaining about bugmail from Jelmer?
[12:45] <maxb> Obviously you're not subscribed to bzr bugmail :-)
[12:46] <maxb> He is on a tagging/triaging rampage :-)
[12:46] <maxb> I skimmed 450 bugmails this morning
[12:46] <AfC> Crtl+A Ctrl+D baby
[12:47] <AfC> "Internet Kill Switch" :)
[13:20] <jelmer> jml: hi
[13:20] <jelmer> jml: No, there wasn't anything in the last day.
[13:30] <jml> jelmer: thanks.
[13:32] <mgz> "71 messages edited tags only and were marked as seen"
[13:33]  * mgz does an evil laugh
[13:34] <mgz> worth it too, got one more bug marked fixed from reading the ones that actually included comments.
[13:56] <mgz> bug 523989 is annoying. launchpad should just normalise the field.
[13:56] <ubot5> Launchpad bug 523989 in Launchpad itself "=C2=A0 cluttering the mailed diff when changing a bugs description" [Low,Triaged] https://launchpad.net/bugs/523989
[15:01] <AdamDV> How can I resolve/clear all conflicts? I have a bunch (around 20) conflicts that were just due to some stupid line changes, and I've since fixed the files and deleted the .moved .tTHIS .OTHER etc. Went to commit, and it says theres conflicts.
[15:04] <mgz> `bzr resolve`
[15:17] <maxb> Suppose I wanted to make an incompatible API change in bzr.dev within bzrlib.plugins.launchpad.lp_api - would that be ok?
[15:18] <maxb> or should I care about maintaining compatibility
=== oubiwann is now known as oubiwann_
=== zyga is now known as zyga-food
=== beuno is now known as beuno-lunch
=== zyga-food is now known as zyga
[16:39] <vila> maxb: you should care :-}
[16:44] <maxb> vila: for code in a plugin?
[16:44] <maxb> I guess to phrase it another way: does anyone know of bzr plugins *depending* on the bzr launchpad plugin
[16:45] <vila> no idea, but not knowing what compatibility you want to break, I tell you the rule :)
[16:48] <maxb> lp_api.login parameters, basically
[16:48] <maxb> But, I could get around it by having a parameter that can either be a lp_registration.LaunchpadService (old) or a string (new)
[16:48] <maxb> so I should do that
[16:49] <maxb> I suppose
[16:49] <vila> yup and deprecate the former
[17:21] <vila> james_w: so, I'm back to the timeout problem. The issue is trying to get the published sources since the last import,
[17:22] <james_w> and given there was no last import that's going to be a lot of sources
[17:22] <vila> exactly
[17:23] <vila> and since the API provides only create_since_date, we're doomed
[17:23] <vila> that's your primary source for package names right ?
[17:24] <james_w> it's supposed to use very small batches, but I guess the reduction in timeout means that either those batches aren't small enough again, or that the overhead is so high that the batch size doesn't matter
[17:24] <james_w> that's the primary source of new uploads
[17:24] <james_w> there is list_packages.py to just get package names, but it uses the same APIs
=== Ursinha is now known as Ursinha-lunch
[17:25] <vila> james_w: well, in my case, there never was a successful import so that's *all* published sources
[17:25] <vila> hehe
[17:25] <james_w> right
[17:25] <james_w> so you could claim there was an import 10 minutes ago
=== beuno-lunch is now known as beuno
[17:26] <vila> right and that will catch up.... at O time ;)
[17:27] <vila> good enough for my tests but we won't be able to start an importer from scratch, may not be a big deal but I should still file a bug about it I think
[17:30] <maxb> vila: As far as providing an import service, importing new services from a specific date would be fine. So, you'd need to combine that with some other routine which compared latest-publication-in-archive with latest-publication-in-branch for all published packages
[17:31] <maxb> And, you'd only need to do that if you felt you couldn't just allow people to notice out-of-date imports
[17:31] <vila> maxb: the issue here is to establish the list of package names without lp blowing up
[17:31] <maxb> vila: cheat and download the apt Sources files? :-)
[17:32] <vila> *blink*
[17:32] <vila> they are downloaded... but when
[17:33] <maxb> I'm suggesting that if you wanted to bootstrap an importer you would download the Sources file for each distro-pocket and force an individual importer run for each discovered package name
[17:33] <vila> maxb: doesn't sound like cheating to me... but a good way to seed an importer. *Then* it can rely on published sources to discover the new ones, james_w ? sounds correct ?
[17:33] <vila> maxb: got you
[17:34] <maxb> But, you would only need to do this to catch imports missed by the importer installation you were replacing
[17:36] <maxb> james_w: btw, might you have a chance to consider bug 694818? It relies on getting "what's actually useful in production" knowledge from your head :-)
[17:36] <ubot5> Launchpad bug 694818 in Ubuntu Distributed Development "Bitrotted scripts in UDD import-scripts source tree" [Undecided,New] https://launchpad.net/bugs/694818
[17:55] <james_w> vila, that's what I did when I started it
[17:55] <james_w> maxb, I saw it, does it need input from me?
[17:55] <james_w> I think it's a good idea
[17:55] <james_w> you want to know which ones can be deleted?
[17:56] <maxb> james_w: I was assuming you were the best person to rule what was obsolete and what might need updating to work with the new store
[17:56] <maxb> I thought you might be holding on to some bits intending to update them when you next needed them
[17:57] <james_w> I'll take a look
[17:57] <james_w> basically if they haven't been updated yet then they aren't useful :-)
[17:58] <maxb> thanks
[18:30] <lamont> BZR_PLUGINS_AT=bzrtools@/build/buildd/bzrtools-2.3.0 /usr/bin/bzr selftest -s bp.bzrtools
[18:30] <lamont> bzr: ERROR: Couldn't import bzrlib and dependencies.
[18:30] <lamont> I suspect that bzrtools has missing build-deps
[18:31] <lamont> where does bzrlib come from?
[18:32] <lamont> seems to be "bzr"
[18:33] <lamont> james_w: any chance you want to look at a buildlog for me?
[18:34] <maxb> iiuc, the bzr script is supposed to execute in a python which has bzrlib and friends in its library directory
[18:34] <tsdh> Hi. On http://doc.bazaar.canonical.com/plugins/en/pager-plugin.html a pager plugin is listed for bzr.  I'd really like to use that.  But the homepage that is linked from there contains only an empty directory.  Is there another way to get it?
[18:35] <maxb> tsdh: The "empty directory" is actually a bzr branch
[18:36] <tsdh> maxb: Oh, so I should clone that URL to get the plugin?
[18:36] <maxb> yes
[18:38] <tsdh> Yep, that does the trick.
[18:38]  * tsdh feels like an idiot...
[18:39] <LeoNerd> Most webservers just don't display the .bzr directory in the bare index page
=== Ursinha-lunch is now known as Ursinha
[19:50] <jaypipes> hi all, does bzr docs have anything similar to http://www.kernel.org/pub/software/scm/git/docs/git-check-ref-format.html? I'm trying to get a difference of what a bzr branch/tag name can contain vs. a git tag name...
[19:58] <lifeless> jaypipes: tags are unicode pretty much anything except newlines and 0x00
[20:00] <james_w> lamont, sure
[20:01] <lamont> james_w: figured it out
[20:01] <lamont> totally my fail
[20:01] <james_w> ok
[20:03] <lamont> which was complicated by the hardy version working despite my screwup
[20:04] <jaypipes> lifeless: cheers. thx Robert
[20:08] <lifeless> lamont: hey
[20:08] <lifeless> lamont: so if you're playing with packages ATM; whats the current python-subunit in CAT?
[20:11] <lamont>    subunit | 0.0.6-1~bazaar1.0.IS.8.04 |     hardy-cat | source, all
[20:12] <lamont> which interestingly means all of the lucid boxes have 0.0.5-1
[20:13] <lamont> unless the machine was upgraded.
[20:14] <lifeless> lamont: yeah, this is breaking praseodymium pretty hard.
[20:14] <lifeless> lamont: We need 0.0.6 for lucid
[20:15] <lamont> lifeless: I take it this is you saying "that needs to be fixed, promote 0.0.6-1~bazaar1.0.IS.8.04 to lucid-cat"?
[20:16] <lifeless> lamont: is it that easy?
[20:16] <lamont> actually, we have 10.04 version in lucid-cat-proposed --> trivial
[20:16] <lamont> if I upgrade it on pras, can you tell that it's all better trivially?  (and is it broken enough to jfdi?)
[20:16] <lifeless> lamont: there may be a dep on testtools, but I imagine your toolchain will take care of whinging if you're going ot break stuff
[20:17] <lifeless> lamont: its broken enough that whenver a pqm merge fails, pqm barfs to stderr, packs its toys up, and goes home.
[20:17] <lamont> lifeless: chroot or in the real root?
[20:17] <lifeless> lamont: real
[20:17] <lamont> not pqm dchroot?
[20:18] <lamont> so... upgraded in the real root
[20:19] <lamont> 0.9.6-0~bazaar1.0.IS.8.04 <-- python-testtools came for the ride
[20:19] <lifeless> lamont: sweet, thank you!
[20:20] <lifeless> mbarnett: ^ I think we just saved you a bunch of time
[20:20] <lamont> mbarnett: and poke me about testing and such before I make that global, kthx
[20:21] <lifeless> lamont: to test it I'll get a broken merge thrown at pqm from lp
[20:21] <lifeless> lamont: I'm sure it will be no worse than it was
[20:22] <lamont> heh. thanks
[20:22] <lamont> pls do though
[20:23] <lifeless> lamont: I'm arranging that now in #launchpad-dev
[20:23] <lifeless> lamont: the basic symptom has been we go into testfix, merge disappears
[20:24] <lamont> nice
[20:24] <lamont> for eye-stabbing values of "nice"
[20:24] <lifeless> right
[20:24] <lifeless> and pqm mails out a whine to the errors list
[20:25] <lifeless> pqm-errors or something; its where pqm's cron mails to
=== Ursinha is now known as Ursinha-bbl
[21:12] <mbarnett> lifeless: whee!
=== zyga is now known as zyga-nc10
[22:11] <poolie> hello all
[22:12] <jelmer> g'morning poolie
[22:12] <poolie> hi jelmer
[22:15] <lamalex> Hey, I've sort of backed myself into a spot I'm not sure how to get out of. I merged a branch into mine, and as I was typing bzr commit to commit the merge, i got a kernel panic and had to reboot. I forgot to commit when i came back and have been hacking for quite a while with all of those changes from the merge uncommited
[22:16] <lamalex> i want to separate my changes from the merge, is there any way to really do this?
[22:17] <lamalex> and  my other question is why doesn't bzr just do a commit after a successful merge?
[22:17] <fullermd> Well, you could make a copy of the branch and redo the merge by itself...   then try pushing that new rev onto your existing branch and seeing if update DTRT, or try using merge --uncommitted the other way, or do a manual diff of the working trees...
[22:24] <poolie> lamalex, what i would do is:
[22:24] <poolie> make a second working directory, re-do the merge in there, commit that
[22:24] <poolie> pull that into your original working directory
[22:24] <lamalex> poolie, that's what I did
[22:24] <lamalex> well, maybe
[22:24] <poolie> that will insert the merge revision underneath your later changes
[22:25] <poolie> and then only the later changes will be seen as uncommitted
[22:25] <poolie> great
[23:38] <Noldorin> how can i find out what branch the working copy is currently bound to>?
[23:45] <bob2> bzr info