[02:16] <glyph> is there a 'bzr st --no-ignore' or equivalent?
[02:26] <beuno> glyph, maybe bzr ls --ignored?
[02:26] <spiv> glyph: there's the separate 'bzr ignored', but I guess you're after what bzr thinks of all files in a given directory?
[02:28] <spiv> (if so, 'bzr ls' with various flags is probably the way to go)
[02:29] <spiv> glyph: Also, '--no-ignore' is pretty much what bzr st already does: show no ignored files ;)
[02:31] <glyph> spiv: "no ignores" not "no ignored" :)
[02:31] <glyph> spiv: 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:32] <spiv> glyph: bzr ls -iVuR, perhaps with added -v
[02:32] <spiv> And -0
[02:33] <spiv> What's the something, out of interest?
[02:33] <glyph> huh.  What's 'V' mean in that output?
[02:33] <glyph> spiv: revert for reals
[02:34] <glyph> spiv: an operation which, curiously, no version control system implements
[02:37] <spiv> glyph: 'bzr revert && bzr clean-tree --detritus'?
[02:37] <glyph> spiv: <3
[02:38] <spiv> :)
[02:38] <glyph> nope, still doesn't quite work
[02:38] <glyph> it doesn't delete '.moved' directories, apparently.
[02:38] <glyph> oh wait, no, it works
[02:38] <glyph> I just wanted 'bzr clean-tree --unknown --detritus --force'
[02:39] <spiv> (FWIW, the 'V' in that output means 'versioned', I think)
[02:39] <spiv> (not that you care now :)
[02:39] <glyph> wait no... 'bzr clean-tree --ignored --unknown --detritus --force'
[02:39] <glyph> why isn't that the default
[02:39] <glyph> you could make the default behavior be invoked via 'bzr clean-tree --not-really'
[02:40] <spiv> By default it deletes unknowns.
[02:40] <spiv> While leaving potentially valuable ignored files.
[02:41] <spiv> Arch had a sometimes useful distinction between 'junk' (always safe to delete) and 'precious' (not versioned, but don't delete automatically)
[02:42] <spiv> I occasionally wish we'd kept that, although I think probably that level of complexity probably does users more harm than good.
[02:44] <spiv> And 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] <spiv> Except when you do...
[02:45] <spiv> Anyway, I'm glad I've saved you from some shell scripting :)
[02:45]  * spiv -> lunch
[02:45] <glyph> hrm
[02:45] <glyph> you may have saved me even more than you thought
[02:45] <glyph> does this work for svn too?
[02:46] <spiv> Probably!
[02:46] <glyph> Haha it does
[02:46] <glyph> _rad_
[02:48] <glyph> oh crud, except there _are_ like 2 dotfiles I want to not delete
[02:55] <spiv> glyph: easy!
[02:56] <spiv> Just copy those files to /tmp and back :P
[03:04] <spiv> glyph: actually, if you want to be slightly cunning,
[03:04] <spiv> glyph: 'bzr revert; bzr add .dotfile1 .dotfile2; bzr clean-tree --yadda-yadda; bzr rm --keep .dotfile1 .dotfile2'
[03:05] <glyph> spiv: Cute.
[03:05] <spiv> There's no point doing the add before the revert, of course :)
[03:05] <glyph> spiv: I already implemented the other thing, but I might switch to that.
[03:06] <spiv> (The --keep is redundant in this case too, but explicitness and paranoia doesn't hurt)
[03:10] <glyph> spiv: you forgot the last 'bzr revert', too ;)
[03:28] <spundun> hi all... quick question
[03:28] <spundun> if I do bzr checkout URL
[03:29] <spundun> or I do bzr branch URL wd; cd wd; bzr bind URL
[03:29] <spundun> it seems to have the same effect
[03:29] <spundun> am I understanding that right?
[03:29] <spundun> change the first version to bzr checkout URL wd
[03:36] <glyph> spundun: Yes.
[03:36] <glyph> spundun: 'bzr checkout' is an alias for creating a bound branch to make it easier on people who are familiar only with svn.
[03:37] <glyph> If you just s/bzr/svn in your commandlines, everything basically works if you don't think too hard about it :)
[03:37] <spundun> ah, ok
[03:39] <spundun> I 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:40] <spundun> by I, I mean my branch
[03:40] <glyph> spundun: 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:41] <spundun> yes, 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] <glyph> spundun: consider: bzr get ...:.../trunk; cd trunk; hack hack hack; cd ../; mv trunk my-feature-branch; bzr get ...:.../trunk; cd trunk; bzr merge ../my-feature-branch
[03:42] <spundun> ok
[03:42] <spundun> I guess the more I think about it, the more I'll get used to the idea
[03:42] <spundun> or something like that
[03:44] <spundun> thanks glyph
[03:45] <glyph> spundun: 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] <glyph> trunk isn't "special", it's just a branch in a particular place that you've socially agreed is important to a project.
[03:46] <spundun> right, ok
[08:08] <jam> morning all
[08:08] <vila> oops, morning jam et all ;)
[08:09] <jam> I thought it was "et al"
[08:09] <vila> jam: do you know how doc.bazaar.canonical.com scripts are handled ?
[08:09] <vila> argh, yes, it *is* et al
[08:09] <vila> thinko between english, french and latin ;)
[08:09] <fullermd> Just blame it on a typo.  We'll all believe you   :p
[08:10] <vila> hehe
[08:10] <vila> are 'al' and 'all' pronounced the same in english ?
[08:10] <bob2> no, latter is more like awl
[08:10] <fullermd> Not out of my mouth..
[08:11] <fullermd> But 'al' isn't English, so it's a trick question, really...
[08:11] <bob2> it's a (short) name ;
[08:11] <bob2> )
[08:11] <jam> bob2: I've always pronounced "et al" as in "pet" "all"
[08:11] <jam> And I agree more like "awl"
[08:11] <jam> doesn't mean I pronounce it correctly
[08:11] <bob2> hm, I say et al(lan)
[08:12] <bob2> possibly people are too polite to correct me ;p
[08:12] <jam> http://www.thefreedictionary.com/et+al.
[08:12] <jam> says it is supposed to be "et alii"
[08:12] <jam> or et alia
[08:12] <vila> let's add some confusion: 'etal', in french, is where butler cut the meat ;)
[08:12] <bob2> I have even less idea how to pronounce et alli!
[08:13] <vila> bob2: probably like Italy ;)
[08:13] <bob2> haha
[09:05] <vila> mass_import.py up to 812M resident memory, "something" is leaking or python is *really* bad to manage its heap
[09:05] <lifeless> 'manage'. lol.
[09:05] <jam> vila: 812MB for the driving script seems pretty excessive
[09:05] <vila> in other news nexuiz-data is still happily running at 100% CPU without producing any data in its log :-/
[09:05] <vila> jam: right, even 100M would seem excessive...
[09:06] <vila> lifeless: was the joke targeted at python or at my poor english (I guess the former but just checking) ?
[09:06] <jam> vila: python, as I understood it
[09:06] <jam>  /wave lifeless
[09:06] <lifeless> python
[09:07] <lifeless> hai :)
[09:07] <vila> I can't remember if mass_import was already consuming that much memory when running for weeks before my driver changes...
[09:08] <vila> jam: any idea about poking at a running python script with meliae ?
[09:09] <jam> vila: if you can get a pdb console, you can get in with meliae
[09:09] <jam> I think there are some gdb tricks you can pull ,but none that I really know
[09:09] <vila> k, thanks
[09:09] <jam> I think Andrew mentioned using gdb to interrupt, then set trap at the trace function
[09:10] <jam> and then install pdb at that point
[09:10] <jam> that way you know you aren't interrupting the middle of a python OP code, etc.
[09:10] <vila> I think we should just kill this import then and try to reproduce the issue locally
[09:10] <jam> spiv^^?
[09:10] <jam> vila: you mean nexuis?
[09:10] <vila> yup
[09:10] <jam> if you had console access, bzr already installes SIGQUIT => pdb
[09:10] <jam> but I don't think you have console access to the builder process
[09:11] <vila> given it has been spawned from a cron script, I doubt I can get console access yes
[09:12] <vila> the disturbing fact is that the log file hints that we are in the middle of a bzr operation
[09:14] <vila> a commit
[09:15] <jam> vila: We've talked about a SIGUSR1 or SIGHUP handler that would just dump "traceback.format_tb()" into .bzr.log.
[09:15] <vila> 10 days to process a commit is probably considered excessive too :)
[09:15] <jam> It wouldn't be hard to create if you think it would be helpful
[09:15] <jam> vila: we may be inefficient, but 10 days is a little rediculuous
[09:16] <jam> I would say 1 hr is max, even for nexuis-data
[09:16] <vila> oh, sorry, I've been slightly exaggerating, it's 99% CPU not 100
[09:25] <fullermd> Oh, shucks, you made a new release...
[09:26] <jam> vila: well in that case, it is clearly not blocked :)
[09:29] <vila> jam: :)
[09:29] <vila> fullermd: yeah, by the way, any hint about why bzr-duilder is packaged for FreeBSD ?
[09:30] <fullermd> 'cuz C-S packaged it.
[09:30]  * fullermd glances at logs.
[09:30] <fullermd> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/149891
[09:30]  * vila has no idea who Control-Super is...
[09:31] <jam> Better than Meta-Super, that guy is a jerk
[09:31] <vila> I'm pretty sure it requires some debian dependencies...
[09:32] <vila> if not Ubuntu dependencies for that matter
[09:32] <LeoNerd> jam: He recently escaped
[09:32] <vila> LeoNerd: ha ha
[09:32] <vila> using an alternate exit ?
[09:33] <vila> . o O (Slowly but inexorably emacs progresses on all fronts ;)
[09:33] <fullermd> If you're all through bucking around...
[09:34] <vila> Sawhorse Saw"horse`, n.
[09:34] <vila>  A kind of rack, shaped like a double St. Andrew's cross, on
[09:34] <vila>  which sticks of wood are laid for sawing by hand; -- called
[09:34] <vila>  also buck, and sawbuck.
[09:34] <vila>  [1913 Webster]
[09:34] <vila> I'm so much informed now :(
[09:34] <vila> no idea about what a *single* St Andrew's cross is...
[09:35] <fullermd> It's half of a double St. Andrew's cross.
[09:36] <vila> interesting google images results... http://www.google.com/search?client=ubuntu&channel=fs&q=St.+Andrew%27s+cross&ie=utf-8&oe=utf-8
[09:38] <vila> I meant the union jack flag origin of course..
[09:40] <vila> adding 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:41] <lifeless> 'double rainbow'
[10:06] <vila> what with the old mails spam from lists.ubuntu.com ?
[10:27] <catphish> morning
[10:35] <vila> _o/
[10:39] <catphish> _o/ high five
[10:40] <catphish> you'll be relieved to know that i don't need any help today, everything is working nicely :)
[10:40] <vila> yeah !
[10:40] <catphish> hopefully i'm finished with being a pain for now
[10:41] <vila> hehe, you're not a pain, this channel is here to provide help ;D
[10:41] <catphish> and very helpful it is :)
[10:42] <catphish> by the way, my implementation is for http://www.codebasehq.com/
[10:43] <vila> why doesn't it mention bzr then :-p
[10:43] <catphish> because it's not ready yet
[10:43] <vila> good, better than the opposite :)
[10:43] <catphish> we're making a bunch of changes, some of which are announced
[10:44] <catphish> bzr support is not announced, just going to surprise people with it
[10:44] <catphish> plus i wanted to be sure it was going to work
[11:07] <jml> jelmer_: I saw your email to ubuntu-devel about showing authors
[11:08] <jelmer_> jml: I've heard the same concern Dave come up a couple of times before. What do you think?
[11:09] <jml> jelmer_: It reminded me of things I've wanted to do with bzr-stats
[11:09] <jml> jelmer_: get # of landings rather than # of commits.
[11:10] <jml> jelmer_: and it would make 'bzr log' way more useful for PQM-managed projects
[11:10] <jelmer_> jml: Yeah, indeed
[11:11] <jml> hmm.
[11:11] <jml> I wonder how interesting it would be to do it in a plugin
[11:12] <jml> jelmer_: fwiw, I'd propose this output: http://paste.ubuntu.com/578777/
[11:13] <jelmer_> jml: I think we should have all the magic in place to do it in a plugin
[11:13] <jelmer_> "bzr log --format=boo"
[11:14] <jelmer_> that would be an interesting experiment
[11:16] <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:17] <jelmer_> maxb: I'd prefer doing the first, otherwise we'll end up doing the patching forever.
[11:17] <vila> jml, jelmer: Are you talking about adding authors at commit time or extracting them at log time ?
[11:17] <jml> vila: extracting at log time
[11:18] <vila> as 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:19] <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 data
[11:20] <jelmer_> if it's too much of an issue I think a cache would be the best approach
[11:21] <vila> hmm
[11:23] <vila> jelmer_: I was talking about *always* adding authors, only for projects that want it (and I was thinking plugin there, not core)
[11:24] <vila> s/was/*wasn't*/
[11:24] <vila> !
[11:24] <jam> vila: if you have -n0, then you have the information easily available
[11:25] <vila> sure, I thought the issue was to *not* use -n0 nor the implied perf penalty
[11:25] <jam> vila: without it, perf is going to suck quite a bit more, in semi-common cases
[11:25] <vila> and ISTR that adding author in pqm context was mentioned in the past too
[11:26] <jam> determining non-common ancestors is pretty hard
[11:26] <jam> and doing it over-and-over again for each rev is pretty bad
[11:26] <vila> yeah but one day we'll have to fix that once and for all
[11:29] <jam> vila: could you do that tomorrow?
[11:30] <vila> it's on my TODO list, but pretty much at the bottom unfortunately
[11:31] <vila> I just find it annoying that we keep spending time on workarounds :(
[11:33] <maxb> jelmer_: I've not thought about it - I'm planning to study the situation and form an opinion over the weekend
[11:33] <jelmer_> maxb: ok, I'll hold off for a bit then
[11:53] <jelmer_> jam: Did you see my followup to https://code.launchpad.net/~jelmer/bzr-email/drop-pre-0.15/+merge/49628 ?
[11:53] <jam> jelmer_: approved
[11:54] <jelmer_> jam: Thanks
[11:54] <jam> I did see it, but just didn't have anything else to add. "approve of the rest" covered my feelings, though it wasn't explicit
[11:56] <awilkins> Do 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, ok
[11:57] <jelmer_> awilkins: That's a tricky one
[11:57] <awilkins> e.g.   bzr update -r N # where N is less than P which is tip revision ; bzr switch -b newbranch ; bzr revno # emits P not N
[11:57] <jelmer_> awilkins: It would be useful to warn the user in that situation.
[11:58] <jelmer_> awilinks: That said, I think it might require opening the dirstate file to figure out the revno of the working tree
[11:58] <awilkins> jelmer_, 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 DaggyFixes
[11:59] <awilkins> jelmer_, Probably, I know that qlog does something to work out the current revision because it marks it in the log
[12:00] <awilkins> jelmer_, 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 HEAD
[12:01] <jelmer_> awilkins: Yeah, but not for e.g. "bzr branch <remote-location>"
[12:02] <awilkins> jelmer_, No, I don't think that is intuitive
[12: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 sync
[12:02] <awilkins> jelmer_, I think I'm really only thinking about local branches and lightweight checkouts
[12:03] <jelmer_> awilkins: I don't think we should be inconsistent in the way we treat local and remote branches
[12:04] <awilkins> jelmer_, 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 disappointing
[12:05] <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] <awilkins> The -b implies that I'm creating a branch tip and switching to it
[12:07] <awilkins> Or are we driving at different things? My work setup is typically lightweight checkouts
[12:07] <jelmer_> yes, but why do you use "bzr up -r" ? It causes the working tree tip and the branch tip to be different
[12:07] <awilkins> In this case, I am bisecting somewhat manually
[12:08] <awilkins> I 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 it
[12:08] <jelmer_> ah, hmm
[12:09] <jelmer_> so perhaps we should allow you to do something like "bzr switch -b newbranch -rtree:"
[12:10] <awilkins> I was just going to suggest bzr switch -b newbranch -r `bzr revision-info` ; but apparently revision-info does not respect dirstate
[12:10] <jelmer_> awilkins: it has a --tree option
[12:11] <awilkins> jelmer_, Aha, that's nice
[12:12] <maxb> A dirstate-based revspec would be lovely though
[12:12] <maxb> especially for access to pending merge tips
[12:12] <jelmer_> yeah
[12:12]  * jelmer_ files teh bug
[12:14] <awilkins> Ah, and switch -b -r does not behave as you'd want
[12:14] <jelmer_> yeah, please file a bug about that
[12:14] <awilkins> $ bzr switch -b -r 201 fix-update # Tree is up to date at revision 233.
[12:15] <jelmer_> well, you'd want an argument to -b
[12:15] <jelmer_> ah, you have - sorry
[12:15] <awilkins> Ack
[12:15] <awilkins> Ah, yes, not an arg to be, arg to command
[12:17] <awilkins> It doesn't respect the revision argument for either case, branching or non-branching
 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 are
[12:23] <vila> mgz: true and hi !
[12:23] <mgz> and SIGTERM already dumps the current stack as it exits, right?
[12:23]  * mgz waves at vila
[12:24] <vila> hmm, that would at least gives us a hint...
[12:36] <vila> fullermd: I'd like to install sphinx for some tests, but it seems it's available only for py27 :-/
[12:36] <vila> fullermd: 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:44] <vila> ha, finally the true jelmer is back...
[12:46] <jelmer> heh
[12:46] <jelmer> I had a nouveau freeze :-/
[12:46] <vila> hmpf
[12:49] <awilkins> Are 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:50] <maxb> doc/... :-)
[12:50] <jelmer> awilkins: most of the docs live under doc/en in lp:bzr
[12:50] <vila> awilkins: it depends, but doc.bazaar.c.c are mostly in... too slow for jelmer :)
[12:50] <jelmer> vila: and for maxb :)
[12:50] <vila> errk, didn't even saw this one ;D
[12:51] <vila> on the other hand, the shortest answers came first :)
[12:51] <awilkins> Yeah, can't find http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-vss-users.html there though.
[12:52] <awilkins> I should know, I wrote it
[12:52] <awilkins> Gah
[12:53] <jelmer> heh
[12:53] <vila> parent branch: http://bazaar.launchpad.net/~bzr/bzr-migration-docs/trunk/
[12:53] <awilkins> Aha
[14:06] <vila> jelmer: thanks for the review !
[14:29] <jelmer> vila: np
[14:32]  * jelmer resubmits his lazy-bzrdir branch
[14:35] <jelmer> maxb: 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 sid
[14:44] <maxb> Well, the recipe build seems happy
[14:44] <maxb> Got a link to the sid buildlog?
[14:45] <jelmer> there isn't one - I'm building locally
[14:45] <jelmer> I'll pastebin
[14:49] <jelmer> maxb: http://pastebin.ubuntu.com/578852/
[14:50] <maxb> ah, I remember that test, that's the one which tries to connect to a dbus session bus running outside the context of the build
[14:51] <maxb> http://bazaar.launchpad.net/~bzr/bzr-dbus/trunk/revision/47 was my attempt to skip it when appropriate
[14:51] <maxb> I guess my "when appropriate" check isn't working out quite right for you
[14:52] <jelmer> actually, I see what's happening
[15:01] <briandealwis> spiv: 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:02] <jelmer> briandealwis: I bet spiv's asleep
[15:02] <jelmer> briandealwis: if this is a bzr+ssh:// issue you were trying to debug -Dhpss might help
[15:02] <briandealwis> ah, he's showing green
[15:02] <briandealwis> It's a local issue.
[15:03] <briandealwis> I have two branches, p1 and p2 that have a common ancestor.  Trying to push from p1 to p2 results in a strange self-locking problem
[15:03] <jelmer> maxb: fixed it by starting a temporary dbus session
[15:04] <briandealwis> I wasn't having this problem in 2.2.x; maybe I'll try some bisecting.
[15:08] <mgz> briandealwis: what's the bug number?
[15:09] <briandealwis> mgz: haven't filed a bug yet, sorry.
[15:09] <briandealwis> mgz: will do that next
[16:17] <briandealwis> mgz: finally filed as bug 733350
[16:23] <jelmer> vila: Thanks for the review, I'll add some docstrings.
[16:23] <jelmer> vila: it's not just bzr-svn that adds itself to the beginning of the server prober list, bzr-hg and bzr-git do as well
[16:23] <vila> jelmer: thanks for your persistence there ;)
[16:24] <vila> jelmer: one more reason to discuss a saner scheme, the issue has existed for far too long
[16:25] <vila> jelmer: 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] <jelmer> vila: they do an extra OPTIONS request when talking over http, but that's all at this point
[16:26] <jelmer> I added some hacks to do that OPTIONS request over the existing HTTP connection, rather than building up a new connection.
[16:26] <vila> jelmer: and you manage to not load any modules that won't be needed if the probe fail ?
[16:27] <vila> . o O (I'm tired, I'm sure this could expressed in a simpler way :-/)
[16:28] <jelmer> vila: 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 something
[16:29] <vila> ha ok, so the lazy loading addresses the remaining issues then
[16:31] <vila> jelmer: about the OPTIONS stuff, wibni (once you land you hacks in core ;) the smart server was adding its own option too ?
[16:32] <jelmer> vila: what's wibni ?
[16:32] <vila> Wouldn't It Be Nice If ? or did I mangled that ?
[16:33] <mgz> briandealwis: 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 it
[16:33] <jelmer> vila: no, you didn't... just an acronym I didn't know yet :)
[16:33] <briandealwis> mgz: you're right, I made a mistake: it's from the workspace branch
[16:33] <jelmer> vila: 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 script
[16:34] <briandealwis> mgz: I've been able to reproduce the issue from a synthetic branch — it hinges on tags
[16: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] <mgz> okay, in which case the odd thing is is *also* thinks it a checkout of backup?
[16:34] <mgz> that's not intended surely
[16:34] <vila> jelmer: sure and for older clients too, but still
[16:35] <mgz> tags being what's broken seems likely, spiv added some new behaviour there.
[16:35] <briandealwis> mgz: I bind "trunk" to "backup", where "backup" exists on a different drive.  So pushes to "trunk" are backed up
[16:35] <mgz> but the fix for you should probably just be editing a conf file.
[16:35] <mgz> briandealwis: but what is 'workspace'? A normal branch? a checkout?
[16:36] <briandealwis> mgz: a normal branch
[16:36] <mgz> the info posted is of a checkout.
[16:37] <briandealwis> mgz: now I'm confused :)
[16:37] <mgz> `bzr info` on workspace should say it's parent branch is trunk, and have no checkout bits
[16:38] <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] <briandealwis> mgz: I was right originally: it was from "trunk"; that was info carried when branching from my original branches
[16:38] <briandealwis> mh	
[16:39] <briandealwis> mgz: I removed the stray info, and it makes no difference
[16:39] <briandealwis> mgz: I'll add a synthetic example that demonstrates the bug in a sec
[16:39] <mgz> ah, you've got one now?
[16:40] <briandealwis> mgz: yeah — it's all about pushing with tags
[16:40] <briandealwis> mgz: I used bisect to identify the problematic commit.  if you look at it, it adds some locking.
[16:41] <mgz> yup, I can repo too with that.
[16:45] <vila> jelmer: I'm very tempted to give you the green light to land all the weave-in-a-plugin stuff
[16:45] <jelmer> vila: \o/ Did you see the intermediate branch, bzrdir-weave ?
[16:46] <vila> jelmer: 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 issues
[16:46] <vila> jelmer: did you see my reviews ;)
[16:46] <jelmer> clearly I haven't :)
[16:46] <vila> jelmer: and I'm sure you will be motivated to fix any bugs if that's the case
[16:47] <jelmer> yeah, of course
[16:47] <briandealwis> mgz: I tacked on the example
[16:48] <mgz> yup, that's similar to what I got to fail.
[16:48] <vila> jelmer: 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 fallouts
[16:49] <vila> mgz: any progress on https://code.launchpad.net/~gz/bzr/create_delta_index_memoryerror_633336/+merge/52251 ?
[16:49] <jelmer> vila: sounds good to me - most of it is just moving code around now anyway
[16:50] <vila> mgz: I didn't review closely but I was wondering if your actual fix was already viable ?
[16:50] <mgz> yeah, I'm going to give in and rewrite those two functions to take **struct and return a code rather than *struct
[16:51] <mgz> it's a bigger change, but there's no point trying to keep a limited api when they need sensible error handling.
[16:52] <vila> mgz: ha ! Yeah, when you're tired to override, using distinct objects help express better semantics ;)
[17:03] <mgz> darnit, 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:05] <vila> mainline: ?
[17:07] <mgz> http://paste.ubuntu.com/578908/ <- and the number of times I do this as well, env-variables is particularly painful
[17:07] <vila> mgz: bzr help topics
[17:08] <mgz> yeah, but `bzr help topics | grep env` is just as annoying to type every time
[17:08] <vila> mgz: which is itself mentioned in 'bzr help'
[17:08] <vila> oh
[17:08] <mgz> so, I try and remember and get it wrong a few times.
[17:09] <mgz> why, for instance, is 'environmental' abbreviated, but 'variables' is not?
[17:10] <vila> yeah, this needs to be reworked, revisionspec is another bad example
[17:11] <maxb> It should probably be 'environment-variables' with an alias of 'envvars'
[17:12] <vila> or may be bzr-guess could be extended to handle help topics and merge in core
[17:12] <vila> merge*d
[17:12] <vila> I thought Parth worked on a bit on that at some point...
[17:13] <mgz> ^thanks, mainline works, presumably new in 2.2 or 2.3 though.
[17:13] <vila> yup, I'd say 2.3
[17:15] <mgz> right, I need some food, then I'll write a little code.
[17:57] <vila> mgz: mah, my memroy was bad, help topic guessing has been *disabled* in revno... 2 :-(
[18:30] <jelmer> vila: argh, test isolation failure :-(
[18:31] <vila> jelmer: caught by pqm ?
[18:31] <jelmer> vila: yep
[18:32] <vila> which branch ?
[18:32] <jelmer> vila: lazy-bzrdir
[18:32] <vila> k
[18:33] <jelmer> vila:  bzrlib.tests.test_remote.TestBzrDirCloningMetaDir.test_current_server happens to fail because the returned control dir suddenly has its repository format set to 2a
[18:33] <jelmer> the cause seems to be the fact that we now run the per_controldir tests against RemoteBzrDirFormat
[18:33] <vila> ah
[18:34] <vila> why do you suspect an isolation issue ?
[18:34] <jelmer> vila: I can reproduce it locally. "./bzr selftest -s bt.test_remote" succeeds, "./bzr selftest -s bt.per_controldir -s bt.test_remote" fails
[18:34] <vila> arg
[18:35]  * jelmer wonders what the best approach is to debug this sort of thing
[18:35] <vila> they are all painful
[18:35] <vila> :)
[18:35] <jelmer> is there any particular function that gets called after each test?
[18:36] <vila> probably, never tried that approach though
[18:37] <vila> what I generally do is establish a list of tests including the failure and bisect it
[18:37] <maxb> jelmer: Concerning bzr-rewrite packaging - is it correct to drop the "Replaces: bzr-rebase" whilst retaining the Conflicts?
[18:38] <vila> jelmer: 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:43] <vila> seems to be in bzrlib.tests.per_controldir.test_push.TestPush
[18:45] <jelmer> vila: Can you try again with trunk?
[18:45] <vila> try what with which trunk ?
[18:46] <vila> don't lose focus on the crash, different people will have different issues, we'll see later :)
[18:46] <vila> bzrlib.tests.per_controldir.test_push.TestPush.test_push_new_empty
[18:47] <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_server
[18:47] <vila> is enough to reproduce
[18:53] <vila> puzzling
[18:53] <vila> as often with isolation issues...
[18:53] <jelmer> vila: I think I found the test isolation issue
[18:53] <vila> yes ?
[18:54] <jelmer> one of the fallback cases for RemoteBzrDirFormat modifies the RemoteBzrDirFormat in-place
[18:54] <jelmer> in some of the other cases we use .__class__() to create a new copy and modify that
[18:55] <vila> evil
[18:56] <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 me
[18:57] <jelmer> since you mentioned bzr-hg earlier, are you sure you mean with --no-plugins ?
[18:57] <vila> pass for bzr.dev here
[18:58] <vila> even without --no-plugins
[18:58] <vila> crash in the lazy-bzrdir without --no-plugins
[18:58] <vila> revo 401 for bzr-hg
[19:04] <vila> jelmer: gotta go, happy hunting :-}
[19:04] <fullermd> vila: *yawn*
[19:05] <fullermd> vila: py27 was actually switched to the default earlier this week...   I haven't pulled the switch yet.
[19:07] <fullermd> vila: '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:12] <vila> fullermd: thanks ! My notes from the py26 upgrade says: http://paste.ubuntu.com/578954/
[19:12] <vila> fullermd: so, IIUC, I should do the same, I may a bit for things to settle down in ports no ?
[19:12] <fullermd> Pretty much, just s/26/27/ and s/25/26/ all 'round.
[19:13] <vila> k
[19:13] <vila> I should really go now, gf is waiting ;)
[19:13] <fullermd> It should probably be OK, else they wouldn't have pulled the default switch.
[19:13] <vila> k, I'll do a vm backup first anyway
[22:58] <catphish> evening
[22:59] <catphish> does anyone know how i might go about converting a filtered-139770606741392:// url to a real path?
[23:01] <jelmer> hi catphish
[23:02] <catphish> hi jelmer
[23:02] <jelmer> catphish: I have no idea, where are you getting that URL from?
[23:03] <catphish> your code ;)
[23:03] <jelmer> I doubt it's *my* code :)
[23:03] <catphish> the (c) has your name in lol
[23:03] <catphish> anyway, its changeBranchTipParams.__dict__['branch'].base
[23:03] <catphish> in a hook
[23:04] <jelmer> catphish: hmm, which file is that?
[23:04] <catphish> shell-hooks
[23:04] <jelmer> oh, that's just coming in from an external source e.g. a smart server
[23:04] <catphish> correct
[23:04] <jelmer> it's unrelated to the shell hooks plugin
[23:05] <catphish> your original hook didnt support the changeBranchTipParams hook
[23:05] <catphish> so i don't suppose it ever came accross data from an external push
[23:05] <catphish> anyway it's branch.base
[23:05] <catphish> and it returns: filtered-139770606741392:///default/
[23:06] <jelmer> I think it predates the changeBranchTipParams hook
[23:06] <catphish> makes sense
[23:06] <catphish> i assume it's a type of chroot
[23:06] <jelmer> yep
[23:07] <catphish> do you have any thoughts how i might map it to the real path?
[23:07] <jelmer> have a look at branch.root_transport
[23:07] <jelmer> it's probably some sort of special transport that wraps the actual transport
[23:10] <catphish> hmm, i don't see branch.root_transport
[23:15] <catphish> ah, its a PathFilteringTransport
[23:26] <maxb> I was looking at this stuff just recently
[23:26]  * maxb tries to remember things
[23:27] <catphish> i'm a little confused by why instance methods accept self as the first parameter, i'm not a python developer but that seems odd
[23:27] <maxb> catphish: Unlike most languages, Python chooses to pass the instance reference as an explicit first parameter, which is conventionally called self
[23:28] <maxb> Rather than defining a special keyword for it
[23:28] <maxb> I suppose you could call it "this" instead of "self", but then anyone else reading your Python code would look at you very strangely
[23:29] <catphish> so it is normal to call: object.method(object)
[23:29] <catphish> ?
[23:30] <maxb> No, when you call it, magic happens, and the reference is provided implicitly
[23:30] <catphish> i understand :)
[23:31] <maxb> Or, 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 call
[23:32] <catphish> ok
[23:33] <catphish> PathFilteringTransport seems reluctant to give up its absolute path
[23:33] <catphish> when asked, it raises filtered-140259821971344:///default/.bzr/branch is not a local path
[23:33] <maxb> I am investigating a possibility....
[23:34] <catphish> thanks
[23:34] <catphish> ah, external_url perhaps
[23:35] <maxb> yes
[23:36] <catphish> awesome
[23:36] <catphish> external_url returns a raw file:// url
[23:36] <catphish> sexy
[23:36] <maxb> :q
[23:36] <maxb> oops
[23:37] <maxb> catphish: note that external_url() may return a readonly+file:// url if the server is running in readonly mode
[23:37] <catphish> good to know
[23:37] <catphish> though in my case that will never happen
[23:37] <catphish> since a read won't trigger my hook
[23:37] <catphish> but i might as well write the plugin to handle it
[23:47] <catphish> all working now, thanks