[00:00] <lifeless> GaryvdM: the index layer does have a cache of its own, and the majority of the cost of traversing is disk io and parsing, yes.
[00:00] <GaryvdM> Ok
[00:00] <lifeless> GaryvdM: but with a big enough data set, the cache can be exhausted, which would lead to duplicate IO
[00:01] <poolie> good morning
[00:01] <GaryvdM> So should I send a patch?
[00:01] <lifeless> GaryvdM: if you've written the code, sure - we can examine it
[00:01] <GaryvdM> ok
[00:03] <poolie> spiv, lifeless, call in a sec
[00:05] <Spaz> ya but that's at the cost of higher latency
[00:05] <Spaz> whops
[00:05] <Spaz> *whoops
[00:05] <Spaz> wrong channel
[00:06] <mwhudson> Spaz: that would be an appropriate comment in here /quite/ a lot of the time :)
[00:07] <Spaz> haha
[00:08] <Spaz> mwhudson, it was related to OS dev
[00:08] <Spaz> not sure you would be interested :p
[00:16] <lifeless> poolie: sure, call is fine
[00:20] <poolie> calling you...
[00:54] <Macarse> hi, which is the best way to: If I delete a file, to get it back?
[00:55] <poolie> Macarse, bzr revert FILENAME
[00:58] <Macarse> poolie: thanx
[03:07] <thumper> poolie, spiv: how is the work on the smart server working with stacked branches?
[03:10] <spiv> thumper: poolie knows the most about that I think
[03:10] <thumper> spiv: ok, thanks
[03:10] <mwhudson> afaik the branch is approved
[03:10]  * mwhudson pokes around in bb
[03:10] <mwhudson> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ce01316480809050416r72b3f857h4a664a2cc4e157b0%40mail.gmail.com%3E
[04:18] <poolie> thumper, not sure if you saw that
[04:18] <poolie> my net connection seems to be flapping again...
[04:18] <poolie> thumper, bug 261315 is in review, i'll merge it for 1.7
[04:45] <thumper> poolie: great
[04:48]  * igc lunch
[05:52] <BahamutZERO> Hello fellow Bzr users. I have a strange problem, and would need some assistance.
[05:54] <BahamutZERO> I setup a shared repository with the 1.6.1-rich-root format.
[05:54] <BahamutZERO> My partner created a local branch on his machine with just bzr init, and then pushed to that repository.
[05:54] <BahamutZERO> Doing a bzr info on this remote branch (inside that shared repository) indicates the branch format is "unnamed"
[05:55] <bob2> they're using 1.6?
[05:55] <BahamutZERO> Trying to branch that remote branch on my machine then yields a ERROR: KnitPackRepository (url) is not compatible with RemoteRepository(url) error.
[05:55] <BahamutZERO> Yes, they should be.
[05:55] <BahamutZERO> They downloaded the latest Bzr for Windows binary.
[05:56] <BahamutZERO> So, after that first failure, I bzr upgrade --format 1.6.1-rich-root inside the shared repository branch
[05:56] <BahamutZERO> It seemed to succeed, and a bzr info on it now reports the format is 1.6.1-rich-root
[05:56] <BahamutZERO> however, trying to branch from that yields the same error, with the addition of the error message "different rich-root support"
[05:58] <bob2> you get that error when trying to branch using 1.6.1?
[05:58] <BahamutZERO> correct
[05:59] <spiv> Is there a shared repository locally?  Why are you using 1.6.1-rich-root?
[05:59] <BahamutZERO> The shared repository is on my machine, so it is "local" in that sense
[05:59] <BahamutZERO> I have no idea :p
[06:00] <BahamutZERO> It seems it is required for bzr-svn support, but I am quite new at Bzr. Should I just leave it at the default format?
[06:00] <spiv> THe "different rich-root support" message is saying that the local repository is in a format that's incompatible with the remote format.
[06:00] <BahamutZERO> hum
[06:01] <spiv> Ah, if you're using branches from bzr-svn, then yes you do need a format with rich-root support such as 1.6.1-rich-root.
[06:01] <BahamutZERO> if there is no local repository, will the branch command create one?
[06:01] <BahamutZERO> And if so, it would likely pick the default format
[06:01] <BahamutZERO> leading to that error
[06:01] <spiv> Right.  (Even a standalone branch has a repository, it just isn't shared with any other branches.)
[06:01] <BahamutZERO> And my current situation is a pure Bzr scenario; in that case, which format is preferable?
[06:02] <spiv> If you're not using any plugins, then the default format created by "bzr init" is fine.
[06:02] <BahamutZERO> yeah, so I would have to bzr init --format... then branch from inside there, provide the --format to the branch command
[06:02] <BahamutZERO> noted, thank you
[06:03] <spiv> Choosing a non-default format is really a "you should understand why you are doing this" situation :)
[06:03] <BahamutZERO> haha, or a RTFM :p
[06:49] <vila> goood morning bazaar !
[06:50] <lifeless> hola
[06:50] <poolie> hello vila!
[06:50] <poolie> lifeless, i finished your book, it was pretty good
[06:51] <lifeless> cool
[06:51] <vila> poolie: that's the second time you said so, now I'm curious :) What is this book about, what's the title ?
[06:52] <poolie> "Leadership and Self Deception"
[06:52] <lifeless> http://www.amazon.com/Leadership-Self-Deception-Getting-Out/dp/1576751740
[06:55] <vila> thks :)
[06:57] <poolie> i can give you a synopsis but i think robert is reluctant to disclose any spoilers
[06:58] <poolie> the narrative form perhaps makes it a bit hard to express other than in examples but i think the key message is
[06:58] <poolie> consistent with writers about mindfulness
[06:59] <vila> hehe, just read the abstract and bookmarked it for later, if you both enjoyed it, it's quite enough reviews to try it :)
[06:59] <poolie> that if you notice you're doing something unpleasant, (making yourself) feel bad, or frustrated with other people
[06:59] <poolie> it may be a clue that you're twisting yourself up to justify something that's not actually true, or a decision you don't really believe in
[07:00] <vila> 'doing something unpleasant" ? Because *you* feel that unpleasant or others feel that unpleasant ?
[07:00] <poolie> well, either, but i had in mind
[07:01] <poolie> the former
[07:02] <vila> I see
[07:03] <poolie> for instance, sometimes i keep working late on something in a bloody-minded way, without really enjoying it or necessarily being more productive
[07:04] <poolie> if you asked me at this moment i'd say it's because i really want to fix this bug or whatever it is
[07:04] <poolie> they suggest that if i thought about it more clearly, my motivation might really be to prove to myself that i work hard, or something like that
[07:08] <poolie> lifeless, would you agree with that summary?
[07:09] <vila> quality vs quantity, a life's work ;)
[07:12] <lifeless> poolie: its an interesting take on it, its not the take I have
[07:12] <lifeless> vila: I suggest grabbing it and reading it :)
[07:13]  * vila stretch his arm across earth but fails to grab :D
[07:43] <kwwii> so what does one do when bzr says that it is unable to obtain lock (for 65 hours, 53 minutes) and the bzr break-lock command doesn't work?
[07:43] <spiv> kwwii: break-lock should work
[07:44] <spiv> Does it give an error, or just silently fail to break the lock?
[07:44] <kwwii> spiv: it says bzr ERROR: Unsupported protocol for url ...
[07:44] <spiv> kwwii: ah, let me guess, this is on Launchpad?
[07:45] <kwwii> spiv: yes :-)
[07:45] <spiv> kwwii: Don't use the "lp-1234://..." URL with bzr break-lock, just use the regular URL you use to access the branch.
[07:46] <spiv> e.g. "lp:foo" or "bzr+ssh://bazaar.launchpad.net/...".
[07:46] <mwhudson> spiv: going to need a bzr dev's help to fix that bug :)
[07:46] <spiv> The error message that suggests break-lock is a bit misleading, it's a known bug.
[07:46] <spiv> mwhudson may even have the bug number handy ;)
[07:47] <spiv> (The error message that suggests *the wrong URL* for break-lock, that is.  Suggesting break-lock is entirely appropriate.)
[07:47] <mwhudson> https://bugs.edge.launchpad.net/bzr/+bug/250451
[07:48] <kwwii> spiv: wonderful! that worked, thanks :-)
[07:48] <kwwii> you made my morning
[07:48] <spiv> Who needs search APIs when you have lp devs to find bugs for you? :)
[07:48] <spiv> kwwii: glad I could help.
[07:48] <mwhudson> spiv: i'm sure you know this, but the programmatic api for locks in bzr is *terrible*
[07:49] <spiv> Yeah.
[07:49] <spiv> "Patches welcomed."
[07:50] <mwhudson> unfortunately it smells like an area which risks "patches argued about for weeks"
[07:51] <spiv> That's why I didn't say "Patches accepted" ;)
[07:51] <lifeless> meh
[07:51] <lifeless> I don't think it would be argued over
[07:51] <spiv> Actually, I don't think it's so terrible.
[07:51] <AfC> Oh boy, I'm totally going to use that in my next big public keynote rant :)
[07:51] <mwhudson> (also, no time, as usual)
[07:51] <spiv> (But I wouldn't want reality to get in the way of a joke)
[07:52] <AfC> spiv: (no fear :))
[07:59] <lifeless> night everyone
[08:02] <poolie> mwhudson, what kind of thing are you talking about with the lock api?
[08:11] <mwhudson> poolie: breaking a lock requires installing a ui factory and using a specific lock id requires setting an environment variable are the ones i remember
[08:12] <lifeless> mwhudson: environment variable?!
[08:12] <mwhudson> lifeless: BZR_EMAIL iirc
[08:12] <lifeless> lock ids should be random always
[08:14] <mwhudson> well not lock id perhaps
[08:14] <mwhudson> the <whoever> in "this branch was locked at 8:54pm by <whoever>"
[08:16] <lifeless> oh sure
[08:16] <poolie> biab
[08:25] <markh> heh - 'bzr co -v' doesn't appear very verbose - it is still silent if the checkout succeeds.
[08:28] <jml> if a working tree falls in the woods etc etc
[08:33] <lifeless> jml: its a bear ?
[08:41]  * jml could do with a beer
[08:41] <jml> not sure what I'd do with a mute, narcoleptic forest bear though.
[08:42] <jml> lifeless: want to talk about testresources?
[08:42] <poolie> jml, want a quick call?
[08:43] <jml> poolie: sure, why not.
[08:44] <lifeless> jml: if we're quick, raid is at 6
[08:44] <poolie> i prefer raid 1...
[08:45] <lifeless> sunwell time :)
[08:45] <lifeless> >>>>> raid 1
[08:47] <jml> lifeless: poolie got me first. some other time.
[08:47] <lifeless> hokay
[09:35] <d3ko> Hi to all!
[09:36] <d3ko> I don't know if this is the right place, but I have a very strange error using bazaar and I didn't found anything on google or forum....
[09:37] <d3ko> This is the error:
[09:37] <d3ko> darkstar:/opt/ezechiele# bzr check
[09:37] <d3ko> Checking working tree at 'file:///opt/ezechiele/'.
[09:37] <d3ko> bzr: ERROR: not well-formed (invalid token): line 10892, column 74
[09:38] <d3ko> Any suggestion?
[09:38] <poolie> d3ko: please file a bug on launchpad.net including the traceback from ~/.bzr.log, and post the number here?
[09:40] <d3ko> ok, I do it asap and I post the number. Thank you very much.
[09:51] <jonnydee> hi, I tried to use "bzr shell" on windows but invoking this command returns with "ERROR: No module named readline". I did some research and it turns out that the python installation for windows does not ship with such a library (http://pypi.python.org/pypi/readline/2.5.1): "[...]f you are using Windows, which also ships without GNU readline, you might want to consider using the pyreadline module instead, which is a readline replace
[09:51] <Odd_Bloke> jonnydee: You got cut off at 'readline replace'.
[09:51] <Odd_Bloke> But that sounds like something worth filing a bug for.
[09:51] <Odd_Bloke> Assuming, of course, that one isn't already there.
[09:52] <jonnydee> Odd_Bloke: what do you mean with "cut off at 'readline replace'"? Is it the python line in Bazaar which produces this error?
[09:53] <mwhudson> jonnydee: each line in irc can only be so long
[09:53] <mwhudson> jonnydee: so your long line got truncated
[09:54] <jonnydee> ok, I see. So here is my complete text again:
[09:54] <jonnydee> hi, I tried to use "bzr shell" on windows but invoking this command returns with "ERROR: No module named readline"
[09:54] <jonnydee> I did some research and it turns out that the python installation for windows does not ship with such a library (http://pypi.python.org/pypi/readline/2.5.1)
[09:54] <jonnydee> "[...]f you are using Windows, which also ships without GNU readline, you might want to consider using the pyreadline module
[09:54] <jonnydee> instead, which is a readline replacement written in pure Python that interacts with the Windows clipboard."
[09:55] <jonnydee> that's it :)
[09:55] <Odd_Bloke> Right.
[09:55] <Odd_Bloke> File a bug. :)
[09:55] <jonnydee> ok, so I will look for a corresponding bug and file one if no one does exist
[09:56] <jonnydee> thanks for your help :)
[10:01] <d3ko> poolie: ok, I posted the bug. Bug number is 267670, link: https://bugs.launchpad.net/bzr/+bug/267670
[10:08] <jonnydee> Odd_Bloke: I've posted the bug now: https://bugs.launchpad.net/bzr/+bug/267674
[10:08] <Odd_Bloke> markh: ^
[10:11] <awilkins> Anyone know of a way of making urllib NOT use a proxy on windows?
[10:12] <awilkins> jonnydee: You need to install pyreadline then it works.
[10:12] <jonnydee> so pyreadline is compatible with gnu readline?
[10:13] <awilkins> jonnydee: I can't recall, I did this a while ago
[10:13] <jonnydee> ok, I will try it... thanks a lot for your help
[10:14] <awilkins> http://ipython.scipy.org/moin/PyReadline/Intro
[10:14] <awilkins> But possibly not windows...
[10:14] <awilkins> Oh, wait, PyReadline is for Windows...
[10:14] <jonnydee> hey, wow!! it works!!! :) :) :)
[10:15] <jonnydee> So what should I do with the bug report?
[10:15] <awilkins> Maybe put a comment on it suggesting that Windows users should install PyReadline?
[10:16] <awilkins> (the error message could say this too)
[10:16] <jakob> d3ko: what is in the directory in the non-working example??
[10:16] <jonnydee> Maybe change it such that Bazaar should somehow tell windows users to download and install this library in order to mak the 'shell' command work
[10:16] <jonnydee> ok
[10:16] <jakob> d3ko: since the bzr add command gives no feedback, it seems that you're committing an empty branch, which shouldn't work to begin with
[10:17] <jakob> d3ko: at least, I get  bzr: ERROR: no changes to commit. use --unchanged to commit anyhow
[10:17] <d3ko> jakob: no, the add command works well and gives me complete output
[10:17] <jakob> so what is the output??
[10:17] <d3ko> jakob: in the log there is the complete output, I put the [...] because the project is quite big
[10:18] <jakob> :P aah, went too fast :P
[10:18] <d3ko> :)
[10:21] <jakob> d3ko: could it have something to do with keymapper/priva.####OD#
[10:22] <jakob> where the #'s are some strange characters that my browser can't print??
[10:23] <d3ko> jakob: yes, maybe
[10:23] <d3ko> i try to delete that file, is not fundamental
[10:24] <spiv> d3ko, jakob: yes, I'd say that filename is likely to be the problem
[10:25] <d3ko> jakob, spiv: YES! check now is working!
[10:25] <d3ko> I try some change and then revert
[10:25] <spiv> I don't think 0x08 in ASCII can be represented in XML files, and bzr uses XML for recording the inventory.
[10:26] <awilkins> XML? Urrrgh.
[10:26] <spiv> bzr ought to give a better error in this case, and give it sooner.
[10:26] <awilkins> And use less XML!!!!
[10:26] <jszakmeister> awilkins: +1!
[10:26] <spiv> awilkins: yeah, there's a new inventory format that gets worked on from time to time.
[10:27] <d3ko> spiv, jakob: yes, all seems working!
[10:27] <spiv> If you ask on the list poolie or someone can probably post an update on where it's at.
[10:28] <awilkins> I know that SVN went from XML wc metadata to K/V pairs and gained lots of performance
[10:28] <d3ko> That was a spurious file, I think too that bzr ought give an error earlier
[10:30] <d3ko> Thank you all!! So fast :)
[10:30] <spiv> I think SVN used XML alot more heavily than bzr is using it.
[10:31] <d3ko> Maybe file names should encoded in some way, like Base64?
[10:31] <jszakmeister> spiv: yeah, it was littered all through-out the working copy.  It's still used between mod_dav and the client too.
[10:31] <spiv> IIRC it's certainly visible in the profiles of certain operations, but perhaps surprisingly not as dominant as one's "yuck XML yuck" intuition might lead you to expect :)
[10:32] <spiv> I haven't looked at that data recently, though.  I know it's something we plan to replace, it just hasn't got to the top of the list of things to do.
[10:33] <jszakmeister> Oh, I believe you.  I just have a personal disgust for XML... seems to be everyone's hammer in the corporate environment. :-)
[10:34] <poolie> night all
[10:34] <spiv> jszakmeister: yeah.  Our working copy state is in mostly in a single binary file, rather than scattered in lots of little files all through the tree.
[10:34] <d3ko> spiv, jszakmeister, jakob: what I have to do with bug report?
[10:34] <d3ko> I can give the solution
[10:34] <d3ko> Have i to do something else?
[10:35] <spiv> d3ko: please do explain your workaround, i.e. that it was just that one file name that was the problem.
[10:35] <d3ko> night, poolie! Here is 11:35 AM :)
[10:35] <spiv> d3ko: that's all you need to do
[10:35] <spiv> poolie: g'night
[10:36] <jszakmeister> spiv: Which is a great idea. :-)  I've wanted to switch since SVK showed how keep it more central could be a boon.  But the WC code is more than I can take on right now.
[10:41] <awilkins> Maybe we should do a protocl buffers version...
[10:42] <awilkins> I've been meaning to experiment with proto for one of my own concerns - it's presently large, enterprisey, messages in XML
[10:42] <awilkins> But I'm not sure the underlying technology deserves to have it's life prolonged by being given a good serialization
[10:43] <awilkins> As far as I'm concerned, the more it sucks, the sooner we can move onto something better.
[10:43] <awilkins> 
[10:45] <d3ko> spiv: ok, I've added a comment with the explanation, I cannot change the status of the bug, maybe you can
[10:47] <d3ko> I don't know if you are also developers, but... i love bazaar :) - great software!
[10:48] <spiv> Lots of us here are (including me).
[10:48] <spiv> So, thanks! :)
[10:50] <spiv> d3ko: I've updated the bug status.  Thanks for the report.
[10:52] <d3ko> Thanks to you all :) - for support and software. Hope this helps other people.
[10:53] <speakman> hi! any bzr-trac devs inhere?
[10:53] <d3ko> Now I have to go (I have to fix some bugs in my own software!). Bye!
[10:57] <speakman> i've run into a strange bug and I don't know how to make a proper bug report with it.
[10:58] <speakman> short: I can't see changesets in branches, but in trunk it's ok.
[11:13] <jakob> does anyone have some experience with setting up authentication.conf files?
[11:14] <jakob> i'm trying for http, but bzr doesn't seem to do anything with it
[11:16] <spiv> vila: ^
[11:16]  * spiv -> food
[11:48] <Pilky> does anyone know what the state of the bzr-git plugin is?
[12:01] <vila> jakob: what are you trying to do and what doesn't work ?
[12:07] <Odd_Bloke> Pilky: Very much alpha still, IIUC.
[12:07] <Odd_Bloke> jelmer would know more.
[12:07] <Pilky> ok, thanks
[12:15] <jakob> vila: from the manual I suspected that if I do eg bzr co http://jakob@host/bzr_repos I wouldn't have to type a password, if I have an authentication.conf file with user=jakob,password=pass
[12:15] <vila> jakob: that's the idea yes
[12:16] <jakob> well..... it doesn't work; maybe I need to set somewhere where my authentication.conf resides?
[12:16] <vila> *what* doesn't work ? :) and authentication.conf is in ~/.bazaar directory
[12:17] <jakob> aha, the command works, but I still have to type the password
[12:17] <jakob> (actually.... twice)
[12:17] <vila> that means bzr couldn't find the right section in your file, how does it look ?
[12:18] <vila> !paste
[12:18] <jakob> [bzr-repos]
[12:18] <jakob> user=jakob
[12:18] <jakob> password=
[12:19] <jakob> where I left out the actual pass.... that's all; I removed all the other options, to make things default
[12:20] <jakob> actually.... I found the answer already
[12:20] <vila> And it is ?
[12:21] <vila> I was about to advice using -Dauth so that the section used is shown, that helps debug the authentication.conf file
[12:22] <jakob> well... I'm not sure yet what the precize answer is...
[12:23] <jakob> I went on to try to let the name of the section in the auth file exactly match the name of the domain as set in the .htaccess file
[12:23] <jakob> then i suddenly started working
[12:23] <jakob> but now I changed things back and it still works :P
[12:23] <vila> the name in the file is just a comment really
[12:24] <vila> may be you didn't save your file ? (I hate me when I do that :)
[12:24] <vila> Does using -Dauth shows you the relevant section name ?
[12:24] <vila> try bzr info or bzr revno
[12:25] <vila> with the right location added of course
[12:25] <jakob> -Dauth doesn't give any extra info....
[12:26] <vila> sorry, it's in the .bzr.log file
[12:26] <vila> not on the screen
[12:27] <jakob> both info and revno work like a charm
[12:27] <jakob> (I tried them on the remote location; assuming that was what you meant)
[12:27] <vila> every command should work the same, if revno works and not another, that's a bug
[12:28] <vila> s/work the same/& regarding authentication :)/
[12:28] <jakob> well, indeed the [bzr-repos] section is used
[12:29] <jakob> weird... but what the hey.... things work as expected, so I'm happy now
[12:29] <jakob> even though it remains a bit of a mystery what was going on previously
[12:29] <vila> good, so your file is correct, be aware though, that your section is really a catch-all and will apply to all schemes
[12:30] <jakob> I know.... now that things work again, I'll put in details :)
[12:30] <vila> ok, let us know how it turns out :)
[12:33] <jakob> ooh... one thing... can I use wildcards in the authentication.conf file
[12:33] <jakob> like eg: host=www.*astro.rug.nl to allow catching www.astro.rug.nl as well as www.intra.astro.rug.nl?
[12:35] <jakob> hmm... apparently not :(
[12:36] <vila> jakob: hmm, no, but you can use .astro.rug.nl (note the leadind dot) to match the domain
[12:36] <jakob> vila: aah.. thanks! works like a charm :)
[12:37] <vila> happy to help ((c) jam)
[12:50] <gnomefreak> how long should i wait for deletion of a branch? seems like everytime i push it goes to rev. 2 after deleting branch and im trying to make this rev 1
[12:50] <gnomefreak> i trie --overwrite but still made it rev 2
[13:03] <awilkins> gnomefreak: When you push, it pushes your local revisions ; if your local branch is at r2, a new branch you push will be at r2
[13:03] <gnomefreak> ah thats right
[13:03] <gnomefreak> thanks
[13:03] <awilkins> gnomefreak: If you want it to be r1, make an empty branch and merge your r2 branch into ti
[13:04] <gnomefreak> no r2 now that i think since i want upstream r1 and r2 for this comit
[13:04] <awilkins> Or since it's pretty young, why not trash the .bzr folder and re-init/add/commit
[13:04] <gnomefreak> commi
[13:06] <jakob> vila: I see you're one of the main developers of the web-dav plugin?
[13:06] <vila> yes
[13:07] <jakob> vila: any idea what the following means:
[13:07] <jakob> bzr: ERROR: http://www.intra.astro.rug.nl/%7Ejakobb/bzr_repos/repos1/.bzr/branch is permanently redirected to http://www.intra.astro.rug.nl/~jakobb/bzr_repos/repos1/.bzr/branch
[13:07] <vila> apache2 humor
[13:07] <jakob> that's what I was afraid of :/
[13:07] <vila> you asked for 'blah blah', that's a directory, please use 'blah blah/'
[13:08] <jakob> let me first ask if I use the plugin right: this is what I'm trying:
[13:09] <jakob> bzr push http+webdav://jakob@www.intra.astro.rug.nl/~jakobb/bzr_repos/repos1/
[13:09] <vila> if you control the apache2 server you can use 'DirectorySlash Off' to tell him, you're working not joking :)
[13:09] <jakob> nope, I'm just a user.... that's the whole reason for going bzr
[13:10] <jakob> I want my repos accessible over http, such that I can let others access them as well, but still have some control over who accesses them through .htaccess
[13:10] <vila> it shouldn't error then, can you file a bug with the traceback and the relevant part of the log while running bzr push -Dhttp <etc>
[13:10] <jakob> that's very much impossible with svn
[13:10] <vila> file it against bzr-webdav, not bzr
[13:11] <jakob> what error message should I get if the webserver is not webdav-enabled?
[13:11] <jakob> another one?
[13:11] <vila> errr, I don't remember exactly, certainly something like 501
[13:11] <markh> awilkins: you still here?
[13:12] <vila> but I don't understand why a redirected leads to an error, that's why I ask for the traceback and the log
[13:12] <vila> s/redirected/redirection/
[13:12] <jakob> I'll file a bug asap
[13:13] <jakob> well.... as far as I can tell it's not even a redirection by the way :P
[13:13] <vila> jakob: one thing you can try is to define a <Directory> section in your .htaccess (if your server allows it)
[13:13] <jakob> it's just the ~ that is replaced with %7E
[13:13] <vila> take a look at the NOTES file in the webdav plugin
[13:15] <vila> hmm, where is that %7e coming from ? Did you type it or does it come from a remembered location ?
[13:18] <jakob> no, it's something that bzr does all over the place
[13:19] <fullermd> Seems to me that bzr URL-escapes ~ at the drop of a hat.
[13:19] <awilkins> markh: Yes
[13:20] <jakob> vila: what do the Alias /bzr /src/DAV precisely do? Do they need to be changed for my particular installation or is it some standard stuff?
[13:21] <vila> fullermd, jakob : pedantically speaking '~' in an url should be escaped, that's what bzr does silently (mostly silently) . I'm still wondering why the http server can return an invalid url...
[13:21] <vila> jakob: forget the alias, it's just a short cut, you don't need it in your case
[13:28] <jakob> vila: before I actually didn't check the NOTES..... very bad, always RTFM :P
[13:29] <vila> Well, the fine manual is not that good for that plugin :-) Patches welcome :)
[13:29] <jakob> vila: but apparently the 'DAV on' is needed? that actually gives me back a 500
[13:30] <jakob> I'll have to check with system management first I guess :/
[13:30] <vila> DAV on is what *activates* dav, if the server doesn't support it... yes, you need to check with system management
[13:31] <vila> but if you do, tell them to use DirectorySlash Off at the minimum, DavDepthInfinity on is also needed to support packs
[13:33] <vila> jakob: rug == royal university groningen ?
[13:34] <vila> ha, no, rijksuniversiteit groningen :) Should translate as above though...
[13:36] <jakob> vila: well, actually we don't have much to do with the university
[13:37] <jakob> the astro-domain is for astronomy and we have our seperate system
[13:37] <jakob> linux instead of win***&@#$!#@
[13:38] <vila> jakob: well, the question was more: *can* you get in touch easily the sys-admins to allow such modifications
[13:38] <vila> jakob: you connection is noisy, strange chars at the end of your previous message
[13:38] <jakob> and our own web-server....... which should support dav I was promised some time ago
[13:38] <vila> apache2 ?
[13:38] <jakob> vila: aaaah, yes sure, the're right accross the hall :)
[13:38] <vila> :D
[13:40] <jakob> but I'm figuring out some details about at least 2 other bugs right now.... sambaserver stuff :P
[13:40] <vila> Check with them then, and if they are affraid about the DavDepthInfinity, try to find a place where you can store all bzr related stuff, bzr itself uses a depth of max 3 or 4
[13:40] <jakob> vila: isn't there some nice PHP-function that checks for webdav??
[13:41] <jakob> the guy that actually admins the webserver is not at the institute today :(
[13:41]  * vila knows nothing about PHP (not even the meaning of the TLA :)
[13:41] <jakob> oke... I'll find out....
[13:41] <jakob> and let you know of course ;)
[13:42] <vila> but looking at the headers returned by the server should tell you (for which you just have to look at .bzr.log after issuing a bzr command with -Dhttp :)
[13:42] <vila> except if the server is hiding itself...
[13:44] <jakob> in the last 2 years the system has been breached 3 times... so it just might do that
[13:52] <jakob> vila: DAV/2 it says
[13:53] <vila> full header is ?
[13:53] <jakob> Server: Apache/2.0.52 (Red Hat) mod_ssl/2.0.52 OpenSSL/0.9.7a PHP/4.3.9 mod_python/3.1.3 Python/2.3.4 DAV/2 SVN/1.1.4
[13:55] <vila> I don't understand the '500' then :-(
[13:55] <fullermd> Probably means it doesn't allow fiddling with that setting in .htaccess.
[13:56] <jakob> I just found a website that also has some tests on it... I'll work through them first: http://www.howtoforge.com/setting-up-webdav-with-apache2-on-debian-etch
[13:56] <vila> fullermd: was wondering about that, but you know apache better than me :D
[13:57] <fullermd> Oh, I dunno about that.  But I know how I've provoked 500's before   ;)
[13:58] <vila> http://httpd.apache.org/docs/2.0/mod/mod_dav.html says 'Context:	directory' for the 'Dav on' directive. Does that forbids .htaccess ?
[13:58] <fullermd> Not necessarily, but it's probably under Options (seems to be the catchall), and that isn't AllowOverride'd for him there.
[13:59] <fullermd> (would be my guess, at any rate)
[13:59] <fullermd> (which is to say; it's not an Apache limitation, so much as a that-Apache-config limit)
[14:00] <vila> http://httpd.apache.org/docs/2.0/mod/core.html#directory says 'Context:	server config, virtual host'
[14:00] <vila> I read that at forbidden in .htacess (which doesn't contradict your point)
[14:02] <vila> On the other hand the Dav Directive example is inside a <Location> 8-/
[14:04] <jakob> vila,fullermd: this cadaver-program says: 405 Method Not Allowed
[14:04] <jakob> (that's without the DAV on, just to see that it's maybe automatically enabled)
[14:05] <jakob> with the DAV on, I immediately get an 500
[14:05] <vila> For what request ? (-Dhttp... )
[14:08] <jakob> ooh, that's in another program, called cadaver
[14:08] <jakob> that's apparently some sort of webdav-
[14:08] <jakob> interface
[14:08] <jakob> sort of ftp for http-connections
[14:09] <uniscript> Is there a way to get bzr-svn to only pull the head revision but keep things in true local .bzr (with no need to reaccess the svn repo) and then to push changes back up?
[14:11] <uniscript> i.e. without pulling the whole history
[14:12] <vila> jakob: ok, but what are you trying to do ? 500 is 'internal server error' I doubt you can debug that without looking at server logs
[14:22] <jakob> vila: that's the problem; server logs are not accessible :(
[14:22] <vila> jakob: :-/ Even by asking kindly ? :)
[14:26] <jakob> vila: well, maybe if he is back at the institute... I usually can get a lot done with the admins, because I find many bugs for them, and often I also manage to find a solution, saving them time ;)
[14:27] <vila> jakob: ok, keep us informed anyway :)
[14:28] <vila> and thanks for trying that hard :) Hopefully it will helps others once we understand the limitations.
[14:31] <jakob> vila: I'll keep y'all posted .......
[14:48] <pickscrape> If I bzr uncommit, should I be able to find the revision uncommitted in the shared repository?
[14:48] <bob2> yes
[14:48] <pickscrape> What is the best way to find it? bzr heads doesn't seem to be showing it.
[14:49] <pickscrape> Ooh, heads --all might help...
[15:12] <joh> Hi, I'm trying to push my repository to another machine with ssh:  bzr push --remember bzr+ssh://... but I get the following error: bzr: ERROR: Generic bzr smart protocol error: bad protocol marker "error\x01Generic bzr smart protocol error: bad request 'bzr request 2'\n"
[15:12] <joh> What's wrong? Version mismatch?
[15:13] <joh> Got bzr 0.15 on the target and 1.3.1 on the client :P
[15:13] <uws> Why doesn't bzr+ssh://somehost/~/someproject work?
[15:13] <uws> the ~ is not expanded, and I need to provide a complete path to the branch :s
[15:23] <markh> awilkins: in case you happen to *still* be up - I'd love your review on my patch to solve the transport clone issues I send to the list on (my) Saturday.  But for now I must sleep...
[15:41] <Odd_Bloke> uws: It's a known problem, certainly.  Perhaps '~<username>/...'?
[15:43] <uws> Odd_Bloke: that's just as bad ;)
[16:52] <PeakerWork> Hey, is it possible to pull all revisions of all branches in some remote repository?
[16:54] <Jc2k> PeakerWork: there is a multi-pull command in bzrtools, i dont know if that works for your needs or not
[16:54] <PeakerWork> Jc2k: I am just wondering, in the context of comparing "git fetch" with bzr's pull
[16:54] <Jc2k> yes, im watching that convo :)
[16:56] <Jc2k> PeakerWork: i think multi-pull will only pull branches you are interested in
[16:57] <Jc2k> PeakerWork: so i could get branches from all overthe place (not just the mainline repository)
[16:57] <Jc2k> PeakerWork: and bzr multi-pull will keep them all up to date
[16:57] <PeakerWork> Jc2k: but it won't see new branches/etc
[16:58] <Jc2k> PeakerWork: i think so, but i dont normally care about other peoples branches myself
[16:59] <Jc2k> of course, when i set up bzr-mirror.gnome.org i did look at what would be needed to let people clone a full repository
[16:59] <Jc2k> its not much effort, from what i recall
[17:02] <PeakerWork> I much prefer the bzr approach, but I've only used git for a day..
[17:03] <PeakerWork> when starting with bzr, it was after trying arch, monotone, and a couple of others. I loved bzr because it was the first time I tried things, and they worked exactly as I'd expected
[17:03] <PeakerWork> now with git, I'm puzzled by the CLI again
[17:03] <Jc2k> i set up bzr-mirror.gnome.org, git-mirror.gnome.org and hg-mirror.gnome.org
[17:03] <Jc2k> thats a lot of repositories
[17:03] <Jc2k> git caused me the most pain
[17:03] <Jc2k> and it still isnt set up right
[17:03] <PeakerWork> maybe Pythoneers minds are wired differently :)
[17:04] <Jc2k> e.g. http://blogs.gnome.org/johncarr/2008/08/22/git-mirrror-making-it-suck-less/
[17:14] <Jc2k> PeakerWork: that entire conversation is annoying. does the entire conversation condense to "we think git is the best because everything is in one folder" ?
[17:18] <PeakerWork> Jc2k: well, there is the pre-fetching of remote branches that might be useful to you later, which is useful..
[17:18] <Jc2k> PeakerWork: well, tags would be pre-fetched obviously
[17:19] <Jc2k> PeakerWork: generally the number of branches to number i care about means that im pulling a lot of noise
[17:20] <PeakerWork> noise is cheap :)
[17:20] <PeakerWork> you can merge the interesting stuff very quickly which is nice
[17:21] <Jc2k> i suppose
[17:21] <Jc2k> im not very familiar with the bzr code, but it looks fairly easy to code this up
[17:21] <Jc2k> i think the reason it hasnt is that the bzr guys have thought about it and just dont agree with the git model
[17:22] <PeakerWork> the switch working tree model is also nice for very large working trees
[17:22] <PeakerWork> performance-wise
[17:25] <robsta> hi
[17:25] <robsta> is there a prepare-ChangeLog.pl with bzr support out there?
[17:32] <LarstiQ> PeakerWork: swithcing working trees is a different problem from "clone a repository"
[17:32] <PeakerWork> LarstiQ: yeah, it is also useful, though
[17:32] <LarstiQ> PeakerWork: it is, and bzr does it as well.
[17:34] <PeakerWork> LarstiQ: that's great, I love bzr.  Its still said that git scales better, so I have to put up with it for this large project, instead of bzr :(
[17:40] <LarstiQ> PeakerWork: is that your decision, or collaboration with others?
[17:40] <LarstiQ> PeakerWork: just curious
[17:41] <PeakerWork> LarstiQ: well, a bunch of coworkers here (including me) want to move from perforce into something reasonable (read, dvcs)
[17:41] <LarstiQ> PeakerWork: and the next question is then of course, did you try bzr and find it too slow, or was the decision to use git made based on expecting scaling problems?
[17:41] <LarstiQ> PeakerWork: aha :)
[17:41] <PeakerWork> I can try to convince them of a different decision, but the project is pretty large, and they're very afraid of having it be too slow with bzr, and being committed to a tool that might be too slow
[17:41] <PeakerWork> well, what if it grows too slow as the history grows, rapidly?
[17:42] <PeakerWork> we can't "try" to know that?
[17:42]  * LarstiQ nods
[17:43] <LarstiQ> PeakerWork: very understandable
[17:43] <LarstiQ> PeakerWork: is it already sizeable? Or do you foresee it growing very fast?
[17:44] <PeakerWork> its pretty large already, file-wise. History-wise, its in perforce and would be hard to extract
[17:44] <PeakerWork> p4 keeps history on a per-file basis
[17:44] <LarstiQ> PeakerWork: there used to be a p4 plugin for bzr, no clue if that is maintained
[18:03] <LarstiQ> PeakerWork: if you have some spare time, I'd be interested to know if that still works (and gives satisfactory results)
[18:03] <PeakerWork> I'll try to remember to try that, I'll be off work here for a couple of weeks though
[19:59] <evge> I have create a authentication.conf in ~/.bazaar for sftp host, but bzr keep asking me for password, any ideas ?
[20:00] <Verterok> evge: I think ssh/sftp allways prompts for user input
[20:01] <Verterok> evge: if you have pub/priv keys, you can use a ssh-agent
[20:03] <evge> yeah, this would be a solution for the future, the initial problem was that olive-gtk poped up an error when I tried to update that branch :/
[20:43] <Snaury__> jelmer: do you plan on improving subversion error reporting in bzr-svn? I just received SubversionException: (None, 170001) and I spent quite some time to figure it was just Authorization error. ;)
[20:44] <jelmer> Snaury__, it should already convert a 170001 error into a regular "Permission Denied" error
[20:44] <jelmer> Snaury__, if you get a traceback for 170001, please file a bug about it (and include the traceback)
[20:45] <Snaury__> Hmm. Then it could be a bug: http://pastebin.ubuntu.com/44642/
[20:45] <Snaury__> I was trying to svn-push into a repository where I forgot to edit svnserve.conf and add write rights.
[20:46] <jelmer> Snaury__: Looks like we simply need to catch SubversionExceptions there and raise convert_error(ex)
[20:49] <Snaury__> So, do you want me to file a bug report or will you just fix it without one?
[20:49] <Snaury__> jelmer ^^
[20:49] <jelmer> Snaury__, please file a bug report
[20:50] <jelmer> Snaury__, I don't have time to look into it atm, and I would otherwise probably forget about it
[20:50] <Snaury__> jelmer: ok, doing it now
[20:59] <Snaury__> bug #267899
[20:59] <jelmer> Snaury__, thanks!
[21:10] <jelmer> Snaury[away], should be fixed in 0.4.13 with a bit of luck
[22:07] <a7p> hi everyone - I'm just wondering why I cannot a bug concerning the bzr-eclipse-plugin (when entering a comment, eclipse crushes regulary) - does anyone know this one?
[22:07] <beuno> a7p, sorry, you cannot what?
[22:08] <Verterok> a7p: just going to ask that ^
[22:08] <Verterok> hi beuno
[22:08] <beuno> hiya Verterok  :)   how's your first day of vacation?
[22:08] <a7p> ;) I cannot enter a Commit Comment
[22:09] <nDuff> a7p, "cannot a bug" -- you mean cannot file a bug? cannot find any references to a previously-filed report on that bug?
[22:09] <a7p> arg,
[22:09] <a7p> sry
[22:09] <a7p> cannot find a bug
[22:09] <nDuff> *someone* is always first
[22:10] <Verterok> beuno: it's ok...trying to get up to date with bzr-related things :)
[22:10] <nDuff> might be you this time.
[22:10] <beuno> Verterok, that may take you a while  ;)
[22:10] <a7p> I had this behavior a few month ago, when I tried bazaar-eclipse and is still there, absolutly reproducible - It is impossible to use bzr with eclipse... I cannot believe no one else stubled upon this one.
[22:11] <Verterok> a7p: please file a bug. also if you have a stacktrace, that would be great
[22:11] <Verterok> a7p: I'll take a look ATM
[22:11] <Verterok> beuno: indeed, tons of mails to read
[22:11] <a7p> but if there is no obvious known reason (which I just did not see), I'll gladly file a bug.
[22:12] <a7p> Verterok: thx.
[22:12] <Verterok> a7p: I use bzr-eclipse to work on bzr-eclipse and never get into that bug :p
[22:13] <a7p> Verterok: okay, now I feel lonley *g*
[22:13] <Verterok> a7p: but if you can reproduce it, attach <workspace>/.metadata/.log and I'll try to reproduce it
[22:14] <a7p> I am running 1.7dev with eclipse-gandymede on osx - may be a rare setup.
[22:14] <Verterok> a7p: not at all. I'm with the exact setup :)
[22:14] <Verterok> a7p: OS X 10.4, bzr.dev and eclipse 3.4
[22:15] <a7p> same, but osx 10.5.4
[22:16] <a7p> Verterok: dcc, mail or should I attach it to a bug?
[22:17] <Verterok> a7p: please attach it to the bug
[22:17] <a7p> okay, l'll send you the LP-id in a minute
[22:19] <Verterok> a7p: great!, thanks
[22:25] <a7p> LP: 267924
[22:25] <beuno> bug #267924
[22:25] <beuno> you have to know how to tickle ubottu the right way
[22:25] <beuno> :)
[22:25] <a7p> @ Verterok - hope it helps ... if you have any further questions about my setup, feel free to contact me.
[22:26] <a7p> beuno: been lazy the last months... all work no play ... *g*
[22:27] <pickscrape> beuno: just out of interest, has the breadcrumbs stuff been looked at? I'm fully prepared to be told that it's naff and needs work. :)
[22:27] <Verterok> a7p: ok, I'll take a look as soon I finish a new the merge dialog. thanks
[22:27] <beuno> a7p, you can solve that by getting a job on what you play with
[22:28] <beuno> pickscrape, ah, I suck. I'll get to it this week, I super-promise.
[22:28] <beuno> I've been slacking off on Loggerhead stuff
[22:28] <pickscrape> no problem :)
[22:28] <pickscrape> I do foresee there being problems with it. The template stuff is new to me, especially the macro side of things.
[22:29] <beuno> I'm sure we'll work it out pretty quickly, it was shaping up pretty well last time I peaked at it
[22:29] <beuno> tomorrow seems like a good day for me to do some LH work
[22:46] <pickscrape> Anyone have any idea how I might track down a segfault when running bzr qlog?
[22:46] <a7p> beuno: if you are hireing for anything interessting, feel free to tell me *g* - currently I am doing "flash-shit", but the next paid project is going to be zope3-based ... and I am really happily looking forward to that.
[22:48] <lifeless> actionscript and python have a lot in common
[22:58] <a7p> lifeless: but not enough ..
[22:58] <a7p> I also hate the flash-player and the adobe authoring enviroment
[22:58] <a7p> environment
[23:59] <spiv> Good morning.