[00:00] hey vila [00:00] welcome back, good to see you [00:06] lifeless: the problem is that once you sign up for a bazaar-vcs account, the first link it gives you is your personal page, and then you follow it and it wants to create it for you. [00:06] So the *sign-up* procedure encourages it [00:07] yes [00:07] I wonder which page to edit to fix that [00:08] lifeless: I'll try to ping newz tomorrow to ask [00:09] lifeless: do you think there might be an obvious way to make the 'three_level' test go faster? [00:09] 60s for a test is a bit ugly [00:09] I guess it is 68s, and iter_all is 81s [00:09] well [00:10] make the code faster :) [00:10] I'm at least tempted to profile it and see if there is anything obvious [00:11] on the dirstate corruption [00:11] the change I'm proposing for locks should help that too :P [00:12] there are lots of ways around it [00:13] just getting rid of the write-in-place will help [00:13] however we go about it [00:13] assuming it is the truncate() causing the problem [00:14] yah [00:14] thats true [00:20] does bzr support inline branches? [00:21] I don't know what that means [00:22] it means creating a new branch in the same directory and being able to switch between them without changing directories [00:25] no to git-style branches, yes to switching one working copy between branches in a repository [00:25] gotcha [00:26] technomancy: we have a bzr switch command that can switch branches in a single working dir [00:26] technomancy: and we have cheap branches (they are 'bare' - no source files) [00:27] so if I've got my own branch checked out in one directory and a friend's checked out in another, I can't exactly just "bzr diff" them, can I... how does that work? [00:28] bzr diff -r branch:otherdir [00:28] aha; thanks! [00:32] I heard Emacs was planning on migrating to bzr, does anyone know how that's going? [00:32] nobody in #emacs seems to know; heh. [00:33] there's a bzr mirror of the emacs trunk [00:33] yeah, but afaik that's still all unofficial [00:33] and i think there are some performance concerns, at least some of which are fixed [00:33] but i guess right now a whole lot of nothing is happening :) [00:34] right; it sounded like they were waiting for some more perf fixes... Emacs is one of the oldest extant projects in any version control system, so it makes sense that it would be a good deal more taxing than your average launchpad project. =) [00:35] it's not actually that big [00:35] it's only 80k mainline revisions or something [00:35] which, yeah, is on the large end, but it's nothing compared to OOo :) [00:36] interesting. Yeah I was thinking more in terms of years than any actual measurements I had read. [00:37] oh probably yes [01:13] can you diff with a branch straight from launchpad that you haven't checked out locally yet? [01:13] oh wait, I think I can figure that out. [01:14] yup, that worked [01:16] is there any way to automate file downloads when you cut a new release in launchpad, or do you have to create your tar/zip files manually and upload them through the web interface? [01:17] technomancy: that last question may be better asked in #launchpad [01:17] oh, of course [01:17] I don't know the answer myself, sorry [03:06] jam: don't suppose you are still around ? === mw is now known as mw|out [03:44] lifeless: got an eta for reviewing https://code.edge.launchpad.net/~jml/testresources/tests-meaning-cleanup? [03:52] 'soon' [03:58] whee [03:58] 10 second saving on cold-cache stat [04:04] lifeless: fair enough [04:04] lifeless: also, 10s on cold-cache is pretty good. [04:05] lifeless: if you have a look at the TODO file I've added, then that'll unblock me for further work. [04:05] jml: 1m5 to 53 seconds [04:05] jml: k [04:06] lifeless: does the saving translate to hot-cache? [04:08] maybe [04:08] call for testers coming this afternoon [04:08] heh [04:08] lifeless: well, I'm offline until this evening. maybe I'll talk to you then. [04:11] okies === samurai is now known as samiam [04:50] can you have the bazaar mailing list available on www.opensubscriber.com [04:50] it really has a cool (soothing) interface to reading mailing lists [04:51] anyone here personally interested in brz-perforce-bzr interface? [04:54] * jamesh hasn't had to use p4 since 2001 and is happy to keep it that way [04:55] xshelf: you can probably get bazaar on opensubscriber yourself [04:55] lifeless: The mail I send to bazaar for subscription requires auth confirmation which opensubscriber does not support [04:56] lifeless: So, the list maint needs to bypass confirmation for this mail address [04:56] oh [04:57] I guess that is a way of only archiving lists with admin approval [04:58] you can also reply to author or group with that interface [04:59] with Yahoo supporting only 15 filters, I run out of filter space if I subscribe to multiple lists! [05:00] Hence, I prefer a one stop shop of reading lists [05:30] man we're going to get a lot of mail when aaron gets back and restarts bb [05:40] gmane! === wantok is now known as `6og [06:34] I'm not clear from http://bazaar-vcs.org/NestedTreeSupport on the status of nested tree support. I'm reading posts from early 2007 which say it's "soon"... [06:34] Can anyone give me a more up to date view? [06:36] Ok, this seems like what I'm after http://bazaar-vcs.org/NestedTreeProgress [06:37] Last update was May 07 though, anyone know if any progress has been made since then? [06:37] chmac, yeah, that hasn't happened yet [06:37] you can ping LarstiQ [06:37] and make him feel guilty about it [06:37] that's what I do [06:37] :) [06:37] LarstiQ: Nested Tree support? When's it gonna happen? :) [06:38] maybe even email the list to get the subject re-started [06:38] beuno: I'm considering bzr vs svn for a new project. [06:38] It's managing WordPress installations, and keeping the up to date [06:38] So I was thinking to use nested trees to keep the plugins up to date [06:38] chmac, well, we have something really cool, which is the "bzr-upload" plugin [06:38] I only need very basic support, to add a nested tree, to update it to the latest version, and then to roll it back to a previous version if necessary [06:39] beuno: Cool, let me check that out... [06:39] which will let you upload *just* the working tree, and *just* what has changed since the last upload [06:39] right, nested trees don't currently work, so I wouldn't go down that path just yet [06:40] beuno: Ok, bzr-upload looks very interesting [06:40] It would allow me to keep the code in one central location, and push updates selectively to remote hosts [06:40] chmac, and not just because I'm onw of the authors. It actually works :) [06:40] That might bypass my need for nested trees, as I could simply push plugins separately [06:40] :) [06:40] chmac, yeap, that's the idea. Mainly aimed at web-dev [06:41] https://launchpad.net/bzr-upload/+download: [06:41] No download files exist for this project. [06:41] chmac, yeah, we haven't made an official release (will soon) [06:42] so, to install it: mkdir ~/.bazaar/plugins && bzr co lp:bzr-upload ~/.bazaar/plugins/upload [06:42] if you're on linux [06:42] Ubuntu :) [06:42] cool, the above should work then [06:42] and you're set [06:43] beuno: Will it allow me to push a previous revision without rolling back my "working copy" ? [06:43] chmac, yeap, just specify -r X [06:43] :) [06:43] and, if you find you need features that aren't there, file bugs, we'll get it done :) [06:44] beuno: Now that's what I want to hear! :) [06:44] It's checking out now... [06:47] beuno: Will it support ssh host definitions? So sftp://blah/some/path/ ? Automatically picking up my ssh key and so on? [06:48] beuno: When I run `bzr help upload` the first line is "Unable to load plugin 'upload' from '/home/me/.bazaar/plugins'" [06:48] Yet it outputs the help just fine... [06:48] chmac, how odd... [06:49] can you take a peak in ~/.bzr.log? [06:49] you should have a traceback [06:51] beuno: http://pastebin.com/d4cc40f5f [06:51] chmac, what version fo bzr are you using? [06:51] smells old [06:51] Bazaar (bzr) 1.3.1, latest in Ubuntu 8.04 [06:52] chmac, hrmm... mind filing a bug that it doesn't work with 1.3.1, and upgrading to 1.6rc3? https://launchpad.net/~bzr/+archive [06:53] beuno: Happy to file a bug. It does actually produce the output ok though. [06:54] Shall I try a test upload to see if it works? [06:54] chmac, yeah, it will work. It's the "auto" feature that won't. [06:54] Ok [06:54] chmac, I'll file the bug, don't worry [06:54] upgrade, and the message will be gone [06:54] beuno: Ok, great, if you need anything else from me, just let me know [06:55] chmac, you've already found a bug, plenty help already :) [06:55] :) [06:57] chmac, bug #259647 if you want to subscribe [06:57] Launchpad bug 259647 in bzr-upload "auto feature doesn't work with older bzr versions and tracebacks" [Undecided,New] https://launchpad.net/bugs/259647 [06:59] beuno: nice, just subscribed, and running `apt-get update` to install the latest bazaar, thanks for all this [06:59] chmac, happy to help, and, especially, welcome new users :) [07:01] Looks like the Thai ubuntu mirror is out of date, time to find an alternative... [07:01] it should download from PPA, not ubuntu mirrors [07:02] beuno: Yeah, but the `apt-get update` was failing because of a mirror issue [07:02] Seems to be running ok now against Taiwan :) [07:03] chmac: A list of Ubuntu archive mirrors may be found here: https://launchpad.net/ubuntu/+archivemirrors [07:03] jpds: System > Software Sources has a neat tool which checks the mirrors and determines which one is fastest, turns out Taiwan is faster than Thailand in Bangkok :) [07:04] yeah, I use brazil [07:04] chmac: Oh, that's neat. Didn't know that. [07:10] chmac, I'm off for the night. Good luck with that, and feel free to hang around here and ask questions. Everyone is very friendly here :) [07:11] beuno: Thanks again :) [07:24] morning [07:24] is there release date scheduled for 1.6? [07:26] gour: btw, doing a branch of ghc inside a shared repo (generating a tree) takes about 6s without hardlinks [07:26] * thumper is away [07:26] thumper: heh [07:27] kinda off-topic, but can anyone lend me a clue about how I can filter launchpad bugmail using gmail? It doesn't recognize the mail as coming from a list [07:28] (its bzr bugmail I most need to filter, which is why the question isn't completely off-topic ;) [09:57] Anyone familiar with the bzr upload plugin around? [09:58] beuno said it leaves a file on the server to track what version was last uploaded. I'd like to see a demo of that file, where it's placed, the filename, and so on... [10:03] chmac: i guess you can go bzr upload bzr+ssh://localhost/tmp/test and look in /tmp/test :) [10:03] (or however it works) [10:05] mwhudson: Hadn't thought of doing it to localhost, that's an idea... :) [10:07] Turns out it's crashing on my machine, I'm not running a late enough version of bzr [10:07] Upgrading caused hassle earlier, I'll try it again... [10:11] If I grab bazaar from ppa.launchpad to get the latest version, I can't also get bzr-svn there can I? [10:12] When I try to install the latest bzr it's failing because bzr-svn depends on it, but there's no newer version of bzr-svn [10:15] i uninstalled the bzr-svn package and stuck trunk in ~/.bazaar/plugins/svn [10:23] mwhudson: Is it that easy? [10:23] I love me some bazaar... :) [10:27] Hi! I'm looking for some features in bzr, and would be interested to learn if they are available already, or if not, if they have been discussed before, and what you know about the status of them. [10:28] One would be a way to merge distinct branches. Say you have two projects that started as independent branches, but they grow together with interdependence in both directions, so they should be merged into a single source tree. Is there a way to do so which would maintain the revision history of both parts from before the merger? [10:29] MvG: i thought there was a (kludgy) trick for that [10:29] The second would be an analogous to the "svn cp" command. When you refactor a file, it makes sense to have two files descend from a common previous file, so that again lines in both files can be attributed to revisions before the split. Is there any way to achieve this in bzr? [10:30] MvG: Something with "use the null revision as the merge parent" methinks [10:30] uws: Would that work with rich root repos, where even the root dir has a file id? Do you know how I would formulate that on the command line? [10:32] cd tmp [10:32] Sorry, wrong window... [10:33] I'm getting this error when trying to check out bzr-svn: ERROR: Invalid http response for http://bazaar.launchpad.net/%7Ejelmer/bzr-svn/0.4/.bzr/repository/packs/bffc0ecb67b4c56b089ca948c85597dc.pack: Expected a boundary (nDMiLeDyiK0rv.WGnkX:) line, got '' [10:33] Any suggestions? [10:36] MvG: Something like bzr merge /path/to/other/branch -r 0..12345 where 12345 is the tip of the other branch [10:36] MvG: backup/try first, it might do strange things [10:38] uws: At least on a test repo that looks very promising. -r 0..-1 would be the generic way. Thanks a lot, that will be helpful! [10:38] MvG: yw. [10:39] MvG: let me know if you know about the "cp" thing :) [10:40] uws: Sure. [10:42] chmac: "bzr branch http://bazaar.launchpad.net/%7Ejelmer/bzr-svn/0.4" works for me, with current bzr.dev. Was that the command you tried? You might try branching http://people.samba.org/bzr/jelmer/bzr-svn/0.4 instead. [10:42] MvG: That wasn't the command I tried, I was trying `bzr co lp:bzr-svn ~/.bazaar/plugins/bzr-svn/` [10:42] But I'm trying your command now [10:43] I'm also reading https://bugs.launchpad.net/bzr/+bug/198646 [10:43] Launchpad bug 198646 in squid "Invalid http response ... Expected a boundary" [Medium,Fix released] [10:43] It looks like bazaar can cause issues with firewalls, I'm in Thailand, so everything runs through a transparent proxy [10:43] I'm trying to run the command via tsocks, but that doesn't seem to be working either... [10:44] chmac: You can register an ssh pubkey with launchpad, then the lp: branches will convert to bzr+svn, which might work better. [10:44] MvG: That sounds like a plan... [10:44] I'll be in Australia on Sunday and will probably not have this issue, but the ssh option is probably sensible anyway... [10:45] what does bzr: ERROR: Path(s) are not versioned: debian/changelog mean? see: http://pastebin.mozilla.org/520727 for changelog [10:46] it looks perfect to me. i get it when trying to commit changelog [10:46] If this transp. proxy is repeatedly causing you trouble, I would probably start looking for ways to avoid it when the need arises. Most of the ideas I can think of right now do require a host on the outside through which you can relay things, though. [10:47] gnomefreak: It means that the file is not under control of bzr. If you just created it (like it seems), you should call "bzr add debian/changelog" first. [10:47] gnomefreak: "bzr status" is useful to tell you about files not yet added. [10:48] i found issue [10:48] i forgot to add debian/ [10:48] Woohoo, it worked via tsocks after all :) [10:48] Gotta love ssh! :) [10:49] will commit take several files at a time if i list them "bzr commit rules control"? [10:49] gnomefreak: Sure. Why not simply say "bzr commit" to commit all your changes in one bunch? [10:50] MvG: what changelog on a separate commit [10:50] i want [10:50] not what [10:51] Does anybody know whether bundlebuggy is ill? Haven't been able to reach it lately, connections always time out. [10:55] uws: Found http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/45083 by Martin Pool which says the feature is wanted, but not yet implemented. Still hunting for the references. [10:59] jelmer: How does bzr-svn handle copied files from svn? Do you have an elegant way of representing the copy, whcih would be suitable for non-svn use cases as well? [11:01] Oh, I guess not, as you are the author of http://bazaar-vcs.org/BzrFileCopies and the corresponding https://launchpad.net/bzr/+spec/filecopies is marked "not started". uws, I think that sums it up so far. [11:16] MvG: I'm not the author of that page :) [11:17] uws: No, sorry, that was addressed to jelmer. [11:17] Should have been more clear. [11:18] MvG: it's ok. [11:18] thanks for the pointer [11:18] http://bazaar-vcs.org/DraftSpecs/PathTokens seems worth reading as well. [11:26] lifeless: Your path tokens approach, are they intended to replace file ids? Or be an additional tool along file ids for cases where file ids don't get the job done by themselves? [11:57] MvG: replace [11:57] MvG: or more accurately, implement copy in the file id model [11:58] I believe I can see the issue in both your use cases, but I have doubt that a single approach would be fit to address them both. [12:00] As I understand it, the file tokens for copy would depend only of the history of the files involved, whereas the working with different trees in the parallel import scenario would be based on some user configuration, ore some perhaps costly automatic search for a common ancestor. [12:04] For copy/merge, a DAG of file ids might serve as a token. I have some ideas how to implement this, although I don't know how they would agree with the current infrastructure. But I can see no way to generalize this for parallel imports. [12:06] lifeless: If I want to put some ideas into words, should I do so in the wiki, or add comments on launchpad, or discuss them here? [12:08] MvG: well for parallelimports tokens would work by allowing a join to take place at the first time both trees are examined [12:09] the mailing list is probably the best place to describe thoughts on this [12:10] lifeless: Ah, so you don't want to seamlessly handle distinct imports in all commands, but instead want a single command to join the trees, which does specialized work, and continue from there handling things as two related branches, right? [12:11] I'm starting a mail to the list. Thanks. [12:14] MvG: actually, I mean that 'merge OTHERIMPORT" [12:14] will see separate tokens for conflicting file paths [12:15] and depending on what we decide works best UI wise, with either have an option to enable, or disable, joining the tokens where the file path conflicts exist [12:15] when you commit that merge, you will have created a join in the per-file dags, and subsequent merges in either direction will not conflict [12:16] Makes sense. [12:16] this should be fast - the number of token changes in two parallel imports will be 1 each, and user friendly [12:19] How about this case: I have a private parallel import, and for some reason I want to merge that branch into an official branch, not the other way round, and continue working on these two in that fashion. So I myself would want to join the DAGs, but it wouldn't make much sense to push these joins anywhere, as noone else can make any use of the IDs from my private branch in any case. I would want a "private, unpushable join". Do you consider this scenar [12:20] it cut off at 'do you consider this scenar' [12:22] ... this scenario to be of any relevance at all? [12:22] well [12:23] I don't really understand the scenario [12:23] you want to merge a private branch into the official branch [12:23] but you don't want to merge your history? [12:23] ignore implementation details for now [12:23] (file ids & file tokens are implementation details) [12:26] MvG: still there? [12:28] lifeless: been AFK ... catching up now. [12:30] I want to merge the history, but I want to filter which part of the history I publish, I think. [12:30] can you be more specific? [12:31] (I'm still not understanding the use case) [12:31] Let's try a set of examples. [12:31] I create a branch "checkout" from an upstream repo and a branch "tarball" from a tarball. [12:32] I do "cd checkout; bzr merge ../tarball" or some such. [12:32] Now when I do "bzr log", I want to see a forked hiostory for the files, as they come from the tarball and the checkout. [12:33] sure [12:33] But when I push the branch, I might wish the option of hiding all the joins, so people think that files changed in the tarball were modified by me, and files just present in the tarball were newly added by me. [12:34] well the forked history would show that anyway [12:34] The forked history would register a different branch from which files have been merged, up to the initial import of the tarball. [12:34] On my system at least. [12:35] Gotta go now, I'll write the mail later today, and include this scenario for discussion once I have thought more about it. [12:35] showing a fork and showing you as having made changes/added files are not mutually exclusive options [12:37] anyhow, I think you could do revert --forget-merges after doing a merge to mainline; not sure why you would want to [13:16] Hi! One of my branches (actually the trunk) has a parent branch ('bzr info' says so) that it doesn't need (since it is itself the trunk). Can I remove the parent branch? [13:18] cyberco: only by editing .bzr/branch/branch.conf currently [13:18] not that it's particulary important to do so. [13:23] james: ok, sounds a little dangerous (being new to bzr). I guess it won't do any harm there is still a parent (that doesn't exist anymore), will it? [13:24] cyberco: no, it is only used as a default for things like `bzr pull` when you don't supply any arguments. [13:24] ok, that's no problem then [13:24] indeed :) [13:25] cyberco: in case you want to change it, bzr pull --remeber some/other/branch would do it. [13:25] cyberco: maybe not for trunk, but will come in handy for others. [13:26] another question. On the server I've branched my trunk to 'workbranch'. Then I branched it to my local machine using sftp. But when I try to push my changes back to the 'workbranch' on the server I get the message: "This transport does not update the working tree" [13:26] cyberco: right [13:27] cyberco: if you don't need the working tree there (and I suspect you don't), then I'd blow it away on the server with `bzr remove-tree` [13:28] larstiq: which means that the files will be removed but not the bzr info? [13:28] cyberco: exactly. [13:28] cool [13:29] cyberco: in the case you did want to have a working tree there, the message is harmless, .bzr is still updated. You can `bzr up` on the server to update the working tree, or use a plugin like push-and-update to do that everytime you push. (Or bzr-upload if you don't want .bzr, say, website deployment) [13:32] Yes, that was what I figured, but I don't need a 'working tree' on the server, so I thought that was a lot of hassle. But, alas, things work wonderful now! Thanks for your help [13:32] I'm really impressed with bazaar [13:33] thanks :) [13:33] LarstiQ: lifeless anyone free to share some point with main ghc dev (JaffaCake in #ghc) ? [13:33] gour: I'll join, but I can't guarantee anything [13:33] LarstiQ: ok. [13:34] has anyone experience in setting up a http bzr repository protected by an .htaccess file? [13:34] gour: in general, there are more eyes in here, so I would recommend asking questions here. But I recognize the value of hopping over to their community for help. [13:34] gour: I just wish I was better at giving it. [13:34] yes, but let's take whatever opportunity which arises [13:36] ok [13:38] how are commit rights normally arranged? By standard OS file access control? [13:39] cyberco: yes. [13:40] grutte_pier: not me. [13:41] cyberco: from the hasseling I'm having now with .htaccess I would say yes [13:42] Heya, svn has --stop-on-copy to show log from branch point forward. Does bzr have anything like that? [13:42] my problem is that even with a authentication.conf file, I keep getting a 401: Authentication requested error,that bzr doesn't deal with... [13:44] I need to publish branches over http, I can not find documentation about it in the user guide, any hints ? [13:46] I guess I can use `bzr log -r ancestor:foo..`. [13:46] moya: same here! I think you'll need the WebDAV plugin to do that [13:47] moya: you are not coincidentally trying to protect you're branches by a .htaccess + .htpasswrd file are you? [13:48] moya: https://launchpad.net/bzr.webdav [13:48] grutte_pier: yes I am [13:48] grutte_pier: using LDAP instead of .htpasswd file [13:48] you want people to be able to push over http as well? [13:49] james_w: yes, I'd like everything possible available over http [13:49] grutte_pier: access the branch by http://user@host/... [13:49] yeah, you need either webdav, or the smart server [13:53] LarstiQ: that gives an error as well: PathNotChild: Path 'http://host' is not a child of path 'http://user@host': user name mismatch [13:54] * LarstiQ blinks [13:55] maybe host is not allowed to be a www. adres? [14:00] grote_pier:) Do you have links where these "commit rights" access-issues are described? [14:00] grutte_pier: what version of bzr are you using, and can you pastebin the traceback for that? [14:02] cyberco: no links yet [14:02] LarstiQ: version 1.5... but I've been having the problems with all previous versions [14:03] LarstiQ: I'm not sure what a 'pastebin' means..... :( [14:03] grutte_pier: http://rafb.net/paste/ [14:06] LarstiQ: great facility ;) http://rafb.net/p/7cPcjb41.html [14:07] grutte_pier: there are tons of these pastebins around, rafb is just the one I can remember [14:09] hi, am am trying to use the api of bazaar and wanted to ask you guys how to get the permissions of a file in bzr. [14:15] Leonidas: I'm not sure what you mean. [14:15] Leonidas: do you mean, what are the unix permissions of a file in a historical revision? [14:16] LarstiQ: Now, when I have a revtree I can get a files contents via a StriongIO object. But I'd also like to get the special attributes like link, executable etc. [14:16] Leonidas: ah ok, right, those we do track. But everything other than executable we do not. [14:16] ping Jc2k [14:17] I think exacutable and link is the only thing I need to know anyway. [14:17] There is revtree.is_executable, but what about links? [14:19] robsta pong === mw|out is now known as mw [14:20] Leonidas: is there one specific file you are interested in, or do you need to handle all files? [14:20] hi Jc2k, i'm trying to reach bkor for 2 days now, to help out with the bzr/svn maintainter script workaround, but to no avail [14:21] Jc2k: any alternative? [14:21] LarstiQ: I just need it for one file at the moment (I the future I might better use a cache for this, but first I wanted to get it working). [14:21] LarstiQ: same story for test release 1.6 [14:22] Leonidas: well, there are iter_entries type apis for the latter. [14:29] Leonidas: revtree.kind(fileid) [14:29] grutte_pier: ok, back to your problem [14:30] LarstiQ: thanks, I'm trying but I am struggling a bit with IPython, it somehow chokes on exceptions. [14:31] Leonidas: you can %pdb in ipython for dropping you into a debugger when that happens, but can you provide some more info? [14:31] grutte_pier: https://bugs.edge.launchpad.net/bzr/+bug/245964 looks ort of similar [14:31] Launchpad bug 245964 in launchpad-bazaar "nosmart+http interacts badly with http redirects" [Critical,Fix released] [14:32] LarstiQ: well, it seems to be rather IPython related: http://paste.pocoo.org/show/82797/ [14:32] Leonidas: wuh [14:32] Leonidas: it barfs on getcwd()? [14:34] LarstiQ: oh, indeed. [14:34] grutte_pier: is there a redirect going on perhaps? [14:34] LarstiQ: yep, there is... this looks indeed very familiar [14:34] LarstiQ: I have deleted the directory it was in. Just fixed it by chdiring somewhere else. [14:35] Leonidas: ok :) [14:36] Mhh, that might explain my earlier troubles with it. Sometimes I delete branch folders from one of my numerous screen sessions. [14:41] LarstiQ: when taking another close look at my traceback, the remarks in bug 245964 make sense as well [14:41] Launchpad bug 245964 in launchpad-bazaar "nosmart+http interacts badly with http redirects" [Critical,Fix released] https://launchpad.net/bugs/245964 [14:42] LarstiQ: in the bug they speak of some comparison and indeed the error in my traceback, is that http://host/.bzr/smart is compared with http://user@host/ .... without the additional .bzr-path [14:43] LarstiQ: it makes sense that something is going wrong there, because they are simply different paths [14:44] LarstiQ:with nosmart+http the same problems happens with .bzr/smart replaced with .bzr/branch-format [14:45] grutte_pier: well, foo/.bzr/etc is a a child of foo/, our problem is that foo isn't foo. [14:45] grutte_pier: I'm not exactly sure why that arises. [14:45] grutte_pier: and I really need to go out and buy breakfast [14:45] * LarstiQ heads to the AH, oh no, aldi. [14:46] grutte_pier: I'll get back to you on this. [15:16] hey :) [15:16] every time I push via FTP - all .bzr files which are altered get the permissions 0600 ... [15:16] but this blocks access from the HTTP-server [15:16] so I can't pull via http any more [15:17] is it possible to make bzr change the default permissions to 0644 ? [15:50] james_w, hi [15:52] hey beuno [15:52] how's it going? [15:52] good thanks, you? [15:53] pretty good too [15:54] I'll be in London again next week, if you want to/can drop by :) [15:54] ah cool [15:54] next week isn't great for me though, sorry [15:55] no worries, next time (which, for now, seems to be october) [15:55] cool [15:55] you're travelling a lot? [15:56] heh, yeah, seems like it's going to be like this for quite a while [15:57] beuno: how so? [15:57] LarstiQ, hi. Well, I have 3 trips already planned from here to december, and a few "maybes" [15:58] I see. [15:59] everytime I start to complain about 14 hour plane trips, I remember australian folks do 24+ :) [16:12] Necoro: I don't think we chmod over ftp, but I could be wrong [16:13] if we *do* then setting the permissions on the '.bzr/' directory itself should cause us to set permissions on files correctly. [16:13] But my guess is that it is an ftp server thing, and something outside of bzr's control [16:14] beuno: I'm a bit surprised their bringing you to London so often, I suppose it depends if you enjoy it or not whether I should be congratulating you or expressing sympathy :) [16:14] jam: on my local branch the permissions are correct [16:14] so - perhaps it is really a server thing [16:14] Necoro: TODO: jam 20051215 ftp as a protocol seems to support chmod, but [16:14] ftplib does not [16:15] Necoro: but I also see a "SITE CHMOD" command [16:15] So it seems that the server *might* support chmod [16:15] jam, heheh, well, I *do* enjoy the sprints. Actual plane flights, not as much, but I'm getting used to them. I guess my work needs more high bandwidth interaction [16:15] Necoro: we generally set permissions based on the .bzr/ directory [16:15] beuno: just hack on the plane, right? [16:15] lifeless does that [16:15] you can get some interesting work out of him before/after sprints [16:16] Necoro: so if the .bzr/ directory is set 700 we will create files as 600 [16:16] if it is 777 we should create files as 666 [16:16] yeah, I really have to start upgrading to business class, where they have plugs for laptops [16:16] Necoro: that, of course, requires the ftp server to support both stat and chmod [16:17] Necoro: hm... I see a possible problem. It seems that our code doesn't detect ftp permissions correctly, but it does try to *set* them. :( [16:17] vila: ping, just curious if you know about the SITE CHMOD work [16:30] jam, all debs uploaded, moving on to docs tweaks [16:30] /cheer [16:39]