[00:02] <mwhudson> oh
[00:02] <mwhudson> i guess my branch copying over vfs can screw this up
[00:03] <mwhudson> jelmer: does bzr info -v on a locked branch tell you about the lock?
[00:04] <jelmer> mwhudson: I'm not sure, I don't think t does
[00:04] <jelmer> *it
[00:49] <peitschie> hi... i was wondering if anyone might have the time to help me attempt to adapt https://code.launchpad.net/~spiv/bzr/chk-canonicalizer-613698/+merge/32294 to be targetable to specific revision set?  I have a repo that has been reconciled for all revisions bar 2 new ones which were accidentally checked in using a broken revision history... which is now sinking the shared repo again
[00:53] <mkanat> peitschie: Do you think it would be a good idea to write a pre_change_branch_tip hook that rejects commits if they're going to do that to your repo?
[00:54] <peitschie> mkanat: it'd likely have been useful if I'd anticipated it :)
[00:54] <mkanat> peitschie: Yeah. I just mean since you indicated in your email that this sort of thing happens all the time.
[00:54] <peitschie> mkanat: at this point though, reconciling and repairing the broken revs are my top priority
[00:54] <mkanat> peitschie: Sure, I understand that. (I don't know much of anything about that area, though, so I can't help there.)
[00:54] <peitschie> mkanat: not all the time :)... just since the update
[00:56] <mkanat> peitschie: Ah, okay. :-)
[07:21] <vila> hi all !
[07:22] <mgz> morning vila!
[07:22] <vila> mgz: hey !
[07:23] <mgz> first, coffee, then I need to dump some of this bzr state I've been carrying in my head
[07:59] <mgz> vila: what's the right way to set an env var for the duration of a test only? I'm blanking...
[07:59] <vila> set_or_unset something, let me check
[07:59] <vila> the tests themselves are isolated so you don't have to restore it
[07:59] <vila> if you use the right base class that is
[08:00] <mgz> I'm looking at that code, and it seems to isolate then reset certain env vars, but only those as far as I can tell
[08:00] <vila> oh, hum, _captureVar does it. I'm not sure that's the right API to use or we should make it public maybe
[08:00] <mgz> looks like TestCase._captureVar would do what I want, bar the underscore
[08:01] <mgz> ...vilawins.
[08:01] <vila> :)
[08:01] <vila> defined in TestCase anyway, so you shouldn't be able to leak
[08:02] <vila> hmm, yeah, don't use _captureVar
[08:02] <mgz> calling it more than once for the same value would be bad
[08:02] <vila> or you risk retoring the bad value
[08:02] <vila> restoring
[08:02] <mgz> in fact, I think it might already be broken on windows
[08:03] <vila> osutils.set_or_unset_env is the one to use, may be not the best name though
[08:03] <mgz> as it's case insensitive and the override dict has values differing only by case
[08:03] <vila> weeeell, don't do that then :)
[08:04] <vila> I don't know of a case where differently cased vars are set to different values on *nix, but _cleanEnvironment already list FTP_PROXY and ftp_proxy and the like
[08:05] <mgz> right, that's a problem on windows
[08:05] <mgz> because the first one resets the value
[08:05] <vila> only for tests writers, but it may be wise to update the docstring then
[08:05] <mgz> then the second one records that reset value as the right thing
[08:06] <vila> yes, that's the possible failure I was referring to
[08:06] <mgz> am I reasoning this thing right?
[08:06] <mgz> anyway, doesn't matter much, you'd need to be caring your proxy still worked after running selftest for it to matter
[08:06] <vila> but only if you use _captureVar, not if you use set_or_unset
[08:07] <vila> not if you set an unknown env var.... you need to update _cleanEnv to have it tracked :)
[08:08] <mgz> I'll think of some better way of spelling this, need to share the code with doctests anyway
[08:08] <mgz> but... back to what I was doing
[08:14] <vila> mgz: Any thought on http://wiki.hudson-ci.org/display/HUDSON/testng-plugin (I know I shouldn't divert you :)
[08:15] <mgz> I know nothing about testng, so I'd need to find out more to have useful thoughts
[08:21] <vila> mgz: no hurry, I'll keep it on my radar, reporting skips sounds like a nice addition
[08:21] <vila> well, not applicable even more
[08:22] <vila> the idea was more about, if we can do that for skipped and not applicable tests, may be we can also report leaks this way
[08:23] <vila> maxb: regarding bug #636930 what should be our next move ? None ?
[08:23] <mgz> I think we have things to be fixing to get better results anyway
[08:24] <mgz> see bug I'll be filing later when I get down my todo list a little further for instance
[08:24] <vila> mgz: I'll look
[09:20] <maxb> vila: Someone actually needs to produce test run logs of 2.2.1 on maverick, with each failure justified as occurring with 2.2.0-1 too
[09:20] <vila> maxb: I see
[09:22] <mgz> ...vila, does your new news script check the items are in the right slot? we have a bunch of mps up right now that'd merge but put their news under 2.3b1
[09:22] <vila> mgz: fixed-in ? No, it doesn't do any check
[09:22] <mgz> does anyone?
[09:23] <vila> I warned the PP after releasing 2.3b1...
[09:23] <mgz> this is why I never write any news!
[09:23] <mgz> it's more trouble that it's worth :)
[09:23] <vila> :-P
[09:24] <vila> mgz: asking the RM to do that will be order of magnitude more trouble :)
[09:24] <mgz> okay, I think only roryy's news needs moving of the bits that I merged
[09:25] <vila> at least fixed-in should make such errors more obvious
[09:25] <mgz> having some sensible means of doing the merge locally before handing off to pqm would also help
[09:32] <vila> mgz: you need to use pqm-submit for local merges
[09:33] <mgz> I remember you showing me that but don't actually remember how.
[09:33] <vila> mgz: which is what feed-pqm is using under the wood
[09:33] <mgz> ...I think 'wood' is the wrong noun, but I now can't remember the right one.
[09:34] <mgz> hood.
[09:34] <vila> "bzr pqm-submit -m '(nick)message(Name)'" as feed-pqm add nick/Name
[09:34] <mgz> it's a car metaphor, not a furniture one
[09:34] <vila> hehe, hood, 3 letters right out of 4, I can even pretend it was a typo :)
[09:35] <vila> thanks for pointing this out :)
[11:23] <mgz> ...just thought of a cunning manifest hack, and it appears to work
[11:26] <mgz> bundling a dll in each dir would be ridiculous, but can put in more than one manifest, doesn't even seem to matter much what they contain
[11:32] <vila> mgz: the last assumption sounds suspicious...
[11:33] <vila> mgz: 'what they contain' sounds like you may be finding an irrelevant (even if correct) dll already loaded no ?
[11:36] <mgz> yeah, don't really want to deploy it without some grounding in fact
[11:40] <mgz> hm, maybe it matters a bit more thant I thought, does seem to want the ..\
[11:41] <vila> hehe, funny how we tend to come here with vague beliefs to get them refuted ;)
[11:42] <vila> which is a Good Thing :)
[11:42] <mgz> well, it's not the actual location of the dll, but it's close enough apparently
[11:43] <vila> yeah for DWIM paths: look there or close enough
[11:45] <vila> bbiab
[12:07] <zyga> how can I change the default log format for all commands that use log somehow? Do I need to add lots of alias commands?
[12:08] <Glenjamin> what commands use log?
[12:09] <zyga> Glenjamin, for example bzr missing
[12:09] <zyga> I'd like missing to use git log format
[12:10] <Glenjamin> i suspect the "easiest" way to do this would be a plugin
[12:10] <zyga> !
[12:10] <zyga> no configuration for such a preference?
[12:18] <Glenjamin> ah, i was incorrect
[12:19] <Glenjamin> "bzr help log-formats" indicates there is a preference
[12:19] <Glenjamin> zyga: ^^
[12:20]  * zyga checks
[12:20] <zyga> Glenjamin, thank you that's exactly what I was looking for
[14:42] <vila> bialix, GaryvdM: ping, I see you don't add a '-1' in the windows installer names, is that deliberate ? Do you add it only if you need to build a new one ?
[15:41] <jam> morning all
[15:41] <jam> hi vila
[15:41] <vila> jam: hey !
[15:46] <jam> mtaylor: still having the "missing inventories" problem?
[16:01] <jam> vila: I'm trying to figure out how we generated 450 bug emails since last wed. It has been like 100 emails per day...
[16:05] <vila> jam: huh, really ?
[16:05] <jam> yep
[16:05] <jam> at least in my inbox
[16:05] <jam> it may be qbzr, etc
[16:06] <vila> ha, right, if I look at my bzr-bugs box, 450 goes back to sept 22
[16:42] <mgz> I have three more bugs to add to jam's mountain today as well
[16:42] <mgz> just working out the last one now
[16:43] <mgz> looks easy like the first rather than horrid like the second
[18:15] <immy> hii.
[18:15] <immy> why isn't anyone talking. :(
[18:16] <dash> immy: did you have a question? :)
[18:16] <immy> yes. :) what is this chtroom for. :)
[18:17] <dash> immy: http://bazaar-vcs.org/
[18:17] <dash> immy: a version control tool, mostly used by programmers. :)
[18:18] <immy> oh right.
[18:18] <immy> cool!
[18:18] <immy> why is it used?
[18:19] <dash> immy: did you ever save a file you were working on, then realize you deleted or changed some things you wanted to keep?
[18:19] <dash> immy: bzr is a tool for remembering all the older versions of your files in a project
[18:20] <dash> so you can look at its entire history, from the beginning up to now
[18:20] <immy> ohhh i see.
[18:20] <immy> cool!
[18:21] <dash> for text files it can also show you the differences between different versions
[18:21] <dash> and if you have a project that multiple people work on, it can merge together work done on different versions to make a combined version
[18:21] <rubbs> immy: http://betterexplained.com/articles/a-visual-guide-to-version-control/  and http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ can explain about what this does on a more "zoomed out" level
[18:22] <dash> the Ubuntu project uses bzr a lot as a tool to help programmers around the world cooperate on the same projects
[18:25] <mgz> so, version control is cool and all, but where are the cute guys?
[18:26] <vila> dash, rubbs, mgz : He's gone...
[18:26] <dash> alas.
[18:26] <mgz> ah, here's one.
[18:26] <rubbs> vila: opps. that's what I get for ignoring quits...
[18:26] <dash> i thought we had a new user ;)
[18:28] <mgz> wow, that's a pretty crazy traceback in bug 654684
[18:30] <vila> mgz: geez, that was fixed long ago...
[18:32] <mgz> he says he tried 2.2.1 which suggests otherwise
[18:32] <vila> weird, looks like bug #395714
[18:33] <mgz> the subprocess branch location is pretty unlikely, I doubt he's even trying to use http
[18:33] <mgz> so there's probably a qbzr or explorer bug there as well
[18:34] <vila> mgz: don't forget it's bencoded ?
[18:35] <mgz> ah, yeah.
[18:35] <mgz> he does say "local branch" but that could mean over the lan or something
[18:38] <vila> hmm, checkout with http will not allow commits either or is it different with svn ?
[18:38] <dash> vila: svn can do commits via http.
[18:38] <vila> anyway, jelmer will kill me still haven't implemented OPTIONS in our http transports :-/
[18:38] <vila> kill me for
[18:39] <mgz> on the topic of svn, I need some user support...
[18:39] <vila> dash: ha right, thanks
[18:40] <mgz> tried to do `svn update -r 78554 a_file` on the python 2.7 maint branch, which used to be python trunk, and it deleted the file rather than change it to an old version
[18:40] <mgz> presumably because the rev predated the name change which confused something?
[18:41] <mgz> what keywords can I use to find a fix for that, everything's too generic.
[19:26] <lifeless> mgz: 'svn UI doing as designed' ?
[19:40] <mgz> lifeless: how do I get the old rev then? switch then update -r worked but switch is a big hammer.
[19:46] <fullermd> Import into bzr, then...    ;)
[19:47] <mgz> heh.
[20:55] <maxb> mgz: As far as svn's concerned, a switch operation is strictly a superset of an update operation. Thus, you can switch -r
[20:56] <maxb> and on that note, /me afks
[21:30] <git__> anyone know what "PointlessCommit(No changes to commit)" mean?
[21:30] <dash> it means you tried to do a commit with no changes in it
[21:31] <git__> i made change to the file but still get the error message
[21:31] <git__> is there a limit how many directories bzr can traverse?
[21:31] <dash> git__: what does 'bzr status your/file/name' say?
[21:31] <dash> no
[21:32] <git__> doesn't say anything
[21:33] <dash> git__: then the file is unchanged.
[21:33] <git__> let me change the file now, and do bzr status [filename]
[21:33] <mgz> or unversioned.
[21:34] <mgz> do `bzr add yourfile`?
[21:34] <dash> mgz: it'd say "unknown" if it wasn't added
[21:34] <git__> even after changing the file, i did bzr status [filename], nothing return
[21:35] <mgz> not if it's in the ignore list I think.
[21:35] <dash> mgz: oh true
[21:35] <dash> git__: what's the filename
[21:35] <git__> category.tpl
[21:35] <git__> every files in the directory have that problem
[21:35] <dash> hmm well that won't be in the default ignore list
[21:36] <mgz> what's the directory name? :)
[21:36] <git__> product
[21:36] <mgz> okay, that's not very ignorable either
[21:43] <git__> I use bazaar explorer, it works
[21:57] <gmpff> hi
[22:23] <git__> is there any plan for bzr to support image differential?
[22:23] <git__> i like bzr upload feature, that's the coolest
[22:23] <dash> git__: you can use any diff program you like with bzr
[22:37] <jam> \o/ I finally dug myself out of 450 bug mail message backlog. The big offender was james_w with his udd spam. (Not that those aren't worthy, but it generated a *huge* amount of emails over the week(end))
[22:38] <jam> git__: "image differential"? I believe qbzr already supports showing images side-by-side when seeing them in a diff
[22:38] <jam> (bzr qdiff, IIRC)
[22:41] <james_w> jam: yeah, sorry about that
[23:01] <jam> james_w: I just responded to your history email, I think you might be wrong about the analysis, but I could have messed something up myself.
[23:01] <jam> I have to go now, but I'll try to follow up tomorrow.
[23:02] <james_w> jam: thanks, I'll take a look
[23:31] <jml> mgz: I promise, soon, I will review your branches.
[23:31] <jml> mgz: thank you for them
[23:31] <mgz> ha, do that then I just make you review more
[23:32] <mgz> (they all kinda need input rather than rubber stamping, so I don't mind you taking a while)
[23:33] <mgz> o, while I have you though, is it easy to give me triage rights on testtools?
[23:35] <mgz> I've filed a few things and then can't prio them.
[23:35] <jml> mgz: uhh, probably... I've made a note & will fix it if I can.
[23:36] <mgz> it's a niggle only.
[23:39] <jml> mgz: don't get me started on niggles
[23:39] <jml> anyway, must retire. g'night.
[23:39] <mgz> night!
[23:44] <poolie> hi jml, mgz, good night
[23:45] <mgz> hey poolie.