=== Ursinha is now known as Ursinha-afk
glyphis there a 'bzr st --no-ignore' or equivalent?02:16
beunoglyph, maybe bzr ls --ignored?02:26
spivglyph: there's the separate 'bzr ignored', but I guess you're after what bzr thinks of all files in a given directory?02:26
spiv(if so, 'bzr ls' with various flags is probably the way to go)02:28
spivglyph: Also, '--no-ignore' is pretty much what bzr st already does: show no ignored files ;)02:29
glyphspiv: "no ignores" not "no ignored" :)02:31
glyphspiv: I want a complete enumeration of all files, with none of them ignored, to do something programmatic (in a shell script) to a bzr working tree.02:31
spivglyph: bzr ls -iVuR, perhaps with added -v02:32
spivAnd -002:32
spivWhat's the something, out of interest?02:33
glyphhuh.  What's 'V' mean in that output?02:33
glyphspiv: revert for reals02:33
glyphspiv: an operation which, curiously, no version control system implements02:34
spivglyph: 'bzr revert && bzr clean-tree --detritus'?02:37
glyphspiv: <302:37
glyphnope, still doesn't quite work02:38
glyphit doesn't delete '.moved' directories, apparently.02:38
glyphoh wait, no, it works02:38
glyphI just wanted 'bzr clean-tree --unknown --detritus --force'02:38
spiv(FWIW, the 'V' in that output means 'versioned', I think)02:39
spiv(not that you care now :)02:39
glyphwait no... 'bzr clean-tree --ignored --unknown --detritus --force'02:39
glyphwhy isn't that the default02:39
glyphyou could make the default behavior be invoked via 'bzr clean-tree --not-really'02:39
spivBy default it deletes unknowns.02:40
spivWhile leaving potentially valuable ignored files.02:40
spivArch had a sometimes useful distinction between 'junk' (always safe to delete) and 'precious' (not versioned, but don't delete automatically)02:41
spivI occasionally wish we'd kept that, although I think probably that level of complexity probably does users more harm than good.02:42
spivAnd of course no categorisation is ever perfect: sure .pyc files are almost always junk or explicitly versioned, but maybe you don't want your vcs to randomly delete .o files that are expensive to rebuild.02:44
spivExcept when you do...02:44
spivAnyway, I'm glad I've saved you from some shell scripting :)02:45
* spiv -> lunch02:45
glyphyou may have saved me even more than you thought02:45
glyphdoes this work for svn too?02:45
glyphHaha it does02:46
glyphoh crud, except there _are_ like 2 dotfiles I want to not delete02:48
spivglyph: easy!02:55
spivJust copy those files to /tmp and back :P02:56
spivglyph: actually, if you want to be slightly cunning,03:04
spivglyph: 'bzr revert; bzr add .dotfile1 .dotfile2; bzr clean-tree --yadda-yadda; bzr rm --keep .dotfile1 .dotfile2'03:04
glyphspiv: Cute.03:05
spivThere's no point doing the add before the revert, of course :)03:05
glyphspiv: I already implemented the other thing, but I might switch to that.03:05
spiv(The --keep is redundant in this case too, but explicitness and paranoia doesn't hurt)03:06
glyphspiv: you forgot the last 'bzr revert', too ;)03:10
spundunhi all... quick question03:28
spundunif I do bzr checkout URL03:28
spundunor I do bzr branch URL wd; cd wd; bzr bind URL03:29
spundunit seems to have the same effect03:29
spundunam I understanding that right?03:29
spundunchange the first version to bzr checkout URL wd03:29
glyphspundun: Yes.03:36
glyphspundun: 'bzr checkout' is an alias for creating a bound branch to make it easier on people who are familiar only with svn.03:36
glyphIf you just s/bzr/svn in your commandlines, everything basically works if you don't think too hard about it :)03:37
spundunah, ok03:37
spundunI find the concept weird that I create a branch using bzr branch URL, and then within that branch I can just do bzr push URL, then I'm not reall a branch anymore, I'm the trunk :/03:39
spundunby I, I mean my branch03:40
glyphspundun: But it is a branch: if you commit to it, it won't get committed to trunk.  You could push it somewhere else on the server, if you didn't want to push those revisions to trunk.03:40
spundunyes, I get that. But somehow in my mind, I shouldn't be able to push my branch back to the trunk, I should have to merge it or something...03:41
glyphspundun: consider: bzr get ...:.../trunk; cd trunk; hack hack hack; cd ../; mv trunk my-feature-branch; bzr get ...:.../trunk; cd trunk; bzr merge ../my-feature-branch03:41
spundunI guess the more I think about it, the more I'll get used to the idea03:42
spundunor something like that03:42
spundunthanks glyph03:44
glyphspundun: another way to think of it is that initially, a branch is a perfect copy of the thing it's a branch of.  you can push/pull between them to re-synchronize them, assuming they haven't diverged.  A merge is only necessary to resolve the conflict that occurs when two branches go in two different directions.03:45
glyphtrunk isn't "special", it's just a branch in a particular place that you've socially agreed is important to a project.03:45
spundunright, ok03:46
=== jdobrien_ is now known as webm0nk3y
jammorning all08:08
vilaoops, morning jam et all ;)08:08
jamI thought it was "et al"08:09
vilajam: do you know how doc.bazaar.canonical.com scripts are handled ?08:09
vilaargh, yes, it *is* et al08:09
vilathinko between english, french and latin ;)08:09
fullermdJust blame it on a typo.  We'll all believe you   :p08:09
vilaare 'al' and 'all' pronounced the same in english ?08:10
bob2no, latter is more like awl08:10
fullermdNot out of my mouth..08:10
fullermdBut 'al' isn't English, so it's a trick question, really...08:11
bob2it's a (short) name ;08:11
jambob2: I've always pronounced "et al" as in "pet" "all"08:11
jamAnd I agree more like "awl"08:11
jamdoesn't mean I pronounce it correctly08:11
bob2hm, I say et al(lan)08:11
bob2possibly people are too polite to correct me ;p08:12
jamsays it is supposed to be "et alii"08:12
jamor et alia08:12
vilalet's add some confusion: 'etal', in french, is where butler cut the meat ;)08:12
bob2I have even less idea how to pronounce et alli!08:12
vilabob2: probably like Italy ;)08:13
=== weigon_ is now known as weigon
vilamass_import.py up to 812M resident memory, "something" is leaking or python is *really* bad to manage its heap09:05
lifeless'manage'. lol.09:05
jamvila: 812MB for the driving script seems pretty excessive09:05
vilain other news nexuiz-data is still happily running at 100% CPU without producing any data in its log :-/09:05
vilajam: right, even 100M would seem excessive...09:05
vilalifeless: was the joke targeted at python or at my poor english (I guess the former but just checking) ?09:06
jamvila: python, as I understood it09:06
jam /wave lifeless09:06
lifelesshai :)09:07
vilaI can't remember if mass_import was already consuming that much memory when running for weeks before my driver changes...09:07
vilajam: any idea about poking at a running python script with meliae ?09:08
jamvila: if you can get a pdb console, you can get in with meliae09:09
jamI think there are some gdb tricks you can pull ,but none that I really know09:09
vilak, thanks09:09
jamI think Andrew mentioned using gdb to interrupt, then set trap at the trace function09:09
jamand then install pdb at that point09:10
jamthat way you know you aren't interrupting the middle of a python OP code, etc.09:10
vilaI think we should just kill this import then and try to reproduce the issue locally09:10
jamvila: you mean nexuis?09:10
jamif you had console access, bzr already installes SIGQUIT => pdb09:10
jambut I don't think you have console access to the builder process09:10
vilagiven it has been spawned from a cron script, I doubt I can get console access yes09:11
vilathe disturbing fact is that the log file hints that we are in the middle of a bzr operation09:12
vilaa commit09:14
jamvila: We've talked about a SIGUSR1 or SIGHUP handler that would just dump "traceback.format_tb()" into .bzr.log.09:15
vila10 days to process a commit is probably considered excessive too :)09:15
jamIt wouldn't be hard to create if you think it would be helpful09:15
jamvila: we may be inefficient, but 10 days is a little rediculuous09:15
jamI would say 1 hr is max, even for nexuis-data09:16
vilaoh, sorry, I've been slightly exaggerating, it's 99% CPU not 10009:16
fullermdOh, shucks, you made a new release...09:25
jamvila: well in that case, it is clearly not blocked :)09:26
vilajam: :)09:29
vilafullermd: yeah, by the way, any hint about why bzr-duilder is packaged for FreeBSD ?09:29
fullermd'cuz C-S packaged it.09:30
* fullermd glances at logs.09:30
* vila has no idea who Control-Super is...09:30
jamBetter than Meta-Super, that guy is a jerk09:31
vilaI'm pretty sure it requires some debian dependencies...09:31
vilaif not Ubuntu dependencies for that matter09:32
LeoNerdjam: He recently escaped09:32
vilaLeoNerd: ha ha09:32
vilausing an alternate exit ?09:32
vila. o O (Slowly but inexorably emacs progresses on all fronts ;)09:33
fullermdIf you're all through bucking around...09:33
vilaSawhorse Saw"horse`, n.09:34
vila A kind of rack, shaped like a double St. Andrew's cross, on09:34
vila which sticks of wood are laid for sawing by hand; -- called09:34
vila also buck, and sawbuck.09:34
vila [1913 Webster]09:34
vilaI'm so much informed now :(09:34
vilano idea about what a *single* St Andrew's cross is...09:34
fullermdIt's half of a double St. Andrew's cross.09:35
vilainteresting google images results... http://www.google.com/search?client=ubuntu&channel=fs&q=St.+Andrew%27s+cross&ie=utf-8&oe=utf-809:36
vilaI meant the union jack flag origin of course..09:38
vilaadding double to the search terms amazingly returns images with... two crosses... how smart... NOT !09:40
* fullermd declines to enquire into where vila's mind wanders...09:40
lifeless'double rainbow'09:41
vilawhat with the old mails spam from lists.ubuntu.com ?10:06
catphish_o/ high five10:39
catphishyou'll be relieved to know that i don't need any help today, everything is working nicely :)10:40
vilayeah !10:40
catphishhopefully i'm finished with being a pain for now10:40
vilahehe, you're not a pain, this channel is here to provide help ;D10:41
catphishand very helpful it is :)10:41
catphishby the way, my implementation is for http://www.codebasehq.com/10:42
vilawhy doesn't it mention bzr then :-p10:43
catphishbecause it's not ready yet10:43
vilagood, better than the opposite :)10:43
catphishwe're making a bunch of changes, some of which are announced10:43
catphishbzr support is not announced, just going to surprise people with it10:44
catphishplus i wanted to be sure it was going to work10:44
jmljelmer_: I saw your email to ubuntu-devel about showing authors11:07
jelmer_jml: I've heard the same concern Dave come up a couple of times before. What do you think?11:08
jmljelmer_: It reminded me of things I've wanted to do with bzr-stats11:09
jmljelmer_: get # of landings rather than # of commits.11:09
jmljelmer_: and it would make 'bzr log' way more useful for PQM-managed projects11:10
jelmer_jml: Yeah, indeed11:10
jmlI wonder how interesting it would be to do it in a plugin11:11
jmljelmer_: fwiw, I'd propose this output: http://paste.ubuntu.com/578777/11:12
jelmer_jml: I think we should have all the magic in place to do it in a plugin11:13
jelmer_"bzr log --format=boo"11:13
jelmer_that would be an interesting experiment11:14
jelmer_maxb: Do you have any thoughts on how we should deal with the dh_python2 transition ?11:16
jelmer_maxb: I guess we could either create separate recipes for the older distro series, or patch all of them to avoid dh_python2.11:16
jelmer_maxb: I'd prefer doing the first, otherwise we'll end up doing the patching forever.11:17
vilajml, jelmer: Are you talking about adding authors at commit time or extracting them at log time ?11:17
jmlvila: extracting at log time11:17
vilaas jelmer mentioned there are perfs issues (so far) and in the context of pqm, I think adding the authors at commit time would make far more sense no ?11:18
jelmer_vila: I think that would use up precious space in the revision text for some projects, and it wouldn't help with historical and foreign data11:19
jelmer_if it's too much of an issue I think a cache would be the best approach11:20
vilajelmer_: I was talking about *always* adding authors, only for projects that want it (and I was thinking plugin there, not core)11:23
jamvila: if you have -n0, then you have the information easily available11:24
vilasure, I thought the issue was to *not* use -n0 nor the implied perf penalty11:25
jamvila: without it, perf is going to suck quite a bit more, in semi-common cases11:25
vilaand ISTR that adding author in pqm context was mentioned in the past too11:25
jamdetermining non-common ancestors is pretty hard11:26
jamand doing it over-and-over again for each rev is pretty bad11:26
vilayeah but one day we'll have to fix that once and for all11:26
jamvila: could you do that tomorrow?11:29
vilait's on my TODO list, but pretty much at the bottom unfortunately11:30
vilaI just find it annoying that we keep spending time on workarounds :(11:31
maxbjelmer_: I've not thought about it - I'm planning to study the situation and form an opinion over the weekend11:33
jelmer_maxb: ok, I'll hold off for a bit then11:33
jelmer_jam: Did you see my followup to https://code.launchpad.net/~jelmer/bzr-email/drop-pre-0.15/+merge/49628 ?11:53
jamjelmer_: approved11:53
jelmer_jam: Thanks11:54
jamI did see it, but just didn't have anything else to add. "approve of the rest" covered my feelings, though it wasn't explicit11:54
awilkinsDo people think that branching  a working tree at a given revision should branch from that revision even if it's not the tip of the branch for that working tree?11:56
jelmer_jam: ah, ok11:56
jelmer_awilkins: That's a tricky one11:57
awilkinse.g.   bzr update -r N # where N is less than P which is tip revision ; bzr switch -b newbranch ; bzr revno # emits P not N11:57
jelmer_awilkins: It would be useful to warn the user in that situation.11:57
jelmer_awilinks: That said, I think it might require opening the dirstate file to figure out the revno of the working tree11:58
awilkinsjelmer_, A valid story would be - I bisected to find a bug, now I want to branch the revision that introduced it to fix it ala DaggyFixes11:58
awilkinsjelmer_, Probably, I know that qlog does something to work out the current revision because it marks it in the log11:59
awilkinsjelmer_, For switch -b it must be doing it anyway because it merges the new branch (at HEAD) to the one you have so you end up with a working tree of HEAD12:00
jelmer_awilkins: Yeah, but not for e.g. "bzr branch <remote-location>"12:01
awilkinsjelmer_, No, I don't think that is intuitive12:02
jelmer_awilkins: So, I think it makes sense to warn the user if they try to branch from a location where there are both a working tree and a branch with the tip out of sync12:02
awilkinsjelmer_, I think I'm really only thinking about local branches and lightweight checkouts12:02
jelmer_awilkins: I don't think we should be inconsistent in the way we treat local and remote branches12:03
awilkinsjelmer_, I agree that's a useful warning ;  I found the idea that once I had updated my lw checkout to a particular revision that switch -b would branch that revision to be intuitive and the result (branching the HEAD of the branch bound to the checkout) to be understandable but disappointing12:04
jelmer_awilkins: Is there a particular reason why you're only switching your working tree rather than your working tree *and* your branch tip ?12:05
awilkinsThe -b implies that I'm creating a branch tip and switching to it12:05
awilkinsOr are we driving at different things? My work setup is typically lightweight checkouts12:07
jelmer_yes, but why do you use "bzr up -r" ? It causes the working tree tip and the branch tip to be different12:07
awilkinsIn this case, I am bisecting somewhat manually12:07
awilkinsI have located the revision with the bug in it and wish to start a new branch with this revision at it's tip so I can fix it12:08
jelmer_ah, hmm12:08
jelmer_so perhaps we should allow you to do something like "bzr switch -b newbranch -rtree:"12:09
awilkinsI was just going to suggest bzr switch -b newbranch -r `bzr revision-info` ; but apparently revision-info does not respect dirstate12:10
jelmer_awilkins: it has a --tree option12:10
awilkinsjelmer_, Aha, that's nice12:11
maxbA dirstate-based revspec would be lovely though12:12
maxbespecially for access to pending merge tips12:12
* jelmer_ files teh bug12:12
awilkinsAh, and switch -b -r does not behave as you'd want12:14
jelmer_yeah, please file a bug about that12:14
awilkins$ bzr switch -b -r 201 fix-update # Tree is up to date at revision 233.12:14
jelmer_well, you'd want an argument to -b12:15
jelmer_ah, you have - sorry12:15
awilkinsAh, yes, not an arg to be, arg to command12:15
awilkinsIt doesn't respect the revision argument for either case, branching or non-branching12:17
mgz<jam> vila: We've talked about a SIGUSR1 or SIGHUP handler that would just dump "traceback.format_tb()" into .bzr.log. <- there's still a good chance this would kill the ongoing operation, given how dodgy signals are12:22
vilamgz: true and hi !12:23
mgzand SIGTERM already dumps the current stack as it exits, right?12:23
* mgz waves at vila12:23
vilahmm, that would at least gives us a hint...12:24
vilafullermd: I'd like to install sphinx for some tests, but it seems it's available only for py27 :-/12:36
vilafullermd: I don't want to play around with 2 different versions of python on my babune slave, so, is bzr packaged for 2.7 and if not when/why/what ?12:36
vilaha, finally the true jelmer is back...12:44
jelmerI had a nouveau freeze :-/12:46
awilkinsAre the docs on the website in the main source tree? I've spotted a bug asking for some clarification in the Visual Sourcesafe docs I wrote but I can't remember where the doc sources are ....12:49
maxbdoc/... :-)12:50
jelmerawilkins: most of the docs live under doc/en in lp:bzr12:50
vilaawilkins: it depends, but doc.bazaar.c.c are mostly in... too slow for jelmer :)12:50
jelmervila: and for maxb :)12:50
vilaerrk, didn't even saw this one ;D12:50
vilaon the other hand, the shortest answers came first :)12:51
awilkinsYeah, can't find http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-vss-users.html there though.12:51
awilkinsI should know, I wrote it12:52
vilaparent branch: http://bazaar.launchpad.net/~bzr/bzr-migration-docs/trunk/12:53
vilajelmer: thanks for the review !14:06
jelmervila: np14:29
* jelmer resubmits his lazy-bzrdir branch14:32
jelmermaxb: Hmm, weren't all the issues with running the bzr-dbus testsuite on a buildd fixed now?14:35
* jelmer is still getting failures building for sid14:35
maxbWell, the recipe build seems happy14:44
maxbGot a link to the sid buildlog?14:44
jelmerthere isn't one - I'm building locally14:45
jelmerI'll pastebin14:45
jelmermaxb: http://pastebin.ubuntu.com/578852/14:49
maxbah, I remember that test, that's the one which tries to connect to a dbus session bus running outside the context of the build14:50
maxbhttp://bazaar.launchpad.net/~bzr/bzr-dbus/trunk/revision/47 was my attempt to skip it when appropriate14:51
maxbI guess my "when appropriate" check isn't working out quite right for you14:51
jelmeractually, I see what's happening14:52
briandealwisspiv: I've been seeing if I could duplicate that strange locking problem.  Doesn't work on a cooked up example.  But it always happens with a particular branch.  -Dlock doesn't show anything out of the ordinary (to me).  Are there any other debug switches I could try?15:01
jelmerbriandealwis: I bet spiv's asleep15:02
jelmerbriandealwis: if this is a bzr+ssh:// issue you were trying to debug -Dhpss might help15:02
briandealwisah, he's showing green15:02
briandealwisIt's a local issue.15:02
briandealwisI have two branches, p1 and p2 that have a common ancestor.  Trying to push from p1 to p2 results in a strange self-locking problem15:03
jelmermaxb: fixed it by starting a temporary dbus session15:03
briandealwisI wasn't having this problem in 2.2.x; maybe I'll try some bisecting.15:04
mgzbriandealwis: what's the bug number?15:08
briandealwismgz: haven't filed a bug yet, sorry.15:09
briandealwismgz: will do that next15:09
briandealwismgz: finally filed as bug 73335016:17
ubot5Launchpad bug 733350 in Bazaar "LockContention error when pushing to a bound branch" [Undecided,New] https://launchpad.net/bugs/73335016:17
jelmervila: Thanks for the review, I'll add some docstrings.16:23
jelmervila: it's not just bzr-svn that adds itself to the beginning of the server prober list, bzr-hg and bzr-git do as well16:23
vilajelmer: thanks for your persistence there ;)16:23
vilajelmer: one more reason to discuss a saner scheme, the issue has existed for far too long16:24
vilajelmer: and even if your work allows more lazy loading, ISTM that bzr-svn users still pay a penalty when they work with bzr branches only right ?16:25
jelmervila: they do an extra OPTIONS request when talking over http, but that's all at this point16:25
jelmerI added some hacks to do that OPTIONS request over the existing HTTP connection, rather than building up a new connection.16:26
vilajelmer: and you manage to not load any modules that won't be needed if the probe fail ?16:26
vila. o O (I'm tired, I'm sure this could expressed in a simpler way :-/)16:27
jelmervila: yes, that's the point of the probers. the prober implementations live inside the plugin __init__ and only load the actual stuff when they find something16:28
vilaha ok, so the lazy loading addresses the remaining issues then16:29
vilajelmer: about the OPTIONS stuff, wibni (once you land you hacks in core ;) the smart server was adding its own option too ?16:31
jelmervila: what's wibni ?16:32
vilaWouldn't It Be Nice If ? or did I mangled that ?16:32
=== beuno is now known as beuno-lunch
mgzbriandealwis: is that info at the bottom for the trunk branch? if so, the push branch value is odd, try editing .bzr/branch/branch.conf to remove it16:33
jelmervila: no, you didn't... just an acronym I didn't know yet :)16:33
briandealwismgz: you're right, I made a mistake: it's from the workspace branch16:33
jelmervila: Yeah, it'd be nice to add an OPTIONS entry for the bzr smart server.. though we should probably still support the POST request in case the user is e.g. using a cgi script16:33
briandealwismgz: I've been able to reproduce the issue from a synthetic branch — it hinges on tags16:34
vila. o O (There you are, people are so used to your tyops that they see tyops even when you type correctly)16:34
mgzokay, in which case the odd thing is is *also* thinks it a checkout of backup?16:34
mgzthat's not intended surely16:34
vilajelmer: sure and for older clients too, but still16:34
mgztags being what's broken seems likely, spiv added some new behaviour there.16:35
briandealwismgz: I bind "trunk" to "backup", where "backup" exists on a different drive.  So pushes to "trunk" are backed up16:35
mgzbut the fix for you should probably just be editing a conf file.16:35
mgzbriandealwis: but what is 'workspace'? A normal branch? a checkout?16:35
briandealwismgz: a normal branch16:36
mgzthe info posted is of a checkout.16:36
briandealwismgz: now I'm confused :)16:37
mgz`bzr info` on workspace should say it's parent branch is trunk, and have no checkout bits16:37
mgz`bzr info` on trunk should have no parent branch, and say it's a checkout of backup.16:38
mgz`bzr info` on backup should just say it's a normal branch.16:38
briandealwismgz: I was right originally: it was from "trunk"; that was info carried when branching from my original branches16:38
briandealwismgz: I removed the stray info, and it makes no difference16:39
briandealwismgz: I'll add a synthetic example that demonstrates the bug in a sec16:39
mgzah, you've got one now?16:39
briandealwismgz: yeah — it's all about pushing with tags16:40
briandealwismgz: I used bisect to identify the problematic commit.  if you look at it, it adds some locking.16:40
mgzyup, I can repo too with that.16:41
vilajelmer: I'm very tempted to give you the green light to land all the weave-in-a-plugin stuff16:45
jelmervila: \o/ Did you see the intermediate branch, bzrdir-weave ?16:45
vilajelmer: since you raise an error if the old_register_format is used, the worst that can happen is that people running trunk will have to revert if they encounter issues16:46
vilajelmer: did you see my reviews ;)16:46
jelmerclearly I haven't :)16:46
vilajelmer: and I'm sure you will be motivated to fix any bugs if that's the case16:46
jelmeryeah, of course16:47
briandealwismgz: I tacked on the example16:47
mgzyup, that's similar to what I got to fail.16:48
vilajelmer: with 2.4b1 close to freeze, I tend to prefer landing now than wait for a second review which will requires more effort from the reviewer than your own efforts to fix the hypothetical fallouts16:48
vilamgz: any progress on https://code.launchpad.net/~gz/bzr/create_delta_index_memoryerror_633336/+merge/52251 ?16:49
jelmervila: sounds good to me - most of it is just moving code around now anyway16:49
vilamgz: I didn't review closely but I was wondering if your actual fix was already viable ?16:50
mgzyeah, I'm going to give in and rewrite those two functions to take **struct and return a code rather than *struct16:50
mgzit's a bigger change, but there's no point trying to keep a limited api when they need sensible error handling.16:51
vilamgz: ha ! Yeah, when you're tired to override, using distinct objects help express better semantics ;)16:52
mgzdarnit, what's the trick for getting the mainline rev a dotted rev was merged in? I always forget it and give up and use qlog instead.17:03
vilamainline: ?17:05
mgzhttp://paste.ubuntu.com/578908/ <- and the number of times I do this as well, env-variables is particularly painful17:07
vilamgz: bzr help topics17:07
mgzyeah, but `bzr help topics | grep env` is just as annoying to type every time17:08
vilamgz: which is itself mentioned in 'bzr help'17:08
mgzso, I try and remember and get it wrong a few times.17:08
mgzwhy, for instance, is 'environmental' abbreviated, but 'variables' is not?17:09
vilayeah, this needs to be reworked, revisionspec is another bad example17:10
maxbIt should probably be 'environment-variables' with an alias of 'envvars'17:11
vilaor may be bzr-guess could be extended to handle help topics and merge in core17:12
vilaI thought Parth worked on a bit on that at some point...17:12
mgz^thanks, mainline works, presumably new in 2.2 or 2.3 though.17:13
vilayup, I'd say 2.317:13
mgzright, I need some food, then I'll write a little code.17:15
=== deryck is now known as deryck[lunch]
=== beuno-lunch is now known as beuno
vilamgz: mah, my memroy was bad, help topic guessing has been *disabled* in revno... 2 :-(17:57
jelmervila: argh, test isolation failure :-(18:30
vilajelmer: caught by pqm ?18:31
jelmervila: yep18:31
vilawhich branch ?18:32
jelmervila: lazy-bzrdir18:32
jelmervila:  bzrlib.tests.test_remote.TestBzrDirCloningMetaDir.test_current_server happens to fail because the returned control dir suddenly has its repository format set to 2a18:33
jelmerthe cause seems to be the fact that we now run the per_controldir tests against RemoteBzrDirFormat18:33
vilawhy do you suspect an isolation issue ?18:34
jelmervila: I can reproduce it locally. "./bzr selftest -s bt.test_remote" succeeds, "./bzr selftest -s bt.per_controldir -s bt.test_remote" fails18:34
* jelmer wonders what the best approach is to debug this sort of thing18:35
vilathey are all painful18:35
jelmeris there any particular function that gets called after each test?18:35
vilaprobably, never tried that approach though18:36
vilawhat I generally do is establish a list of tests including the failure and bisect it18:37
maxbjelmer: Concerning bzr-rewrite packaging - is it correct to drop the "Replaces: bzr-rebase" whilst retaining the Conflicts?18:37
vilajelmer: as an aside, just trying to run bzr with my current trunk of bzr-hg crashes with NotImplementedError: <bound method type.known_formats of <class 'bzrlib.plugins.hg.HgProber'>>18:38
vila--no-plugins time is back :-/18:38
vilaseems to be in bzrlib.tests.per_controldir.test_push.TestPush18:43
=== deryck[lunch] is now known as deryck
jelmervila: Can you try again with trunk?18:45
vilatry what with which trunk ?18:45
viladon't lose focus on the crash, different people will have different issues, we'll see later :)18:46
vila./bzr selftest --no-plugins -s bzrlib.tests.per_controldir.test_push.TestPush.test_push_new_empty -s bzrlib.tests.test_remote.TestBzrDirCloningMetaDir.test_current_server18:47
vilais enough to reproduce18:47
vilaas often with isolation issues...18:53
jelmervila: I think I found the test isolation issue18:53
vilayes ?18:53
jelmerone of the fallback cases for RemoteBzrDirFormat modifies the RemoteBzrDirFormat in-place18:54
jelmerin some of the other cases we use .__class__() to create a new copy and modify that18:54
jelmer./bzr selftest --no-plugins -s bzrlib.tests.per_controldir.test_push.TestPush.test_push_new_empty -s bzrlib.tests.test_remote.TestBzrDirCloningMetaDir.test_current_server passes in bzr.dev for me18:56
jelmersince you mentioned bzr-hg earlier, are you sure you mean with --no-plugins ?18:57
vilapass for bzr.dev here18:57
vilaeven without --no-plugins18:58
vilacrash in the lazy-bzrdir without --no-plugins18:58
vilarevo 401 for bzr-hg18:58
vilajelmer: gotta go, happy hunting :-}19:04
fullermdvila: *yawn*19:04
fullermdvila: py27 was actually switched to the default earlier this week...   I haven't pulled the switch yet.19:05
fullermdvila: 'member you're _building_ via ports, so it's not a question of 'packaged against'; it builds against whatever you've got installed.  So switching to 2.7, and rebuilding py* and bzr (maybe 1 or 2 other bits?) would do the job.19:07
vilafullermd: thanks ! My notes from the py26 upgrade says: http://paste.ubuntu.com/578954/19:12
vilafullermd: so, IIUC, I should do the same, I may a bit for things to settle down in ports no ?19:12
fullermdPretty much, just s/26/27/ and s/25/26/ all 'round.19:12
vilaI should really go now, gf is waiting ;)19:13
fullermdIt should probably be OK, else they wouldn't have pulled the default switch.19:13
vilak, I'll do a vm backup first anyway19:13
catphishdoes anyone know how i might go about converting a filtered-139770606741392:// url to a real path?22:59
jelmerhi catphish23:01
catphishhi jelmer23:02
jelmercatphish: I have no idea, where are you getting that URL from?23:02
catphishyour code ;)23:03
jelmerI doubt it's *my* code :)23:03
catphishthe (c) has your name in lol23:03
catphishanyway, its changeBranchTipParams.__dict__['branch'].base23:03
catphishin a hook23:03
jelmercatphish: hmm, which file is that?23:04
jelmeroh, that's just coming in from an external source e.g. a smart server23:04
jelmerit's unrelated to the shell hooks plugin23:04
catphishyour original hook didnt support the changeBranchTipParams hook23:05
catphishso i don't suppose it ever came accross data from an external push23:05
catphishanyway it's branch.base23:05
catphishand it returns: filtered-139770606741392:///default/23:05
jelmerI think it predates the changeBranchTipParams hook23:06
catphishmakes sense23:06
catphishi assume it's a type of chroot23:06
catphishdo you have any thoughts how i might map it to the real path?23:07
jelmerhave a look at branch.root_transport23:07
jelmerit's probably some sort of special transport that wraps the actual transport23:07
catphishhmm, i don't see branch.root_transport23:10
catphishah, its a PathFilteringTransport23:15
maxbI was looking at this stuff just recently23:26
* maxb tries to remember things23:26
catphishi'm a little confused by why instance methods accept self as the first parameter, i'm not a python developer but that seems odd23:27
maxbcatphish: Unlike most languages, Python chooses to pass the instance reference as an explicit first parameter, which is conventionally called self23:27
maxbRather than defining a special keyword for it23:28
maxbI suppose you could call it "this" instead of "self", but then anyone else reading your Python code would look at you very strangely23:28
catphishso it is normal to call: object.method(object)23:29
maxbNo, when you call it, magic happens, and the reference is provided implicitly23:30
catphishi understand :)23:30
maxbOr, to be slightly more truthful, when you reference object.method, what you get is not the raw method object, but is a *bound* method - a wrapper that inserts the object reference before passing on the call23:31
catphishPathFilteringTransport seems reluctant to give up its absolute path23:33
catphishwhen asked, it raises filtered-140259821971344:///default/.bzr/branch is not a local path23:33
maxbI am investigating a possibility....23:33
catphishah, external_url perhaps23:34
catphishexternal_url returns a raw file:// url23:36
maxbcatphish: note that external_url() may return a readonly+file:// url if the server is running in readonly mode23:37
catphishgood to know23:37
catphishthough in my case that will never happen23:37
catphishsince a read won't trigger my hook23:37
catphishbut i might as well write the plugin to handle it23:37
catphishall working now, thanks23:47

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