/srv/irclogs.ubuntu.com/2011/12/16/#bzr.txt

pooliehi spiv, all00:02
* thumper looks for bzr guru01:13
thumperwho is awake01:13
jelmerok, I admit it.01:13
jelmerI'm still awake01:13
thumperhi jelmer :)01:13
jelmerwhat's up thumper ? :-)01:13
thumperI have an interesting process problem01:14
thumperlets say I'm doing a bug fix01:14
thumperbased off trunk01:14
thumperand after some investigation I have a small patch01:14
thumpernow, that patch is identified as being simple enough for an SRU01:14
thumperso I'd like to make my branch now based of the SRU branch01:14
thumperbut I want my changes kept01:14
thumperany ideas?01:14
jelmerthumper: so you'd like to cherry pick your fix into an older release series?01:15
thumperor just rebase the branch01:15
jelmeror do you want to create a patch to go into the debian/patches directory of your SRU package?01:15
thumperI suppose you could shelve, then pull override?01:16
thumperwe have a series branch for the SRU work01:16
jelmerthumper: Are you doing any commits in the mean time?01:16
thumpermaybe...01:16
thumperI'm trying to nut out a simple process01:16
jelmerthumper: if not, I would just do "bzr merge -d sru --uncommitted trunk"01:16
thumperfor working on SRUable bug fixes01:16
thumperjelmer: so making a new branch?01:17
jelmerthumper: otherwise just "bzr merge -r-3..-1 trunk" if you want to cherrypick the last three commits - though that doesn't preserve the commit history01:17
jelmerthumper: I would definitely make a new branch for the SRU work01:17
thumperI'm not interested in the commit history for this case01:17
thumperok, too hard to rebase the existing?01:18
jelmerthumper: rebasing works too, but the problem with rebasing is that you're applying all commits individually01:18
thumperhow does merge --uncommitted work when the other branch is based off a much older revision?01:18
jelmerso if each one fails to apply, you have to resolve conflicts in each one.01:18
thumperbut it gives you the conflict markers et al?01:18
jelmerthumper: yeah, --uncommitted should work in that case01:19
thumperok, cool01:19
thumperthanks01:19
jelmerthumper: you do get the conflicts, but you have to resolve them and run "bzr rebase-continue" for each commit that conflicts01:19
jelmerthumper: if you have 2 commits that's probably not an issue01:19
jelmerthumper: if you're backporting 40 commits it becomes more annoying :)01:19
thumperjelmer: I'd probably rather avoid rebase...01:20
jelmer(presuming most of them conflict, of course)01:20
jelmerthumper: in that case using "bzr merge -rFROM..TO ../trunk" to cherrypick existing revisions, or "bzr merge --uncommitted" indeed seem like the best choices01:20
thumperjelmer: thanks for that01:21
thumperjelmer: -3..-1 only takes two commits right?01:24
thumperthe last and second last?01:24
jelmerthumper: yes01:28
jelmerthumper: "bzr help merge" also has a pretty good description01:28
thumperkk, ta01:28
kinkieHi all07:59
vilakinkie: hi08:06
vilahi all !08:06
fullermdOh, vila's up.  Must be bedtime.08:24
vilafullermd: huh ? Are you ill ?08:26
vila:-p08:26
fullermdMentally or physically?  :p08:28
vilaWell, we're talking about some recent change so I guess it means the later :)08:29
vilajelmer: 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:49
ubot5Launchpad bug 904704 in bzr-builddeb "non utf-8 encoded changelogs cannot be parsed with recent python-debian" [High,In progress] https://launchpad.net/bugs/90470408:49
ChrisCauserHi 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?08:59
vilaChrisCauser: show us your script and we'll see what happens ;)09:00
ChrisCauservila: Thanks http://paste.ubuntu.com/771983/09:00
vilaChrisCauser: but basically, yes, this a good place to ask09:01
ChrisCauserI'm afraid I'm going to be horrifically vague because bzr 2.5 is on my home computer and I'm at work09:01
ChrisCauserBasically, this is a bash prompt for bzr09:01
ChrisCauserin 2.3 and 2.4, it works as you'd think09:01
ChrisCauserin 2.5, I get [:] output, because I get a  NotABranchError being caught in line 5109:02
ChrisCauserI get the same error if I use open_containing in line 3909:03
vilak, was about to suggest that,09:03
ChrisCauserThe 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:04
vilawhich you disagree with because bzr can find a branch there otherwise right ?09:05
ChrisCauserAlso, 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
ChrisCauseryes, exactly09:05
vilaright, it finds a .bzr/branch dir09:05
vilawhat kind of branch is that ? What does 'bzr info -v' says ?09:06
ChrisCauserHang on a second. I'll just install 2.5 on my work computer09:06
vilaline 40 is useless isn't it ?09:07
vilahmm, using branch.nick *after* unlock is... blurry09:07
ChrisCauserThis script is full of historical artefacts. You are correct about line 4009:09
mthaddonvila: howdy, have a python-testtools question for you09:10
mthaddonvila: 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
vilamthaddon: hello !09:10
ChrisCauservila: http://paste.ubuntu.com/771990/09:10
vilamthaddon: according to jml who is testtools ubermaster, quoting "using 0.9.6 is close to criminal",09:11
ChrisCauservila: This is the error I get http://paste.ubuntu.com/771991/09:11
mthaddonvila: 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 - thx09:11
vilamthaddon: so using 0.9.8 should be ok, but I defer to jml and mgz who knows the compatibility better than me09:12
vilamthaddon: as far as bzr itself is concerned, yes09:12
mthaddonthx09:12
jmlvila: the NEWS file has got all known compat issues. I'm pretty sure we're OK though09:12
* jml means to submit the latest release to Debian & backport 0.9.12 to lucid if possible09:12
vilajml: thanks, my confidence was ~90%, going up to 99% if you say so09:12
vilaChrisCauser: looking,09:14
vilafirst 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 bzrlib09:15
vilaChrisCauser: your script works for me09:15
jmlvila: double check the Changes section of 0.9.8 to be extra sure09:15
ChrisCauservila: What version of bzr are you using? I'm using the daily ppa09:15
vilaChrisCauser: I've been running from source since... can't remember09:16
vilarevno 6376 right now09:16
vilajml: loooking09:16
vilamthaddon: Hold on !09:17
mthaddonholding09:17
vilamthaddon: there is a pending bug regarding upgrading pqm09:17
mthaddonvila: you're saying we can't upgrade to 0.9.8 just yet on bzr's pqm instance?09:18
vilamgzctl alarm ring09:18
vilamthaddon: searching the bug, from memory, compat issue for older bzr series09:18
ChrisCauservila: 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 anyway09:19
vilabug #83946109:19
ubot5Launchpad bug 839461 in Bazaar "can't run selftest for 2.2 with recent subunit/testtools" [High,Confirmed] https://launchpad.net/bugs/83946109:19
mthaddonvila: but we're already on 0.9.6 on pqm, so it seems like we'd already be in trouble there09:20
vilamthaddon: ok, so, basically, mgz will knows better than me or at least it will be easier for me to discuss with him09:20
vilaouch09:20
vilamthaddon: bumper to critical, I'll get in touch with you once mgz is up and running ;)(09:21
mthaddonk, thx09:21
vilaChrisCauser: gimme as sec09:22
ChrisCauservila: Thanks09:25
vilaChrisCauser: what's your mininum python version requirement ?09:26
vilamum, sry :)09:26
ChrisCauservila: For the script? I guess it's the minimum for bzr which is 2.609:27
vilalol, what an idiot, you're right of course :)09:27
ChrisCauser:)09:28
vilaChrisCauser: http://paste.ubuntu.com/772000/ is how I would spell it these days09:30
vilaChrisCauser: does this make a difference ?09:31
ChrisCauservila: 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 :S09:32
vilaa 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, etc09:33
vilanot having probers means nothing can be used09:34
ChrisCauserAh, Ok. Well, apparently I have no probers, and ControlDirFormat.register_format is not being fired09:34
vilahmm,add a 'print bzrlib.__file__' after import bzrlib to double-check which version you're using09:35
ChrisCauservila: Looks good: /usr/lib/pymodules/python2.6/bzrlib/__init__.pyc09:36
vilaand 'bzr version' tells you the same story or a different path ?09:36
vilaChrisCauser: Also, try with BZR_PLUGIN_PATH=-site09:39
ChrisCauservila: Yes, it's the same. I have now got it working. I have to "import bzrlib.bzrdir" explicitly in the script09:39
vilaO_o09:40
vilaChrisCauser: file a bug please09:40
vilaand what if you set BZR_PLUGIN_PATH ?09:40
vilaChrisCauser: and anything interesting in .bzr.log ?09:41
ChrisCauser.bzr.log looks pretty uninteresting09:41
ChrisCauserBZR_PLUGIN_PATH makes no difference09:42
vilahehe, well done vila, spot on !09:45
vilaat least we know the issue doesn't come from a plugin ;)09:45
vilaChrisCauser: I'm out of ideas for now, but I not used to write scripts using bzrlib, try again later, jelmer and mgz may know better09:46
vilaChrisCauser: if nothing else, 'with bzrlib.intialize()' should be enough, if it's not, t's a bug09:48
vila'I not used'... "I'm not used" and I need more coffee :)09:48
ChrisCauservila: 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
ChrisCauserPerhaps it was a speed consideration that it was left out09:49
ChrisCauserAnyway, many thanks for all the hard sleuthing. I'll file a bug report09:49
vila1143 does not match, what's the line content /09:50
vila?09:50
vilacontroldir.ControlDirFormat.register_prober(BzrProber) ????09:50
wgzfailing to get network operational this morning...10:00
wgzvila: are we going to do another release off 2.2?10:01
vilahttps://launchpad.net/bzr/+milestones says 2012-02-09 but is subject to change depending on bugs fixed10:02
ChrisCauservila: Yes, that's the one. I've filed a bug report10:02
ChrisCauserhttps://bugs.launchpad.net/bzr/+bug/90521810:02
ubot5Ubuntu bug 905218 in Bazaar "bzrlib.initialize() misses out the default prober" [Undecided,New]10:02
ChrisCauserI hope it is detailed enough10:03
vilawgz: 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:03
vilawgz: my turn now :)10:04
vilawgz: did you get some results for news_merge on pqm ?10:04
wgzthe only obvious locations.conf seemed to last modified 3 years ago10:04
wgzwhile we have mthaddon it would be good to ask him if that's the current one or if the real thing is elsewhere10:05
vilagood point10:05
vilalet's talk about testools first then10:05
vilawhat are the options ?10:05
wgzwell, I'm not too worried about upgrading it, various small things have broken and then been fixed across versions10:06
vilais 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:06
vilaor separate pqm from the other ?10:07
wgzif it turns out something fails with the new version, we just need to land whatever bzrlib change is required10:07
wgzbut 0.9.8 should be fine for 2.210:07
wgzwhereas newer versions would require some test output fix backporting10:07
vilacan you double-check that and update bug #839461 ?10:07
ubot5Launchpad bug 839461 in Bazaar "can't run selftest for 2.2 with recent subunit/testtools" [Critical,Confirmed] https://launchpad.net/bugs/83946110:07
wgzsure10:08
vilaI just bumped it to critical waiting for a more precise diagnosis10:08
wgzheh, I don't have a 2.2 tree here10:08
wgzI think I deleted it as no longer relevent10:08
* wgz branches10:08
vilamwhahah, you want to make our compat overlord cry ?10:09
wgzwell, I *run* a pre-2.2 version as my base bzr on this box10:13
wgzokay, with trunk testtools, get three:10:15
wgzAttributeError: 'module' object has no attribute 'ExtendedTestResult'10:15
wgzwill roll back to 0.9.810:15
wgzthere's a change I fixed that in I could backport to 2.210:15
* vila nods and notes that 0.9.12 seems possible (this will have my preference)10:18
wgzno s- bt.test_selftest errors with 0.9.810:20
wgzI'll do a more extensive subset and see if there's anything else, but I expect it to be okay10:21
wgzokay, two doctest isolation problems that weren't backported...10:24
wgzdammit! was a laptop hardware bug10:32
wgzcan probably transfer to the right box now10:32
vilawgz: "laptop hardware bug" ? Related to testtools ?10:38
mgzyeay! and it's still morning10:38
mgzno, related to me not being able to get on the network this morning10:39
mgzenabling then disabling the wireless made the wired hardware start responding10:39
mgzwill have to remember that for next time.10:40
mgzso I don't spend quite as long checking the cabling...10:40
wgzhttp://float.endofinternet.org/xmlbin/2.2_testtools_0.9.810:42
wgzall known issues, nothing testtools related10:43
vilaso 0.9.8 is a valid alternative for bzr-2.2 ?10:43
wgzyup.10:43
vilajml, mthaddon : ^10:44
vilajml: is that ok with you or do you need 0.9.12 somewhere (in which case, when ? ;)10:44
mthaddonvila: that's great, thx10:45
mthaddonvila: we'll go with 0.9.8 for now10:45
vilawgz: I never know how to interpret (grok?) these pages10:46
wgzclick on the little coloured boxes10:46
* vila nods10:46
vilabut how can I conclude: nothing wrong here10:46
wgzwhat I did was:10:47
vilafor the whole page without clicking on all red (only ?)10:47
wgz1) see there was no big red bar for any of the rows10:47
wgzthat would indicate a test module failed to import10:47
wgzthen 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 different10:48
vilaha, ok10:48
wgzideally, you'd just look at the whole page and go "no red or orange!"10:48
wgzbut the testsuite isn't quite that solid10:48
vilayeah, now I understand that I can't get that without practice ;)10:49
wgzeg:10:49
wgzhttp://float.endofinternet.org/xmlbin/2.2_testtools_0.9.8#bb.test_version.TestVersionUnicodeOutput.test_unicode_bzr_home10:49
wgzthis is a problem with the test, and the design of trace10:49
vilahehe, I almost mentioned just that one :)10:49
wgzthe test wants to escape isolation and get real `bzr version` output10:50
vilahttp://float.endofinternet.org/xmlbin/2.2_testtools_0.9.8#%28doctest%29bzrlib10:50
wgzand fails if trace.enable_default_logging() hasn't been called10:50
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 isolation10:51
vilaoh, ChrisCauser encountered an issue in a script even after calling bzrlib.initialize() bug #90521810:51
ubot5Launchpad bug 905218 in Bazaar "bzrlib.initialize() misses out the default prober" [Undecided,New] https://launchpad.net/bugs/90521810:51
wgzright, we have a bunch of issues that selftest doesn't catch by default because it generally runs in a fully set up environment10:52
wgzthe import tariff type tests are a way around that10:52
vilaa job for a subprocess test10:52
wgzhttp://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/5494 <- fix for that bzrlib doctest issue10:55
vilaand you're still based on 2.2 because this runs with ?10:55
* vila tries to refresh his memory ;)10:56
wgz...without testtools :)10:56
vila:-D10:56
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 ;)10:57
wgzha, okay, with trunk the only new errors are in <http://zippedmartin.dyndns.org/xmlbin/newtestresult#bt.test_selftest>11:16
hrwjelmer: like promised: bug 905275 reported11:16
ubot5Launchpad bug 905275 in bzr-git (Ubuntu) "git clone bzr::lp:armel-cross-toolchain-base creates duplicated tags" [Undecided,New] https://launchpad.net/bugs/90527511:17
wgzthe bad part is the fix for that is from my testcase collection branch, so there's no direct backport possible11:17
vilawgz: gut feeling == skip those tests for 2.2 and be done11:19
vilawgz: if this is enough to allow us to use 0.9.12, the risk is negligible11:20
wgzthough... I do have one neat rev for it: <http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/5340.12.7>11:20
vilawgz: would be clearer with from bzrlib.testools.testresult import doubles11:21
vilawgz: but small enough as it is for SRUs11:22
vilaerr, but good enough as it is, being small, for SRUs11:22
vilawgz: could you update the bug with a summary/bug task creation whatever you feel appropriate :)11:23
vilawgz: and thanks a lot, that's far clearer now, death to FUD ! :)11:24
wgzwill just test 2.3/2.4 as well while here11:26
niemeyerHey all11:57
niemeyerQuick question:11:57
niemeyerOnce one "bzr update -r N", how to tell which revision the current working tree currently represents?11:58
niemeyer"bzr revno" still shows the tip11:58
wgz`bzr revno --tree`11:59
vilajelmer: 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-svn12:09
vilajelmer: I'll switch to BZR_PLUGIN_PATH-site12:09
vilajelmer: I'll switch to BZR_PLUGIN_PATH=-site12:09
jmlvila: 0.9.8 is a valid alternative. 0.9.12 is at the mercy of a willing volunteer to package12:25
jmlvila: which might end up being me, but others are welcome to go ahead.12:25
vilajml: thanks for confirming12:43
wgzbah, initialize is still a mess12:50
wgzpass setup_ui=False and you get a traceback12:50
wgzwhat's needed to get the old (quiet) behaviour bad again: <http://paste.ubuntu.com/772153/>12:55
vilawgz: 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 want13:13
wgzyeah.13:14
vilatests 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 block13:15
vilashould scale for threads too13:15
vilathis 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 API13:16
vilameh and tests of course13:16
wgzsee r6210 as well13:23
vilahehe, yeah, I know this one :)13:31
vilaI don't like the global_state=None approach hence my "provides a sensible default behavior when importing bzrlib"13:31
vilain other words, let's initialize *something* cleanly and *then* give ways to tweak13:32
=== yofel_ is now known as yofel
adiroibanHi. I am getting this error: 14:59
adiroibanbzrlib.errors.IllegalUseOfScopeReplacer: ScopeReplacer object 'StringIO' was used incorrectly: Object already cleaned up, did you assign it to another variable?: _factory14:59
adiroibansecond time I call branch = bzrlib.branch.Branch.open_containing(self.url)[0]14:59
adiroibanany idea what is wrong?14:59
wgzwe need more context to know what's going wrong, it's a symptom of lazy import misuse15:00
wgzso, full traceback, and ideally the module with your code as well?15:00
adiroibanI am trying to fix the buildbot, bzrpoller15:01
wgzah... it's an error in trace15:01
wgzfrom bzrlib.lazy_import import lazy_import15:01
wgzlazy_import(globals(), """15:01
wgzfrom cStringIO import StringIO15:01
wgz...15:01
adiroibanhttp://pastebin.ubuntu.com/772280/15:01
adiroibancall is at line 28715:02
wgzyou can probably avoid it by doing `with bzrlib.initialize(): your_main()` in your script15:02
adiroibanaha15:02
adiroibanso the bzrlib.initialize() should be called only once?15:03
wgzfile a bug against bzr, because the bad code is in bzrlib.trace15:03
adiroibanok. I will file a bug. thanks!15:03
wgzand yes, the fix is probably just to make init happen once at the right time15:03
wgzinclude the full traceback in the bug, and say what you run to hit it15:05
adiroibanany suggestion for the title?15:06
adiroibanor just put any title that will be updated15:06
adiroibanif required15:06
wgz"IllegalUseOfScopeReplacer from replacement of StringIO" or something15:06
adiroibanok15:06
lamalexHi, is there any way to get bzr-builder to use pbuilder to build its package?15:09
jelmerlamalex: at the moment, no15:11
jelmerlamalex: though you should be able to use --no-build and then use pbuilder manually15:11
adiroibanwgz: 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 error15:13
wgzadiroiban: could also just be a race, which we have a bug for already15:13
wgzbut it's config not trace that needs fixing, I guessed wrong15:14
adiroibanwgz: unfortunately I am stuck with python 2.5 so I am using bzr 2.3.415:15
wgzso, try "from bzrlib import config; config.StringIO()" before spawning threads15:15
wgzwhich will deal with that particular one at least15:16
adiroibanit seems like config.StringIO() solve the problem...15:16
adiroibanthanks!15:16
lamalexjelmer, ah, that's a good idea15:22
lamalexjelmer, i was looking through the source to try and find where it actually builds and i can only find where it builds the source package15:22
jelmerlamalex: it doesn't build binary packages at all15:25
lamalexoh, ha15:26
lamalexbut --no-build and pbuilder should work for building a binary package15:26
jelmervila: what's the easiest way to create a stack from a string?15:49
vilajelmer: a store from a string and then a stack from a store like I did for your commit builder branch ?16:04
jelmervila: ah, thanks16:05
vilabzrlib.tests.test_commit.py16:05
vilajelmer: and hi ! :)16:06
* vila scrolls back for stacked questions16:06
vilajelmer: 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
ubot5Launchpad bug 904704 in bzr-builddeb "non utf-8 encoded changelogs cannot be parsed with recent python-debian" [High,In progress] https://launchpad.net/bugs/90470416:08
vilaalso, ChrisCauser encounter a weird issue: bug #90521816:08
ubot5Launchpad bug 905218 in Bazaar "bzrlib.initialize() misses out the default prober" [Critical,Confirmed] https://launchpad.net/bugs/90521816:08
vilajelmer: I thought the prober could ring a bell with you16:09
jelmervila: yep, target 2.8 and mark as fixcommitted16:09
jelmervila: yeah, that makes sense16:09
jelmervila: we don't import bzrlib.bzrdir necessarily16:09
jelmervila: so we don't register the prober for .bzr in some cases. We should probably import bzrlib.bzrdir from bzrlib.initialize()16:09
vilabut the end result is that open_workingtree ends up raising NotABranch because no prober is registered16:10
jelmervila: right, because we haven't registered the prober for .bzr/16:11
vilaa bit weird that importing workintree.py doesn't trigger importing bzrdir.py...16:12
vilaand also why wasn't it the case for bzr-2.4 ? (Probably more lazy loading related)16:12
jelmervila: yeah, more lazy loading16:12
jelmervila: there isn't much in bzrlib.workingtree that is bzr-specific16:13
jelmervila: so nothing uses bzrlib.bzrdir16:13
vilayeah, wt.py vs wt4.py ?16:13
jelmervila: right - wt.py just contains the main API, which is shared by bzr and foreign formats16:13
jelmervila: 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:14
jelmerI think in bzrlib.workingtree16:15
jelmeras we're already doing something similar in bzrlib.branch and bzrlib.repository16:15
vilaor registering the bzr prober lazily somehwere ?16:15
vilaha, that's probably best then16:15
ChrisCauserjelmer: Thanks a lot for the help with #90521816:31
jelmerChrisCauser: np16:33
jelmerwe've been reducing the number of imports that bzr does at startup time, and that's now biting us16:34
ChrisCauserjelmer: 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 it16:38
vilajelmer: worth mentioning in the what's new ;)16:43
jelmervila: what is?16:44
vilajelmer: more lazy loading => bzr quicker16:45
jelmervila: ah, yeah16:45
wgzwow config_dir is called too many times... <http://float.endofinternet.org/xmlbin/dev_testtools_trunk#bb.test_version.TestVersion.test_main_version>17:13
jelmerwgz: hmm, how can you tell?17:15
jelmerah, I see now17:15
jelmerwell, GlobalStore is called very often17:16
vilaIf it's now called more often than GlobalConfig, I call it progress ;-)17:18
wgzis there a reason test_osutils.TestGetuserUnicode tests use LOGNAME rather than USERNAME?17:18
wgzI broke them because LOGNAME is meaningless on win.17:19
vilawelcome to environ and its standardS17:19
wgzokay, I have a kinda-plan with directories17:26
wgzon startup, bzr should resolve and prepare any well known locations it needs, then stash them somewhere obvious (ie... fix global_state)17:26
wgzso, this is the 'home' config location, a cache directory, whereever we think .bzr.log should go... anything else?17:27
wgzcurrently 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 piecemeal17:28
jelmerhmm17:44
jelmerI 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 file17:45
mgzwould be nice if pathconf didn't suck17:46
mgzalas, it does.17:46
Pengjelmer: Could create a file once and then stat() it everafter.17:46
PengHmm, that'd be a problem if it was moved onto a different fs that did or didn't support the exec bit...17:47
mgzPeng: also, some C libs emulate the exec bit based on file extension17:48
jelmerPeng: yes, and file systems that don't support the X bit have different defaults for the executable bit.17:48
mgzrather than actually storing a bit with the file17:48
mgzjelmer: so, it's easy to discount support in a few cases17:50
mgzproving support is hard17:50
mgzthough not quite as hard as proving bug-free support :)17:50
mgzyou could cover the common cases if you can use (and trust) a syscall to give you the filesystem type17:52
mgzI bet nfs makes life hard there though17:52
jelmermgz: I agree the sensible thing to do is:17:53
jelmer* assume win32 doesn't support the executable bit17:53
jelmer* on other platforms, assume the executable bit is support unless we can somehow determine that it definitely isn't17:54
vilaconf.set('xxx', ''), val = conf.get('xxx') , val == '""' >.<17:54
jelmeryeah, a configuration option would indeed also be a possibility17:55
jelmerI wish we had a per-tree configuration though..17:55
vilanah, was mentioning the siliest bug ever, re-read17:55
vilasetting a conf option to '', re-reading it, get '""', not ''17:56
jelmerah :)17:56
mgzheh17:56
vilaconfigobj apparently, been there since epoch17:56
vilawhy we never ran into it....17:57
mgzokay, I'm going to finish off the lazy_import threading branch17:58
mgzwon't help people marooned on bzr 2.3 like earlier, but the current code is insane compared to MvG's17:59
jelmermgz: cool17:59
jelmermgz: I think I found an alternative18:00
mgzdoing a fix for that dumb use of StringIO on 2.3 onwards is probably also worthwhile18:00
mgzjelmer: do tell18:00
jelmermgz: it's not exactly ideal but better than what we have now18:01
jelmermgz: use stat('.bzr/format') to get st_dev18:01
jelmerthen use getmntent to find the file system type..18:02
mgzand nfs won't be clever and lie18:03
mgz?18:03
jelmermgz: well, we'll get back "nfs" for nfs mounts18:03
mgzif so, that's worth doing.18:03
jelmermgz: and there's no way of knowing what the underlying fs is, but we can just default to assuming it supports the executable bit18:04
jelmermgz: at least it means we'll get it right for FAT, etc18:04
mgzwell, or fall back to trying a dance18:04
mgzif we can trust 'ext4' (ho ho) then at least the common case doesn't need funny business18:04
vilaand we'll keep assuming that's true for the whole wt18:05
mgz...can anyone think of a reason not to use trace.mutter from inside lazy_import resolution?18:06
jelmermgz: overhead?18:06
vilatrace lazy import18:06
mgzonly for duplicate resolution, so not all the time... will double check the loop issue18:07
jelmermgz: still there?19:20
mgzjelmer: yup, just had a break for dinner19:43
mgzdid the basic simplifications I suggested for the lazy_import change20:37
mgzbut wonder if there isn't a proper race-aware way of doing this20:37
mgzwhere the first thread to both get, and delete, scope, gets to do the work20:38
mgzthis could mean other threads are stuffed waiting for it to finish I guess, so deadlock20:39
mgzmeph.20:39
mgzcan still use that to work out if it's a race or a reuse though20:40
Noldorinhey folks20:45
Noldorinhi mgz20:45
mgzhey Noldorin20:45
Noldorinhow's... things?20:46
Noldorinsaw the b4 release of 2.5 :-)20:47
Noldorinlooking good20:47
mgzgetting there :)20:52
Reggiecan 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 C21:48
Reggiewhat's the easiest way to remove it from A and B?21:48
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 it21:49
Reggiethanks21:49
jelmerhi Reggie21:55
Reggiehi21:55
jelmerReggie: bzr uncommit is what you're looking for probably21:55
PengIt sounded to me like it was too late for uncommitting.21:56
Reggiedev commited locally and then pushed to remote branch21:56
wgz<http://doc.bazaar.canonical.com/beta/en/user-guide/adv_merging.html#reverse-cherrypicking>21:56
wgz<http://doc.bazaar.canonical.com/beta/en/user-guide/undoing_mistakes.html#undoing-the-last-commit>21:56
Reggiethen merged up to B and C locally and pushed them21:56
Reggienow we need to remove the last changeset on the remote repos A & B21:57
wgzwhether you want to uncommit or merge a reversion depends on how public the branches in question are21:57
Reggiethese are not public21:57
Reggieinternally hosted21:57
wgzif lots of people use them, they'd get confused if you rewrite history on them by removing the commit entirely21:57
Reggienot an issue21:58
wgzthen uncommit and email to everyone saying "whoops" is generally fine21:58
Reggiehere 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
Reggiedo I need to do the bzr uncommit on the remote repo?21:59
wgzyeah, you just pass it as the location21:59
wgzso, `bzr uncommit A` `bzr uncommit B`22:00
Reggiewill repo C get confused?  the change needs to be in C  (these repos are chained together)22:00
wgzdepends how you did the merge.22:00
wgzyou can branch all three locally, try it out and see22:01
wgzthen do it for real when you have the state you want22:01
Reggiedevs 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 push22:01
Reggiemake sense?22:02
wgzthis is getting out of basic fixing a mistake, and into workflows22:02
wgzwhat would the correct series of operations have been?22:02
Reggiemake change in C and push only to C22:02
Reggieinstead dev thought the fix should go all the way back to A22:03
Reggiethis is a single product versioned.  vesrion A, vesrion B, version C22:03
wgzand C is newest.22:03
Reggieyup22:03
wgzuncommit on all three then do it right is fine then.22:03
Reggieany big problem with overwriting the changed files with files from revision-1 and doing a new set of commits/pushes?22:04
wgzif 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
ReggieI say that because repo C may be already been changed by others so uncommit there might be challenging22:04
wgzif you can replay the new changes on C that's also fine, but deeper into history rewrite territory22:05
Reggieyes, 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 C22:06
Reggiethe bad change is the very last change on A & B but it's not the last change on C22:06
wgzthat 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
Reggieright22:10
Reggie:)22:10
wgz`bzr revert *` rather.22:10
wgzyou want to keep the merge, but not the changes.22:11
Reggiewgz, thanks.  really appreciate the help22:11
Noldorinwgz, oh yeah, was going to ask. does bzr have 'service' plugins like hg does? like for notifying you when someone pushes?22:21
Noldorinon a bzr server22:21
Noldorinthat is22:21
Noldorinalso, does LP specifically have them?22:22
wgzbzr does, lp doesn't as far as I'm aware, but various things you can use for landing changes like pqm and tarmac can notify23:25

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!