[00:38] <poolie> hi all
[00:39] <jelmer> hellø!
[00:43] <poolie> hi jelmer
[00:49] <knighthawk> jelmer are you still here?
[00:50] <jelmer> knighthawk: yeah, though not for much longer
[00:51] <knighthawk> In my bzr branch I ran 'bzr rebase'
[00:52] <knighthawk> it was pointing to my svn repo
[00:52] <knighthawk> but this was *after* I did the push with append_revisions_only = False
[00:54] <knighthawk> so I'm worried now that I can't recover the history in svn with --overwrite. Also mind you several other people have made commits to the svn repo since I did all this.
[00:54] <knighthawk> so I'm thinking that history might just be lost.
[00:55] <jelmer> knighthawk: the history is still there - see 'svn log <repos-history>'
[00:56] <jelmer> knighthawk: it will be tricky to get both the old revisions and the new revisions though
[00:56] <knighthawk> k jelmer thanks I'll try to figure it out.
[01:01] <spiv> Morning.
[01:05] <jelmer> hey spiv, how's your morning?
[01:07] <spiv> Pretty good considering V woke up at least 4 times last night!
[01:07] <poolie> hi spiv, ocuh
[01:07] <poolie> *ouch
[01:08] <spiv> We think it's his molars coming through
[01:08] <spiv> Well, we can see that they are, but we're guessing that's why he's waking up so often.
[01:13] <poolie> hm, we probably need jubany to be upgraded to something with 2.6 if we require that in 2.5
[01:13] <poolie> bzr *2.4
[01:14] <jelmer> spiv: :-/
[01:21] <mgz> what's the planned release date for bzr 2.4?
[01:22] <poolie> for the final one?
[01:22] <mgz> yup.
[01:22] <poolie> lp currently has 4 august
[01:22] <poolie> the general thing is, about 2 months before the ubuntu release
[01:23] <poolie> it can be flexible
[01:27] <spiv> Regarding jam's comment on https://bugs.launchpad.net/bugs/267296, I wonder if we should have a "needs-piloting" tag?  Patch pilots could search for that bug tag in addition to scanning the +activereviews page.
[01:28] <spiv> Ideally LP would have some way of bringing partial work to our attention, but that might be an ok workaround.
[01:34] <poolie> spiv, well, that's kind of what the 'has patch' thing is meant to track
[01:34] <poolie> but it is not a very good match for a few reasons
[01:34] <poolie> well, not a perfect match
[01:34] <spiv> Right
[01:36] <spiv> I suppose that particular branch can been seen on https://code.launchpad.net/~bzr-pqm/bzr/bzr.dev/+merges?field.status=WORK_IN_PROGRESS too
[01:37] <spiv> It'd be nice to see that list of w-i-p branches ordered by the importance of the bug they are linked to (if any).
[01:39] <spiv> (Or perhaps if advanced bug search could specify “show only bugs with linked merge proposals with status X”)
[01:43] <poolie> mm
[01:43] <poolie> i don't think i touched any code yesterday
[01:43] <poolie> hope to do better today
[06:19] <poolie> spiv is it possible that bug 390745 would be covered by your repack refactoring?
[06:25] <spiv> poolie: hmm!
[06:25] <poolie> i realize it's a bit hard to say since we don't know exactly what leads up to it
[06:25] <spiv> poolie: it might, but it's hard to be certain
[06:25] <spiv> It's probably the best hypothesis we have so far
[06:52] <lifeless> poolie: bug 664242 may not be one you want closed
[06:53] <poolie> thanks
[06:53] <poolie> i wonder how it even got incomplete
[06:53] <lifeless> you filed it that way
[06:53] <poolie> mm so it seems
[06:53] <poolie> i don't normally do that
[06:54] <poolie> did launchpad just decide to start catching up on expiry?
[06:54] <lifeless> we just fixed a bug
[06:54] <poolie> oh a bug was fixed that was blocking it?
[06:54] <lifeless> yeah
[06:54] <poolie> jolly good
[06:54] <lifeless> thats why it worked for a week or so
[06:54] <lifeless> then broke
[06:54] <lifeless> the bug is fixed
[06:54] <lifeless> the bug that stopped us knowing is also fixed.
[07:08] <poolie> oh, lifeless, is the maverick-proposed bzr working out ok?
[07:08] <poolie> i didn't hear any screaming
[07:08] <lifeless> i've had one of those days
[07:09] <poolie> with no code?
[07:09] <poolie> sorry to hear that
[07:09] <poolie> let me know if anything does break
[07:10] <lifeless> 6am starts make me a little slow
[07:10] <lifeless> I spent a ridiculous chunk of time tracking down some test failures in my branch to store INCOMPLETE_WITH_RESPONSE in the db
[07:11] <lifeless> culminating with finding that we expire bugs to which the user has replied - https://help.launchpad.net/Bugs/Expiry#Old, unattended and incomplete?
[07:11] <poolie> ouch
[07:12] <lifeless> I had naively assumed that replying prevents expiry
[07:12] <poolie> i would have too
[08:26] <poolie> hi jam!
[09:32] <gour> morning
[09:32] <gour> there is no bzr-svn for bzr-2.3?
[09:42] <poolie> hi gour
[09:42] <poolie> i think there is
[09:42] <gour> but not released?
[09:42] <poolie> 1.0.3?
[09:43] <gour> "1.0.4 (works with Bazaar 2.2)"
[09:44] <gour> http://wiki.bazaar.canonical.com/ForeignBranches/Subversion#releases
[09:49] <poolie> ah, yes
[09:49] <poolie> it is 1.0.4 and it is not released yet
[09:49] <poolie> i think jelmer is planning to make one soon, but he should be online in a bit
[09:51] <poolie> ok, good night
[09:52] <gour> 'night poolie
[12:21] <jelmer> hi jam
[12:37] <jam> hi jelmer
[12:37] <jam> by the way, I was agreeing with you on bug #317357
[12:37] <jam> I was just also letting Federico know that his patch had landed
[12:38] <jelmer> jam: Ah, thanks. I read the emails out of order, that must be what confused me.
[12:39] <Bersam> Hi everybody! how can i get an old version from bzr? "$bzr co lp:appname1.0" wont work!
[12:39] <jelmer> Bersam: you can use tags - "bzr branch -rtag:bzr-1.0 lp:bzr bzr-1.0"
[12:40] <Bersam> jelmer: thanks :)
[21:49] <Jordan_U_work> Whenever I try to "bzr branch" from one of the branches I recently created it creates a branch without any checkout and I need to run "bzr checkout" to actually work with the files. Why is this happening but when I for instance "bzr branch lp:grub2" I get a branch with a checkout?
[22:05] <maxb> Jordan_U: Please could you run "bzr info" within the problem branch and pastebin the result?
[22:08] <Jordan_U> maxb: http://pastebin.com/ymzLpshR
[22:09] <maxb> Jordan_U: A shared repository, amongst other things, contains a flag to set whether new branches default to having working trees or not
[22:09] <maxb> As your info shows you are indeed within a shared repository, I imagine that that setting is to not create trees at present
[22:10] <Jordan_U> maxb: Ahh, indeed I always use shared repositories. How can I change this flag?
[22:10] <maxb> bzr reconfigure --with-trees / --with-no-trees
[22:11] <Jordan_U> maxb: Thank you.
[22:11] <maxb> The odd thing is the default is with trees, so something or someone must have switched it off explicitly
[22:13] <Jordan_U> I only installed bzr on this machine recently, from Ubuntu 10.10 repositories. I don't remember ever changing this setting. It's possible I had bzr installed some months / years ago and removed it again but these repositories and branches were all created recently.
[22:16] <fullermd> At one time init-repo defaulted to no-trees.
[22:17] <fullermd> That was a loong time ago though.
[22:17] <fullermd> grep of release notes says it went --trees in 0.15.
[22:18] <fullermd> (i.e., 4 years and a month ago)
[22:21] <Jordan_U> Maybe I do remember specifying --no-trees, though i can't remember why.
[22:22] <fullermd> A little deforestation is good for the soul.
[22:22] <Jordan_U> Ahh, I was in a hurry and just followed the example in "bzr help init-repo" which uses --no-trees.
[23:05] <jelmer> moin
[23:39] <magcius> oh man
[23:39] <magcius> you know what I *love* about bzr?
[23:39] <magcius> "bzr: ERROR: Unable to create symlink 'standard_test_template.py' on this platform"
[23:40] <magcius> so instead of doing the sane thing, you just fail. And leave me with a .bzr dir.
[23:44] <maxb> Patches gratefully accepted? :-)
[23:47] <magcius> hasn't NTFS supported symlinks since like 1994?
[23:49] <jelmer> magcius: That support isn't exposed in the Python API IIRC
[23:53] <mgz> or in windows.
[23:53] <mgz> the failure mode sucks, but so do most of the reasons people version symlinks.
[23:54] <magcius> You can just copy the file instead of leaving me with ".bzr", though
[23:54] <mgz> I would if I could, magcius.
[23:55] <mgz> checking out from within cygwin is the best workaround I've found.