jml | jam: if there's better practice for wrapping a bzr command in a plugin I'd love to read about it. | 00:03 |
---|---|---|
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:05 |
beuno | Ng, pretty easy | 00:06 |
beuno | Ng, http://bazaar-vcs.org/Integrating_with_Bazaar | 00:07 |
LarstiQ | Ng: bzrlib is supposed to be usable that way | 00:07 |
Ng | nice :) | 00:08 |
* beuno waves at LarstiQ | 00:08 | |
LarstiQ | hey beuno :) | 00:08 |
jml | hey, the new progress bar in the bzr in today's ppa is pretty nice. | 00:50 |
LarstiQ | jml: yup! | 00:57 |
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:58 |
jml | although, who knows, maybe there were performance improvements in the update as well :) | 00:59 |
LarstiQ | nafaik, I think you're right about it subjectively feeling faster | 01:00 |
jam | jml: well, you could have used "*args, **kwargs" and then pulled out only the ones you actually cared about | 01:04 |
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:05 |
enigma | I've noticed that I'm doing a "branch" and then "upgrade" a lot. | 01:06 |
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:07 |
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:08 |
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:09 |
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:10 |
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:11 |
LarstiQ | Ng: I'd probably use bzrdir.create_repository(shared=True) | 01:12 |
LarstiQ | Ng: like cmd_init_repo does as well | 01:12 |
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:13 |
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:14 |
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:15 |
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:16 |
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:17 |
jml | are there already Python libs for parsing diffs? | 01:56 |
pygi | hi folks | 04:44 |
=== asac_ is now known as asac | ||
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? | 10:35 |
=== beaumonta is now known as abeaumont | ||
maxb | Why doesn't "bzr branch" remember the source as a saved push location, and can I make it do that? | 15:32 |
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:34 |
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 | 15:35 |
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:02 |
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:03 |
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:04 |
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:05 |
jelmer | rocky, not much news, Alexander was working on a minor bug fix | 16:06 |
rocky | jelmer: what's the last known versions of trac and bzr it works with? | 16:07 |
Jc2k | jelmer: the dulwich thing we were talking about; didnt need an api change but there was a buglet that i fixed. | 16:11 |
=== abadger19991 is now known as abadger1999 | ||
rysiek|pl | hi all | 18:23 |
rysiek|pl | guys, does anyone of you use bzr through sftp? | 18:24 |
rysiek|pl | a branch that a few devs use? | 18:24 |
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:25 |
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:26 |
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:37 |
kumi | Oh I see, you're using sftp. We use bzr+ssh | 18:38 |
rysiek|pl | right, that makes it clear | 18:39 |
rysiek|pl | thanks | 18:39 |
rysiek|pl | I'll switch to bzr+ssh | 18:39 |
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:42 |
LarstiQ | rysiek|pl: in the meantime, I do like kumi and use acls | 18:43 |
rysiek|pl | LarstiQ: thanks | 18:43 |
rysiek|pl | LarstiQ: don't acls work only on XFS? | 18:45 |
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:47 |
rysiek|pl | ok | 18:48 |
mxpxpod | does bzr-svn support making svn tags? | 19:51 |
jelmer | mxpxpod: yes | 19:59 |
mxpxpod | jelmer: just use bzr tag, right? | 19:59 |
jelmer | mxpxpod: yep | 20:00 |
mxpxpod | jelmer: thanks | 20:00 |
mxpxpod | jelmer: how does it know where to store the svn copy it makes? | 20:01 |
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:02 |
jelmer | mxpxpod: yes | 20:03 |
* jelmer back in ~15 minutes | 20:03 | |
mxpxpod | jelmer: thanks a ton, that's great | 20:03 |
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:12 |
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:14 |
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:15 |
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:16 |
jelmer | it only works if the old location is recognized as a branch location | 20:17 |
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:03 |
* rysiek|pl 's gotta test it, although it probably will fail spectacularly | 21:04 | |
chaynesin | Need help setting up server repo with trees | 21:16 |
davidstrauss | chaynesin: ok | 21:20 |
davidstrauss | chaynesin: what's the problem you're trying to solve that the docs don't clearly address? | 21:22 |
davidstrauss | chaynesin: (re: PMed question) "no trees" = "no working copy" | 21:24 |
davidstrauss | chaynesin: oh wait, *without* using no tree | 21:25 |
davidstrauss | hmm | 21:25 |
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:26 |
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:28 |
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:29 |
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:30 |
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:31 |
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:32 |
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:33 |
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:34 |
davidstrauss | rysiek|pl: bzr+ssh uses server-side bzr binaries and plugsin | 21:35 |
rysiek|pl | davidstrauss: yeah, sorry for the omittance | 21:35 |
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:36 |
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:37 |
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:38 |
davidstrauss | chaynesin: yes, but you'll have to make sure the bzr binary is in PATH or manually specified in the client commands | 21:39 |
chaynesin | thanks a lot, i guess that's it for now. | 21:43 |
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:44 |
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:46 |
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:48 |
Peng_ | amanica_: Ah, that. Cool. :) | 21:49 |
sjokkis | hi i've fucked up and commited an empty revision. how do i check out a previous one? | 21:51 |
amanica_ | beuno: it compresses to 285K, so maybe I can attach that also... | 21:52 |
amanica_ | sjokkis do you want to uncommit it? | 21:53 |
sjokkis | i guess so | 21:58 |
sjokkis | oh right, that's a command | 21:58 |
sjokkis | gotcha | 21:58 |
sohail | hi | 22:13 |
sohail | is there an equivalent of svn cp? | 22:13 |
Peng_ | sohail: No | 22:14 |
sohail | Peng_, then how do I record that I copied a file | 22:15 |
Peng_ | sohail: You can't. | 22:18 |
Peng_ | sohail: Bzr's nifty rename support comes at the price of making copies more difficult, and nobody's done the work yet. | 22:19 |
sohail | Peng_, so I use double the space... | 22:21 |
Peng_ | sohail: I guess so. | 22:22 |
sohail | Peng_, in a way I guess it is good... It made me do some overdue refactoring :-) | 22:30 |
jelmer | Peng_: I don't think the rename support makes copies more difficult | 22:31 |
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 | 22:32 |
Jc2k | jelmer: around? | 23:34 |
Jc2k | jelmer: im adding SSH support to dulwich (should be easy..) but i really should change the API here.. | 23:35 |
davidstrauss | How can I get my blog added to Bazaar Planet? | 23:59 |
davidstrauss | I mean Planet Bazaar. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!