[00:25] <poolie> BitSprocket, which bit didn't work?
[00:25] <poolie> what's going wrong?
[00:28] <BitSprocket> It seems that it removed something called 'tree' *unsure* but the files are still marked with the versioning status as if nothing changed.  I tried to export the files but that didn't seem to work either...
[00:29] <poolie> what does 'bzr status' show?
[00:29] <BitSprocket> '... Modified'
[00:30] <poolie> so you did 'bzr rm --keep THING'
[00:30] <poolie> and now 'bzr st' still shows some files under that directory as modified?
[00:30] <poolie> really?
[00:31] <BitSprocket> Yes, but it may be after I've done some more tinkering.  I just tried the bzr rm --keep and now the status says:
[00:31] <BitSprocket> bzr: ERROR: No WorkingTree exists for "file:///home/scott/pytivo/.bzr/checkout/".
[00:31] <poolie> !
[00:31] <poolie> maybe you're in the wrong directory?
[00:32] <BitSprocket> I thought so too so I tried the same steps moving down the directory structure to where the actual files were and did the same thing with the same results.
[00:32] <poolie> in which directory is your actual working tree?
[00:32] <BitSprocket> not sure what you mean by working tree ... sorry
[00:33] <poolie> do you have ~pytivo/trunk or something?
[00:33] <poolie> i mean ~/pytivo/trunk ?
[00:33] <BitSprocket> Ah, yes, its exactly that.
[00:33] <poolie> ok, cd there
[00:33] <BitSprocket> done
[00:33] <poolie> now which directory did you want to un-version?
[00:33] <BitSprocket> trunk and everything below
[00:34] <poolie> !!
[00:34] <poolie> hm
[00:34] <poolie> i think i misunderstood your question
[00:34] <poolie> why do you want to do this?
[00:35] <BitSprocket> Well, I'm learning how to use bzr and I discovered that I created the repository in the wrong directory.  My files are actually located in pytivo/trunk/TheBayer and I don't need version control configured for anything above theBayer.  I figured if I removed the whole thing and started over I would be better off.
[00:36] <poolie> oh i see
[00:36] <poolie> so what is TheBayer?
[00:36] <poolie> all the source is inside that?
[00:36] <BitSprocket> Its a python project that allows me to stream videos to my tivo box from the network.  And yes, that's where the source files are.
[00:36] <poolie> when someone else gets a checkout, do you want them to get a directory called TheBayer, or do you want them to just get the files that you have inside that directory?
[00:37] <BitSprocket> Well, for now, it's a project that I'm using to learn python so for the immediate future it won't be a public repo.  I just wanted to be able to roll back changes if I really fouled things up.
[00:37] <BitSprocket> I suppose that directory and everything below as one package
[00:43] <poolie> ok so really TheBayer is the name of your branch?
[00:43] <poolie> as opposed to trunk?
[00:43] <poolie> that's the codename for the feature or something?
[00:44] <BitSprocket> TheBayer is the name of the project that I downloaded from the web.  It's not really my project, its someone elses work that I'm using to cut my teeth.  No codenames, nothing special.  I believe that's what he named his fork from another project.
[00:45] <BitSprocket> I untarred it and got a directory called TheBayer with all the source in it.
[00:45] <BitSprocket> the pytivo and trunk folders I created myself.
[00:47] <poolie> ok
[00:47] <poolie> so i suggest you do
[00:47] <poolie> cd ~/pytivo/trunk/
[00:47] <poolie> mv TheBayer ../
[00:47] <poolie> cd ../TheBayer
[00:47] <poolie> bzr init; bzr add; bzr commit
[00:48] <BitSprocket> Okay, so if I understand you, you are suggesting I move the folder and create a new repo right?
[00:59] <poolie> yes
[01:00] <BitSprocket> got it...
[01:02] <spiv> Morning.
[01:03] <mneptok> spiv: ahoyhoy
[01:06] <BitSprocket> Hi spiv;GugaDin
[01:16] <meoblast001> if any of you are familiar with TracBzr, i'm getting "Warning:  Error with navigation contributor 'BrowserModule' "
[01:17] <meoblast001> that is, in the Admin/Repositories page
[02:13] <poolie> hi spiv
[02:14] <poolie> spiv, lifeless, one of us should look at https://bugs.launchpad.net/bugs/594275 fairly soon
[02:16] <lifeless> what makes that one critical?
[02:16] <lifeless> (vs other automated imports failing)
[02:16] <lifeless> we need to move the package importer from its current machine too
[02:16] <lifeless> and find a team to own it
[02:18] <lifeless> fixing that particular bug may fix 15 or so imports
[02:18] <lifeless> which would be nice
[02:18] <poolie> lifeless, it makes it critical that it's blocking barry's attempt to do udd
[02:18] <poolie> on inspection a downgrade might be appropriate
[02:43] <lifeless> man, I hate spam
[02:44] <lifeless> and gmail is failing at catching all these twitter 'we've reset your password' mails.
[02:44] <lifeless> It appears that the spammers are bcc'ing all of canonical on each personalised mail!
[02:46] <fullermd> "... twitter ..."   <--- Found your problem.
[02:46] <lifeless> hah
[02:49] <lifeless> vila: btw
[02:49] <lifeless> SYN_SENT2 minutes
[02:50] <lifeless> http://www.dd-wrt.com/wiki/index.php/Router_Slowdown was a quickly found reference for this
[02:50] <lifeless> vila: which suggests to me that the server thread isn't actually accepting when it starts, but has presumably open the socket so it doesn't get rejected either. Or something.
[02:51] <chx> i have created a launchpad branch stacked on top of an earlier tag of another lp branch. i have a local checkout of both for speedy work. I would like to merge all revisions affecting a certain directory. How can I do that? Just doing the merge does the file changes but does not actually merge revisions.
[02:52] <lifeless> thats right, merging only part of a patch is a cherrypick and cannot show up as a full merge.
[02:53] <chx> as said, i would like to merge full revisions, affecting a file / directory ... does that involve lots of scripting trickery :) ?
[02:57] <lifeless> you want to merge a revision, but not its parents, right ?
[03:02] <lifeless> chx: ^?
[03:02] <chx> reading
[03:02] <chx> hrm
[03:03] <chx> i think the answer is yes :)
[03:03] <lifeless> so, thats not a complete merge
[03:03] <chx> oh?
[03:03] <chx> well, yes, it's cherry picking
[03:03] <lifeless> a complete merge merges a revision *and its parents*, recursively
[03:03] <chx> but it's revisions that it merges
[03:03] <lifeless> all the way back to the revisions that your branch already has
[03:03] <chx> which would bring in changes to ohter wiles.
[03:03] <chx> *files
[03:04] <chx> so a) i need to find which revisions affected a file b) merge in just those revisions
[03:04] <chx> right?
[03:05] <lifeless> lets start over
[03:05] <lifeless> what are you doing at the moment, and what is going wrong
[03:06] <chx> heh
[03:07] <chx> let's go step by step
[03:07] <chx> a)  i have created a launchpad branch (sandbox) stacked on top of an earlier tag of another lp branch (trunk)
[03:07] <chx> b) i have checked out both
[03:07] <chx> c) cd sandbox/sites
[03:07] <chx> d) bzr merge ~/examiner/trunk/sites/parc/
[03:08] <chx> e) bzr ci -m 'merged in parc changes to sandbox'
[03:08] <chx> f) check with bzr log -n0 -- oopsie no revisions!
[03:08] <chx> g) bzr uncommit
[03:08] <chx> h) /join #bzr
[03:08] <chx> makes sense?
[03:09] <lifeless> what does bzr root ~/examiner/trunk/sites/parc/
[03:09] <lifeless> print out
[03:10]  * spiv guesses the root is ~/examiner/trunk
[03:11] <chx>  /home/chx/examiner/trunk
[03:11] <lifeless> ok
[03:11] <chx> it's a checkout of lp:~examiner-dev/examiner/trunk
[03:11] <lifeless> chx: that has happened because you merged a subdirectory.
[03:11] <chx> I created the sandbox branch with bzr branch -r tag:Perugina --stacked lp:~examiner-dev/examiner/trunk lp:~examiner-dev/examiner/sandbox if that matters
[03:11] <lifeless> chx: doing that makes it a cherrypick
[03:11] <chx> i see.
[03:11] <lifeless> chx: and cherrypicks *are not recorded in log*
[03:12] <chx> hm
[03:12] <lifeless> you have two options
[03:12] <lifeless> a) don't worry about it not being in log
[03:12] <lifeless> b) don't merge a subdirectory
[03:13] <chx> and if i do bzr merge -c 15932 ../trunk then it'll show up?
[03:13] <lifeless> no
[03:13] <chx> only bzr merge ../trunk will?
[03:13] <lifeless> because -c does a cherrypick in the graph as well, a different sort of cherrypick but still a cherrypick
[03:13] <lifeless> thats right.
[03:14] <chx> ok, so then i might pick a
[03:14] <chx> and hope that when i later do just bzr merge trunk then it will simply figure out that some differences are already in.
[03:15] <chx> it looks like i have no other choice
[03:15] <spiv> Right.  bzr merge can record "revision X (and all parents of X) has been merged", but not "revision X without parents" or "just some subdirectories changed in revision X", or other variations.
[03:15] <spiv> 'bzr merge' will generally avoid reporting conflicts if the exact change to merge already seems to have been applied.
[03:15] <chx> but then bzr merge is awesome and will figure out that some changes are already in.
[03:16] <chx> right.
[03:17] <chx> my heart still aches for darcs but it is so slow :(
[06:35] <poolie> lifeless, oh did i mention that we talked a bit about user models
[06:36] <poolie> there's a file in devnotes about this
[06:36] <poolie> http://doc.bazaar.canonical.com/devnotes/bzr3-user-stories.html
[06:41] <lifeless> cool
[06:44] <spiv> way
[06:44] <spiv> ...that was an odd typing mistake, but let's pretend I meant to say "way cool" :)
[06:49] <poolie> hey spiv :)
[06:56] <poolie> spiv, https://code.edge.launchpad.net/~mbp/bzr/590638-buffering/+merge/27578 is the issue of excessive buffering from last monday
[06:56] <poolie> not urgent
[06:57] <spiv> poolie: thanks!
[06:58] <assad> how to confirm that merge is done and all conflicts resolved?
[06:58] <poolie> assad, 'bzr st'
[07:00] <assad> poolie, i am getting this: pending merge tips: (use -v to see all merge revisions)
[07:00] <poolie> ok
[07:00] <assad> poolie, is the merge over and conflicts resolved?
[07:00] <poolie> try 'bzr conflicts'
[07:00] <poolie> if there are none you're ready for 'bzr commit'
[07:01] <assad> none, thanks
[07:01] <assad> :)
[07:29] <vila> hi all
[07:31] <poolie> hi there vila
[07:31] <poolie> i have a ScriptRunner patch for you
[07:31] <vila> poolie: hey !
[07:31] <poolie> and i guess you already know you're lotzman this week
[07:32] <vila> hmm, looks like I missed a joke somewhere, that's the second time I see 'lotzman' used and I have no idea what it means :) Well, except some relation with patch pilot  that is :)
[07:32] <poolie> it's the Russian word for "pilot" in the sense of someone who helps a ship into a harbor
[07:33] <poolie> bialix told us that when he asked what 'patch pilot' means
[07:33] <vila> haaa, yeah, the first reference was from bialix indeed :)
[07:33] <vila> 'pilote' is the French word for that
[07:34] <poolie> heh
[07:35] <poolie> so https://code.edge.launchpad.net/~mbp/bzr/scripts/+merge/27581 is the one i was thinking of
[07:35] <poolie> and then https://code.edge.launchpad.net/~mbp/bzr/externalbase/+merge/27583 uses scripts quite a lot and to good effect
[07:35] <vila> ok, I'll look into it today
[07:41] <poolie> i don't mean to harrass you there :)
[07:42] <vila> hehe, no harassment taken :)
[07:45]  * mneptok arrives on cue
[07:45] <mneptok> did someone order some harrassment?
[07:59] <assad> poolie, how can i update one branch on launchpad with another branch on launchpad? so that i dont have to first merge my branch and then push the changes to the other branch.
[08:01] <poolie> can you explain more?
[08:01] <vila> assad: A merge requires a working tree, lp have no WT, I'm pretty sure you can't achieve what you want there
[08:01] <spiv> assad: If I'm understanding your question correctly (what exactly do you mean by "update"?), you can't.  What's the problem with pushing the changes?
[08:09] <assad> poolie, i intend to update/push changes to my branch from the parent branch via lp itself. so that i dont have to move files through my machine.
[08:09] <poolie> assad, just for curiousity which project is this?
[08:09] <poolie> assad, no, you can't really do that, you need to push from your machine into the other branch
[08:09] <assad> poolie, ok
[08:10] <poolie> it might be nice if lp let you do the merge remotely but we don't atm
[08:10] <assad> ok
[08:24] <vila> lifeless, spm: How did your pqm fixes went ?
[08:24] <vila> poolie: geee ! No harassment but nothing less than *7* mps !!! :)
[08:26] <spm> hey vila, sadly no progress *yet*, but I am right now about to attempt to apply lifeless' patch and get the package(s) rebuilt. which is step A in this one.
[08:26] <vila> spm: hi ! No harassment, no harassment :) Thanks for the feedback !
[08:27] <spm> :-) np
[10:44] <lifeless> vila: did you see my web link for you in backlog ?
[10:46] <vila> lifeless: yup, thanks
[10:47] <vila> I don't know how to check that on windows though, but I'm about to try to address it anyway by finishing what I started on SmartServer_for_testing first and see from there
[10:49] <lifeless> vila: try changing the timeout in the registry, if the behaviour changes to match, thats what it is
[10:50] <vila> regis..what ? :)
[12:33] <bialix> heya
[12:33] <bialix> bonjour vila !
[12:46] <wgrant> \/win 5
[13:00] <vila> bialix: privet Sacha !
[13:00] <bialix> cool
[13:00] <bialix> privet
[13:01] <bialix> vila: just want to say that I've read your comment to leaking merge proposal and I very impressed
[13:03] <vila> by what ? The number of dormant bugs ? :-) The 22 hours on windows ? :-P I'll get them pass on windows, I tell you ;)
[13:09] <bialix> by the problem and analysis
[13:09] <bialix> did not realized hidden problems
[13:10] <bialix> vila: and yes, 22 hours is a bit tooooooooooooooooooooooooooo much
[13:10] <vila> bialix: ha, yeah, tricky stuff :-/
[13:10] <vila> hehe, don't worry, I'll fix that :)
[13:10] <bialix> cool :-)
[13:11] <vila> but the nice thing is that it should help use more threads in the future (outside of the test servers) while still keeping a python-ish way to describe the processing, still a long way to get there though :-/
[13:17] <bialix> vila: I don't understand though your remark about slicing test suite to keep number of opened sockets below th elimit
[13:18] <vila> bialix: when using --parallel=fork, we spawn several processes, each of them with only a slice of the whole test suite
[13:18] <vila> bialix: so each process see less leaks and is able to finish
[13:19] <bialix> I think limit for opened sockets is limit for all running processes
[13:21] <vila> bialix: Well, it could be on windows but --parallel=fork doesn't work on windows anyway
[13:21] <bialix> hehe, nice
[13:21] <vila> :-/
[13:42] <Lo-lan-do> Hi all :-)
[13:43] <Lo-lan-do> jelmer: Do you know if anyone is planning to bring recent versions of bzr, bzr-svn and loggerhead to backports.org?
[13:43] <jelmer> Lo-lan-do: not that I'm aware of
[13:44] <Lo-lan-do> Thanks. I guess I'll try that myself then.
[13:44] <Kamping_Kaiser> the bzr versions reasonably recent, 'just' all the packages which depend on it are broken as a result :
[13:44] <Kamping_Kaiser> :/
[13:45] <Lo-lan-do> http://bzr.debian.org/loggerhead/pkg-python/python-defaults-debian/annotate/head:/dh_python2? seems to crash somewhere in bzrlib
[13:45] <Lo-lan-do> bzr 2.0.3, loggerhead 1.10 or so
[14:09] <jelmer> Lo-lan-do: I know at least two other people who are interested in bzr and bzrtools in backports
[14:20] <Lo-lan-do> jelmer: Let's see if anyone shouts at my email :-)
[15:25] <Kamping_Kaiser> Lo-lan-do: re your email for bzr backports, one of my last messages to bpo users was about doing bzr package backporst. iirc it contains a list of packages which need rebuilding/changing. i can probably find it if you think it'll help
[17:13] <maxb> Is there really much of a performance penalty in fetching between pack-0.92 and 1.9 formats?
[17:13] <maxb> Or is bzr being a bit over-eager at warning me about format mismatches?
[17:14] <jelmer> maxb: between pack-0.92 and 1.9 it shouldn't be very expensive
[17:14] <maxb> Do you think it's expensive to justify bzr issueing a warning on pull?
[17:34] <parthm> jam: ping
[17:34] <jam> hi parthm
[17:34] <parthm> hi jam.
[17:35] <parthm> i was hoping to complete the lock-url patch. does the 5 sec timeout for LockContention seem ok to you?
[17:36] <jam> so we've certainly gone around on it a lot :)
[17:36] <jam> IMO, the timeout should be on the order of how long it takes to take and release the lock
[17:36] <parthm> jam: yes :) .. i suppose anything is better than 300.
[17:37] <jam> so that 2 people who are doing things that *can* be done won't block eachother
[17:37] <jam> for example, updating branch.conf
[17:37] <jam> also, updating pack-names is done with a physical lock
[17:37] <jam> so we should look at how long it takes to get the lock, update pack-names, and then release the lock
[17:38] <jam> That, I think, is the key thing to watch out for
[17:38] <jam> because if 2 people push to a shared repo, but to different branches
[17:38] <jam> we want that to succeed
[17:39] <parthm> jam: that makes sense.
[17:39] <jam> now *if* that is being performed (not with SFTP requests, for example), then 5s is probably reasonable
[17:40] <parthm> jam: i could do a quick check of doing a push from two terminals into one repo at the same time (with 5s timeout). i suppose that should cover it.
[17:41] <parthm> separate branches.
[17:41] <jam> the ordering is... take the name lock, read the current content, compare it with your own content, write up new pack-names content to a temporary file, and then overwrite the existing file (either with simple POSIX rename, or 'fancy-rename'), unlock
[17:42] <jam> parthm: well, there is a bit more 'exact timing' issues than just manually testing
[17:42] <jam> unless you stress test it with a lot of pushes, etc.
[17:43] <parthm> jam: maybe i can just set the timeout to 10s and set the url patch to 'needs review'. these two are actually separate. i can open a bug on getting a better estimate for timeout.
[17:44] <parthm> i agree that a stress test is probably a good way to tune the timeout.
[17:45] <jam> let me think for a sec
[17:45] <jam> I think I can do a simple test
[17:45] <jam> and have it run against a remove bzr
[17:45] <jam> and just see how things go
[17:46] <jam> and hopefully have you/someone in AU run it
[17:46] <parthm> jam: ok.
[19:04] <MTecknology> I'm trying to run  yes yes
[19:04] <MTecknology> I'm trying to run  yes yes | bzr pull  but it's not being picked up by the ssh agent "Are you sure you want to continue connecting (yes/no)? " any ideas how to get around this?
[19:05] <Lo-lan-do> Run bzr pull by hand and say yes to ssh?
[19:06] <MTecknology> Lo-lan-do: scripting this
[19:06] <Lo-lan-do> SSH should then remember your answer
[19:06] <MTecknology> I need to answer it from a script
[19:07] <Lo-lan-do> Set the StrictHostKeyChecking option to false in your SSH config file?
[19:08] <MTecknology> :D
[19:08] <MTecknology> thanks
[19:08] <Lo-lan-do> (I didn't suggest that, and you found about it yourself, and don't complain if you mess up your security)
[19:09] <MTecknology> :P
[19:09] <MTecknology> I can easily comprehend the issues with it
[19:10] <MTecknology> wide open to man-in-the-middle
[20:36] <bendj> I've got a local branch with a parent of "/repos/pf6".  i want to switch the local banch to use, and be in-sync with, a different parent, "/repos/pf6-617".
[20:36] <bendj>   i entered my local branch, and issued a "bzr switch /repos/pf6-617", and got: bzr: ERROR: Cannot switch a branch, only a checkout.
[20:37] <bendj> hm.  so, how do I make the switch?
[20:42] <lifeless> bendj: I think you have two concepts conflated
[20:42] <lifeless> bendj: 'parent' is used for the 'pull' and 'merge' commands.
[20:42] <lifeless> bendj: switch is used to change a checkout to be a checkout of a different branch
[20:43] <lifeless> bendj: can you describe differerntly what you want to happen, maybe I can suggest a way
[20:49] <bendj> lifeless: I did -- (1) bzr init-repo --no-trees /repos (2) cd /repos (3) bzr branch --no-trees source1 (4) bzr branch --no-trees source2  (5) cd /home (6) bzr branch /repos/source1 mysite (7) cd mysite (8) hack, hack, hack ...
[20:49] <bendj>  so, in my language, /home/mysite has a 'parent' of /repos/source1
[20:49] <bendj> i want to switch it to a 'parent' of /repos/source2
[20:49] <bendj> description make sense?
[20:49] <lifeless> bendj: I think what you wanted to do in step 6 was 'bzr checkout --lightweight /repos/source1 mysite'
[20:50] <lifeless> bendj: I can help you make it like that
[20:50] <lifeless> bendj: first, cd to mysite
[20:50] <bendj> i THINK i may need to convert the /home/mysite branch to a checkout (via bind?), then i can do the switch ...
[20:50] <lifeless> and do 'bzr push :parent'
[20:51] <bendj> lifeless push --> "update a mirror of this branch".  sorry, which mirror gets updated?
[20:51] <lifeless> :parent is an alias for 'the parent of this branch'
[20:51] <lifeless> which according to your commands is /repos/source1
[20:52] <lifeless> by  (6) bzr branch /repos/source1 mysite
[20:52] <bendj> lifeless: yup.  but, isn't that going to attempt to 'make changes' to the parent, aka /repos/source1?
[20:52] <lifeless> bendj: isn't that what you wanted ?
[20:52] <bendj> nope.
[20:53] <lifeless> bendj: Do you want to discard the work you've donein mysite ?
[20:54] <bendj> lifeless context -> i'm attempting to update /home/mysite (a pressflow/drupal site, based off the 'release' trunk @ /repos/source1).
[20:54] <bendj> i want to switch /home/mysite to be bbased off newer 'test' branch source of pressflow @ /repos/source2.
[20:55] <lifeless> have you made changes in mysite itself ?
[20:55] <bendj> scads!
[20:55] <lifeless> then you have the following situation
[20:55] <lifeless> branchA (trunk), branchB(test) and branchC(mysite)
[20:56] <lifeless> these all have unique content
[20:56] <bendj> pls keep typing.  brb .... minor emer
[20:56] <lifeless> switch is a command to well, 'switch out' or totally replace a working area with some other branch - it says (for instance), 'I have mysite, but I really want test.'
[20:56] <lifeless> this isn't what you want to do.
[20:57] <lifeless> What I think you want to do is 'bring in the changes that test made so that I have both the work from test and the work from mysite'
[21:00] <lifeless> the way to do that is 'bzr merge /repos/source2; bzr commit -m "Merge in test"'
[22:18] <bendj> lifeless: thanks.  emer wasn't so minor ...  sorry bout that
[23:12] <mgz> man, I keep breaking things
[23:13] <mgz> should have a precommit hook that runs the tests against all four python implementations
[23:13] <lifeless> :)
[23:13] <lifeless> mgz: that would be nice
[23:13] <lifeless> mgz: I thought about a check-all or something
[23:14] <lifeless> but didn't get the activation energy up
[23:24] <mgz> okay, my list of things to do in the branch is at least diminishing
[23:25] <mgz> only hard thing left is decision about moving/renaming some of this 'utils' stuff
[23:25] <mgz> it's a little annoying currently as now testtools.run and testtools.testresult need utils, which pulls in a bunch of code most of which is only needed for Python 2, and some of it only for the test suite
[23:26] <mgz> I think iterate_tests should move anyway as it's part of the base public api
[23:26] <lifeless> agree
[23:32] <lifeless> mgz: so I think iterate_tests should move; we should leave a forwarder behind
[23:32] <lifeless> mgz: we should split 'end users want' and 'only selftest wants' - but for testtools anything generic end users may still want, because of its rather introspective nature
[23:32] <mgz> yup. there's no fancy deprecater as in bzrlib though, right?
[23:33] <mgz> some of this end users indirectly want, but should only be accessible via say, method on testresult
[23:33] <mgz> otherwise they'd need all this horrible version checking in their code as well
[23:34] <lifeless> that seems to be a swings and roundabout distinction
[23:34] <lifeless> unless its already on unittest.TestResult
[23:34] <lifeless> and if it is, they may want to be able to monkeypatch their own - say twisted.trial.TestResult - so a helper function may be nice anway
[23:34] <mgz> ah, I see.
[23:35] <lifeless> I don't see that they would need version checking
[23:35] <lifeless> it can be in our helper, or in our module or whatever
[23:36] <poolie> hi there jam?
[23:47] <thumper> will bzr run as bzrlib within google appengine?
[23:53] <lifeless> it should
[23:53] <lifeless> obviously without the C extensions
[23:53] <lifeless> I don't think anyone has tried.
[23:54] <mgz> would be interesting to see.
[23:54] <lifeless> GAE is a classic example of why we have a no-C-requirement policy
[23:54] <lifeless> even though I waver on that from time to time
[23:55] <lifeless> I think we could be _so_ much faster if we went pure C, with a python version as a port rather than the primary environment.
[23:57] <davidstrauss> I'm helping a person who's getting "bzr: ERROR: Unsupported protocol for url "ancestor:lp:~pressflow/pressflow/merge-drupal-6.17" when running "bzr diff --old=ancestor:lp:~pressflow/pressflow/merge-drupal-6.17"
[23:59] <thumper> lifeless: having a main function in C with a python fallback seems OK to me...
[23:59] <thumper> lifeless: is this not allowed?