[00:03] jam: if there's better practice for wrapping a bzr command in a plugin I'd love to read about it. [00:05] how easy/sane is it to call bzr's api directly from a python app if you just care about really simple add/commit stuff? [00:06] Ng, pretty easy [00:07] Ng, http://bazaar-vcs.org/Integrating_with_Bazaar [00:07] Ng: bzrlib is supposed to be usable that way [00:08] nice :) [00:08] * beuno waves at LarstiQ [00:08] hey beuno :) [00:50] hey, the new progress bar in the bzr in today's ppa is pretty nice. [00:57] jml: yup! [00:58] jml: it not cleaning up properly is a bit suboptimal, but even then I rather like it. [00:58] yeah. [00:58] it actually does make bzr feel faster. :) [00:59] although, who knows, maybe there were performance improvements in the update as well :) [01:00] nafaik, I think you're right about it subjectively feeling faster [01:04] jml: well, you could have used "*args, **kwargs" and then pulled out only the ones you actually cared about [01:05] jam: yeah. [01:05] jam: I just cargo culted from the way loom handled "switch", which was probably not the wisest thing [01:05] Quick question: Is there any plan to add "--format" to bzr branch? [01:05] So I could do: bzr branch --format=1.9 sftp://.... [01:06] I've noticed that I'm doing a "branch" and then "upgrade" a lot. [01:07] Since we've been keeping our bzr server using the rich-root-pack format. [01:07] And I like having 1.9-rich-root on my workstation. [01:07] enigma: I don't know of any. [01:07] hmm, what about for initialising a repo from a python app - is there a better way than bzrlib::builtins::cmd_init? [01:08] enigma: I only know of bzr init; bzr pull to accomplish that [01:08] enigma: interesting idea though [01:08] enigma: but it sounds like a good idea. if you start filing a bug at http://bugs.edge.launchpad.net/bzr/+filebug, Launchpad might show you a bug that's already filed. [01:08] Ng: umm... [01:09] Ng: I think I've written public code that does this somewhere. [01:09] Oh...I guess I didn't think about using a repo....thanks for the tip. [01:10] Ng: https://code.edge.launchpad.net/~jml/+junk/bzr-establish -- it probably either calls cmd_init or copies from it. [01:10] So, I would do "bzr init-repo --1.9-rich-root" and then any branches I pull into that repo would automatically use 1.9-rich-root? [01:11] They would automatically use that repo format, yes. [01:11] I think they'd default to the upstream branch format, though. [01:11] jml: thanks :) [01:11] So you'd probably get to sift through a bunch of 'unnamed'. [01:12] Ng: I'd probably use bzrdir.create_repository(shared=True) [01:12] Ng: like cmd_init_repo does as well [01:13] I wish looms had better toolchain support [01:13] fullermd: "unnamed"? [01:13] fullermd: I didn't realize I could run a different branch format than the repo format. [01:14] Well, you'd have to, since the repo format can't store a branch :) [01:14] What does the repo store? Just revisions? [01:14] 1.6 introduced a new branch format; I think --1.9-* uses that, instead of branch6. [01:15] Yah. [01:15] OK. [01:15] fullermd: Thanks for the help. [01:15] There are 3.5 formats involved; the repo, the branch, and the WT, plus a half in the container format. They can be largely varied independently. [01:15] The various names like --1.9-rich-root etc are aliases for {repo X, branch Y, WT Z} [01:16] Oh...if I'm running the 1.9 branch format on an client and I push back to a 1.0 branch format, is that going to cause problems? [01:16] I don't think so. [01:16] Generally branch formats don't introduce hitches like that; it's mostly repo formats. [01:16] (like the rich-root vs. poor-root hump) [01:17] Between branch5 and branch6 there were some, since branch6 supports tags and b5 didn't. But the push would still work; it just wouldn't copy any tags. [01:17] fullermd: OK. [01:17] fullermd: What's the "WT"? [01:17] I don't _think_ the 1.6 branch format made any changes that will hiccup like that. But I don't really know; I haven't looked much at it. [01:17] Working tree. [01:17] Oh, OK. [01:56] are there already Python libs for parsing diffs? [04:44] hi folks === asac_ is now known as asac [10:35] Hey guys, I'm looking for the current data of the performance testing history in bzr [10:35] http://bazaar-vcs.org/PerformanceHistory [10:35] * dwt indicates that I might find it at [10:35] http://codespeak.net/bzr/perf_history/summary_bzr.dev.html [10:35] but unfortunately thats not the case. :/ [10:35] anymore [10:35] could somebody please advise? === beaumonta is now known as abeaumont [15:32] Why doesn't "bzr branch" remember the source as a saved push location, and can I make it do that? [15:34] maxb: you can bzr push :parent [15:34] aha [15:34] thanks [15:34] maxb: after that, it will remember the push location [15:35] maxb: on why it doesn't do that, in the model of standalone branches, theoretically it is very unlikely you will push to the same place you branch from [15:35] in practice, I don't know if that is a good decision, although frequently it is true for me [16:02] jelmer: hey, i don't suppose you come up with any sort of work around for that bzr corruption bug that was reported a little while ago? (bzr-svn) [16:03] rocky, no sorry, I haven't had time to look at that yet [16:03] maxb: any time you want bzr to remember a push/pull/merge location just remember to use --remember when you do it [16:04] i can imagine time is limited :) [16:04] rocky, working on other bzr-svn bugs atm [16:04] as it is for all of us [16:05] i've been working on ClueReleaseManager (pypi server) lately ... to go along with ClueBzrServer (bzr-over-http) and ClueMapper (trac project admin tool) [16:05] which reminds me... [16:05] jelmer: has trac-bzr got any love lately? [16:06] rocky, not much news, Alexander was working on a minor bug fix [16:07] jelmer: what's the last known versions of trac and bzr it works with? [16:11] jelmer: the dulwich thing we were talking about; didnt need an api change but there was a buglet that i fixed. === abadger19991 is now known as abadger1999 [18:23] hi all [18:24] guys, does anyone of you use bzr through sftp? [18:24] a branch that a few devs use? [18:25] I ave run into some problems with permissions. specifically, the whole branch is owned by root:bzr and all the devs are in the bzr group [18:26] but if a dev creates a new file, it gets owned by devuser:bzr and the perms are set so that the group hasn't got write access to it [18:26] which causes obvious problems here ;) [18:26] so my question is: how do you overcome such problems? bzr --serve? some nifty sticky perms with proper umasks for all the devs? [18:26] any hints? [18:37] I use umasks and setgid on my branch [18:37] kumi: I found this helpful bugger: https://lists.ubuntu.com/archives/bazaar/2008q1/038455.html [18:37] kumi: are you using sftp or bzr+ssh? [18:38] Oh I see, you're using sftp. We use bzr+ssh [18:39] right, that makes it clear [18:39] thanks [18:39] I'll switch to bzr+ssh [18:42] Are you on linux? you might be able to continue using sftp if you use ACL [18:42] yeah, on linux [18:42] ACL? ACL for what? [18:42] setfacl/getfacl [18:42] ah, rigt [18:42] I'll investigate into that, thanks [18:42] rysiek|pl: openssh had a problem with not respecting setgid bits in sftp, that got fixed in http://www.openssh.com/txt/release-5.1 [18:43] rysiek|pl: in the meantime, I do like kumi and use acls [18:43] LarstiQ: thanks [18:45] LarstiQ: don't acls work only on XFS? [18:47] rysiek|pl: I use them on ext3, I'm sure they work on reiser too. [18:47] right, thanks [18:47] and probably ext4 and btrfs [18:47] I think you have to mount the fs with the acl option though [18:48] ok [19:51] does bzr-svn support making svn tags? [19:59] mxpxpod: yes [19:59] jelmer: just use bzr tag, right? [20:00] mxpxpod: yep [20:00] jelmer: thanks [20:01] jelmer: how does it know where to store the svn copy it makes? [20:02] mxpxpod: if you have a standard svn layout (trunk, branches, tags), it will create a new directory in tags/ [20:02] jelmer: even if I've just pulled directly from trunk, right? [20:03] mxpxpod: yes [20:03] * jelmer back in ~15 minutes [20:03] jelmer: thanks a ton, that's great [20:12] jelmer: if I do a nasty thing like svn mv foo/trunk foo/branches/old-trunk; svn mv foo/branches/new-trunk foo/trunk, how much will it break bzr-svn? [20:14] luks: depends on what you mean by how much [20:14] luks: bzr-svn will most likely give you a divergedbranches error (unless new-trunk is a direct ancestor of old-trunk) [20:15] jelmer: I mean if do a clean branch from foo/trunk, will it stop on the move, follow the move, follow the move but using a giant delete + add? [20:16] luks: it will follow the move [20:16] great! [20:16] thanks [20:16] luks: no delete + add involved [20:16] I wasn't sure if it works cross-branch as well [20:17] it only works if the old location is recognized as a branch location [21:03] hmmm [21:03] I jost got a crazy idea [21:03] would it be possible to version a single dir [21:03] within two branches? [21:03] using mount --bind? [21:04] * rysiek|pl 's gotta test it, although it probably will fail spectacularly [21:16] Need help setting up server repo with trees [21:20] chaynesin: ok [21:22] chaynesin: what's the problem you're trying to solve that the docs don't clearly address? [21:24] chaynesin: (re: PMed question) "no trees" = "no working copy" [21:25] chaynesin: oh wait, *without* using no tree [21:25] hmm [21:26] chaynesin: by default, pushing and committing to the server tree will not update the server's working copy [21:26] chaynesin: regardless of whether the server has tree or no tree set [21:28] is there any way to maintain a server repos with working files that updates automatically with push or commit or anything else that can be done via ftp? [21:28] chaynesin: yes, with a bzr plugin [21:29] so bzr has to be installed with that plugin on the server? what's the pluging? [21:29] chaynesin: https://launchpad.net/bzr-push-and-update/ [21:29] chaynesin: not sure how well it will work with sftp, though [21:30] chaynesin: ssh is generally a better solution for server repo access [21:30] I have a python script that runs in a screen session, watching certain changes with inotify [21:30] and running a bash script that updates the tree [21:30] rysiek|pl: why don't you just run the plugin i linked to? [21:31] davidstrauss: I didn't know of that plugin when I needed that [21:31] davidstrauss: besides, this plugin (as a bzr plugin) will *not* work with ftp/sftp [21:31] so the plugin is clientside but requires ssh access. i think that will work for me. [21:31] rysiek|pl: neither will your approach work with ftp/sftp [21:32] chaynesin, or bzr-upload [21:32] davidstrauss: oh, but it does :) [21:32] which will work with ftp [21:32] The bzr-push-and-update plugin simply makes bzr automatically run "ssh foo@bar bzr update /path/to/branch" after pushing, so you need bzr installed remotely. [21:32] but it won't keep a repository on the remote side [21:32] just the working tree [21:33] davidstrauss: it just sits in a screen session monitoring the .bzr directory for changes that occur upon commits, pushes, merges, etc, and runs the bash script [21:33] anywhoo, just my $.02 [21:33] is it ok for me to send a merge-directive to the list without a bundle (just a public branch location)? [21:33] amanica_, yeap [21:33] amanica_: should be fine [21:33] thanx [21:33] amanica_, but sending in the actual patch makes it a lot easier to review [21:33] the bundle is 1.1MB [21:33] is bzr-upload another pluggin that runs on the client? [21:34] chaynesin, yes [21:34] Heheh. I think someone sent a bundle that large a while ago; I don't remember what the reaction was. [21:34] amanica_, I've sent bigger ones [21:34] amanica_: Just out of curiosity, what's your patch about? How'd it get that large? :D [21:34] chaynesin: from what I understand, there is no way to have a "server-side" bzr plugins, unless you are using bzr --serve and bzr:// [21:34] SVGs and PNGs :) [21:34] :) last time I did that it got stuch so I had to zip it [21:35] rysiek|pl: bzr+ssh uses server-side bzr binaries and plugsin [21:35] davidstrauss: yeah, sorry for the omittance [21:36] how do bzr-upload and bzr-push-and-update different, just in the command they ask via ssh the server bzr to run? [21:37] chaynesin: bzr-upload is not designed to work in tandem with a server-side repository+tree [21:37] right, it just uploads the working tree [21:37] bzr-upload is designed to publish the working tree [21:37] and keeps a reference of what you uploaded last [21:37] so iy just uploads the changed files [21:37] s/iy/it [21:37] it's mostly targeted at web development [21:38] looks like bzr-push-and-update is what I want, so I have to install bzr on the server, but can that be done w/o root? [21:39] chaynesin: yes, but you'll have to make sure the bzr binary is in PATH or manually specified in the client commands [21:43] thanks a lot, i guess that's it for now. [21:44] :( without the bundle it it still 994K so I'm considering it with --no-patch as well. (I'll attach useful diffs for reviewing) [21:46] Peng_ sorry I only saw your question now. it removes all the trailing white space from the code (about 3000 lines) [21:46] (and yes, martin requested it) [21:46] (aka poolie) [21:48] beuno: do you think I can send it with --no-bundle and --no-patch ? or do you think I should just send the big file? [21:49] amanica_: Ah, that. Cool. :) [21:51] hi i've fucked up and commited an empty revision. how do i check out a previous one? [21:52] beuno: it compresses to 285K, so maybe I can attach that also... [21:53] sjokkis do you want to uncommit it? [21:58] i guess so [21:58] oh right, that's a command [21:58] gotcha [22:13] hi [22:13] is there an equivalent of svn cp? [22:14] sohail: No [22:15] Peng_, then how do I record that I copied a file [22:18] sohail: You can't. [22:19] sohail: Bzr's nifty rename support comes at the price of making copies more difficult, and nobody's done the work yet. [22:21] Peng_, so I use double the space... [22:22] sohail: I guess so. [22:30] Peng_, in a way I guess it is good... It made me do some overdue refactoring :-) [22:31] Peng_: I don't think the rename support makes copies more difficult [22:32] Peng_: it's just that the developers seem to not want to implement copy support that works worse (in terms of merge) than rename support [23:34] jelmer: around? [23:35] jelmer: im adding SSH support to dulwich (should be easy..) but i really should change the API here.. [23:59] How can I get my blog added to Bazaar Planet? [23:59] I mean Planet Bazaar.