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