[00:02] <poolie> hi spiv, all
[01:13]  * thumper looks for bzr guru
[01:13] <thumper> who is awake
[01:13] <jelmer> ok, I admit it.
[01:13] <jelmer> I'm still awake
[01:13] <thumper> hi jelmer :)
[01:13] <jelmer> what's up thumper ? :-)
[01:14] <thumper> I have an interesting process problem
[01:14] <thumper> lets say I'm doing a bug fix
[01:14] <thumper> based off trunk
[01:14] <thumper> and after some investigation I have a small patch
[01:14] <thumper> now, that patch is identified as being simple enough for an SRU
[01:14] <thumper> so I'd like to make my branch now based of the SRU branch
[01:14] <thumper> but I want my changes kept
[01:14] <thumper> any ideas?
[01:15] <jelmer> thumper: so you'd like to cherry pick your fix into an older release series?
[01:15] <thumper> or just rebase the branch
[01:15] <jelmer> or do you want to create a patch to go into the debian/patches directory of your SRU package?
[01:16] <thumper> I suppose you could shelve, then pull override?
[01:16] <thumper> we have a series branch for the SRU work
[01:16] <jelmer> thumper: Are you doing any commits in the mean time?
[01:16] <thumper> maybe...
[01:16] <thumper> I'm trying to nut out a simple process
[01:16] <jelmer> thumper: if not, I would just do "bzr merge -d sru --uncommitted trunk"
[01:16] <thumper> for working on SRUable bug fixes
[01:17] <thumper> jelmer: so making a new branch?
[01:17] <jelmer> thumper: otherwise just "bzr merge -r-3..-1 trunk" if you want to cherrypick the last three commits - though that doesn't preserve the commit history
[01:17] <jelmer> thumper: I would definitely make a new branch for the SRU work
[01:17] <thumper> I'm not interested in the commit history for this case
[01:18] <thumper> ok, too hard to rebase the existing?
[01:18] <jelmer> thumper: rebasing works too, but the problem with rebasing is that you're applying all commits individually
[01:18] <thumper> how does merge --uncommitted work when the other branch is based off a much older revision?
[01:18] <jelmer> so if each one fails to apply, you have to resolve conflicts in each one.
[01:18] <thumper> but it gives you the conflict markers et al?
[01:19] <jelmer> thumper: yeah, --uncommitted should work in that case
[01:19] <thumper> ok, cool
[01:19] <thumper> thanks
[01:19] <jelmer> thumper: you do get the conflicts, but you have to resolve them and run "bzr rebase-continue" for each commit that conflicts
[01:19] <jelmer> thumper: if you have 2 commits that's probably not an issue
[01:19] <jelmer> thumper: if you're backporting 40 commits it becomes more annoying :)
[01:20] <thumper> jelmer: I'd probably rather avoid rebase...
[01:20] <jelmer> (presuming most of them conflict, of course)
[01:20] <jelmer> thumper: in that case using "bzr merge -rFROM..TO ../trunk" to cherrypick existing revisions, or "bzr merge --uncommitted" indeed seem like the best choices
[01:21] <thumper> jelmer: thanks for that
[01:24] <thumper> jelmer: -3..-1 only takes two commits right?
[01:24] <thumper> the last and second last?
[01:28] <jelmer> thumper: yes
[01:28] <jelmer> thumper: "bzr help merge" also has a pretty good description
[01:28] <thumper> kk, ta
[07:59] <kinkie> Hi all
[08:06] <vila> kinkie: hi
[08:06] <vila> hi all !
[08:24] <fullermd> Oh, vila's up.  Must be bedtime.
[08:26] <vila> fullermd: huh ? Are you ill ?
[08:26] <vila> :-p
[08:28] <fullermd> Mentally or physically?  :p
[08:29] <vila> Well, we're talking about some recent change so I guess it means the later :)
[08:49] <vila> jelmer: ping, workflow question, I've landed the fix for bug #904704, should I: 1) mark the bug fix committed, 2) target 2.8, or both or something else ?
[08:59] <ChrisCauser> Hi everyone. I've just got a regression in a script I have written when using bzr 2.5 and was wondering if anyone can help me out?
[09:00] <vila> ChrisCauser: show us your script and we'll see what happens ;)
[09:00] <ChrisCauser> vila: Thanks http://paste.ubuntu.com/771983/
[09:01] <vila> ChrisCauser: but basically, yes, this a good place to ask
[09:01] <ChrisCauser> I'm afraid I'm going to be horrifically vague because bzr 2.5 is on my home computer and I'm at work
[09:01] <ChrisCauser> Basically, this is a bash prompt for bzr
[09:01] <ChrisCauser> in 2.3 and 2.4, it works as you'd think
[09:02] <ChrisCauser> in 2.5, I get [:] output, because I get a  NotABranchError being caught in line 51
[09:03] <ChrisCauser> I get the same error if I use open_containing in line 39
[09:03] <vila> k, was about to suggest that,
[09:04] <ChrisCauser> The only oddness I can remember is that if I say open '/home/causer/working_copy', the error says that it cannot find a branch in '/home/causer/working_copy/'
[09:05] <vila> which you disagree with because bzr can find a branch there otherwise right ?
[09:05] <ChrisCauser> Also, if the cwd is '/home/causer/working_copy/sub_directory', the error says the url is '/home/causer/working_copy/' again (i.e. it sort of knows that it is a branch)
[09:05] <ChrisCauser> yes, exactly
[09:05] <vila> right, it finds a .bzr/branch dir
[09:06] <vila> what kind of branch is that ? What does 'bzr info -v' says ?
[09:06] <ChrisCauser> Hang on a second. I'll just install 2.5 on my work computer
[09:07] <vila> line 40 is useless isn't it ?
[09:07] <vila> hmm, using branch.nick *after* unlock is... blurry
[09:09] <ChrisCauser> This script is full of historical artefacts. You are correct about line 40
[09:10] <mthaddon> vila: howdy, have a python-testtools question for you
[09:10] <mthaddon> vila: we have 0.9.6-0~bazaar1.0.IS.8.04 of python-testtools installed, but there's a 0.9.8-1~bazaar1-0.IS.10.04 lurking in lucid-cat-proposed - do you know if it's safe to promote that package so it gets installed on the servers?
[09:10] <vila> mthaddon: hello !
[09:10] <ChrisCauser> vila: http://paste.ubuntu.com/771990/
[09:11] <vila> mthaddon: according to jml who is testtools ubermaster, quoting "using 0.9.6 is close to criminal",
[09:11] <ChrisCauser> vila: This is the error I get http://paste.ubuntu.com/771991/
[09:11] <mthaddon> vila: ok, cool - the reason I'm asking is because he has asked for 0.9.8 and I'm wondering if we can use it across the board - so that sounds like a yes - thx
[09:12] <vila> mthaddon: so using 0.9.8 should be ok, but I defer to jml and mgz who knows the compatibility better than me
[09:12] <vila> mthaddon: as far as bzr itself is concerned, yes
[09:12] <mthaddon> thx
[09:12] <jml> vila: the NEWS file has got all known compat issues. I'm pretty sure we're OK though
[09:12]  * jml means to submit the latest release to Debian & backport 0.9.12 to lucid if possible
[09:12] <vila> jml: thanks, my confidence was ~90%, going up to 99% if you say so
[09:14] <vila> ChrisCauser: looking,
[09:15] <vila> first things that comes to mind so far but not guaranteed to fix your issue: you want a try:finally to unlock when you're really done instead of ad-hoc, you want to make sure you properly initialize bzrlib
[09:15] <vila> ChrisCauser: your script works for me
[09:15] <jml> vila: double check the Changes section of 0.9.8 to be extra sure
[09:15] <ChrisCauser> vila: What version of bzr are you using? I'm using the daily ppa
[09:16] <vila> ChrisCauser: I've been running from source since... can't remember
[09:16] <vila> revno 6376 right now
[09:16] <vila> jml: loooking
[09:17] <vila> mthaddon: Hold on !
[09:17] <mthaddon> holding
[09:17] <vila> mthaddon: there is a pending bug regarding upgrading pqm
[09:18] <mthaddon> vila: you're saying we can't upgrade to 0.9.8 just yet on bzr's pqm instance?
[09:18] <vila> mgzctl alarm ring
[09:18] <vila> mthaddon: searching the bug, from memory, compat issue for older bzr series
[09:19] <ChrisCauser> vila: Hmm. I'm on 6349. Python is 2.6. Well, I'll take a look myself and if I find anything, I'll let you know. Thanks for the help anyway
[09:19] <vila> bug #839461
[09:20] <mthaddon> vila: but we're already on 0.9.6 on pqm, so it seems like we'd already be in trouble there
[09:20] <vila> mthaddon: ok, so, basically, mgz will knows better than me or at least it will be easier for me to discuss with him
[09:20] <vila> ouch
[09:21] <vila> mthaddon: bumper to critical, I'll get in touch with you once mgz is up and running ;)(
[09:21] <mthaddon> k, thx
[09:22] <vila> ChrisCauser: gimme as sec
[09:25] <ChrisCauser> vila: Thanks
[09:26] <vila> ChrisCauser: what's your mininum python version requirement ?
[09:26] <vila> mum, sry :)
[09:27] <ChrisCauser> vila: For the script? I guess it's the minimum for bzr which is 2.6
[09:27] <vila> lol, what an idiot, you're right of course :)
[09:28] <ChrisCauser> :)
[09:30] <vila> ChrisCauser: http://paste.ubuntu.com/772000/ is how I would spell it these days
[09:31] <vila> ChrisCauser: does this make a difference ?
[09:32] <ChrisCauser> vila: No, unfortunately. I'm looking at the source, and it seems like no _probers are being registered in the ControlDirFormat class. I'm trying to find out what a prober is now :S
[09:33] <vila> a prober decides which format should be used based on whatever it feels appropriate: which files are there, what do they content, what kind of server, etc
[09:34] <vila> not having probers means nothing can be used
[09:34] <ChrisCauser> Ah, Ok. Well, apparently I have no probers, and ControlDirFormat.register_format is not being fired
[09:35] <vila> hmm,add a 'print bzrlib.__file__' after import bzrlib to double-check which version you're using
[09:36] <ChrisCauser> vila: Looks good: /usr/lib/pymodules/python2.6/bzrlib/__init__.pyc
[09:36] <vila> and 'bzr version' tells you the same story or a different path ?
[09:39] <vila> ChrisCauser: Also, try with BZR_PLUGIN_PATH=-site
[09:39] <ChrisCauser> vila: Yes, it's the same. I have now got it working. I have to "import bzrlib.bzrdir" explicitly in the script
[09:40] <vila> O_o
[09:40] <vila> ChrisCauser: file a bug please
[09:40] <vila> and what if you set BZR_PLUGIN_PATH ?
[09:41] <vila> ChrisCauser: and anything interesting in .bzr.log ?
[09:41] <ChrisCauser> .bzr.log looks pretty uninteresting
[09:42] <ChrisCauser> BZR_PLUGIN_PATH makes no difference
[09:45] <vila> hehe, well done vila, spot on !
[09:45] <vila> at least we know the issue doesn't come from a plugin ;)
[09:46] <vila> ChrisCauser: I'm out of ideas for now, but I not used to write scripts using bzrlib, try again later, jelmer and mgz may know better
[09:48] <vila> ChrisCauser: if nothing else, 'with bzrlib.intialize()' should be enough, if it's not, t's a bug
[09:48] <vila> 'I not used'... "I'm not used" and I need more coffee :)
[09:49] <ChrisCauser> vila: Thanks a lot for all your help. I'm pretty sure the problem is that the prober being registered in bzrlib.bzrdir.__line__ == 1143 should be registered on initialize().
[09:49] <ChrisCauser> Perhaps it was a speed consideration that it was left out
[09:49] <ChrisCauser> Anyway, many thanks for all the hard sleuthing. I'll file a bug report
[09:50] <vila> 1143 does not match, what's the line content /
[09:50] <vila> ?
[09:50] <vila> controldir.ControlDirFormat.register_prober(BzrProber) ????
[10:00] <wgz> failing to get network operational this morning...
[10:01] <wgz> vila: are we going to do another release off 2.2?
[10:02] <vila> https://launchpad.net/bzr/+milestones says 2012-02-09 but is subject to change depending on bugs fixed
[10:02] <ChrisCauser> vila: Yes, that's the one. I've filed a bug report
[10:02] <ChrisCauser> https://bugs.launchpad.net/bzr/+bug/905218
[10:03] <ChrisCauser> I hope it is detailed enough
[10:03] <vila> wgz: so, a new 2.2 is pretty unlikely but I'd rather not discover a compat issue when trying to do a release to fix a critical issue...
[10:04] <vila> wgz: my turn now :)
[10:04] <vila> wgz: did you get some results for news_merge on pqm ?
[10:04] <wgz> the only obvious locations.conf seemed to last modified 3 years ago
[10:05] <wgz> while we have mthaddon it would be good to ask him if that's the current one or if the real thing is elsewhere
[10:05] <vila> good point
[10:05] <vila> let's talk about testools first then
[10:05] <vila> what are the options ?
[10:06] <wgz> well, I'm not too worried about upgrading it, various small things have broken and then been fixed across versions
[10:06] <vila> is 2.2 compatible with  0.9.8-1~bazaar1-0.IS.10.04 (available according to mthaddon) or should we instead check for 0.9.12 and wait for jml to provide it for lucid ?
[10:07] <vila> or separate pqm from the other ?
[10:07] <wgz> if it turns out something fails with the new version, we just need to land whatever bzrlib change is required
[10:07] <wgz> but 0.9.8 should be fine for 2.2
[10:07] <wgz> whereas newer versions would require some test output fix backporting
[10:07] <vila> can you double-check that and update bug #839461 ?
[10:08] <wgz> sure
[10:08] <vila> I just bumped it to critical waiting for a more precise diagnosis
[10:08] <wgz> heh, I don't have a 2.2 tree here
[10:08] <wgz> I think I deleted it as no longer relevent
[10:08]  * wgz branches
[10:09] <vila> mwhahah, you want to make our compat overlord cry ?
[10:13] <wgz> well, I *run* a pre-2.2 version as my base bzr on this box
[10:15] <wgz> okay, with trunk testtools, get three:
[10:15] <wgz> AttributeError: 'module' object has no attribute 'ExtendedTestResult'
[10:15] <wgz> will roll back to 0.9.8
[10:15] <wgz> there's a change I fixed that in I could backport to 2.2
[10:18]  * vila nods and notes that 0.9.12 seems possible (this will have my preference)
[10:20] <wgz> no s- bt.test_selftest errors with 0.9.8
[10:21] <wgz> I'll do a more extensive subset and see if there's anything else, but I expect it to be okay
[10:24] <wgz> okay, two doctest isolation problems that weren't backported...
[10:32] <wgz> dammit! was a laptop hardware bug
[10:32] <wgz> can probably transfer to the right box now
[10:38] <vila> wgz: "laptop hardware bug" ? Related to testtools ?
[10:38] <mgz> yeay! and it's still morning
[10:39] <mgz> no, related to me not being able to get on the network this morning
[10:39] <mgz> enabling then disabling the wireless made the wired hardware start responding
[10:40] <mgz> will have to remember that for next time.
[10:40] <mgz> so I don't spend quite as long checking the cabling...
[10:42] <wgz> http://float.endofinternet.org/xmlbin/2.2_testtools_0.9.8
[10:43] <wgz> all known issues, nothing testtools related
[10:43] <vila> so 0.9.8 is a valid alternative for bzr-2.2 ?
[10:43] <wgz> yup.
[10:44] <vila> jml, mthaddon : ^
[10:44] <vila> jml: is that ok with you or do you need 0.9.12 somewhere (in which case, when ? ;)
[10:45] <mthaddon> vila: that's great, thx
[10:45] <mthaddon> vila: we'll go with 0.9.8 for now
[10:46] <vila> wgz: I never know how to interpret (grok?) these pages
[10:46] <wgz> click on the little coloured boxes
[10:46]  * vila nods
[10:46] <vila> but how can I conclude: nothing wrong here
[10:47] <wgz> what I did was:
[10:47] <vila> for the whole page without clicking on all red (only ?)
[10:47] <wgz> 1) see there was no big red bar for any of the rows
[10:47] <wgz> that would indicate a test module failed to import
[10:48] <wgz> then I clicked on the little red and orange boxes, and saw they were all failures I know about already, mostly related to the selftest environment being slightly different
[10:48] <vila> ha, ok
[10:48] <wgz> ideally, you'd just look at the whole page and go "no red or orange!"
[10:48] <wgz> but the testsuite isn't quite that solid
[10:49] <vila> yeah, now I understand that I can't get that without practice ;)
[10:49] <wgz> eg:
[10:49] <wgz> http://float.endofinternet.org/xmlbin/2.2_testtools_0.9.8#bb.test_version.TestVersionUnicodeOutput.test_unicode_bzr_home
[10:49] <wgz> this is a problem with the test, and the design of trace
[10:49] <vila> hehe, I almost mentioned just that one :)
[10:50] <wgz> the test wants to escape isolation and get real `bzr version` output
[10:50] <vila> http://float.endofinternet.org/xmlbin/2.2_testtools_0.9.8#%28doctest%29bzrlib
[10:50] <wgz> and fails if trace.enable_default_logging() hasn't been called
[10:51] <wgz> ^that's an old doctest error that's fixed on trunk, basically it's spelt wrong and happened to work in some cases, again because of bad isolation
[10:51] <vila> oh, ChrisCauser encountered an issue in a script even after calling bzrlib.initialize() bug #905218
[10:52] <wgz> right, we have a bunch of issues that selftest doesn't catch by default because it generally runs in a fully set up environment
[10:52] <wgz> the import tariff type tests are a way around that
[10:52] <vila> a job for a subprocess test
[10:55] <wgz> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/5494 <- fix for that bzrlib doctest issue
[10:55] <vila> and you're still based on 2.2 because this runs with ?
[10:56]  * vila tries to refresh his memory ;)
[10:56] <wgz> ...without testtools :)
[10:56] <vila> :-D
[10:57] <vila> . o O (This guy is schizophrenic, not only does he needs 2 nicks, he also manages to contribute (significantly) to a tool he doesn't use ;)
[11:16] <wgz> ha, okay, with trunk the only new errors are in <http://zippedmartin.dyndns.org/xmlbin/newtestresult#bt.test_selftest>
[11:16] <hrw> jelmer: like promised: bug 905275 reported
[11:17] <wgz> the bad part is the fix for that is from my testcase collection branch, so there's no direct backport possible
[11:19] <vila> wgz: gut feeling == skip those tests for 2.2 and be done
[11:20] <vila> wgz: if this is enough to allow us to use 0.9.12, the risk is negligible
[11:20] <wgz> though... I do have one neat rev for it: <http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/5340.12.7>
[11:21] <vila> wgz: would be clearer with from bzrlib.testools.testresult import doubles
[11:22] <vila> wgz: but small enough as it is for SRUs
[11:22] <vila> err, but good enough as it is, being small, for SRUs
[11:23] <vila> wgz: could you update the bug with a summary/bug task creation whatever you feel appropriate :)
[11:24] <vila> wgz: and thanks a lot, that's far clearer now, death to FUD ! :)
[11:26] <wgz> will just test 2.3/2.4 as well while here
[11:57] <niemeyer> Hey all
[11:57] <niemeyer> Quick question:
[11:58] <niemeyer> Once one "bzr update -r N", how to tell which revision the current working tree currently represents?
[11:58] <niemeyer> "bzr revno" still shows the tip
[11:59] <wgz> `bzr revno --tree`
[12:09] <vila> jelmer: toying around with your feature-flags branch, ./bzr selftest -s bt.test_bzrdir hangs in bzrlib.tests.test_bzrdir.TestHTTPRedirections_pycurl.test_loop tracked down to bzr-svn
[12:09] <vila> jelmer: I'll switch to BZR_PLUGIN_PATH-site
[12:09] <vila> jelmer: I'll switch to BZR_PLUGIN_PATH=-site
[12:25] <jml> vila: 0.9.8 is a valid alternative. 0.9.12 is at the mercy of a willing volunteer to package
[12:25] <jml> vila: which might end up being me, but others are welcome to go ahead.
[12:43] <vila> jml: thanks for confirming
[12:50] <wgz> bah, initialize is still a mess
[12:50] <wgz> pass setup_ui=False and you get a traceback
[12:55] <wgz> what's needed to get the old (quiet) behaviour bad again: <http://paste.ubuntu.com/772153/>
[13:13] <vila> wgz: the more I think about library state, the more I believe it should provides a sensible default behavior when importing bzrlib and *then* allows calls to initialize() to override whatever you want
[13:14] <wgz> yeah.
[13:15] <vila> tests and bzr commands would then be executed into a with bzrlib.initialize() block setting the needed bits and restoring the previous state when leaving the block
[13:15] <vila> should scale for threads too
[13:16] <vila> this should also limit the places where you need to pass the state around to: commands, tree, branch and repo signgificant calls without requiring passing it across the whole API
[13:16] <vila> meh and tests of course
[13:23] <wgz> see r6210 as well
[13:31] <vila> hehe, yeah, I know this one :)
[13:31] <vila> I don't like the global_state=None approach hence my "provides a sensible default behavior when importing bzrlib"
[13:32] <vila> in other words, let's initialize *something* cleanly and *then* give ways to tweak
[14:59] <adiroiban> Hi. I am getting this error: 	
[14:59] <adiroiban> bzrlib.errors.IllegalUseOfScopeReplacer: ScopeReplacer object 'StringIO' was used incorrectly: Object already cleaned up, did you assign it to another variable?: _factory
[14:59] <adiroiban> second time I call branch = bzrlib.branch.Branch.open_containing(self.url)[0]
[14:59] <adiroiban> any idea what is wrong?
[15:00] <wgz> we need more context to know what's going wrong, it's a symptom of lazy import misuse
[15:00] <wgz> so, full traceback, and ideally the module with your code as well?
[15:01] <adiroiban> I am trying to fix the buildbot, bzrpoller
[15:01] <wgz> ah... it's an error in trace
[15:01] <wgz> from bzrlib.lazy_import import lazy_import
[15:01] <wgz> lazy_import(globals(), """
[15:01] <wgz> from cStringIO import StringIO
[15:01] <wgz> ...
[15:01] <adiroiban> http://pastebin.ubuntu.com/772280/
[15:02] <adiroiban> call is at line 287
[15:02] <wgz> you can probably avoid it by doing `with bzrlib.initialize(): your_main()` in your script
[15:02] <adiroiban> aha
[15:03] <adiroiban> so the bzrlib.initialize() should be called only once?
[15:03] <wgz> file a bug against bzr, because the bad code is in bzrlib.trace
[15:03] <adiroiban> ok. I will file a bug. thanks!
[15:03] <wgz> and yes, the fix is probably just to make init happen once at the right time
[15:05] <wgz> include the full traceback in the bug, and say what you run to hit it
[15:06] <adiroiban> any suggestion for the title?
[15:06] <adiroiban> or just put any title that will be updated
[15:06] <adiroiban> if required
[15:06] <wgz> "IllegalUseOfScopeReplacer from replacement of StringIO" or something
[15:06] <adiroiban> ok
[15:09] <lamalex> Hi, is there any way to get bzr-builder to use pbuilder to build its package?
[15:11] <jelmer> lamalex: at the moment, no
[15:11] <jelmer> lamalex: though you should be able to use --no-build and then use pbuilder manually
[15:13] <adiroiban> wgz: I tried wrapping the call to bzrlib.branch.Branch.open_containing in a with: bzr.initialize() block, and also tried to call bzr.initialize() just after the import bzrlib, but I get the same error
[15:13] <wgz> adiroiban: could also just be a race, which we have a bug for already
[15:14] <wgz> but it's config not trace that needs fixing, I guessed wrong
[15:15] <adiroiban> wgz: unfortunately I am stuck with python 2.5 so I am using bzr 2.3.4
[15:15] <wgz> so, try "from bzrlib import config; config.StringIO()" before spawning threads
[15:16] <wgz> which will deal with that particular one at least
[15:16] <adiroiban> it seems like config.StringIO() solve the problem...
[15:16] <adiroiban> thanks!
[15:22] <lamalex> jelmer, ah, that's a good idea
[15:22] <lamalex> jelmer, i was looking through the source to try and find where it actually builds and i can only find where it builds the source package
[15:25] <jelmer> lamalex: it doesn't build binary packages at all
[15:26] <lamalex> oh, ha
[15:26] <lamalex> but --no-build and pbuilder should work for building a binary package
[15:49] <jelmer> vila: what's the easiest way to create a stack from a string?
[16:04] <vila> jelmer: a store from a string and then a stack from a store like I did for your commit builder branch ?
[16:05] <jelmer> vila: ah, thanks
[16:05] <vila> bzrlib.tests.test_commit.py
[16:06] <vila> jelmer: and hi ! :)
[16:06]  * vila scrolls back for stacked questions
[16:08] <vila> jelmer: ping, workflow question, I've landed the fix for bug #904704, should I: 1) mark the bug fix committed, 2) target 2.8, or both or something else ?
[16:08] <vila> also, ChrisCauser encounter a weird issue: bug #905218
[16:09] <vila> jelmer: I thought the prober could ring a bell with you
[16:09] <jelmer> vila: yep, target 2.8 and mark as fixcommitted
[16:09] <jelmer> vila: yeah, that makes sense
[16:09] <jelmer> vila: we don't import bzrlib.bzrdir necessarily
[16:09] <jelmer> vila: so we don't register the prober for .bzr in some cases. We should probably import bzrlib.bzrdir from bzrlib.initialize()
[16:10] <vila> but the end result is that open_workingtree ends up raising NotABranch because no prober is registered
[16:11] <jelmer> vila: right, because we haven't registered the prober for .bzr/
[16:12] <vila> a bit weird that importing workintree.py doesn't trigger importing bzrdir.py...
[16:12] <vila> and also why wasn't it the case for bzr-2.4 ? (Probably more lazy loading related)
[16:12] <jelmer> vila: yeah, more lazy loading
[16:13] <jelmer> vila: there isn't much in bzrlib.workingtree that is bzr-specific
[16:13] <jelmer> vila: so nothing uses bzrlib.bzrdir
[16:13] <vila> yeah, wt.py vs wt4.py ?
[16:13] <jelmer> vila: right - wt.py just contains the main API, which is shared by bzr and foreign formats
[16:14] <jelmer> vila: I wonder what the better fix is, explicitly importing "bzrlib.bzrdir" at the top of wt.py, or adding "import bzrlib.bzrdir" to bzrlib.initialize?
[16:15] <jelmer> I think in bzrlib.workingtree
[16:15] <jelmer> as we're already doing something similar in bzrlib.branch and bzrlib.repository
[16:15] <vila> or registering the bzr prober lazily somehwere ?
[16:15] <vila> ha, that's probably best then
[16:31] <ChrisCauser> jelmer: Thanks a lot for the help with #905218
[16:33] <jelmer> ChrisCauser: np
[16:34] <jelmer> we've been reducing the number of imports that bzr does at startup time, and that's now biting us
[16:38] <ChrisCauser> jelmer: I guessed that was the problem, but on the flip side, I /really/ do appreciate the work in this area. Bzr is so much quicker now. I really notice it
[16:43] <vila> jelmer: worth mentioning in the what's new ;)
[16:44] <jelmer> vila: what is?
[16:45] <vila> jelmer: more lazy loading => bzr quicker
[16:45] <jelmer> vila: ah, yeah
[17:13] <wgz> wow config_dir is called too many times... <http://float.endofinternet.org/xmlbin/dev_testtools_trunk#bb.test_version.TestVersion.test_main_version>
[17:15] <jelmer> wgz: hmm, how can you tell?
[17:15] <jelmer> ah, I see now
[17:16] <jelmer> well, GlobalStore is called very often
[17:18] <vila> If it's now called more often than GlobalConfig, I call it progress ;-)
[17:18] <wgz> is there a reason test_osutils.TestGetuserUnicode tests use LOGNAME rather than USERNAME?
[17:19] <wgz> I broke them because LOGNAME is meaningless on win.
[17:19] <vila> welcome to environ and its standardS
[17:26] <wgz> okay, I have a kinda-plan with directories
[17:26] <wgz> on startup, bzr should resolve and prepare any well known locations it needs, then stash them somewhere obvious (ie... fix global_state)
[17:27] <wgz> so, this is the 'home' config location, a cache directory, whereever we think .bzr.log should go... anything else?
[17:28] <wgz> currently there are 6 or so bugs about locations of things, that would be easiest to fix in one big go rather than moving stuff around piecemeal
[17:44] <jelmer> hmm
[17:45] <jelmer> I wonder if there's an easy way to discover whether a file system supports the executable bit, other than trying to change it on a particular file
[17:46] <mgz> would be nice if pathconf didn't suck
[17:46] <mgz> alas, it does.
[17:46] <Peng> jelmer: Could create a file once and then stat() it everafter.
[17:47] <Peng> Hmm, that'd be a problem if it was moved onto a different fs that did or didn't support the exec bit...
[17:48] <mgz> Peng: also, some C libs emulate the exec bit based on file extension
[17:48] <jelmer> Peng: yes, and file systems that don't support the X bit have different defaults for the executable bit.
[17:48] <mgz> rather than actually storing a bit with the file
[17:50] <mgz> jelmer: so, it's easy to discount support in a few cases
[17:50] <mgz> proving support is hard
[17:50] <mgz> though not quite as hard as proving bug-free support :)
[17:52] <mgz> you could cover the common cases if you can use (and trust) a syscall to give you the filesystem type
[17:52] <mgz> I bet nfs makes life hard there though
[17:53] <jelmer> mgz: I agree the sensible thing to do is:
[17:53] <jelmer> * assume win32 doesn't support the executable bit
[17:54] <jelmer> * on other platforms, assume the executable bit is support unless we can somehow determine that it definitely isn't
[17:54] <vila> conf.set('xxx', ''), val = conf.get('xxx') , val == '""' >.<
[17:55] <jelmer> yeah, a configuration option would indeed also be a possibility
[17:55] <jelmer> I wish we had a per-tree configuration though..
[17:55] <vila> nah, was mentioning the siliest bug ever, re-read
[17:56] <vila> setting a conf option to '', re-reading it, get '""', not ''
[17:56] <jelmer> ah :)
[17:56] <mgz> heh
[17:56] <vila> configobj apparently, been there since epoch
[17:57] <vila> why we never ran into it....
[17:58] <mgz> okay, I'm going to finish off the lazy_import threading branch
[17:59] <mgz> won't help people marooned on bzr 2.3 like earlier, but the current code is insane compared to MvG's
[17:59] <jelmer> mgz: cool
[18:00] <jelmer> mgz: I think I found an alternative
[18:00] <mgz> doing a fix for that dumb use of StringIO on 2.3 onwards is probably also worthwhile
[18:00] <mgz> jelmer: do tell
[18:01] <jelmer> mgz: it's not exactly ideal but better than what we have now
[18:01] <jelmer> mgz: use stat('.bzr/format') to get st_dev
[18:02] <jelmer> then use getmntent to find the file system type..
[18:03] <mgz> and nfs won't be clever and lie
[18:03] <mgz> ?
[18:03] <jelmer> mgz: well, we'll get back "nfs" for nfs mounts
[18:03] <mgz> if so, that's worth doing.
[18:04] <jelmer> mgz: and there's no way of knowing what the underlying fs is, but we can just default to assuming it supports the executable bit
[18:04] <jelmer> mgz: at least it means we'll get it right for FAT, etc
[18:04] <mgz> well, or fall back to trying a dance
[18:04] <mgz> if we can trust 'ext4' (ho ho) then at least the common case doesn't need funny business
[18:05] <vila> and we'll keep assuming that's true for the whole wt
[18:06] <mgz> ...can anyone think of a reason not to use trace.mutter from inside lazy_import resolution?
[18:06] <jelmer> mgz: overhead?
[18:06] <vila> trace lazy import
[18:07] <mgz> only for duplicate resolution, so not all the time... will double check the loop issue
[19:20] <jelmer> mgz: still there?
[19:43] <mgz> jelmer: yup, just had a break for dinner
[20:37] <mgz> did the basic simplifications I suggested for the lazy_import change
[20:37] <mgz> but wonder if there isn't a proper race-aware way of doing this
[20:38] <mgz> where the first thread to both get, and delete, scope, gets to do the work
[20:39] <mgz> this could mean other threads are stuffed waiting for it to finish I guess, so deadlock
[20:39] <mgz> meph.
[20:40] <mgz> can still use that to work out if it's a race or a reuse though
[20:45] <Noldorin> hey folks
[20:45] <Noldorin> hi mgz
[20:45] <mgz> hey Noldorin
[20:46] <Noldorin> how's... things?
[20:47] <Noldorin> saw the b4 release of 2.5 :-)
[20:47] <Noldorin> looking good
[20:52] <mgz> getting there :)
[21:48] <Reggie> can anyone help a relative bzr novice out?  I have someone who pushed a change to remote repo A, and then merged that to remote repo B and then C.  The change should have only gone into C
[21:48] <Reggie> what's the easiest way to remove it from A and B?
[21:49] <Reggie>  I know I can overwrite the affected files with the files from current-1 and then do a normal commit but hoping there is an easier or more standard way to do it
[21:49] <Reggie> thanks
[21:55] <jelmer> hi Reggie
[21:55] <Reggie> hi
[21:55] <jelmer> Reggie: bzr uncommit is what you're looking for probably
[21:56] <Peng> It sounded to me like it was too late for uncommitting.
[21:56] <Reggie> dev commited locally and then pushed to remote branch


[21:56] <Reggie> then merged up to B and C locally and pushed them
[21:57] <Reggie> now we need to remove the last changeset on the remote repos A & B
[21:57] <wgz> whether you want to uncommit or merge a reversion depends on how public the branches in question are
[21:57] <Reggie> these are not public
[21:57] <Reggie> internally hosted
[21:57] <wgz> if lots of people use them, they'd get confused if you rewrite history on them by removing the commit entirely
[21:58] <Reggie> not an issue
[21:58] <wgz> then uncommit and email to everyone saying "whoops" is generally fine
[21:59] <Reggie> here is where I get confused.  I do a bzr uncommit and now I see the changed files (which is correct). what then?  the bzr uncommit doesn't effect the remote repo?
[21:59] <Reggie> do I need to do the bzr uncommit on the remote repo?
[21:59] <wgz> yeah, you just pass it as the location
[22:00] <wgz> so, `bzr uncommit A` `bzr uncommit B`
[22:00] <Reggie> will repo C get confused?  the change needs to be in C  (these repos are chained together)
[22:00] <wgz> depends how you did the merge.
[22:01] <wgz> you can branch all three locally, try it out and see
[22:01] <wgz> then do it for real when you have the state you want
[22:01] <Reggie> devs do merges on their local workstations.   they would typically push in folder A  then from inside folder B they would do  bzr pull; bzr merge ..\A;  bzr commit -m"merged"; bzr push
[22:02] <Reggie> make sense?
[22:02] <wgz> this is getting out of basic fixing a mistake, and into workflows
[22:02] <wgz> what would the correct series of operations have been?
[22:02] <Reggie> make change in C and push only to C
[22:03] <Reggie> instead dev thought the fix should go all the way back to A
[22:03] <Reggie> this is a single product versioned.  vesrion A, vesrion B, version C
[22:03] <wgz> and C is newest.
[22:03] <Reggie> yup
[22:03] <wgz> uncommit on all three then do it right is fine then.
[22:04] <Reggie> any big problem with overwriting the changed files with files from revision-1 and doing a new set of commits/pushes?
[22:04] <wgz> if this happened some revisions back, you'd want to reverse the merge on A, merge up to B, merge up to C *then revert the tree but keep the merge*
[22:04] <Reggie> I say that because repo C may be already been changed by others so uncommit there might be challenging
[22:05] <wgz> if you can replay the new changes on C that's also fine, but deeper into history rewrite territory
[22:06] <Reggie> yes, I think you just said what I was trying to say.  basically undo the change manually in A & B and then do what I call null-merge to C
[22:06] <Reggie> the bad change is the very last change on A & B but it's not the last change on C
[22:10] <wgz> that option is basically just `bzr merge -r-1..-2 -d A A; bzr commit A; bzr merge -d B A; bzr commit B; bzr merge -d C B; bzr revert C; bzr commit C`
[22:10] <Reggie> right
[22:10] <Reggie> :)
[22:10] <wgz> `bzr revert *` rather.
[22:11] <wgz> you want to keep the merge, but not the changes.
[22:11] <Reggie> wgz, thanks.  really appreciate the help
[22:21] <Noldorin> wgz, oh yeah, was going to ask. does bzr have 'service' plugins like hg does? like for notifying you when someone pushes?
[22:21] <Noldorin> on a bzr server
[22:21] <Noldorin> that is
[22:22] <Noldorin> also, does LP specifically have them?
[23:25] <wgz> bzr does, lp doesn't as far as I'm aware, but various things you can use for landing changes like pqm and tarmac can notify