=== BasicHatesWin32 is now known as BasicOSX === kiko is now known as kiko-afk [00:45] GPHemsley: OS X 10.4 installer? [01:03] anyone here use trac-bzr and been noticing some heavy memory leaks? [01:18] is there a way to do automatic paging of bzr commands? [01:18] or do i need to be less lazy about passing it to | less [02:44] lifeless: found your umbrella [03:13] jelmer: need any clarification on 277369? Just FYI you can catch me on IRC most of the time :) [04:28] jelmer: any ideas on how to make progress on Bug #276219 [04:28] Launchpad bug 276219 in bzr-svn "Segmentation fault in the calling of subversion libraries." [Undecided,New] https://launchpad.net/bugs/276219 [07:26] find_branches should be a generator. [07:29] yield jml [07:30] never. [07:33] also, it's slow and cpu intensive [08:01] * jml hacks on a plugin to switch from tree-and-branch repos to treeless repo and lightweight checkouts [08:06] chandlerc_[m]: 8 hours later, but if you still need it :) http://bzr.oxygene.sk/bzrbrowse.cgi/bzr-plugins/pager [09:34] * jml is done [09:52] hmm. [09:52] cbranch seems to be taking an order of magnitude longer than branch; co --lightweight [10:30] for some reason, I am running 'bzr check' on a large repository. [11:35] * jml learns cbranch [11:35] ... and discovers bzr cbranch --lightweight --hardlink [11:36] man, I'm going to be making branches *all the time* [12:01] * AfC just updated a Subversion project that decided it was on [svn] revision 701629. [12:01] 700,000 ? [12:08] kde? [12:09] No. A small Java build tool (ish) called Ivy. [12:10] Oh my god. The repository root is https://svn.apache.org/repos/asf , which seems to mean that bloody EVERYTHING done under the Apache umbrella is in a single Subversion repo? Gadzooks! [12:11] I've just finished a draft of a plugin that does 'bzr new-project foo trunk' that creates a shared repo in foo and a branch called trunk in it [12:11] it also does treeless repos for those crazies. [12:12] yay [12:15] lp:~jml/+junk/bzr-establish if you are interested — very rough atm. [12:15] no warranty express or implied, all rights reserved etc etc. [12:17] hey jml [12:17] james_w: hi [12:18] look like you're having a productive weekend [12:19] james_w: not productive enough :) [12:19] james_w: but still kind of fun. [12:19] s/kind of// [12:29] AfC: Sure; it's easier to manage the universe if it's all in one place, right? :p [12:31] * AfC really hates the Apache community's mindset, but that's nothing new. [13:16] Can I easily search the history for a deletion of a file? [13:24] Not directly. [13:24] Closest thing would be to dig through log -v 'till you see it disappear. [13:29] Weird [15:38] When I have a Inventory and bind that to Tree._inventory, how do I add files to it? [15:38] I probably can add InventoryFile (& friends) to it, but I don't know how to add the contents to the InventoryFile [15:42] I'm not sure whether using TreeBuilder couldn't be easier even. [18:08] i've pushed a local repository to a remote machine, but the rights then doesn't permit anybody except me to write in it [18:08] is there anyway, instead of changin with chmod, the rights for pushed repo? [18:09] nefertum: you want to set the repo or its container dirs to have the right group (chgrp) and possibly chmod g+s (sticky group bit) to have subdirs/subfiles inherit the right group owner [18:09] yes, that's [18:09] so i've started a main branch, and pushed in a remote machine [18:09] i'd like other developers to be able to push their commits [18:10] i can change rights by hand but it's not very elegant [18:10] smart [18:12] you only have to change them once [18:12] you could do so before pushing in the first place, too [18:12] you have to set the right group ownership [18:25] Peaker: but i have to do that for every branches i publish [18:25] nefertum: or to a single containing directory above them all [18:26] but when you push another branch that directory doesn't have the parent rights [18:26] it does, if the parent had g+s, I think [18:26] mmm [18:27] Peaker: how I set sticky group bit? [18:27] nefertum: chmod g+s [18:27] mmm [18:27] thanks Peaker [18:58] hello, is it possible to create a working tree on a remote host, pulling it from a local branch ? [20:43] bzr branch /home/tacone/tmp/my-repo sftp://tacone@localhost/home/tacone/mybranch creates an empty directory with .bzr in it, but no other files. further pull/merge attempts in that dir will fail. am I missing something ? [20:43] Why would future pull attempts fail? [20:43] (obviously merge attempts would fail, since merge needs a WT, but that's another matter) [20:44] If you're in a position to merge into it (or for that matter, to pull into it) you can create the WT as needed. [20:44] merge will fail with a error message (says checkout dir doesn't exists) [20:45] pull doesn't fail. works, but create no file [20:45] Is there any way to get a Free bzr? [20:45] Well, that's all expected, since you don't have a WT there. You can create one with checkout if you want one. [20:45] luke-jr_, what do you mean by "free"? [20:45] I'll email you a free bzr for $29.95... [20:45] beuno: free as in speech [20:46] luke-jr_, it *is* free [20:46] luke-jr_: bzr is part of GNU [20:46] it appears bzr depends on 'cElementTree' [20:46] which is non-Free [20:46] fullermd: isn't the branch command supposed create a working tree ? [20:47] luke-jr_, I don't think it depends [20:47] Non-Free? [20:47] maybe, optionally, for perfomance [20:47] beuno: it does on hardy [20:47] Depends: libc6 (>= 2.1.3), python (>= 2.4), python (>> 2.5) | python-celementtree, python (<< 2.6), python-central (>= 0.6.1) [20:47] beuno: even the non-'c' version is non-Free IIRC [20:47] oh well. optionally, right. [20:48] :) [20:48] It's built in to python 2.5. Only need it separately for 2.4. [20:48] fullermd: Python 2.5 is non-Free then, or it was relicensed? [20:48] fullermd: isn't the branch command supposed to create a working tree ? [20:49] I'm pretty sure bzr wouldn't be part of the gnu toolchain if it wasn't completely free [20:49] Er. The cElementTree license is isomorphic to a 3-clause BSD license. [20:49] That's less involved and more "Free" (if you wish to attach such a mystic meaning to the word) than Python itself. [20:50] fullermd: the cElementTree license prohibits commercial use [20:50] or rather, prohibits sale [20:51] ok, I just think I'll open a bug for that. [20:51] Oh that's the elementtree license I was looking at. [20:52] The PKG-INFO file in the cElementTree dist says License: Python (MIT style) [20:52] Gentoo says it's the same license [21:03] the latest ElementTree download has the no-fee license [21:03] but also says Python in the PKG-INFO file [21:03] :/ [21:07] What's the latest? [21:08] 1.2.7 preview [21:09] http://svn.effbot.org/public/tags/elementtree-1.2.7-20070827-preview/README [21:09] the 1.3 subversion repo has it as well [21:09] Looks the same to me. [21:09] exactly [21:09] Permission to use, copy, modify, and distribute this software and its associated documentation for any purpose __and without fee__ is hereby granted... [21:10] I don't think that means what you think it means. [21:11] well, I am taking it literally [21:11] he is only granting permission "without fee" [21:11] for without fee* [21:11] By any reading I can readily imagine, it means the same thing as the similar words in the MIT license. [21:12] whatever he meant to say, he said the permission is granted for…without fee [21:12] "[...] for any purpose is hereby granted without fee" is linguistically identical, if perhaps clearer. [21:12] I'm not an English major nor lawyer, but that seems to have a different meaning [21:13] I think you're misreading it. It would be trivial to settle with a quick email. [21:16] * luke-jr_ emails. [21:17] If the "without fee" were a provision binding on the user, it would be put in the section after "provided that". [21:17] now I've hit a larger, unrelated problem: xv appears to have the same issue, but not ambiguous [21:17] Yeah, xv is actually shareware. [21:17] :/ [21:18] open source shareware, I presume? [21:18] * luke-jr_ ponders if he's even willing to make *that* compromise [21:18] working OpenGL will make xv useless anyway, I think [21:19] The README requires prior consent for distribution of modified versions. [21:20] I wonder from time to time if I might replace xv in my usage, but the darn thing just keeps working, and I haven't seen a good alternative anyway. [21:20] OpenGL doesn't replace it? [21:21] OpenGL is an API, not a program... [21:22] xv is a program? [21:22] OK, maybe we're talking about different xv's :p [21:22] apparently! [21:22] I don't even care about this one [21:22] haha, oops [21:22] I'm talking about xv the image viewer, which has been standard issue for like 15 or 20 years. [21:23] I was talking about the 'xv' X11 extension, and confusing it with the viewer [21:23] * luke-jr_ wonders what is depending on the xv app [21:23] I have no idea what would or even could. You mean bzr is depending on it? [21:23] nope [21:23] * fullermd is all confuzzled now. [21:23] sorry, this is unrelated to bzr now [21:24] I'm just cleaning out all non-Free cruft from my desktop [21:24] Anyway, Xv works well with my video card. OpenGL, I seriously doubt near as well. [21:24] Gentoo just got ACCEPT_LICENSE so I can easily weed them out [21:25] Though I wouldn't think libXv had a license any different than any other component of X... [21:29] actually, X.org is a complete mishmosh of licenses supposedly [21:29] I've had to approve about 10 different ones so far [21:35] hah, found out that ElementTree's author did not coin that phrase [21:36] so he has no say as to its real meaning anyhow [21:36] that came fron font-adobe-75dpi [21:37] dev-python/imaging depended on xv btw [21:48] done: https://bugs.launchpad.net/bzr/+bug/278303 [21:48] Launchpad bug 278303 in bzr "bzr can't create a branch via sftp" [Undecided,New] [21:49] That's not really a bug... [21:49] branch creates a new branch, which is what it did. [21:50] You can't work with a WT remotely. [21:54] I didn't know. [21:54] Well, that's what we have IRC here for :) [21:54] yes but you got somewhat distracted before, didn't you ;-) [21:55] A case could theoretically be made that the lack of remote WT support is bug-ish, but it'd be a hard row to hoe. [21:55] Well, that's ALSO what IRC is for :p [21:56] do you know any good bidirectional sync over ftp which doesn't require anything installed on the remote end ? [21:56] Over _FTP_? I have no idea. I spend a half hour each morning praying that FTP is really dead this time... [21:56] tacone: FTP is a security hole [21:56] sftp [21:56] pardon [21:56] I mean, wget or any of that family of stuff can sync one way or the other of course. [21:57] tacone: Subversion ☺ [21:57] doesn't need to be versioned anyway. [21:57] I dunno if anybody's built anything in particular for SFTP like that. Most of the time if you have sftp, you have ssh, so you can just use rsync or something (of course that requires something on the server side) [21:58] rsync is uni-directional [21:58] unison requires also installation on the remote end. [21:58] Well, you can't have "bi-directional" without versioning. You can only have alternating uni-directional. [21:58] right. [22:16] * fullermd is being made highly grumpy by this merge :( === Verterok is now known as Verterok|out