[00:17] mwhudson: I think we have to introduce a new format to fix that serializer problem. [00:18] if people have used it, for sure [00:19] abentley: can we just rename 1.6-rich-root 1.6-subtrees, and add 1.6-rich-root? [00:20] lifeless: I don't think it makes sense to call it 1.6 if it wasn't introduced in 1.6 [00:20] abentley: true [00:20] abentley: I was thinking 1.6.1 [00:21] lifeless: Yeah, that would be tolerable, I think. [00:21] I'll have to go back and see whether it ever claimed not to support subtrees. [00:23] lifeless: It claims not to support subtrees, but has a serializer that does. I think it's a lost cause. [00:23] agreed [00:23] lets make it say its bad in 1.6.1 [00:23] and get 1.6.1 out there asap; intrepid is in feature freeze, and has 1.6 [00:23] You know, it's funny how little I hear about the Ubuntu dev cycle. [00:24] Anyhow, I agree we should do that. [00:40] jam: Well, the upgrade completes, and it seems to work out right... [00:42] Can Bazaar do client cert auth over http(s)? [00:44] awilkins: I don't know, but if you can find the right magic to give pycurl, I can help you hook it in [00:45] CAn it do basic/digest? [00:45] I really can't open this up too far ; I now have IIS 6 running an HPSS (as long as you don't want any dumb service too!) [00:46] jam: check is happy (of course, it was happy on the knit before too) [00:47] Options for IIS 6 are - SSPI (not an option here), basic, digest, anonymous. You can also restrict connections to specific IPs, domain names, and posession of a client certificate [00:49] You can map client certs to user accounts which would be one way of enforcing ACL [00:50] awilkins: https + basic yes, I think we support digest already too [00:50] * elmo growls at #262450 [00:51] lifeless: That's great [00:51] I must sleep but I can try configuring that tomorrow. I'll probably update my WSGI gateway script to support multiple repos too [00:55] bug #262450 [00:55] bug #262450 [01:25] bug 262450 [01:36] kiorky, hi [01:38] kiorky, it looks more like a bzr problem to me [01:38] kiorky, the tgz file appears to contain a newline [01:44] hey jelmer [01:45] hi LarstiQ [01:45] are you in .nl? [01:45] yep [01:45] jelmer: I failed in letting you know there was a python-nl meeting today :/ [01:47] LarstiQ, well, I was busy this evening anyway [01:47] LarstiQ, how was the meeting? [01:47] jelmer: great! [01:47] jelmer: steve pointing me out swamped me with people for the rest of the evening though ;) [01:47] (-: [01:47] but that was partly what made it good, talking to lots of people === jamesh_ is now known as jamesh [02:32] jam: Thanks for all the reviews. [02:41] abentley: yeah, well I'm the 1.7 RM , I figure I need to get the review queue down, right? [02:41] abentley, lifeless: So I just had jaypipes test my patch with the mysql tree [02:42] and it drops the "bzr branch" time from 80+minutes down to 23min [02:42] So I'd like to get that patch, and a possible patch for the bug lifeless mentioned [02:42] and do a 1.6.1 [02:42] probably 1.6.1rc1 [02:42] Are you guys able to review it so I can get it turned around by tomorrow? [02:43] jam: my time isn't really my own 'till next week. [02:44] jam: make sure they're in BB? [02:44] jam: I'll do a review pass after lunch [02:44] The fetch regression is [02:44] I'll polish the other fetch bug [02:44] bugfix and submit it [02:44] jam: theres a critical format bug too; [02:44] jam: 1.6-rich-root isn't [02:45] lifeless: except that is a finalized format [02:45] I don't think we can do anything but change the name to it [02:45] as people are already using it as-is [02:45] jam: we have to remove it [02:45] jam: have bzr complain, and introduce a good one, because it won't work correctly for people [02:45] I'm pretty sure people have already upgrade to it, I think I have at least one branch here [02:46] I can understand "complain and ask to upgrade" or whatever [02:46] but I think we need to leave it as a "supported" format [02:46] (I don't care a lot for my own branch, as I can trivially get rid of it) [02:46] but it has made it to an official release [02:47] jam: no, we don't have to keep it supported [02:47] its a brown paper bag bug === Spaz_ is now known as Spaz [02:48] I think we have to let people upgrade away from it sure, to prevent data loss, but it won't push or pull properly [02:48] jam: awesome work, mate :) 91 minutes -> 23 minutes. [02:48] lifeless: that was more my point [02:49] I would really like it if someone else could take over that one [02:49] I don't have a lot of "work" time left today [02:49] jam: right [02:49] I'm mostly just sending in fixes I've already done [03:06] lifeless: would you be able to do a patch for a --1.6-real-rich-root ? [03:08] maybe, I'll see what I can do [03:08] k [03:08] worst case I'll get to it tomorrow [03:08] no promises - I've got a few too many balls in the air this week [03:08] but the turn-around time for reviewing a patch is a bit long [03:08] with everyone gone [03:09] I might give a poke at it right now [03:09] to catch your post-food reviews [03:12] abentley: just to be clear, we should use serializer v6, right? [03:13] jam: yes. It needs to be the same serialiser as rich-root-pack uses. [03:14] abentley: interestingly the docstring for RichRoot5 *does* say it supports external refs [03:14] Maybe a copy paste bug? [03:14] ah, it means Stacked branches rather than subtrees [03:14] RichRoot5? We have one ofthose? [03:14] "external lookups" confused me [03:15] abentley: RepositoryFormatKnitPack5RichRoot is the class [03:15] jam: yeah, I find that one a bit confusing too. [03:16] "results in non-truncated ghosts after reconcile" doesn't really seem to characterize it [03:17] also, "get_matching_bzrdir" returns "bzrdir.make_format(development1-subtree)" what is up with that? [03:18] jam: RepositoryFormatKnitPack5RichRoot was copied/pasted from Development1, perhaps a bit too quickly. [03:28] hi all. I just converted a svn repo into a bzr ... repo? I didn't use the --tree option. the faq says I should bzr co, but when I try I get: bzr: ERROR: No repository present: "file:///home/mdione/src/projects/psync/new/" [03:41] Hi StyXman, using bzr-svn? [03:51] lifeless: there are 3 patches for 1.6.1 review, which should all be in BB [04:11] jam: what was teh 1.5 mysql clone time? [04:30] * Peng_ notices this discussion. [04:34] Shush, Bundle Buggy. I know I don't have voting rights. It was a joke! [04:58] hi all. got a quick bzr question... is there a way to list branches / tags that are present in a remote repository? [04:59] (remote shared repo) [05:00] bzr branches url [05:01] ah I guess I need a more recent version of bzr then... my ubuntu got 1.3.1 [05:01] bzr: ERROR: unknown command "branches" [05:02] thanks for the info. will try a later version. [05:02] Actually, it's a part of the bzrtools plugin. [05:02] oh [05:03] thanks. going to d/l and check it out. [05:03] ah, sorry [05:42] lifeless: "bzr branch lp:mysql-server" was ~90 minutes with bzr1.5, ~80 ish with 1.6, and 23min with the patch [05:43] also, what is your feeling about --1.6-rich-root and renaming the old format? [05:43] jam: we don't want users reading docs that say '1.6-rich-root' and getting the broken on [05:43] one [05:44] ok, so you prefer --1.6-rich-root-broken and new and improved --1.6-rich-root? [05:44] I prefer [05:44] --1.6-rich-root-broken [05:44] or better yet, the broken one not registered at all [05:44] and --1.6.1-rich-root [05:44] I think we at least have to register it as a repo format [05:44] but we may not need to do a bzrdir format [05:45] I'll try that route [05:46] yes, thats right [05:49] So it would be possible to upgrade from the broken format, but it wouldn't be visible in any way, outside of the code? That sounds nice. [05:49] Or...I dunno. :) [05:50] How easy was it to create something in the 1.6-rich-root format? "branch --stacked" from some rich-root-pack branch? [05:52] lifeless, abentley: hmm... we have some stacking tests that assume stacking formats are all the same [05:52] and development-subtree uses serializer 7 [05:52] versus 1.6-rich-root using 6 [05:52] (the new one) [05:52] Peng_: yeah [05:52] Should I just disable the development-subtree from being tested? [05:52] Peng_: ebrownbag [05:53] jam: uhm, no, lets fix it right [05:53] jam: or it will just bite us later [05:53] k, it is only "test_stack_checks_compatibility" at the moment [05:53] But I'll poke at it a bit [06:06] ah, the problem is that "development" still uses serializer 5 [06:32] Ow! bzr, kindly don't consume 650Mb res. [06:35] * RAOF watches as bzr attempts to consume more memory than all other processes combined. [06:35] Well, if you're just going to leave it lying around where bzr can find it... [06:35] RAOF: what are you doing, and what version precisely? [06:35] Oooh, so close. It made it up to 998MB res. [06:36] There shall be a brief haitus while my system is paged back in... [06:36] bzr versoin 1.6, running "bzr multi-pull" in a repository with...6 branches [06:37] lifeless: I heard bzr 1.6 had a memory problem. I wasn't aware that extended up to 1gb resident :) [06:38] RAOF: actual released version? [06:38] lifeless: As packaged in Ubuntu Intrepid, yes. [06:38] RAOF: same repository format? [06:39] Yup. All pack-0.92 [06:39] damn [06:39] thats just wrong, it shouldn't spike like that [06:40] can you reproduce with bzr.dev? [06:40] It seems like each branch was stacking its own memory on the last; as if there was no GC going on. [06:40] Let's have a try with bzr.dev. [06:42] * RAOF rather wishes firefox wouldn't spawn so many empty windows [06:43] lifeless: The easiest way to run bzr.dev will be to just run 'bzr' from my branch, right? [06:44] yes [06:56] Progress bars almost uniformly suck. [06:57] bzr's is no exception :( [06:57] yes [06:57] progress is ard [06:57] Which is why they always suck. [06:59] Yay! We now have bzr.dev head. [07:01] ...and we're up to 600Mb resident before it gives any output at all. [07:02] RAOF: please file a bug [07:02] And we break the 1/2 of my physical memory barrier! [07:02] RAOF: having enough data to reproduce will be important [07:02] also, hit ctrl-\ [07:02] and get a back trace [07:03] Ah. While bzr is multi-pulling. Check. [07:04] Hm. That's new and different. I've never used pdb before. [07:05] later all, sluggish stuff [07:06] RAOF: really? [07:06] RAOF: let's switch lives [07:06] Heh. [07:11] Oh, that's rather interesting. It seems that the horrible memory use requires the presence of non-branch directories. [07:12] jelmer: hello, in regard to bug #261878 the problem is that svn can fetch the repo... [07:12] Launchpad bug 261878 in bzr-svn "bzrlib.plugins.svn.core.SubversionException" [Undecided,Incomplete] https://launchpad.net/bugs/261878 [08:40] Hi :) I just wanted to ask if somebody could maybe set the importance of https://bugs.launchpad.net/bzr/+bug/255656 to at least medium? I fear that this bug gets forgotten, otherwise, in spite of the availability of a bugfix branch from lifeless. Our set up at work requires us to use a windows network drive for hosting our repository. And it's really an annoying bug... [08:40] Launchpad bug 255656 in bzr ""bzr: ERROR: [Errno 22] Invalid argument" when "bzr pack" is executed manually or when "autopack" is triggered on a repository located on a windows network share" [Undecided,New] === bronger is now known as Torsten === Torsten is now known as bronger [10:03] gour, svn doesn't fetch as much data as bzr-svn, it just fetches the last revision [10:52] jelmer: still, i can do svn log and see the history...the point is that for quite some time i fetch and update pandoc repo and build the package, but bzr-svn fails to replace the need for svn [10:52] gour, the problem appears to be that the svn server is unreliable [10:52] gour, bzr-svn has to do far more requests than svn [10:52] since it fetches every revision in history [10:53] and the server occassionally fails with http errors [10:55] i understand bzr-svn does more...however, i'd like to use bzr instead of svn and dunno what to do in this case [10:56] gour, the problem really is in the reliability of google code, that's out of my control :-( [10:57] if you're trying to do a one time import, you can branch into a shared repository and repeat when it fails [10:57] well, i want to constantly fetch from the repo.. [10:57] jelmer: how well do stacked bzr-svn branches work? [10:58] gour, as long as you're ok with retrying occasionally, that shouldn't be a problem [10:58] LarstiQ, they're not layered appropriately enough in bzr yet for it to work well [10:59] jelmer: ok. let me try to re-do and continue with that process [11:00] LarstiQ, they do work, but all files have to be fetched individually atm, which doesn't make the process any faster [11:01] jelmer: ah [11:07] .wg 3 [11:07] gah [11:07] fail [11:09] 'morning Jc2k :-) [11:13] morning jelmer :) [11:19] jelmer: the problem is that if i retry with 'bzr pull', bzr says it's not a branch, so i've to try 'bzr branch' again which fails [11:19] jelmer: it looks like catch-22 [11:21] gour: bzr init' then pull [11:21] Is it possible to extract a part of a branch into a new branch? [11:21] E.g. I have this "subproject" that I want to promote to a real project [11:21] jonnydee: I think its merged and fixed in 1.6 [11:21] uws: bzr split [11:22] lifeless: what will happen with revisions touching both files inside and outside this subproject directory? [11:23] uws: it keeps all the history, as that lead into the project [11:23] uws: it just creates a fork in the road, where one side is the subdir, and the other side is all but the subdir [11:23] lifeless: so basically it's a new branch, removes everything not in that dir, and moves everything in that dir to the branch root? [11:23] yes [11:24] which lets you merge branches from before the split smoothly and so on [11:24] lifeless: Ok thanks. will investigate [11:25] lifeless: the "move" line in bzr status is a bit strange [11:25] renamed: [11:25] subproject => [11:25] perhaps a / at the end helpt ;) [11:25] helps* [11:26] :P [11:26] this is rarely used; please do file bugs :) [11:28] lifeless: I cannot be bothered in this particular corner case ;) [11:28] ok [11:31] lifeless, this is how I ended up solving the sharing of VirtualSignatureFiles btw [11:32] lifeless, A project "bzr-foreign" that is joined to both bzr-svn and bzr-git [11:32] jelmer: and you merge from it twice? [11:32] lifeless, yeah [11:32] kk [11:33] it's not optimal - by-reference nested trees would be awesome! - but good enough for now [11:51] lifeless: I just have had a look at the source code of 1.6 -- it seems like the bugfix is not merged inti bzr 1.6... [12:41] jelmer: don't know how many times i've tried, but 'pull' fails 100% [12:43] jelmer: here is the trace of bzr pull http://rafb.net/p/myafQi40.html [12:56] Hi, when I try to push a new branch to a repository on a windows network share thaen this command fails with a "bzr: ERROR: Could not acquire lock "B:/ProjektM/vendor/.bzr/checkout/dirstate"" [12:57] Is it a bug? BTW, the branch seems to be pushed to the network share. I can checkout from there [12:58] that's just failing to create the working tree [12:58] but a lock seems to exist anyway and I have todo a break-lock [12:58] OS locks are used for that, meaning that the share probably doesn't support them [12:59] the builddeb plugin changed the default result-dir to ".." and the help message refers to --result-dir to change it but it doesn't seem to work. I get bzr: ERROR: no such option: --result-dir [12:59] but when I browse the working tree on the share it exists... [12:59] fta: try --result please [13:00] james_w, seems ok, the help is wrong then. [13:00] thanks [13:00] fta: thanks, I'll fix it for the next upload. [13:01] fta: are you setting --result back to ../build-area? [13:01] it's building... [13:06] james_w, well, didn't work for me. I wanted to revert to the previous default, ie, keep debs in ../build-area but if i set --result=../build-area , i get a traceback when it tries to move the files on themselves, which is obviously wrong. [13:06] fta: ah, thanks, I'll fix that too. [13:06] either there should be a test to detect src = dst, or a way to disable that move [13:06] yeah, I'll do the former I think [13:07] lifeless: are you aware that bug 255656 is not merged in 1.6? [13:07] Launchpad bug 255656 in bzr ""bzr: ERROR: [Errno 22] Invalid argument" when "bzr pack" is executed manually or when "autopack" is triggered on a repository located on a windows network share" [Undecided,New] https://launchpad.net/bugs/255656 [13:17] lifeless: sorry, if I'm bothering you, but I'm trying to convince my development team to use Bazaar and I am constantly experiencing problems with using a network share (which is our setup); the last error I stumbled over today is: bzr: ERROR: Could not acquire lock "B:/ProjektM/vendor/.bzr/checkout/dirstate" when I pushed a new branch. [14:03] fta: http://bzr.debian.org/pkg-bazaar/bzr-builddeb/2.0 has a fix if you need it. [14:10] jonnydee: the bugfix is approved; it may not be in 1.6, but I was sure it was in bzr.dev. If its not I'll make sure it this week [14:11] as for the lock problem, well, its after 11pm for me right now, way to tired to be thinking about it [14:11] jonnydee: please file a bug to provide a discussion point about it [14:15] hi all. I just converted a svn repo into a bzr ... repo? I didn't use the --tree option. the faq says I should bzr co, but when I try I get: bzr: ERROR: No repository present: "file:///home/mdione/src/projects/psync/new/" [14:22] jelmer: I just merged your directory branch, should it check whether bzr-svn is available before trying to checkout Vcs-Svn? [14:25] Hey, I am currently looking into how to ignore certain files from being monitored and got the User Guide open. I don't understand how the syntax for ignoring files down a file tree works (recursive stuff). I've got a .bzrignore file created. [14:26] StyXman: hi, what command did you use to do the conversion? [14:27] Stellaris: if you "bzr ignore dir/subdir/file" it will add an entry to the file, which should give you a hint [14:27] james_w: ah, thanks, will try that [14:37] james_w: thanks! [15:08] james_w: Hi [15:09] james_w: Yeah, it may be nice to check whether bzr-svn is present and give a more understandable error [15:09] james_w: Otherwise, it'll just say "Not a branch" if you try to check out a svn branch [15:16] hey mwhudson [15:16] can you take a look at: https://code.edge.launchpad.net/~beuno/loggerhead/1.6.1/+merge/806 [15:16] when you have time? :) [15:23] lifeless: do you remember why cloning, unlike other operations, inits the branch and tree formats itself? [15:23] lifeless: For Pre-split-out bzrdirs. [15:30] jelmer: ever see anything like this ? http://cluebin.appspot.com/pasted/1201 (bzr 1.6 final, bzr-svn 0.4.11 final, svn 1.4.6) [15:34] do i need to do anything with a branch to get the new b-tree index capability? [15:34] bzr upgrade is saying it has nothing to do [15:35] rocky: https://bugs.launchpad.net/bzr-svn/+bug/250480 [15:35] Launchpad bug 250480 in bzr-svn "Doesn't preserve non-lhs parents for file texts" [Critical,Fix released] [15:36] Jc2k: awesome, thanks [15:36] Jc2k, I'm pretty sure this is different [15:36] oh [15:36] since this is about a revision object, not a file text revision [15:36] ah [15:38] * Jc2k has definitely seen NoSuchRevision before, though [15:38] hi sabdfl, I'm not sure the b-trees in bzr.dev are hooked up to a format yet, certainly not a default one. [15:39] jelmer: is a "try: import bzrlib.plugin.svn; except ImportError:" suitable for that? [15:39] jelmer: in that paste ... ClueMapper-rocky is a regular bzr branch of ClueMapper-trunk which is a bzr-svn checkout ... and "repo" is a "bzr init-repo -1.6-rich-root" repo [15:39] james_w, yep, that should take care of it [15:39] jelmer: cool, I'll add it [15:39] rocky, The revision it fails on, what sort of revision is that? [15:40] The btree stuff is wired up as --btree-plain and --btree-rich-root etc. [15:40] but they're not default afaict [15:41] jelmer: i'm not sure, how do i tell? [15:41] I want to use bzr to version some college papers also I want to have a central repository on a server where I commit all changes so I have a backup if something bad happens. I'll be the only user... Should I use this binded mode? [15:41] rocky, that revision id, is that of a revision in the current branches' history (iow, does "bzr log --show-ids" list it?)? [15:41] dudus, yeah, that sounds like the right approach [15:42] jam: are you familiar with git's recursive merging? Does/could bzr do something similar? Would it help at all? [15:42] jelmer: yes it does [15:42] jelmer: http://cluebin.appspot.com/pasted/1002 [15:42] Kinnison: does --development include that? [15:43] james_w: thx [15:43] rocky, Any chance you can paste the full "bzr log --show-ids" output? [15:43] rocky, this looks like a bug in bzr not being able to cope with ghosts [15:43] sure [15:44] rocky: Thanks for finding so many bugs :-) [15:45] lol [15:45] How is the CVS integration? It's not as good as SVN, right? [15:45] jelmer: http://paste.plone.org/23470 [15:45] sabdfl: Not sure, sorry [15:45] (just in a session at DrupalCon, Lenz Zimmer is talking about bzr, we're all stoked) [15:45] emmajane: yeah, correct [15:45] sabdfl: btree-plain is just pack-0.92 with btrees turned on [15:46] iirc [15:46] emmajane: it's possible to do a one-way conversion, roundtripping is not possible [15:46] abentley: Hm. Not sure about push/pull with loom. Doesn't seem to take the recorded state of the loom into acount at all (from what I can tell). [15:46] emmajane: it's not as good as svn, no. There's no "foreign branch" plugin like bzr-svn, but there are several reasonable converters [15:46] abentley: Rather, it pulls from the currently selected thread (I think). [15:46] rocky: Thanks [15:46] Thanks, jelmer and james_w. [15:47] rocky: This does indeed look like a bug in the ghosts handling [15:47] fbond: Are you pulling from a loom into a loom? [15:47] git has sub-projects, is there an equivalent in bzr? [15:47] abentley: in fact, it's not clear to me that `bzr record` has any value at all, currently. [15:47] abentley: yes [15:48] jelmer: if/when you need me to switch to the bzr-svn branch lemme know [15:48] abentley: I have two looms that are mirrors of each other, but one is beind the other. [15:48] abentley: Be nice to have a single command that brings all the changes from one into the other (in all threads). [15:48] fbond: That's suprising. last time I tried pull, it was definitely broken. [15:50] abentley: You are surprised it's still broken, then? [15:51] fbond: It was broken because it was trying to behave as pull-loom. I would have thought when it was fixed, it would have. [15:52] abentley: Well, I'm currently using 1.3.1... [15:53] emmajane: "nested trees", there's experimental support for them, but nothing solid yet. I hope it will be a 2.0 feature, i.e. this year. [15:54] abentley: In any case, I can pull one thread at a time by moving through threads on each end before pulling. [15:54] thanks, james_w [15:55] bzr has no equiv of svn:externals right ? [15:56] (Lenz Grimmer, I think I had the last name wrong.) [15:57] rocky: aiui.. it has by-value nested trees, but not by-reference trees in 1.6 (svn:externals are by-reference) [15:57] *by-reference nested trees [15:59] what does a "smart server" mean within the context of bzr? (in relation to just a "server") [16:00] when should I use bzr init and when to use bzr init-repo to create a central repository? [16:00] dudus: i just learned that "bzr init" doesn't create a central repository ... it merely turns the directory into a bzr-versionable dir ;) [16:02] in the second exemple in this link it uses init to create the central one !?! http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#publishing-a-branch [16:02] james_w: sorry for dissapearing. bzr svn-import [16:05] StyXman: and you were in /home/mdione/src/projects/psync/ when you ran that? [16:05] StyXman: what directory are you running the "co" command in? [16:05] statik: Lenz says hello. :) [16:07] james_w: no, in /home/mdione/src/projects/psync/new/ [16:08] err, in another dir, actually. so the question is, how should I do it? [16:08] dudus: No, it uses init-repo to create a central repository. [16:08] StyXman: have you moved anything around since running "bzr svn-import"? [16:08] rocky: smart server implies not dumb, e.g. vanilla http is dumb [16:09] james_w: actually I copied the .bzr dir in trunk [16:09] StyXman: ah, that's probably not a good idea [16:10] thing is, if I do a svn-import it creates the whole svn tree: trunk, branches/* and tags/* [16:10] do you just want "trunk"? [16:10] in the parent of all those there's a .bsr [16:11] james_w: idealy I want all the history, but trunk is enough [16:11] s/bsr/.bzr/ [16:11] can you put the .bzr dir back where it was? [16:11] james_w: yah, I only copied it [16:12] ah, can you delete what you copied then? [16:12] yeha, it's throw-away'able :-P [16:13] done [16:13] now "cd trunk; bzr checkout ." [16:14] takes time :) [16:14] there, thanks [16:15] now, i have lots of .bzr dirs [16:15] have you got what you want now? [16:15] psyc/.bzr, psync/trunk/.bzr, psync/tags/*/.bzr, etc [16:16] yep, they are each branches [16:16] except for psyc/.bzr which is the "shared repository" that holds the actual revision data [16:17] aha [16:18] ok, I'll have to re-read the user reference then... thanks james_w [16:43] hello [16:44] I have a question or 2 [16:45] what permissions are required to the .bzr folder and its sub folders if you are going to do http? [16:45] Jc2k: the reason i'm asking is because i was wondering about serving up a bzr repo from my python wsgi app (i'm a python programmer) in a R/W fashion ... does the standard wsgi app allow that? [16:46] (i'm aware of the missing auth problem) [16:46] rocky: not a dev, so dunno [16:48] Jerky_san: if you are just serving the files out over http then any permissions that allow your web server to read the files is enough [16:48] gour: ping [16:49] danke james [16:50] my other question is if i use htaccess to restrict who can see whats in the folder i seem to get an eror that says ERROR: pycurl.error: (65, "necessary data rewind wasn't possible") [16:50] *error [16:51] i thought it had to do wtih permissions to folders/files so i did a test folder and 757 permissions to all files and folders.. [17:10] bleh this error is so wierd ._. [17:16] gour: bzr branch http://bzr-mirror.gnome.org/bzr/pandoc/trunk pandoc [17:16] gour: ping me when you have it, i dont like having non gnome svn stuff on there [17:18] gour: it really was just googlecode being flakey, i had to use bzr pull -r50, bzr pull -r100, bzr pull -r150 and eventually it got there [17:28] rocky, still there? [17:28] jelmer: yes [17:28] rocky, what was the URL of your svn repo again? [17:29] https://dev.serverzen.com/svn/cluemapper [17:29] and the specific branch on which the error occurred? [17:30] jelmer: well, this was against a local bzr branch that branched off of cluemapper/trunk checkout [17:30] err [17:30] cluemapper/ClueMapper/trunk [17:30] thanks [17:36] welp i figured my error out.. apparently the file pycurl.pyd causes it if you attempt to connect through https [18:15]