[00:29] <jelmer> lifeless: ping
[00:41] <lifeless> jelmer: hi
[00:41] <jelmer> lifeless: Any chance you can sponsor the initial upload of bzr-upload or bzr-avahi to Debian ?
[00:42] <jelmer> Jeff has promised to upload bzr-stats
[00:42] <lifeless> I'll see what I can do; I'll need to review the package yadayadayada
[00:42] <lifeless> is the bzr-avahi you've packaged comaptible with bzr-dbus ?
[00:44] <jelmer> afaik yes, but I'll double check
[00:44] <jelmer> bzr-upload has already been reviewed once and uploaded to NEW but was accidently uploaded without source package
[00:45] <lifeless> ahaha
[00:47] <igc> morning
[00:48] <jelmer> Hi Ian
[01:18] <abentley> lifeless: ping
[01:20] <lifeless> pong
[01:21] <abentley> lifeless: Have you seen my fetch patch?
[01:21] <lifeless> I didn't get to reading it yesterday; it sounds conceptually straight forward
[01:22] <lifeless> I'd kind of like to remove all fetching via Packer and instead just use Packer for auto-pack, reconcile, full-pack
[01:22] <abentley> I am concerned that it may not be enough.
[01:22] <lifeless> but I don't know that the performance is stable enough through the generic code path yet
[01:22] <abentley> The packer makes sure that all the compression parents are present.
[01:22] <lifeless> in autopack ?
[01:23] <lifeless> (insert_record_stream also checks for compression parents)
[01:23] <abentley> I'm not sure.  That's what I'm worried about.
[01:23] <lifeless> I think thats a likely hole. dammit
[01:23] <lifeless> uhm
[01:23] <lifeless> I think that the check for existing parents should go through the relevant VersionedFiles attributes' graph object
[01:24] <lifeless> that would solve it comprehensively
[01:24] <lifeless> or something ~= to that
[01:24] <lifeless> I need to pop out for a few minutes
[01:24] <lifeless> will ping on return
[01:24] <abentley> lifeless: Yes, though it makes me wonder whether the packer should be doing it at all.
[01:24] <abentley> lifeless: cool
[01:43] <lifeless> k
[02:42] <jelmer> poolie, ping
[02:44]  * jelmer wonders if he's running into a lot of bugs today or just grumpy..
[02:45] <jelmer> autoppa doesn't work for me yet; is there perhaps an Ubuntu user who could help upload bzr-svn to ppa?
[02:47] <lifeless> jelmer: is it really ubuntu vs debian? or something else?
[02:49] <jelmer> no, it's just several issues in autoppa
[02:52] <jelmer> several minor things that scared me a bit and one thing that actually prevents me from using it
[02:53] <jelmer> I think for the time being it's probably best if somebody else (perhaps the same person who uploads bzr to the ppa) can upload bzr-svn to the ppa
[02:54] <jelmer> This is just not my day..
[02:55] <jelmer> ssh: connect to host bazaar.launchpad.net port 22: Connection refused
[02:55] <spiv> jelmer: eep!
[02:57] <jelmer> ah, appears to be back now
[02:59] <lifeless> poolie: ^
[03:00]  * igc lunch
[03:02] <lifeless> thumper: I want - http://bzr-playground.gnome.org/.mirror-log for launchpad.net
[03:02] <jelmer> lifeless: aol
[03:13] <poolie> jelmer, pong
[03:13] <poolie> jelmer, i can do that upload, can you point me at the packaging branch
[03:13] <jelmer> poolie: Sure, it's at http://bzr.debian.org/pkg-bazaar/bzr-svn/unstable/
[03:14] <poolie> i'm working today on your bug re being unable to branch from bzr-svn
[03:14] <jelmer> poolie, ah, cool
[03:14] <poolie> i guess there is no point packaging it into the ppa until that is fixed
[03:14] <poolie> what else are you hitting?
[03:14] <poolie> oh, and gmail is down too
[03:15] <poolie> well, what a productivity boost :)
[03:15] <jelmer> poolie, Yeah, that doesn't make much sense, indeed
[03:16] <jelmer> poolie: What bugs am I hitting in autoppa you mean?
[03:16] <poolie> 11:44  * jelmer wonders if he's running into a lot of bugs today or just grumpy..
[03:16] <poolie> but i see the context now
[03:16] <poolie> i wasn't sure if you were referring to bzr or autoppa
[03:17] <jelmer> I just filed 6 additional bugs on autoppa
[03:17] <jelmer> and then I hit some open bugs in bzr
[03:17] <jelmer> (already reported though)
[03:18] <jelmer> poolie: if there's anything I can do to help with bzr-svn in ppa, please let me know
[03:19] <poolie> jelmer, for bzr i was just packaging and uploading it by hand
[03:19] <jelmer> poolie, the packaging branch should build without problems with bzr-builddeb
[03:19] <poolie> (the method is in doc.b.o)
[03:19] <poolie> this is very low tech
[03:23] <jelmer> poolie: I did that for a while, but it's too much overhead for me to also upload to PPA
[03:25] <jelmer> autoppa seemed like a nice way to deal with the multiple distributions you have to upload to
[03:25] <lifeless> jam: ping
[03:25] <jelmer> I did uploads of bzr-stats, bzr-rebase, bzr-gtk and bzr-svn to some distributions on ppa for a short while but that was just too much work
[03:26] <lifeless> jam: what mail client are you using? (It seems to quote everything everytime)
[03:27]  * jelmer gets some sleep
[03:28] <mwhudson> beuno: http://bazaar.launchpad.net/~bzr/bzr/trunk/files :)
[03:30] <lifeless> nice
[03:30] <lifeless> bkor: ^
[03:30] <spiv> mwhudson, beuno: hooray!
[03:31] <poolie> sweet!
[03:34] <jelmer> ooh, shiny (-:
[03:51] <lifeless> spiv: is https://bugs.edge.launchpad.net/bzr/+bug/180996 of interest to you?
[03:57] <spiv> lifeless: yes, thanks
[05:04] <Peng_> Hmm, that theme is a little different.
[05:21] <rockstar> spiv, I effing LOVE your latest blog post
[05:21] <spiv> rockstar: thanks :)
[05:30] <AfC> spiv: uh, Andrew, something I don't follow from your excellent essay:if you use `bzr merge -r X..Y` you still have the same problem as rebase - new revisions are made, and if someone has branched off of the old revisions they will still be on a different branch that has no relation to the new hotness one.
[05:30] <AfC> This "discards the real history" if the new branch becomes the published mainline, no?
[05:31] <spiv> Well, the example where I used -rX..Y, X is present so the revision history would be attached.
[05:31] <spiv> I could have used -r..Y I guess.
[05:32] <poolie> jml, thumper, ping?
[05:32] <jml> poolie: hi
[05:32] <jml> poolie: what's up?
[05:32] <poolie> jml, about lp stacking, briefly
[05:33] <poolie> i wanted to let you know i'm working on the two bugs found in stacking betas, being robert's one about stacking on a branch that is later upgraded
[05:33] <poolie> and jelmer's about it breaking branching from bzr-svn
[05:33] <spiv> So in the example I gave things Just Work as they should, but cherrypicking in general is still a problem.
[05:33] <poolie> how is it on the lp side?
[05:33] <jml> poolie: pretty good right now.
[05:33] <RAOF> Just to check; the format for --fixes is --fixes=lp:123456, right?
[05:33] <jml> poolie: you've seen abentley's patch?
[05:34] <jml> RAOF: yes.
[05:34] <jml> RAOF: feel free to poke me into writing better docs at some point
[05:34] <poolie> also, jml, which one?
[05:34] <RAOF> jml: Ta.  Maybe I'll file a documentation bug.
[05:34] <AfC> You say present... but it when you do a cherry pick like that the _revisions_ (if not the text delta) and their history are not present [or is there some magic flag to bzr log|viz I'm missing out on?]
[05:34] <AfC> spiv: ^
[05:34] <RAOF> jml: Heh. I'm too slow :)
[05:34] <jml> poolie: I'll look it up.
[05:35] <jml> poolie: [MERGE] Fetch into stacked branches works correctly
[05:35]  * AfC notes that this is the central problem he has been grappling with since the beginning of Bazaar, and the perennial topic of his questions, most recently in the email titled "There And Back Again" to the mailing list.
[05:36] <AfC> {shrug}
[05:36] <jml> poolie: without that, default stacking is unusable
[05:36] <luks> AfC: the example was about grouping a branch into fewer commits, not about cherry picking
[05:36] <luks> AfC: if you chery pick a revision, and the parent revision is not present in the target branch, the history won't be saved
[05:37] <AfC> luks: no, I get that, but the example also claimed "without losing your history" and as far as I can tell, X..Y cherrypicking has exactly the same [adverse] properties as rebase does, future-wise.
[05:38] <luks> AfC: `merge -r X..Y` with X present in the branch is an equivalen of `merge -r ..Y`
[05:38] <AfC> luks: as a means of submitting patches to another branch [ie, upstream or whatever] then it's all good, no question there
[05:38] <luks> is that more clear now?
[05:38] <luks> it's not cherry picking, it's "merging up to revision Y"
[05:39] <AfC> Ah, I'm accustomed to the X-not-present case.
[05:39] <AfC> (Andrew did start at revision 0 in his essay, I certainly grant you that)
[05:40] <luks> but yes, cherry picking and rebasing have the same problems
[05:40] <luks> (and also similar solutions, that's why bzr-rebase provides `bzr replay`)
[05:46] <spiv> AfC: I see luks has already clarified things, but you can run the shell script at http://rafb.net/p/34dlJk37.html and then use "bzr viz" on the result if you're still curious :)
[05:46] <jml> poolie: sorry, I got distracted
[05:46] <jml> poolie: where were we?
[05:47] <AfC> spiv: no, I get it. You were starting from 0 which is "X already in branch"
[05:47] <spiv> Right.
[05:47] <AfC> spiv: (and I was playing along at home already)
[05:48] <spiv> Cherry-picking with history would be great to have, for obvious reasons.  But you already know that :)
[05:48] <AfC> spiv: in view of the fact that we are all actually talking about the same thing, I would really appreciate your thoughts about the two options in that email I sent last week if it strikes your fancy that you have anything to say on the question
[05:49] <spiv> I'll take another look.
[05:49] <AfC> most kind
[06:03] <igc> spiv: thanks for the InventoryEntry review
[06:03] <igc> spiv: can I confirm you're ok with it landing as is and for me to tweak it later as part of some other work in that area?
[06:05] <igc> I'm not sure a registry is worth the complexity it adds right now personally
[06:05] <spiv> igc: I am
[06:06] <igc> spiv: thanks. I'd liked the feedback btw and I'll incorporate you're thinking when I add some tests in that area soon
[06:06] <igc> s/you're/your/
[06:20] <poolie> jml, me too
[06:20] <poolie> jml, we were going to review blockers to stacking on launchpad
[06:20] <poolie> i'll read aaron's patch
[06:20] <poolie> is there anything else aside from that?
[06:20] <jml> poolie: not that I'm aware of.
[06:21] <jml> poolie: I'm currently testing my branch locally.
[06:21] <poolie> which branch is that?
[06:21] <jml> poolie: my launchpad branch that enables makes use of the in-development bzrlib stacking features.
[06:25] <poolie> spiv, how is memory usage with bzr+ssh in 1.6b?
[06:28] <spiv> poolie: not obviously worse than 1.5 IIRC.  I don't know of any big memory issues that are due to HPSS rather just bzrlib in general.
[06:28] <alecwh> A friend and I are working on a project, and we have a central repository where we both push/pull from. There is one file, /inc/config.py, that contains database info, etc etc. Now, when I push to the repository, it will change the config.py file, so that when my friend pulls, HIS config.py is changed, therefore messing up his database credentials. Is there a way to include config.py in the version control, but stop it from being changed on the 
[06:29] <poolie> alecwh: not at present, but there is some discussion recently about letting you persistently mask in your working tree what things should be committed or not
[06:30] <alecwh> Does git have a feature like this?
[06:30] <poolie> not that i know of
[06:31] <alecwh> Okay, so for the time being, my friend and I should just try to have identical databases and credentials?
[06:32] <poolie> alecwh: how about if you put into that file something like this
[06:32] <poolie> 'from config_local import db_user, db_pass, db_url'
[06:32] <poolie> and then have a config_local.py that's not versioned
[06:32] <poolie> or you could for example wrap that in a try/except block
[06:32] <alecwh> yeah...
[06:33] <alecwh> poolie: thanks, much appreciated
[06:33] <poolie> np, hope that helps
[06:37] <jml> poolie: so, according to abentley and lifeless, it's likely that autopack won't work on stacked branches.
[06:37] <jml> poolie: I would consider this a blocker for Launchpad.
[06:38] <abentley> poolie: Thanks for your review, though.
[06:38] <poolie> heh
[06:38] <poolie> what will happen when it runs?
[06:38] <spiv> jml: add "for b in $branches; do bzr pack $b; done" to a nightly cron ;)
[06:39] <poolie> it won't repack the underlying branch?
[06:39] <mwhudson> spiv: i knew we could rely on you!
[06:39] <poolie> mwhudson: it would be really nice as part of the scalability work to run
[06:39] <spiv> mwhudson: thanks!  I'll be here all week... ("here" == "not in NZ, so you can't hit me")
[06:39] <poolie> to be able* to run pack/check/upgrade etc
[06:40] <mwhudson> spiv: jml will be back in punching range sooner or later
[06:40] <mwhudson> poolie: i'm not sure how that's part of the scalability work, tbh, but yes
[06:41] <abentley> poolie: It will raise errors.RevisionNotPresent on autopack.
[06:42] <poolie> i saw it as connected through being part of looking after a large collection of branches,b ut let's not get hung up on it
[06:42] <poolie> because autopack is trying to repack things in the underlying packs
[06:45] <berto-> anyone familiar with this error when trying to bzr branch an SVN repo via https:  error: (65, "necessary data rewind wasn't possible")
[06:46] <berto-> bzr-svn is compiled against subversion 1.4.4
[06:47] <spiv> berto-: sounds dimly familiar, maybe an interaction with pycurl if you have that installed?
[06:48] <berto-> spiv: yes, pycurl is installed.
[06:49] <berto-> spiv: though a standard curl request via HTTPS to a file in the svn repo works fine.
[06:51] <spiv> berto-: google finds https://bugs.launchpad.net/bzr/+bug/241698 and https://bugs.launchpad.net/bzr/+bug/207734
[06:51] <spiv> berto-: both when bzr tries to probe for a bzr+http service on an http:// URL when pycurl is installed
[06:52] <spiv> berto-: possibly using "svn+https://" or "nosmart+https://" might workaround it.  As would uninstalling pycurl :/
[06:53] <berto-> hmm, can't uninstall pycurl.  i need it for other projects.  i'll try svn+https//
[06:53] <berto-> promising ...
[06:57] <spiv> A hack would be to do "mkdir /tmp/disable-pycurl; echo raise ImportError > /tmp/disable-pycurl/pycurl.py" then use "PYTHONPATH=/tmp/disable-pycurl bzr ..."
[06:57] <spiv> But if svn+https works that would be easier :)
[07:10] <berto-> spiv: hehe, clever.  but, it looks like svn+https is working.  i've had luck branching svn repos, the question is will i be able to push changes back up.  i'll test that as soon as this is done.
[07:23] <berto-> looks like i'm going to have to upgrade to svn 1.5 for this to work ...
[07:24] <alecwh> Are there any notable projects that use bzr exclusively?
[07:24] <lifeless> jml: autopack not working would be a bug
[07:24] <lifeless> jml: Its on my short list to look at closely
[07:24] <berto-> alecwh: http://bazaar-vcs.org/WhoUsesBzr
[07:25] <lifeless> jml: if we extend the work poolie is already doing to make inventories never delta across a repo boundary autopack is guaranteed to work
[07:25] <alecwh> berto-: thanks!
[07:25] <jml> lifeless: cool.
[07:33] <lifeless> spiv: https://bugs.edge.launchpad.net/bzr/+bug/246880
[07:34] <lifeless> spiv: if you could eyeball that; reconcile bug I think
[07:34]  * spiv balls it with eyes
[07:38] <lifeless> poolie: I'm calling it a day; been sneezing and $hit all day - asthma etc are all playing up
[07:38] <spiv> lifeless: hmm.
[07:38] <spiv> lifeless: before you go, care to explain this bug a little more for me, to make sure I understand it?
[07:38] <spiv> lifeless: (feel free to say "no")
[07:39] <lifeless> spiv: sure
[07:39] <lifeless> I've put my understanding to date in the topic
[07:39] <lifeless> bzr reconcile fails to reconcile the branch
[07:40] <spiv> Yeah, it's a bit hard reassembling the diagnosis from a series of bug comments, it's a bit like a stream-of-consciousness :)
[07:40] <poolie> lifeless: sure, i hope you feel better soon
[07:40] <lifeless> spiv: so reconcile fails
[07:40] <lifeless> its meant to do 'oh thats a delta on a text we would not fetch so make it a full text'
[07:40] <lifeless> but its not doing that
[07:41] <lifeless> fetch fails because there is a delta on a text that is not fetched
[07:41] <spiv> And it has enough info to assemble a full text, somehow?  (I guess so, because iter_file_bytes works)
[07:41] <lifeless> jml: btw is there a bug open on lp to have a 'remirror from scratch please' ?
[07:41] <poolie> lifeless: i've just filed bug 252821, is there anything else you can add to it?
[07:41] <lifeless> spiv: yes, because the text chain (D1 and FT) are present
[07:42] <lifeless> spiv: but the revision D1 is not present, only the text is
[07:42] <alecwh> Is there a service for bzr that will notify the freenode channel when a commit has been made? Something like CIA agent?
[07:42] <alecwh> http://cia.vc
[07:42] <jml> lifeless: umm, no, I don't think so.
[07:42] <lifeless> poolie: as I said above the easiest fix is to just always ensure we have the fulltext in the local repo
[07:42] <jml> lifeless: no one has asked for it yet.
[07:42] <poolie> oh is it the same bug?
[07:43] <poolie> as for upgrade
[07:43] <lifeless> poolie: its the same situation causing it
[07:43] <lifeless> it seems to me we can save on code by just using whatever fix you do for inventories to control file texts as well
[07:43] <spiv> Ah, right.  So reconcile is probably being tricked by the lack of a revision, even though there is a text from that revision present (and necessary)?
[07:43] <jml> lifeless: I'll note that Launchpad actually has pretty awesome search nowadays
[07:43] <lifeless> jml: herewith a request
[07:44] <lifeless> jml: concretely I'd like reconcile operations to propogate to the mirror
[07:44] <lifeless> jml: and potentially other deeper voodoo; but reconcile would do for now
[07:44] <lifeless> spiv: I think reconcile is being tricked somehow yes
[07:44] <lifeless> spiv: all I really know is that:
[07:45] <lifeless> the text (ID, D1) is reported as missing
[07:45] <lifeless> (ID, D2) is compressed on (ID, D1)
[07:45] <lifeless> (reported as missing by fetch/reconcile)
[07:45] <lifeless> (ID, D1) is compressed on (ID, FT)
[07:45] <lifeless> D1 and FT revisions are not present
[07:46] <spiv> Right.  Ok, I think I grok the situation.  Thanks!
[07:46] <lifeless> so reconcile should turn D2 into a FT
[07:46] <jml> lifeless: so, a workaround is to change the branch format
[07:46] <lifeless> but its not
[07:47] <lifeless> and its not copying D1 either (which is correct), but that leaves D2 as unreconstructable after the reconcile which is why it fails. or something like that. DUnno.
[07:47] <lifeless> jml: yes. ugh.
[07:47] <mwhudson> >:)
[07:47] <spiv> lifeless: right.
[07:48] <jml> lifeless: can you please file a bug report for this?
[07:50] <astrec> hi all
[07:52] <jml> g'night all.
[07:52] <astrec> q'n about bzr-svn: it has built off trunk without complaint, but tells me: Unable to load bzr-svn extensions - did you build it?
[07:52] <lifeless> ok, gone
[07:52] <astrec> this is bzr 1.6b3
[07:52] <astrec> anyone else seen this?
[07:53] <lifeless> spiv: I've uploaded the tarball if you are interested; I can probably look at it at some point myself too
[07:53] <lifeless> astrec: you've run make ?
[07:53] <lifeless> hmmm, really must go - sorry
[07:53] <astrec> yeah, run make
[07:53] <astrec> no errors
[08:00] <berto-> spiv: svn+https:// is finally working; took a few tries and a ton of patience.  after ~10 minutes, it finally started downloading revisions from the svn repo.  50/1188 so far ... :\
[08:00] <astrec> ok, so i add it to the pythonpath
[08:01] <berto-> astrec: what platform are you on ?
[08:01] <berto-> astrec: i just had that error on OS X, ended up building svn from source.
[08:01] <astrec> sorry, OS X  10.5.4
[08:01] <berto-> are you using the built-in svn ?
[08:02] <astrec> i've tried the binary suggested in the doc, and macports. all svn 1.5.1
[08:02] <berto-> i built from svn source b/c of this: http://samba.org/~jelmer/bzr-svn/FAQ.html#i-am-unable-to-access-a-repository-that-requires-user-password-authentication-or-uses-self-signed-ssl-certificates
[08:03] <astrec> trying to import the plugin from python yields: http://pastebin.com/m196cc427
[08:03] <berto-> astrec: you have apr in /opt
[08:04] <astrec> i do
[08:04] <berto-> mine linked from apr in /usr/lib and it worked fine.  that seems to be your problem.
[08:04] <berto-> oh, /opt must be where macports puts svn, eh?
[08:04] <elmargol> How can I pull a single revision of a branch?
[08:04] <berto-> astrec: i can help you build from source, that will probably clear things up for you.
[08:05] <astrec> that would be great!
[08:05] <spiv> elmargol: do you mean make a branch/checkout without grabbing the whole history, or something else?
[08:05] <elmargol> spiv, I have found branch containing a fix to my branch. And I need to somehow merge this change in
[08:07] <berto-> astrec: ok, cool.  for stuff i compile myself i put it in ~/local
[08:07] <astrec> berto-: same
[08:07] <berto-> so, you can: mkdir -p ~/local/src
[08:07] <spiv> elmargol: ah, so you want to merge rather than pull
[08:07] <berto-> cd ~/local/src
[08:07] <berto-> svn export http://svn.collab.net/repos/svn/trunk svn
[08:08] <berto-> astrec: basically follow this, but change the configure line: http://bazaar-vcs.org/BzrForeignBranches/Subversion?action=show&redirect=BzrSvn#building-from-source
[08:08] <spiv> elmargol: "bzr merge -r 123 OTHER_BRANCH" will merge all changes up to r123, or "bzr merge -c 123 OTHER_BRANCH" will just grab the changes from one revision.
[08:08] <berto-> my configure line goes like this:
[08:08] <elmargol> spiv, thx
[08:09] <berto-> ./configure --prefix=${HOME}/local --without-apxs
[08:09] <spiv> elmargol: if you use -c, you should be aware of http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#pseudo-merging
[08:09] <berto-> astrec: make-check-swig-py is not necessary anymore as bzr-svn doesn't use swig anymore
[08:10] <spiv> elmargol: (cherry-picking individual changes rather than full branches doesn't copy the revision history for those changes, so later merges are likely to have spurious conflicts)
[08:10] <astrec> berto-: lol... i tried compiling it earlier in the day and make-check-swig failed so i gave up
[08:10] <berto-> astrec: hehe.
[08:11] <spiv> elmargol: also, "bzr help merge" will give you lots of options :)
[08:21] <astrec> berto-: compiled. so what did u add to your site-packages?
[08:22] <berto-> astrec: cd ~/.bazaar/plugins/svn
[08:22] <berto-> look for the list basedirs; mine is on line 69
[08:23] <berto-> add '/Users/<username>/local' to the front of that list, replacing <username> with your username, of course.
[08:26] <astrec> berto-: i've been here before: http://pastebin.com/m5b204f5f
[08:26] <astrec> i have some strange issue with apr
[08:27] <berto-> astrec: me too. setup.py line 43, put apr-1-config first.
[08:30] <astrec> berto-: anything else? i get the same error
[08:30] <berto-> astrec: run: which apr-1-config
[08:30] <astrec> "/usr/bin/apr-1-config"
[08:32] <berto-> astrec: you are getting apr-config not found?
[08:32] <astrec> berto-: no, it's in /usr/bin
[08:32] <berto-> as the error.
[08:33] <berto-> and you changed the cmds line to look like this:         cmds = ["apr-1-config", "apr-config"]
[08:34] <astrec> no, that's not the error. i did change the cmds. error i get is: ld: library not found for -lapr-1
[08:34] <berto-> astrec: can you paste the last compile line?
[08:35] <astrec> gcc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g -bundle -undefined dynamic_lookup build/temp.macosx-10.3-i386-2.5/client.o build/temp.macosx-10.3-i386-2.5/editor.o build/temp.macosx-10.3-i386-2.5/util.o build/temp.macosx-10.3-i386-2.5/ra.o build/temp.macosx-10.3-i386-2.5/wc.o -L/Users/cam/local/lib -lsvn_client-1 -lsvn_subr-1 -o build/lib.macosx-10.3-i386-2.5/bzrlib/plugins/svn/client.so -L/usr/lib -lapr-1
[08:37] <markh> is bzr likely to use the python 'compiler' package at runtime, or can I safely exclude it from the windows binaries?
[08:37] <berto-> astrec: you have /usr/lib/libapr-1*.dylib, right?
[08:38] <astrec> "/usr/lib/libapr-1.0.2.7.dylib	/usr/lib/libapr-1.0.dylib	/usr/lib/libapr-1.dylib"
[08:38] <berto-> astrec: why are you getting temp.macosx-10.3 ?
[08:38] <berto-> which python ?
[08:39] <astrec> berto-: not system. /Library/Frameworks/Python.framework/Versions/Current/bin/python
[08:40] <berto-> astrec: that's scary.  you're using an old version of python.
[08:40] <berto-> well, maybe not old, rather not compiled specifically for leopard.
[08:40] <astrec> yeah, not old: Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53). but not compiled for leopard
[08:40] <berto-> astrec: try this: /usr/bin/python2.5 setup.py build
[08:41] <berto-> astrec: i had MacPython on this system and had all sorts of issues.
[08:41] <berto-> is there a reason you need 2.5.2 vs. system python, which is 2.5.1 ?
[08:43] <astrec> berto-: only to add a bunch of packages to it
[08:43] <astrec> berto-: that worked btw.
[08:43] <berto-> oh, i see, it's from darwin ports or something, huh?
[08:43] <astrec> no, it's macpython from python.org
[08:43] <astrec> i think i will use system for bzr
[08:43] <berto-> hmm, where are the extra packages coming from, then?
[08:44] <berto-> astrec: yeah, just change the shebang or add an alias.
[08:44] <astrec> they're part of our app
[08:44] <berto-> astrec: ok.
[08:44] <astrec> will do. thanks for your help berto-
[08:44] <berto-> no problem, enjoy.
[08:51] <kiorky>  jelmer toward bzr svn i didnt upstream you that : http://rafb.net/p/oKgQ9h69.html which facilitate compilation in non standart envs.
[08:51] <kiorky> oups
[08:55] <kiorky> jelmer: http://rafb.net/p/wrinSS26.html
[09:55] <luks> hm, the new loggerhead theme confuses me
[09:57] <jamesh> luks: then file bugs
[09:57] <luks> it's more usability things, than real bugs
[09:58] <jamesh> luks: then file bugs
[09:58] <luks> ok :)
[09:58] <spiv> usability bugs *are* real bugs :)
[09:59] <spiv> After all, they're often hard to fix, like other real bugs ;)
[10:05] <fullermd> "I can't figure out how to file a bug."  "File a bug on it."
[10:30] <luks> ok, I think I'm done for now
[10:30] <luks> bueno will probably hate me anyway :)
[10:40] <Odd_Bloke> james_w: Thanks. :)  It is my first package.
[12:12] <beuno> new theme in LP!
[12:12]  * beuno dances around
[12:17]  * markh tries again :)
[12:17] <markh> is bzr likely to use the python 'compiler' package at runtime, or can I safely exclude it from the windows binaries?
[12:20] <james_w> markh: hi, it's used by configobj apparently, but IronPython doesn't have it, so it handles the import error. However, there is a feature that requires it, but I don't know if that feature is used by bzr.
[12:21] <markh> heh
[12:22] <markh> well, that's good to know, and for the few bytes it would save, I guess it can live :)
[12:22] <james_w> it appears to allow you to embed a dictionary as a value, I don't bzr makes use of that
[12:22] <james_w> you could always strip it and see what fails :-)
[12:23] <markh> I think I'll wait until windows gets down to less than a dozen or so failing tests before I get that brave ;)
[12:25] <markh> It must do something funky with that dict though to require the compiler package...
[12:26] <james_w> it stores it in repr form in the text file as far as I can see
[12:26] <james_w> def getObj(s):
[12:26] <james_w>     s = "a=" + s
[12:26] <james_w>     if compiler is None:
[12:26] <james_w>         raise ImportError('compiler module not available')
[12:26] <james_w>     p = compiler.parse(s)
[12:26] <james_w>     return p.getChildren()[1].getChildren()[0].getChildren()[1]
[12:27] <markh> yeah - which eval could reconstruct - but I guess it wants to avoid eval
[12:27] <markh> "untrusted" config files?
[12:28] <markh> or maybe it supports types that repr/eval can't reconstruct... whatever :)  thanks!
[12:42] <poolie> beuno: well done on the theme, it looks great on lp
[12:44] <beuno> hey poolie!  Thanks  :)  I'm really happy to finally see it live
[12:44] <poolie> don't stop now! :)
[12:45] <beuno> heh, of course not, this is an incentive  ;)
[12:47] <poolie> i think that's enough for me
[12:47] <poolie> night all
[12:47] <markh> night poolie
[12:48] <beuno> g'night poolie
[12:59] <james_w> night poolie
[12:59] <james_w> hi besonen_mobile__
[12:59] <james_w> hi beuno :-)
[13:02] <beuno> howdy james_w!
[13:05] <james_w> beuno: congratulations on the new theme landing, it looks great.
[13:06] <beuno> james_w, thanks :)  although, to be fair, mwhudson's reviews have been unvaluable
[13:14] <bob2> hm, I don't seem to be able to 'branch' a branch in a rich-root-pack repo over bzr+ssh anymore
[13:15] <bob2> ah, B_R_P wasn't set
[14:58] <james_w> hey, could someone in ~bzr and do me a favour and close bug 252894 as Fix Released and milestone for 1.6?
[14:59] <james_w> I'm having some issues today which mean I can't login to launchpad.
[15:00] <Odd_Bloke> james_w: Done.
[15:00] <james_w> thanks
[15:10] <jam> igc: I'll be happy to review your patches, but right now BB is giving me PROXY timeouts
[15:10] <jam> And abentley is in NZ, so will be sleeping during my TZ
[15:10] <igc> jam: yeah - me too
[15:10] <jam> Any chance you could give me the subjects, and I'll do it via email?
[15:11] <igc> jam:sure
[15:11] <igc> jam: Make it easier to introduce new WorkingTree formats
[15:12] <igc> jam: do not export .bzrrules
[15:12] <igc> jam: lookup rules using get_special_file API
[15:12] <igc> that's the 3
[15:12] <jam> igc: quickly, I'm a bit concerned about the 'get_special_file', the other two I'm probably happy with
[15:12] <jam> But I'll review them all
[15:13] <jam> igc: I'm surprised you're still awake, are you shifting your schedule a bit?
[15:14] <igc> jam: just catching up some hours
[15:15] <gour> igc: how is the fight against enemy?
[15:15] <RealNitro> is there a tutorial about interfacing with bzr-repositories through python? Something like repo = BzrRepo(path)
[15:16] <igc> gour: it has its good days and bad days
[15:16] <igc> gour: week 4 of 6 now
[15:16] <jam> RealNitro: http://bazaar-vcs.org/Integrating_with_Bazaar ?
[15:17] <igc> (of the initial stage of the battle at least)
[15:17] <RealNitro> jam: thx!
[15:17] <gour> igc: keep up the spirit. have you managed to read something of that material?
[15:18] <igc> gour: not a lot I must say - my reading pile is long
[15:19] <gour> igc: heh, use Emacs' org-mode and run it for GTD :-)
[15:37] <igc> night all
[15:43] <gour> night, igc
[15:44] <jam> igc: sleep well
[15:44] <jam> patches reviewed
[16:53] <Odd_Bloke> jelmer: python-git is in the NEW queue. :D
[17:55] <Odd_Bloke> If any Mac users have a minute: https://bugs.launchpad.net/qbzr/+bug/253008
[17:56] <james_w> yeah, I didn't know how to install python-qt4 on mac
[17:57] <Odd_Bloke> I should probably have converted it to a question, but was worried that that would confuse everyone involved so didn't. :p
[18:46] <tolstoy> Hi folks. Simple question. If you've branched, and then you work on the branch, etc, etc.  How can you tell exactly when/where you branched from the parent without having tagged?
[18:47] <radix> tolstoy: You can use the "ancestor:branchname" revision spec
[18:47] <radix> so, in the context of ../branch1, if you use "-r ancestor:../trunk", it means "the ancestor revision of this branch in ../trunk"
[18:48] <tolstoy> Hm. Okay.  Thanks.
[18:53] <tolstoy> I think that worked (for my colleague). Thanks!
[19:55] <mtaylor> bzr: ERROR: Invalid bug 252805. Must be in the form of 'tag:id'. Commit refused
[19:56] <mtaylor> I'm not sure what to put for --fixes, given the above error
[19:56] <mtaylor> I tried --fixes=252805...
[19:56] <radix> mtaylor: I think it's supposed to be 'lp:252805'
[19:56] <mtaylor> ah
[19:56] <mtaylor> There we go. thanks radix
[19:59] <Odd_Bloke> mtaylor: If you don't think --fixes is well-documented enough, could you please file a bug about it?
[19:59] <mtaylor> Odd_Bloke: sure
[20:01] <Odd_Bloke> mtaylor: Thanks. :)
[20:04] <mtaylor> Odd_Bloke: Bug 120050
[20:05] <Odd_Bloke> Well, I should probably have checked first. :p
[20:05] <Odd_Bloke> mtaylor: Sorry to waste your time.
[20:05] <mtaylor> Odd_Bloke: no problem!
[20:58] <oohlaf> why doens't bazaar have a bzr copy command?
[20:58] <oohlaf> next to move
[20:59] <oohlaf> I just ran into having to copy a file in a repo and make some modifications to it, but then it's not annotated
[20:59] <oohlaf> with the previous auther
[21:01] <jelmer> oohlaf, it's planned, just not implemented yet
[21:05] <james_w> jam: I was working on the bug tracker thing as well :-)
[21:05] <james_w> jam: are you cleaning your patch up to submit it?
[21:05] <jam> james_w: I'm not doing anything more than what I posted
[21:05] <oohlaf> jelmer: ah, ok
[21:06] <jam> I'm working on merge again
[21:06] <oohlaf> jelmer: you prob need it for svn copy, right?
[21:06] <jam> james_w: if you are working on it, make sure to assign it to you
[21:06] <james_w> jam: cool, I'm working on it, so I didn't want to duplicate work.
[21:06] <james_w> true
[21:07] <beuno> anyone happen to know how I can convince distutils to install zope templates on the package's dir?
[21:11] <jam> beuno: "package's" dir?
[21:11] <jam> do you mean in-place?
[21:12] <beuno> jam, I need them to be in site-packages/.../loggerhead/templates/*
[21:12] <beuno> and it only copies .py in there
[21:12] <jam> Like "python setup.py build_ext -i" ?
[21:12] <Dossy> bzr: ERROR: Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "sftp://dossy@bzr.savannah.gnu.org/srv/bzr/gnash/trunk/".
[21:12] <Dossy> Suggestions?
[21:12] <Dossy> $ bzr version
[21:12] <Dossy> Bazaar (bzr) 1.6b3
[21:12] <jam> Dossy: you are trying to push something which merged trunk
[21:12] <jam> rather than merging into trunk
[21:12] <Dossy> jam: I guess so.
[21:12]  * Dossy is a bzr newbie.
[21:12] <jam> and that cannot be pushed because someone set the "append_only" flag
[21:12] <jam> the recommendation is to
[21:12] <jam> bzr co gnash/trunk
[21:12] <jam> cd trunk
[21:12] <jam> bzr merge ../my-branch
[21:12] <jam> bzr commit
[21:13] <jam> (with appropriate full paths)
[21:13] <Dossy> Oh.  Ack.
[21:13] <Dossy> I have to duplicate commit messages?
[21:13] <beuno> jam, I'm not sure what "setup.py build_ext -i" would do
[21:14] <Dossy> OK, so at this point - what can I do?  LOL.  And, I should bzr checkout and not bzr pull or bzr branch?
[21:14] <jam> beuno: it is what we use with bzr
[21:14] <Dossy> What's the difference between bzr pull and bzr branch anyway?
[21:14] <jam> it puts the .so library "in tree" rather than only building it in the build/... directory
[21:15]  * beuno peaks in bzr's setup.py
[21:15] <jam> Dossy: 'bzr pull' fetches changes that you don't have yet to local
[21:15] <jam> beuno: that would probably be in 'Makefile'
[21:15] <jam> Dossy: I'm assuming you just recently merged trunk?
[21:15] <jam> (as in, the last action you did?)
[21:15] <Dossy> jam, yes
[21:15] <Dossy> and committed the change
[21:15] <jam> then I would "bzr merge -r -2"
[21:16] <jam> which would skip your merge commit
[21:16] <jam> and merge the previous revision
[21:16] <Dossy> Hm.  OK.
[21:16] <jam> and only type the message there
[21:16] <jam> well, you are technically doing it twice, but the one won't show in trunk
[21:16] <jam> Dossy: alternatively you could "bzr uncommit; bzr revert" in your branch
[21:16] <Dossy> Oh, my local commit messages won't show in trunk?
[21:16] <jam> Dossy: well if you do "bzr merge -r -2" then the *last* revision won't be merged
[21:16] <jam> andthus, not show up in log
[21:17] <Dossy> Ohh - what about the commits I actually want to push?  :)
[21:17] <jam> Things you "bzr merge && bzr commit "will show up in the log
[21:20] <Dossy> Wow.  bzr uncommit is ... slow.
[21:21] <james_w> has anyone seen a hang in blackbox.test_outside_wt.TestOutsideWT.test_url_log?
[21:23] <alecwh> Are there any web services (besides Launchpad) that will host bazaar repositories?
[21:24] <james_w> alecwh: alioth and savannah are two that spring to mind, though they are not completely general purpose
[21:24] <alecwh> the project isn't open source...
[21:25] <beuno> jam, I'm looking at it, but I'm not quite sure how I'd use that to copy over arbitrary files
[21:25] <Odd_Bloke> alecwh: Anywhere that gives you SSH and HTTP access can be used as a web host for bzr.
[21:25] <alecwh> What about FTP and HTTP?
[21:26] <jam> beuno: it isn't for copying arbitrary files, it is for building an extension such that you can run in-tree
[21:26] <jam> beuno: I don't honestly know why it isn't copying the files over
[21:26] <jam> Though I don't know what command you are using
[21:26] <jam> beuno: 'python setup.py install --help'
[21:27] <jam> has a --install-base, --install-platbase, --install-purelib, etc
[21:27] <jam> --install-platbase  base installation directory for platform-specific files
[21:27] <jam>                     (instead of --exec-prefix or --home)
[21:27] <jam> sounds like something compiled
[21:27] <beuno> yeah, let me push real quick, and see if something obvious pops up to you
[21:27] <beuno> if not, I'll keep hammering help files and google  :)
[21:29]  * beuno waits for codebrowse to mirror the branch
[21:30] <jam> beuno: I can get it via bzr+ssh
[21:30] <jam> what branch?
[21:30] <jam> (though my net connection here might be rather slow)
[21:30] <beuno> jam, lp:~beuno/loggerhead/fix_setup
[21:31] <jam> beuno: so... can you explain *why* you are doing this?
[21:32] <jam> It seems like SimpleTAL should get installed as normal
[21:32] <jam> and you just use it from there
[21:32] <beuno> jam, I need the *.pt files in templates/
[21:32] <jam> why?
[21:33] <Dossy> grr.  bzr break-lock doesn't seem to work on win32.
[21:33] <Dossy> it just hangs.
[21:34] <jam> beuno: also, I would recommend using loggerhead.__version__ rather than hard-coding '1.6' in setup.py
[21:34] <jam> It is generally a good idea to have a *minimum* number of places where you need to change version strings
[21:35] <beuno> jam, noted
[21:35] <beuno> I need the .pt files there because that's where LH looks for them
[21:35] <jam> otherwise you always forget one :)
[21:35] <jam> beuno: so right now, you just have them manually copied there?
[21:36] <beuno> jam, right now, it doesn't work. setup.py has been broken for ages.
[21:36] <jam> and you can't use a "try import from_tal else import_from_local"
[21:36] <jam> beuno: well, I see .pt files in there
[21:36] <jam> and I ran from source without it causing problems
[21:36] <jam> beuno: are you just trying to install the .pt files that you already *have* in there?
[21:37] <beuno> jam, it works from source. The problem is when you install it
[21:37] <jam> I think I just caught on to what you wanted
[21:37] <beuno> it installs serve-branches in /usr/bin
[21:37] <jam> I thought you wanted to install *Zope* templates
[21:37] <jam> not templates for the Zope engine
[21:37] <beuno> ah, yes  :)
[21:37] <beuno> sorry I wasn't clear from the start
[21:37] <jam> beuno: "package_data"
[21:37] <jam> look at setup.py for bzrlib
[21:38] <jam> namely, the 'doc/api/*.txt'
[21:38] <beuno> that simple?
[21:38]  * beuno looks
[21:38] <jam> and 'tests/test_patches_data"
[21:38] <jam> PKG_DATA = {# install files from selftest suite
[21:38] <jam>             'package_data': {'bzrlib': ['doc/api/*.txt',
[21:38] <jam>                                         'tests/test_patches_data/*',
[21:38] <jam>                                         'help_topics/en/*.txt',
[21:38] <jam>                                        ]},
[21:38] <jam>            }
[21:38] <jam> beuno: so "package_data = {'loggerhead': ['templates/*']}"
[21:38] <jam> or something along those lines
[21:39] <alecwh> jam: pastebin that next time
[21:39] <jam> [21:39] <jam> --- setup.py    2008-07-29 19:17:53 +0000
[21:39] <jam> +++ setup.py    2008-07-29 20:39:29 +0000
[21:39] <jam> @@ -41,6 +41,7 @@
[21:39] <jam>      scripts = ["start-loggerhead", "stop-loggerhead", "serve-branches"],
[21:39] <jam>      packages = ["loggerhead",
[21:39] <jam>                 ],
[21:40] <jam> +    package_data = {'loggerhead': ['templates/*']},
[21:40] <jam>      data_files=[
[21:40] <jam>                  ('share/man/man1',['start-loggerhead.1', 'stop-loggerhead.1']),
[21:40] <jam>                  ('share/doc/loggerhead', ['loggerhead.conf.example'])
[21:40] <jam> alecwh: yeah, sorry
[21:40] <alecwh> =(
[21:40] <jam> Just trying to get done, and firing up a browser takes a while
[21:40] <beuno> jam, you rock, thank you  :)
[22:10] <Dossy> ok, looks like bzr uncommit is broken on win32.  i've left it running ~40 minutes, and it's not done
[22:10] <Dossy> and no progress indicator.  no output at all, and I ran it with -v
[22:19] <lifeless> Dossy: can you look at your .bzr.log
[22:20] <lifeless> beuno: why not nuke serve-branches as a script altogether?
[22:21] <beuno> lifeless, nuke it?  why?
[22:21] <lifeless> beuno: 'bzr serve-branches' as an interim step, and then 'bzr serve --http'
[22:22] <beuno> interesting
[22:22] <lifeless> if you look at the help for bzr serve
[22:22] <lifeless> 'bzr serve-branches' will give you help and option parsing etc for ~ free
[22:23] <lifeless> if you look at the help for bzr serve you'll see that it is basically the same as any help you might write for serve-branches
[22:23] <beuno> lifeless, makes perfect sense, I'll go down that path
[22:23] <beuno> and, good morning  :)
[22:23] <lifeless> hi
[22:24] <lifeless> there is a thread at the moement about whether bzr serve --http makes sense, but putting that aside, having loggerhead start as a normal extension command seems uncontentious and to give benefits.
[22:26] <beuno> yeap, and it will feel much more integrated
[22:26] <beuno> I like it!
[22:27] <beuno> I also have all this ajax-voodoo in store, now that the new theme has landed everywhere
[22:27] <lifeless> cool
[22:27] <lifeless> is the gnome themed loggerhead getting it too ?
[22:28] <beuno> yeap, I uploaded a new branch with the new theme for 'em
[22:29] <beuno> but I don't think Jc2k got around to merging it
[22:29] <beuno> lp:~beuno/loggerhead/new_theme_gnome
[22:29] <lifeless> nag thumper
[22:29] <lifeless> playground is something he has work time for now :)
[22:29] <beuno> yay!
[22:30] <beuno> will do
[22:39] <lifeless> beuno: I'm curious though, I did mention this in the thread
[22:39] <lifeless> was I unclear?
[22:41] <beuno> lifeless, you did, I just didn't see it as straightforward
[22:41] <beuno> 'bzr serve-branches' tipped me off it's much simpler then I thought
[22:41] <lifeless> heh ok
[22:42] <pickscrape> I've just discovered the possible_transports parameter that is available throughout bzrlib
[22:42] <pickscrape> Does this need to be maintained manually?
[22:43] <pickscrape> i.e. if I call a function and pass a list, do I need to add the transport my code uses to the list in case it needed to create a new one?
[22:47] <lifeless> pickscrape: its an optional performance improvement
[22:48] <lifeless> it can also avoid giving users additional password prompts in some situations
[22:48] <pickscrape> lifeless: for what I'm doing it's quite a significant performance improvement :)
[22:49] <pickscrape> It reduces the number of SSH reconnects from some factor of 14 to just 1.
[22:50] <lifeless> nice
[22:50] <lifeless> sounds like you are opening very many new branch/repository objects
[22:51] <pickscrape> Our migration split our monolithic svn repository up into smaller more focused repositories
[22:51] <pickscrape> We're writing a plugin to allow some operations to be performed on a set of them at once.
[22:52] <lifeless> yes, thats the sort of situation where it matters
[22:52] <lifeless> branch objects etc hold open their transport
[22:53] <pickscrape> Yes, it was quite magical making a simple change to the code and then watching the ssh log on the server become far quieter :)
[22:53] <lifeless> but we removed a global cache we had which caused many problems
[22:53] <lifeless> which is why we have this parameter
[22:54] <pickscrape> Lovely feature to find :)
[22:56] <chadmiller> Hi all.  I have a shared repo, containing v1, v2, and v3 branches.  "bzr tags" lists all tags, regardless of whether its associated revision is in this branch or not.  This is a bug, yes?
[22:56] <chadmiller> I can't see how it's useful, but...
[22:57] <lifeless> chadmiller: it lists tags in a given branch
[22:57] <lifeless> chadmiller: so if you have tags that are irrelevant to a branch, you've put them in there somehow :P
[22:58] <lifeless> chadmiller: possibly your converter was not selective about which tags went into which branch
[22:58] <chadmiller> lifeless: Hrm.  That's possible.
[23:00] <chadmiller> And lpbug#138802 won't let me delete them.  Grr.
[23:01] <lifeless> bug 138802
[23:01] <chadmiller> Oh well.  No big deal.  Just ugly.
[23:01] <lifeless> you can copy the tags file up by hand if you like
[23:01] <chadmiller> Not for 175 developers.
[23:01] <lifeless> oh :[
[23:01] <lifeless> true dat
[23:01] <chadmiller> Each with dozens of trees.
[23:02] <chadmiller> Okay.  Thanks.
[23:08] <lifeless> spiv: ping; that reconcile bug - I wasn't intending to ask you to hack on it, but in case you did start doing that I'm going to leave it idle until you reply
[23:35] <pickscrape> lifeless: do you have a minute regarding the possible_transports stuff?
[23:35] <pickscrape> One of the things we're doing is running update on a number of checkouts
[23:36] <lifeless> sure
[23:36] <pickscrape> I've done this by extending bzrlib.builtins.cmd_update, and calling the base class's run method for each checkout I'm iterating through
[23:37] <pickscrape> It works fine, except that it's connecting to the server for each checkout, and possible_transports is initialised in bzrlib.builtins.cmd_update.run() each time
[23:38] <pickscrape> I've experimentally tried moving it to a member variable of bzrlib.builtins.cmd_update instead of a local variable of run(), and that gives me what I need for free without any changes in my code
[23:38] <pickscrape> But I'm not sure if such a change would be acceptable in bzrlib
[23:38] <lifeless> mmm
[23:38] <lifeless> you could do that
[23:38] <lifeless> but the command classes are intended to be CLI layer only
[23:39] <lifeless> why are you not using the WorkingTree.update method ?
[23:40] <pickscrape> The advantage to using the command class is that I get functionality consistent with the main command for free
[23:41] <pickscrape> It's not actually much of an advantage with update, but with things like status it means I get option handling and output consistent with the core command
[23:41] <mwhudson> beuno: hi
[23:43] <lifeless> pickscrape: I'm ok with run being an instance variable
[23:43] <lifeless> pickscrape: long as its not a class variable
[23:44] <pickscrape> lifeless: I'm embarrassed to say I'm not entirely clear on the difference with python :( I'm relatively new to it
[23:44] <lifeless> class foo:
[23:44] <lifeless>   bar = None
[23:44] <lifeless> -> bar is a class variable
[23:44] <lifeless> class foo:
[23:44] <lifeless>   def __init__(self):
[23:44] <lifeless>     self.bar = None
[23:44] <lifeless> -> bar is an instance variable
[23:45] <pickscrape> Aha, that makes sense, thanks. My little experiment used a class variable: I'll try it with an instance variable.
[23:47] <pickscrape> lifeless: worked with the instance variable too
[23:48] <lifeless> put it in NEWS, send a bundle :P
[23:48] <pickscrape> lifeless: If I was to submit a patch, should I do this with just this one command, or others for which it would make sense too?
[23:49] <lifeless> pickscrape: as many as you like
[23:49] <lifeless> I'd start with one and see what the reaction is
[23:49] <lifeless> (unless you've done others already)
[23:49] <pickscrape> lifeless: I've just done one. I'll do that tomorrow. Thanks for the help!
[23:50] <Peng_> Personally, I'd like it if remove-tree could operate on multiple dirs at once, but I've been too lazy to do anything about it.
[23:53] <lifeless> Peng_: I think thats a different change; pickscrape is making the command more useful to subclassers, not changing the UI level behaviour
[23:53] <Peng_> Oh, okie dokie.
[23:57] <spiv> lifeless: I haven't started hacking on it, no.