| igc | emmajane: ping | 00:08 |
|---|---|---|
| KhaZ_ | Hello! I apologize if this is the wrong place to ask this, but does anyone here use the bzr-p4 plugin? I'm trying to understand just what it does but the documentation on it appears to be rather minimal. | 00:35 |
| lifeless | you can try bzr help p4 (if thats what the directory for the plugin is called) | 00:36 |
| lifeless | I don't know how complete it is | 00:36 |
| KhaZ_ | Ah, OK. I supopse I'll isntall it. Just trying to read more of it before I install it - not sure if it will solve my problems or not. | 00:36 |
| lifeless | but most foreign VCS plugins allow 'bzr pull' 'bzr branch' etc to Just Work with urls/locations in those systems | 00:37 |
| KhaZ_ | Ah, neat. Maybe that is something similar to what I want. Is bzr push normally facilitated as well, or is it usually up to the client to use the other VCS' tool for that? | 00:37 |
| lifeless | depends on how complete the plugin is :) | 00:37 |
| KhaZ_ | Ah, but it's not out of the qeustion then at least. | 00:38 |
| lifeless | but yes, certainly for bzr-svn and bzr-git the whole gamut of push/pull/branch/merge commands work | 00:38 |
| KhaZ_ | Swank. I will have to dabble with this. Perforce is getting on my nerves. | 00:38 |
| KhaZ_ | ALright, dumb question. How can I see what plugin directory bzr is scanning for? I'm running cygwin on vista, and I've tried $APPDATA/bazaar/2.0/plugins and ~/.bazaar/plugins, and yet bzr plugins doesn't return me any of my nifty plugins. Is there an easy way to get it to spit out the path it's looking up? | 01:16 |
| fullermd | Not directly, I don't think. But it should be a 'plugins/' subdir under the 'Bazaar configuration' dir that `bzr version` spits out, I think. | 01:18 |
| KhaZ_ | Genius, that works. Thanks fullermd. | 01:19 |
| KhaZ_ | Ah, right. I had reset my BZR_HOME in order to try and keep my linux/windows configurations the same. D'oh, should've checked the env. variables. :/ | 01:20 |
| fullermd | Maybe there should be an arg to 'plugins' to list the search path. | 01:20 |
| KhaZ_ | I was hoping --verbose would show it | 01:20 |
| KhaZ_ | fullermd: Might be a nice add. | 01:20 |
| fullermd | Nah, that just shows where the existing plugins are from. | 01:20 |
| jdub | i'm getting the following error after attempting to bzr co with http basic auth against loggerhead: | 01:20 |
| jdub | bzr: ERROR: exceptions.KeyError: 'user' | 01:20 |
| jdub | (interactive or provided in the url) | 01:21 |
| KhaZ_ | fullermd: Right. I guess my assumption was it woudl say, "Found the following plugins from scanning these paths [searchpath1,searchpath2,searchpath3]: plugin1 [plugin1path], etc." | 01:21 |
| KhaZ_ | Not that it matters, but that was where my intuition took me. | 01:21 |
| fullermd | It's a reasonable intuition. You should file a bug on it. | 01:24 |
| spiv | jdub: hmm, sounds crummy. pastebin a full traceback? | 01:26 |
| jdub | spiv: http://www.gnome.org/~jdub/2009/bzr-20091021002215-9259.crash | 01:27 |
| KhaZ_ | fullermd: Good idea. Done: https://bugs.launchpad.net/bzr/+bug/456834 | 01:31 |
| ubottu | Launchpad bug 456834 in bzr "Command "bzr plugins" - would be nice to output searchpaths somehow." [Undecided,New] | 01:31 |
| lifeless | jdub: is loggerhead doing the auth, or some front-end web server? | 01:47 |
| jdub | lifeless: front end | 01:48 |
| lifeless | how are you passing the user details to the backend then ? :) | 01:48 |
| jdub | lifeless: not sure i am; if anything, i don't want to | 01:49 |
| mwhudson | jdub: i'm suspicious of the bzr-svn in that traceback | 01:49 |
| jdub | mwhudson: you think bzr-svn on the client might be screwing with it? | 01:50 |
| mwhudson | it's possible | 01:50 |
| jdub | ah, you know, yes | 01:51 |
| jdub | it might be trying to use bzr svn on the http url? | 01:51 |
| jdub | jdub@sliver:/tmp$ bzr co bzr+http://whitlam.crikey.com.au/code/live/bzr: ERROR: Generic bzr smart protocol error: Invalid http response for http://whitlam.crikey.com.au/code/live/.bzr/smart: Unknown response code 403 | 01:51 |
| lifeless | I think you should: | 01:51 |
| lifeless | file a bug | 01:51 |
| lifeless | remove bzr-svn if you don't need it | 01:51 |
| lifeless | see if that helps | 01:51 |
| lifeless | there is a bug, thats for sure. | 01:51 |
| mwhudson | jdub: that seems like a more plausible problem in some ways | 01:51 |
| lifeless | jdub: note that bzr+http shouldn't be needed - http:// will probe for .smart anyway. | 01:52 |
| jdub | yeah | 01:52 |
| jdub | jdub@sliver:/tmp$ bzr co http://whitlam.crikey.com.au/code/live/ | 01:52 |
| jdub | bzr: ERROR: Transport error: Server refuses to fulfill the request (403 Forbidden) for http://whitlam.crikey.com.au/code/live/.bzr/branch-format | 01:52 |
| jdub | ^ without bzr-svn installed | 01:52 |
| jdub | ooh, what a lovely little mess :-) | 01:53 |
| lifeless | jdub: 403 sounds like you aren't passing POST to the backend, to me. | 01:53 |
| jdub | that interactive password request dudie did seem a little svn-riffic | 01:53 |
| jdub | lifeless: naw, looks like i'm not serving static files at all :_) | 02:01 |
| lifeless | jdub: yes but that doesn't matter | 02:03 |
| lifeless | jdub: there should be a 'smart' POST attempt in the log | 02:03 |
| lifeless | if that is passed through to loggerhead properly, bzr will talk to that, not to static files. | 02:03 |
| jdub | right | 02:05 |
| jdub | the smart post hits the frontend with a 403 | 02:05 |
| RenatoSilva | how to bzr pull --preview merge-directive.patch? | 02:06 |
| RenatoSilva | or bzr mssing it | 02:06 |
| jdub | lifeless: does the smart check attempt to auth before posting? | 02:18 |
| lifeless | jdub: auth is on-demand, when the server gives 401 | 02:19 |
| lifeless | RenatoSilva: I'm not sure missing works with merge diectives | 02:19 |
| lifeless | RenatoSilva: pull --preview should just work | 02:20 |
| jdub | lifeless: aaaaaaaahhhhhhhhh | 02:22 |
| jdub | lifeless: *lightbulb* | 02:22 |
| jdub | lifeless: i should not bar access to .bzr on this host :) | 02:22 |
| lifeless | you want .bzr/smart to work | 02:23 |
| lifeless | not the rest | 02:23 |
| lifeless | [or at least, you *shouldn't need* the rest] | 02:23 |
| jdub | right | 02:23 |
| lifeless | and you want it auth protected. | 02:23 |
| jdub | yeah | 02:25 |
| james_w | does loggerhead work as a smart server with no extra configuration? | 02:25 |
| jdub | lifeless: oh man... new issue | 02:25 |
| jdub | bzr: ERROR: Server sent an unexpected error: ('error', 'No repository present: "chroot-46030224:///"') | 02:25 |
| jdub | james_w: recent versions, yeah | 02:25 |
| lifeless | jdub: ah, shared repo ? | 02:25 |
| jdub | lifeless: yeah :| | 02:26 |
| lifeless | jdub: there is a bug, Peng will know more | 02:26 |
| james_w | that's neat | 02:26 |
| lifeless | basically it needs to make the chroot in the backend higher up. | 02:26 |
| lifeless | so I know what needs to be done, I haven't gone and looked at it | 02:26 |
| lifeless | jdub: look for Chroot in the loggerhead code, you can probably figure it out | 02:26 |
| lifeless | jdub: rather than branch.base, it will be branch.repository.bzrdir.root_transport, for the chroot root path | 02:27 |
| jdub | lifeless: looks like that might be a bzrlib thing | 02:28 |
| lifeless | jdub: nope | 02:28 |
| lifeless | smart server handles this fine ;) | 02:28 |
| jdub | there's no Chroot in loggerhead | 02:28 |
| lifeless | ugh | 02:28 |
| lifeless | look for smart then | 02:28 |
| jdub | can i /msg for a moment? | 02:29 |
| lifeless | of course | 02:30 |
| spiv | wsgi_app = wsgi.SmartWSGIApp(self.transport) | 02:30 |
| spiv | that's in loggerhead/apps/transport.py, line 85 | 02:31 |
| lifeless | so self.transport needs to be adjusted | 02:31 |
| lifeless | you'll need to find the actual root you want | 02:31 |
| lifeless | and probably need to pass in some adjuster - spiv knwos this much better than I :) | 02:31 |
| spiv | which in turn gets transport from make_app_for_config_and_path, which gets it from the config | 02:32 |
| spiv | Which apparently defaults to '.', unless you pass a command line arg? | 02:33 |
| spiv | I don't really know my way around the loggerhead codebase very well. | 02:34 |
| jdub | yeah | 02:34 |
| lifeless | spiv: yes, but you know the wsgi helpers in bzrlib | 02:34 |
| lifeless | spiv: you see the problem, right? | 02:34 |
| RenatoSilva | lifeless: pull --preview didn't work | 02:36 |
| spiv | lifeless: not really, it's calling the right wsgi helper, I would expect that so long as it feeds the right path to it is all good. | 02:36 |
| RenatoSilva | lifeless: iirc someone here noted that pull doesn't have --preview as expected | 02:38 |
| spiv | lifeless: but I don't know enough about how self.transport is created to know where loggerhead is going wrong | 02:38 |
| spiv | or where jdub's configuration of loggerhead is going wrong, perhaps? | 02:39 |
| jdub | spiv: i'm just passing it a path (to the repo) | 02:39 |
| jdub | spiv: then attempting to co the branch under it | 02:39 |
| jdub | loggerhead autoserves branches under a repo | 02:40 |
| lifeless | spiv: its the transport of the branch, not the repo | 02:41 |
| spiv | lifeless: oh, right, yes, I got that bit :) | 02:41 |
| lifeless | spiv: it needs to be shifted up to the repo; but requests at that path need to be shifted down to the branches relative path | 02:42 |
| spiv | lifeless: I don't know why; the code I've read suggests it shouldn't be | 02:42 |
| spiv | lifeless: i.e. the code I've seen so far looks like it is doing things correctly | 02:42 |
| lifeless | spiv: if you're not bogged down with critical stuff, I think this is actually well worth treating as high and digging into | 02:43 |
| jdub | spiv: 0.17 or beyond? | 02:43 |
| spiv | Hmm, the UserBranchesFromTransportRoot looks a bit suspicious | 02:43 |
| spiv | jdub: I'm reading the code in trunk | 02:43 |
| spiv | Not sure how that relates to version numbers ;) | 02:43 |
| spiv | lifeless: I'm certainly happy to dig for a while | 02:44 |
| spiv | lifeless: I just posted a patch for that "second push failed to complete" bug | 02:44 |
| jdub | thanks dudes :-) | 02:44 |
| lifeless | spiv: awesome; I saw it, but got distracted just as I hit the diff | 02:44 |
| lifeless | Lynne has the lurgy now too | 02:44 |
| spiv | Urgh, lucky Lynne :( | 02:45 |
| spiv | mary and I think we've been fighting off something this week, so far not so bad but not quite feeling 100% either. | 02:46 |
| spiv | Ah, found it I think. | 03:02 |
| lifeless | spiv: vitamin C! | 03:02 |
| thumper | can anyone with windows experience comment on https://bugs.launchpad.net/bugs/455636 to say where to put the ssh key that bzr will use? | 03:08 |
| ubottu | Launchpad bug 455636 in launchpad-code "r/o code download with lp: prefix asks for ssh key" [Undecided,Incomplete] | 03:08 |
| lifeless | thumper: there isn't a place AIUI | 03:11 |
| lifeless | thumper: you run a gui - pageant - and tell it to add the key | 03:12 |
| thumper | lifeless: hmm, that's about as much as I know too | 03:12 |
| SamB_XP | that really ought to be in the help file :-( | 03:12 |
| * igc lunch | 03:34 | |
| SpamapS | Hi.. in perforce if I see a change #, I can say 'p4 describe ######' and it shows me al the changes associated with that.. does bzr have something similar? Right now I have to find the previous revision and use bzr diff.. | 03:39 |
| spiv | jdub, lifeless: so I have a fix for your bug, but now I'm hitting https://bugs.edge.launchpad.net/bzr/+bug/348308 | 03:39 |
| ubottu | Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/348308) | 03:39 |
| jdub | spiv: boh! | 03:39 |
| spiv | jdub, lifeless: will keep poking after lunch, that bug was going to bubble to the top of my list sooner or later | 03:40 |
| fullermd | SpamapS: You don't have to find the previous revision, you can use '-c'. | 03:41 |
| SpamapS | fullermd: ahh thats what I get for only paying attention to the examples and not reading the whole manual. ;) | 03:41 |
| fullermd | SpamapS: (and technically you don't need it with -r either, -c is just less typing ;) | 03:42 |
| fullermd | SpamapS: "bzr diff -c$REV" == "bzr diff -rbefore:$REV..$REV" | 03:43 |
| lifeless | spiv: sweet | 03:51 |
| lifeless | spiv: that is the bug isn't it :) | 03:51 |
| mwhudson | oh _that_ bug! | 04:04 |
| SpamapS | fullermd: thank you.. :) | 04:05 |
| fullets | I've been using a workflow like: bzr init-repo repo; bzr branch svn-trunk bzr-trunk; bzr branch bzr-trunk bzr-feature; hack on bzr feature; cd bzr-trunk; bzr merge ../bzr-feature; bzr push | 04:20 |
| fullets | Trying to bzr diff -c a merge commit from a branch outside that repository causes bzr to crash. Are there any workarounds for this? | 04:20 |
| dash | huh. what version of bzr? | 04:21 |
| fullets | 2.0.1 from the jaunty ppa | 04:21 |
| dash | huh, dang. | 04:21 |
| dash | I've never seen that happen | 04:22 |
| lifeless | what crash | 04:22 |
| fullets | bzr: ERROR: bzrlib.errors.NoSuchRevision: CHKInventoryRepository(path) has no revision | 04:22 |
| lifeless | interesting | 04:24 |
| lifeless | can you try -r before:X..X PATH/TO/BRANCH | 04:24 |
| lifeless | as in 'bzr diff -r before ..... | 04:24 |
| fullets | Sorry, what should the X's be? The revision number of the merge commit? | 04:25 |
| fullets | If so, the same crash happens | 04:25 |
| lifeless | fullets: yes, exactly. | 04:26 |
| fullets | Also -r m..n that cross the merge commit give the same crash | 04:26 |
| lifeless | fullets: if you cd to that branhc | 04:26 |
| lifeless | and then run the command, does it work? | 04:26 |
| fullets | It crashes whether the branch, repo, or the repo's parent dir are my cwd | 04:27 |
| lifeless | does 'bzr log' work when the branch is your cwd | 04:29 |
| fullets | Yes, both displaying the whole log and the log for the merge commit work. Trying to show the merged revisions with --include-merges shows none of the merges | 04:31 |
| lifeless | log -n0 will do that | 04:33 |
| lifeless | I think you should file a bug | 04:33 |
| lifeless | if log works but diff -c doesn't, there is something very strange going on. | 04:33 |
| fullets | I shall file a bug once I finish putting steps to reproduce together :) | 04:35 |
| lifeless | fullets: please file the bug earlier | 04:42 |
| lifeless | fullets: as you may need our help to diagnose it, and bugs provide a place to track the conversation | 04:42 |
| fullets | Very good | 04:42 |
| thumper | how do I create a branch with the LCA of two other branches? | 04:53 |
| lifeless | thumper: cd two; bzr revision-info -r ancestor:one | 04:54 |
| lifeless | then bzr branch -r revid:.... one | 04:54 |
| fullets | lifeless: https://bugs.launchpad.net/bzr/+bug/456908 | 04:55 |
| lifeless | thanks | 04:55 |
| ubottu | Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/456908) | 04:55 |
| lifeless | bug 456908 | 04:55 |
| ubottu | Launchpad bug 456908 in bzr "Merge commits in branch of subversion repository crash on diffing" [Undecided,New] https://launchpad.net/bugs/456908 | 04:55 |
| thumper | lifeless: ta | 04:55 |
| === kirkland` is now known as kirkland | ||
| spiv | jdub: http://bzr.pastebin.com/m5e6d6205 | 06:17 |
| spiv | jdub: there's a couple of minor debug droppings in that (the print statement and the commented out pdb line), but that makes serve-branches work for me with a shared repo | 06:18 |
| spiv | jdub: I'm working on a proper fix for the bzr bug that works around | 06:18 |
| jdub | spiv: rocking -- thanks! :-) | 06:20 |
| lifeless | spiv: nice | 06:20 |
| jdub | spiv: beautiful :-) | 06:21 |
| jdub | spiv: what are the chances that will work with --allow-write? :-) | 06:22 |
| spiv | jdub: I don't see why it wouldn't :) | 06:24 |
| spiv | thumper: btw, https://answers.edge.launchpad.net/bzr/+questions?field.search_text=ssh+windows&field.sort=RELEVANCY&field.sort-empty-marker=1&field.actions.search=Search&field.language=en&field.language-empty-marker=1&field.status=OPEN&field.status=NEEDSINFO&field.status=ANSWERED&field.status=SOLVED&field.status-empty-marker=1 has some info about ssh and windows if you're prepared to dig a bit | 06:28 |
| === obstriege is now known as obst | ||
| jdub | spiv: it does, btw :-) | 06:33 |
| Peng_ | spiv: You rock! Thanks for working on this! :) | 06:37 |
| lifeless | james_w: is there a PPA with bzr builder in it? | 06:40 |
| Peng_ | mwhudson: ping | 07:16 |
| bialix | hello all | 07:37 |
| Peng_ | Hi. :) | 07:37 |
| spiv | Ah good, I have what seems to be a working fix for the bzr+http bug and a draft of a reasonable test. | 07:47 |
| * spiv heads to yoga class feeling satisfied | 07:48 | |
| Peng_ | spiv: I love you. :) | 07:48 |
| Kamping_Kaiser | sigh. dependancy hell for the win. | 08:46 |
| === weigon_ is now known as weigon | ||
| * igc dinner | 09:39 | |
| alex_morelli | hello all | 09:49 |
| alex_morelli | long time ago, I found a plugin for bzr that implemented a "make-log" command a la tla | 09:50 |
| alex_morelli | Now I can't find it anymore... anyone ever heard of it? | 09:51 |
| bob2 | what did make-log do? | 09:57 |
| alex_morelli | It created a log file, to which you appended what you were doing until commit | 10:00 |
| alex_morelli | and you couldn't commit without that log file | 10:00 |
| bob2 | what does it do different to 'touch x ; edit x ; bzr ci -F x' | 10:01 |
| alex_morelli | not much, but you can commit anyway this way | 10:02 |
| alex_morelli | and make-log sort of forced you to behave | 10:07 |
| Kamping_Kaiser | Is `bzr svn-import` supposed to work from a client checkout of an svn repo? | 10:14 |
| Peng_ | Kamping_Kaiser: Not sure. It's not hard to get the URL, though. | 10:15 |
| Kamping_Kaiser | I gen an error "bzr: ERROR: No Repository found at gns/builder-clean. For individual branches, use 'bzr branch'." when trying to run it against an svn checkout (I don't hae access to the svn repo) | 10:15 |
| Kamping_Kaiser | Peng_: ah, i'm supposed to run it on the url? | 10:15 |
| * Kamping_Kaiser tries | 10:16 | |
| Kamping_Kaiser | aaah. *yay* | 10:18 |
| Kamping_Kaiser | Peng_: thanks :) | 10:18 |
| Peng_ | Kamping_Kaiser: :) | 10:19 |
| Peng_ | Kamping_Kaiser: FYI, if you *did* have a copy of the repo locally, you could run it against the directory path too. | 10:19 |
| Peng_ | Probably. | 10:19 |
| Kamping_Kaiser | good to know, thanks. | 10:22 |
| james_w | lifeless: https://edge.launchpad.net/~dailydebs-team/+archive/bzr-builder | 10:28 |
| Kamping_Kaiser | perhaps a strange question: having vampired out of the svn repo, i have a 34mb .bzr directory, and the builder/ directory is empty. is there a non-obvious step involved in making the repository useful? | 10:32 |
| Peng_ | Kamping_Kaiser: svn-import doesn't create working trees by default. cd to a branch and run "bzr checkout". | 10:33 |
| Kamping_Kaiser | ah. | 10:33 |
| Kamping_Kaiser | Peng_: would it be worth noting that somehow on the help (bzr help svn-import)? (sorry if it is, in newer versions) | 10:34 |
| Peng_ | Kamping_Kaiser: I'm running the bzr-svn trunk, and it does mention it. | 10:34 |
| Kamping_Kaiser | Peng_: no worries then. thanks for checking! | 10:34 |
| Kamping_Kaiser | caw. its there | 10:42 |
| Kamping_Kaiser | thanks so much\o/ | 10:42 |
| Peng_ | jam: StaticTuple.as_tuple() doesn't recursively convert other StaticTuples inside the StaticTuple to tuples. Do you think it should? | 10:43 |
| Peng_ | jam: In other words, is that a bug or a feature? :) | 10:43 |
| Peng_ | beuno: ping | 11:38 |
| bialix | шпсЖ зштп | 12:10 |
| bialix | igc: ping | 12:10 |
| igc | hi bialix | 12:10 |
| bialix | I want to convert cvs repo of FTE to bzr | 12:11 |
| bialix | I've managed to rsync entire repo from sf.net | 12:11 |
| bialix | can you point me where to start? | 12:11 |
| bialix | should I use instructions from here: http://cvs2svn.tigris.org/cvs2bzr.html | 12:11 |
| igc | bialix: start with http://doc.bazaar-vcs.org/migration/en/data-migration/index.html | 12:12 |
| bialix | or your plugin has inside something else? | 12:12 |
| igc | bialix: if the instructions aren't clear, we need to improve them | 12:13 |
| bialix | ok, I'll read | 12:13 |
| bialix | will ask questions tomorrow | 12:13 |
| igc | bialix: fast-export-from-cvs calls cvs2bzr to do the export | 12:13 |
| bialix | aha | 12:13 |
| bialix | cvs2bzr page mentions some options.file | 12:14 |
| igc | bialix: hopefully you don't need a custom options file. If you do, I think fast-export-from-cvs allows you to provide one | 12:15 |
| bialix | igc: I have installed TortoiseCVS | 12:16 |
| bialix | I hope it will be enough to use cvs2svn | 12:17 |
| bialix | as I know it can work with RCS co utility or cvs executable | 12:17 |
| bialix | do you control this aspect somehow? | 12:17 |
| bialix | igc: ok, help for fast-export-from-cvs is clear, I'll start experimenting and will report all issues I'll encounter | 12:18 |
| igc | bialix: thanks. we need to get the process *clearly* documented | 12:19 |
| spiv | Peng_: test added, patch up for review | 12:19 |
| spiv | Peng_: feel free to sneak it into your deployment right now and get rid of your monkey patch ;) | 12:20 |
| bialix | igc: my mileage as typical windows/tortoisecvs user will vary | 12:20 |
| spiv | Peng_: Btw I discovered that doing that fix was exactly as painful and confusing as I thought it would be, so I feel less bad about not doing it sooner now :P | 12:21 |
| bialix | igc: and btw, I found gnuwin32.sf.net project is better than unxutils.sf.net | 12:21 |
| spiv | Peng_: (even though the eventual patch is actually quite clear I think, but fully analysing this stuff is always makes me go a bit cross-eyed) | 12:22 |
| bialix | igc: unxutils.sf.net is no more maintained and I'm unable to download sort there | 12:24 |
| Peng_ | spiv: Heh, that makes me feel better about not trying to figure it out myself. | 12:27 |
| Peng_ | spiv: I just confirmed that your fix works. I love you! :) | 12:33 |
| spiv | Peng_: great, thanks for testing :) | 12:46 |
| spiv | Peng_: yeah, it's not so much that it's hard exactly. Just that there are just enough confusingly similar variables involved that it's hard to keep track of what's going on. | 12:51 |
| Peng_ | spiv: Not to rush you, but you're working on a fix for Loggerhead too, right? What's the status of that? | 12:52 |
| spiv | All the various path the user sees/path the http request is delivered to/path in the hpss request/path adjusted relative to server backing transport/path relative to request handler etc | 12:52 |
| spiv | Oh yeah, good point. | 12:53 |
| spiv | I've even tested that it works (with my fix for bzrlib) | 12:53 |
| spiv | So I'll file that merge directive now | 12:53 |
| spiv | Peng_: https://code.edge.launchpad.net/~spiv/loggerhead/shared-repo-fix/+merge/13701 | 13:00 |
| Peng_ | spiv: Great. :) | 13:02 |
| Peng_ | This is missing the point, but testing with "bzr revno" is clever. I always use "bzr log -r -1 -n 1", which takes a while | 13:03 |
| spiv | Peng_: :) | 13:04 |
| spiv | Peng_: a while to type if nothing else! | 13:04 |
| Peng_ | Yeah, that too. | 13:04 |
| igc | night all | 13:10 |
| spiv | g'night | 13:11 |
| beuno | Peng_, hi | 13:19 |
| Peng_ | beuno: I just wanted to say that lp:~beuno/loggerhead/yui3-0-0 is redundant. I pushed a similar branch to lp:~mnordhoff/loggerhead/yui-3.0.0 and lp:~loggerhead-team/loggerhead/yui-3.0.0, which also handles a couple of renamed files better. | 13:24 |
| === mrevell is now known as mrevell-lunch | ||
| beuno | Peng_, did you get it working? | 13:26 |
| Peng_ | beuno: No. I didn't do anything more than update the copy of YUI. | 13:31 |
| beuno | Peng_, gotcha. I will see if I can spend an afternoon fixing it. I have some idea of what needs to be tweaked | 13:33 |
| Peng_ | Oh, good. :) | 13:34 |
| beuno | Peng_, did you get the LP tshirt? | 13:35 |
| Peng_ | beuno: Not yet. | 13:36 |
| beuno | mrevell-lunch, do you know anything ^ | 13:37 |
| * beuno has delegated the problem to a smarter person | 13:37 | |
| nil1 | Hi! | 13:40 |
| nil1 | Is bzr able to handle concurrent commits on a "dumb" server (like FTP)? | 13:41 |
| beuno | nil1, yes | 13:41 |
| nil1 | thanks! | 13:41 |
| Peng_ | There are very brief windows where the repo will be write-locked, though, no? | 13:42 |
| nil1 | Does it require a reliable locking mechanism? | 13:42 |
| nil1 | (locking in the sense of a .lock file being written) | 13:43 |
| Peng_ | nil1: Yes. Bazaar implements said reliable locking mechanism itself. It works fine over FTP. | 13:43 |
| beuno | yes, it locks the repo for brief moments | 13:43 |
| beuno | I guess that would limit how concurrent it can be | 13:43 |
| nil1 | I use the FTP interface of the Tahoe storage grid, where the latency is probably higher than on a normal FTP server | 13:44 |
| nil1 | I'll ask them if writes are reasonably atomic | 13:47 |
| nil1 | (them = Tahoe devs) | 13:47 |
| beuno | nil1, let is know :) | 13:47 |
| nil1 | will do! | 13:47 |
| === mrevell-lunch is now known as mrevell | ||
| Peng_ | Using StaticTuple in Loggerhead is fun. There are currently fewer tuples than lists in memory. :D | 13:52 |
| beuno | Peng_, did it have an impact in memory usage? | 13:55 |
| Peng_ | beuno: It's way too dynamic to be sure. | 13:57 |
| mrevell | Peng_ Your t-shirt'll be in the post today. | 13:59 |
| Peng_ | mrevell: Yay! | 14:00 |
| beuno | thanks mrevell | 14:02 |
| mrevell | Peng_ I've just been told that it has now been sent. | 14:08 |
| beuno | Peng_, spiv's branch looks good to land now, want to merge it yourself or want me to? | 14:10 |
| Peng_ | beuno: You can if you want to. | 14:12 |
| Peng_ | mrevell: Thanks! :) | 14:12 |
| Peng_ | beuno: But I don't mind doing it. | 14:12 |
| spiv | Peng_: woo | 14:12 |
| * spiv -> zzz | 14:12 | |
| beuno | spiv, thanks | 14:13 |
| beuno | Peng_, go for it | 14:13 |
| Peng_ | beuno: 'kay | 14:13 |
| Peng_ | Pushing now | 14:17 |
| beuno | woo! | 14:19 |
| Peng_ | (Pushed again, cuz I forgot to mention bug #348308 in NEWS.) | 14:22 |
| ubottu | Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/348308) | 14:22 |
| Peng_ | I can never merge something in just one revision. :P | 14:22 |
| beuno | heh | 14:24 |
| Peng_ | jam: ping | 14:33 |
| === Island_Usurper is now known as IslandUsurper | ||
| === pickscrape_ is now known as pickscrape | ||
| pickscrape | Could someone explain to me what the --incremental option of bzr svn-import does? | 14:36 |
| Peng_ | pickscrape: "bzr svn-import --incremental" is to "bzr svn-import" as "bzr pull" is to "bzr branch". | 14:39 |
| pickscrape | Peng_: Ah, so if I have an import that I have to kill due to it using 13G of ram, using that option will allow it to carry on from where it left off? | 14:40 |
| Peng_ | pickscrape: ...Probably. | 14:41 |
| pickscrape | Peng_: thanks, I'll try that the next time I have to kill it | 14:41 |
| Peng_ | pickscrape: I'm not sure how much of the import will have been saved if you kill it, but it probably will include most of the repo. | 14:42 |
| === abentley1 is now known as abentley | ||
| === sabdfl1 is now known as sabdfl | ||
| jam | morning all | 15:00 |
| jam | spiv: thanks for the reviews, sleep well | 15:00 |
| jam | Peng_: wave | 15:00 |
| jam | jelmer: it looks like we need an updated bzr-rewrite as wel | 15:01 |
| Peng_ | jam: First of all, I'm sorry about pestering you to keep adding features to StaticTuple. Thanks to all of your work, I finally got the Loggerhead branch working. :) | 15:04 |
| jam | Peng_: good to hear. Did you see my recent patch to support more object types? | 15:05 |
| jam | That should land in bzr.dev today | 15:05 |
| Peng_ | jam: Yeah, I'm using it. | 15:05 |
| jam | it will change slightly, but not dramatically | 15:05 |
| Peng_ | jam: Anyway, on to the continued pestering: The only other things I could want are these, but they're not necessary: Pickle support, and the ability to pass a generator to from_sequence. | 15:05 |
| Peng_ | jam: What do you think? Like I said, they're not necessary, but they would be nice. | 15:06 |
| jam | Peng_: from_sequence(tuple(generator)) should work fine :) | 15:07 |
| jam | and essentially give the same results | 15:07 |
| jam | I have to iterate the generator because ST is a fixed-width object | 15:07 |
| Peng_ | jam: OK. | 15:07 |
| jam | given that, from_sequence(list(generator)) might be better | 15:07 |
| jam | I'm not clear on the tuple internals wrt a generator | 15:07 |
| Peng_ | from_sequence(list(generator)) might be better than from_sequence(tuple(generator))? Why? | 15:08 |
| jam | Peng_: because tuple() is also fixed width, so it has to somehow stage the whole generator result somewhere | 15:08 |
| jam | and then create a tuple | 15:08 |
| jam | *list* can grow | 15:08 |
| jam | so it can stage the contents into itself | 15:09 |
| Peng_ | jam: Ahh, interesting. ...It probably doesn't matter much, though. | 15:09 |
| jam | Peng_: looking at the internals of PySequence_Tuple() it re-allocates the internal tuple | 15:09 |
| jam | holding a size of 10, and then reallocating over and over as it grows | 15:10 |
| jam | so I guess ~ the same as List does | 15:10 |
| jam | Pickle support... I really don't know what it takes to tell pickle about a custom type | 15:10 |
| Peng_ | I think these tuples are only like 1 or 2 items long, so it shouldn't matter much. | 15:11 |
| jam | http://docs.python.org/library/pickle.html#pickling-and-unpickling-extension-types | 15:12 |
| Peng_ | Oh, I hadn't scrolled down that far in the docs. | 15:12 |
| Peng_ | jam: BTW, your merge proposal got the LP equivalent of bb:tweak, more or less. Have you seen it yet? | 15:13 |
| jam | Peng_: yeah, I'm cleaning it up now | 15:13 |
| Peng_ | jam: ok :) | 15:13 |
| jam | Peng_: so if pickling is important to you, I'm happy to look over a patch, give suggestions, etc. I'm probably not going to worry about it myself, though. | 15:19 |
| jam | In general, I think it wouldn't be too hard | 15:19 |
| jam | you just have to implement __reduce__() and __setstate__() | 15:19 |
| jam | except __setstate__() sounds like it happens *after* the class has been instantiated | 15:20 |
| Peng_ | Step 1: Learn C. :P | 15:20 |
| jam | Peng_: if you wrote it sufficiently in Python, translating it to C wouldn't be hard (for someone) | 15:20 |
| jam | you could try doing it on the pure python StaticTuple type to start with | 15:21 |
| jam | or if it 'just gets' it from 'tuple', check what to do there | 15:21 |
| jam | they also mention that you can do this 'after-the-fact' by registering with the 'copy_reg' module | 15:22 |
| jam | http://docs.python.org/library/copy_reg.html#module-copy_reg | 15:23 |
| jam | that may work better, as it can | 15:23 |
| jam | 1) probably be done in pure python | 15:23 |
| jam | 2) you can be more sure that you don't have to construct an object and then call __setstate__ on it | 15:24 |
| jam | hmm.. maybe no nee | 15:24 |
| jam | need | 15:24 |
| jam | given the callable you pass takes a tuple of arguments for the callable | 15:24 |
| Peng_ | I just tested a copy_reg one-liner. It whined about __builtin__.StaticTuple not existing. | 15:25 |
| jam | Peng_: did you have _static_tuple_c imported before you did the unpickle? | 15:26 |
| Peng_ | jam: I had "from bzrlib.static_tuple import StaticTuple". | 15:28 |
| jam | so potentially that is the pure python class, though not if everything is working correctly | 15:29 |
| Peng_ | jam: It's the C version. | 15:29 |
| Peng_ | I note that the C StaticTuple has no __module__ attribute. | 15:29 |
| jam | interesting, given that 'tuple' itself does | 15:32 |
| jam | Peng_: actually *instances* of tuple do not have the __module__ attribute, but t.__class__.__module__ does | 15:35 |
| jam | and | 15:35 |
| jam | >>> _static_tuple_c.StaticTuple.__module__ | 15:35 |
| jam | '__builtin__' | 15:35 |
| jam | I don't specifically know how to change that | 15:35 |
| jam | as I don't see where it is set | 15:35 |
| jam | it seems to be in 'typeobject.c' a function called type_module() | 15:40 |
| jam | and it looks like if you set "tp_name" to "bzrlib._static_tuple_c.StaticTuple" then it will get a module | 15:40 |
| jam | otherwise it defaults to __builtins__ | 15:41 |
| jam | Peng_: give this a shot: http://paste.ubuntu.com/298325/ | 15:42 |
| Peng_ | Are you supposed to hardcode the module like that? Obviously, it isn't necessary when writing Python code. | 15:44 |
| jam | Peng_: that seems to be why Type.__module__ expects | 15:45 |
| jam | we aren't creating a heap type, so we can't just set "Type.__module__" directly | 15:46 |
| jam | and if it isn't a heap type, it checks s = strrchr(type->tp_name, '.'); | 15:46 |
| jam | and if not found returns __builtin__ | 15:46 |
| jam | so I think so | 15:46 |
| Peng_ | jam: This fixes it, but you'll have to adjust __repr__, as it now includes the module too. | 15:50 |
| Peng_ | jam: Or, don't adjust repr, but adjust any tests where it's still hardcoded (if there are any). | 15:51 |
| jam | well, seeing the full format in print '%r' also isn't very nice | 15:52 |
| jam | and I think we have the flag set so you can't subclass StaticTuple | 15:52 |
| jam | so it is safe to just hard-code it there | 15:52 |
| Peng_ | jam: With that patch, pickling works with this one-liner: copy_reg.pickle(StaticTuple, lambda st: (StaticTuple, st.as_tuple())) | 15:53 |
| Peng_ | jam: Although it will probably die horribly if you enable or disable the C extensions in between pickling and unpickling. | 15:53 |
| jam | Peng_: it won't work because the module is hard-coded in the pickle stream | 15:54 |
| jam | now if we wanted to be 'evil' | 15:55 |
| jam | we would make the module name "bzrlib.static_tuple" | 15:55 |
| jam | and then set | 15:55 |
| jam | bzrlib._static_tuple_py.StaticTuple.__module__ == 'bzrlib.static_tuple' | 15:55 |
| jam | at that point | 15:55 |
| jam | I think you could switch between them | 15:55 |
| jam | i'm not positive | 15:55 |
| Peng_ | Probably. | 15:56 |
| jam | but I think the unpickler just tries to grab a class at the given path | 15:56 |
| jam | and passes it the args | 15:56 |
| Peng_ | IMO doing that is nice, but unacceptably evil. | 15:57 |
| Peng_ | Boy. I'm running bzr.dev with 2 unmerged branches + a patch. Fun! | 16:00 |
| Peng_ | jam: So... what do you want to do? About tp_name, and about __reduce__? I could probably do it all, but it would take me a while, since I've written about 4 lines of C, none of them involving Python's C API. | 16:28 |
| jam | Peng_: I can probably put it on my "get to it eventually" list, as the actual amount of work is pretty small | 16:34 |
| jam | did you try the 'nice but evil' hack and see if it worked? | 16:34 |
| Peng_ | jam: What, to make switching between C and Python work? No. | 16:39 |
| Peng_ | jam: Are you going to land the tp_name patch? I'm going to work on pickling -- though I might give up -- so I can make it a part of that. But I don't know what, if anything, to do about repr. | 16:41 |
| jam | Peng_: just change the part that formats to hard-coding it | 16:42 |
| jam | I would land them all together | 16:42 |
| Peng_ | jam: Alright. | 16:42 |
| jam | static tuple type support is in pqm now | 16:46 |
| jam | Peng_: what other unmerged branch are you running? | 16:47 |
| Peng_ | jam: lp:~spiv/bzr/bzr-http-jailbreak-bug-348308 | 16:49 |
| Peng_ | Uh-oh. Applying the tp_name patch to another branch, it doesn't work. :\ | 16:50 |
| Peng_ | And no, I'm not making some mistake like importing the wrong file. | 16:52 |
| === deryck is now known as deryck[lunch] | ||
| awilkins | Thought of the day : a fast-import frontend you can use for benchmarking | 17:08 |
| awilkins | ie - it replays revisions by making changes to the filesystem and driving the porcelain of your chosen VCS | 17:08 |
| awilkins | So you could take a git-fast-export of say.. the kernel tree... and pipe it through this thing to see how various things performed on real-world data | 17:09 |
| jfroy | verterok: ping | 17:21 |
| verterok | jfroy: pong | 17:21 |
| verterok | jfroy: hi | 17:21 |
| verterok | jfroy: I wasn't able to get a spare minute and reboot into OS X, so no push yet :( | 17:22 |
| jfroy | alright, just ping me when you do | 17:24 |
| === beuno is now known as beuno-lunch | ||
| verterok | jfroy: sure, let me try to get the changes from the HFS+ disk ;) | 17:35 |
| verterok | jfroy: pushed revno 13 to lp:~verterok/+junk/OSX-package | 17:44 |
| verterok | jfroy: I remove the -desktop pmdoc, as it was quite outdated | 17:44 |
| verterok | *removed | 17:44 |
| === deryck[lunch] is now known as deryck | ||
| === beuno-lunch is now known as beuno | ||
| jfroy | verterok: so what's the process for the desktop installer? | 18:08 |
| verterok | jfroy: there isn't a desktop installer :) | 18:09 |
| verterok | jfroy: I just builded a PyQt.pkg and included it in the DMG | 18:09 |
| verterok | jfroy: as I'm still using my old script to build the 10.5 installer | 18:09 |
| verterok | jfroy: basically, I think we need a new pmdoc (-desktop) for 10.6 | 18:10 |
| jfroy|work | I see | 18:11 |
| jfroy|work | well that should be easy enough | 18:12 |
| jfroy|work | I don't see a switch to have fetch-external grab PyQt and Sip, am I missing something? | 18:12 |
| Tak | yay, subvertpy crash fixed! | 18:13 |
| verterok | jfroy: it should fetch all the deps | 18:14 |
| jfroy|work | Ah, so it did | 18:15 |
| jfroy|work | hum | 18:17 |
| jfroy|work | why did you modify the config for sip and pyqt that much? | 18:18 |
| jfroy|work | ah I see, the default paths are bogus | 18:23 |
| verterok | jfroy: yeap | 18:24 |
| jfroy|work | anyways, it needs to be done that way too because there's no prefix or root option | 18:27 |
| jfroy|work | was the -q option necessary for pyqt? | 18:27 |
| jfroy|work | it should find the default just fine I would think | 18:28 |
| jfroy|work | oh, did you include Qt in your dmg? | 18:29 |
| verterok | jfroy: no, QT needs to be installed | 18:34 |
| verterok | jfroy|work: ^ | 18:34 |
| verterok | jfroy|work: I'm still trying to build a standalone bundle with qt and pyqt | 18:35 |
| Peng_ | jam: I just sent a merge request for pickling. Peng_ wrote C, ha! (Well, Peng_ copy-and-pasted C.) | 18:39 |
| jam | Peng_: \o/ for you | 18:41 |
| jam | Peng_: https://code.launchpad.net/~mnordhoff/bzr/statictuple-pickling/+merge/13720 doesn't have anything with pickling | 18:43 |
| jam | it only has the repr and tp_name changes | 18:43 |
| Peng_ | jam: I know. Launchpad's mirror is out-of-date; see my message. | 18:44 |
| Peng_ | I didn't want to wait another 4 hours to submit the proposal, or figure out how to trigger a mirror again. | 18:44 |
| Peng_ | Sorry for making it confusing. | 18:44 |
| abli | Hi! If I do a bzr merge of certain revisions (i.e. with from_rev..to_rev) why doesn't it get noted that I have pending merges when I do a "bzr st"? And why dont the merged versions's comments get added when I check in the merge? Any ideas? | 18:46 |
| abli | (using bzr 1.16.1) | 18:47 |
| dash | abli: that's a cherry-pick and bzr doesn't treat it like a 'normal' merge | 18:47 |
| dash | it just applies the changes and doesn't track history | 18:47 |
| jam | Peng_: you could have always hosted the branch... :) | 18:48 |
| abli | and is there some way to make bzr treat it like a normal merge? To get the merged comments in the checkin comment? | 18:48 |
| jam | Peng_: reviewed. I think you need one more Py_INCREF but otherwise it looks good. | 18:48 |
| jam | abli: use "bzr merge -r to_rev" | 18:48 |
| jam | and if you really need to | 18:49 |
| abli | For example, bzr will know that those revisions were merged, right? I.e. won't show them when I run "bzr missing" later? | 18:49 |
| jam | bzr merge --force -r from_rev..ancestor:../other | 18:49 |
| jam | abli: it will show them as missing | 18:49 |
| jam | as said earlier, we don't track the history of cherrypicks | 18:49 |
| Peng_ | jam: How's that fun? If I had originally pushed to LP, it would have been very quick, instead of 8 minutes of streaming data to the out-of-date repo on my server. :D | 18:49 |
| dash | abli: what's your situation? | 18:50 |
| abli | Btw why isn't cherry-picking treated like a normal merge? (I.e. why is the workaround you guys mentioned needed?) | 18:50 |
| jam | Peng_: well at least your server is up to date now :) | 18:51 |
| abli | trying to merge "half" of a branch to trunk. I.e. I have a branch with commits that implement two features, and I want to merge those belonging to one of the features to trunk | 18:52 |
| abli | jam: how should I read that from_rev..ancestor:../other part? I assume I am to run "bzr merge" from the branch I am merging to, right? So running "bzr merge -r from_rev..to_rev other_branch" is a normal cherry-picking, right? so how do I run this non-cherry-pick-but-only-some-revisions merge? Or is it even possible? | 18:56 |
| === maxb_ is now known as maxb | ||
| Peng_ | jam: Thanks for the review. :) | 18:57 |
| Peng_ | Writing (a little bit of) C is kind of fun. Python is so easy that it's boring. :P | 18:58 |
| jam | abli: we don't have a way to internally represent "i'm merging some of the ancestry but not all of it" | 19:02 |
| jam | so there are some options | 19:02 |
| jam | but they all 'break' for some use cases | 19:02 |
| jam | abli: for example you can do | 19:03 |
| jam | bzr merge ../other -r from_rev | 19:03 |
| jam | bzr revert . | 19:03 |
| jam | bzr commit -m "Explicitly remove the initial changes" | 19:04 |
| jam | bzr merge ../other -r ../to_rev | 19:04 |
| jam | however, in that case the initial changes 'won't' land | 19:04 |
| jam | though you can then do the reverse sync | 19:04 |
| jam | with cd ../other | 19:04 |
| jam | bzr merge ../trunk | 19:04 |
| jam | bzr revert . | 19:04 |
| jam | bzr commit -m "Revert the removal from trunk" | 19:04 |
| jam | or something along those lines | 19:04 |
| jam | caveat that merging trunk probably does more than just bring in the feature you just did | 19:05 |
| jam | abli: alternatively, you can look at something like: http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-keep.html | 19:06 |
| jam | for how to take a branch that has multiple features developed on it | 19:06 |
| abli | and then merge to to_rev, and commit, right? But that will show the revisions up to from_rev as merged, won't it? I will want to merge those at some later point | 19:06 |
| jam | and split it into independent branches | 19:06 |
| abli | Ok, thanks, I'll try out that refactoring thing. | 19:19 |
| === bac` is now known as bac | ||
| emmajane | igc, pong (belated) | 20:57 |
| igc | hi emmajane, how are you? | 20:58 |
| beuno | mwhudson, Peng_, I think I have LH working with 3.0.0 | 20:58 |
| emmajane | igc, hey :) | 20:58 |
| beuno | just need to iron out a few errors with the search js | 20:59 |
| mwhudson | beuno: cool | 21:00 |
| thumper | beuno: 3.0.0 what? | 21:10 |
| lifeless | moin | 21:13 |
| lifeless | YUI I imagine | 21:13 |
| igc | hi lifeless, thumper | 21:16 |
| beuno | thumper, lifeless, yes | 21:23 |
| beuno | I'm pretending this is research for the lazr-js sprint in dallas | 21:23 |
| lifeless | beuno: 'it is' | 21:26 |
| jml | I've recently been motivated to care about this bug: https://bugs.launchpad.net/bzr/+bug/152008 | 21:29 |
| ubottu | Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/152008) | 21:29 |
| jml | lifeless, you now have commit rights to testtools. | 21:35 |
| lifeless | cool | 21:36 |
| lifeless | [what prompted this?] | 21:36 |
| jml | I'm yak shaving :) | 21:36 |
| jml | I want to release txsshserver | 21:37 |
| jml | to do this, I need to make sure the tests pass | 21:37 |
| jml | right now, running the tests in trial makes them all skip | 21:37 |
| jml | I have NFI why that's the case, but suspect a bug in testtools (or maybe in trial) | 21:37 |
| lifeless | awesome | 21:37 |
| jml | you've been keeping up to date with python test development much more than I, so I feel that you are in a much better position to get stuff landed. | 21:38 |
| jml | and I feel I'll be less of a blocker if I don't have sole commit rights. | 21:38 |
| lifeless | what was your previous 'policy' about reviews of committer's code | 21:39 |
| lifeless | and how do you want me to behave | 21:39 |
| lifeless | e.g. 2 +1s, then land, or 'if you think it is right just land', or 2 +1s with a timeout? | 21:40 |
| lifeless | jml: ^ | 21:41 |
| jml | lifeless, my policy has been patches get reviewed, and I land patches without review. but I was the sole controller. | 21:43 |
| jml | lifeless, I just got on a call w/ thumper, will actually think about policy when I'm off :) | 21:43 |
| lifeless | jml: indeed, but you can see why I ask :) | 21:44 |
| jml | yes :) | 21:44 |
| lifeless | jml: if you're to be less of a blocker we need committing to be quorate without needing you | 21:44 |
| jml | lifeless, that's right. | 21:45 |
| lifeless | enjoy the call | 21:45 |
| jml | :) | 21:45 |
| jam | jelmer: ping (still need a newer bzr-rewrite for 2.1.0b1 release...) | 21:46 |
| jam | morning lifeless | 21:46 |
| lifeless | hi jam | 21:47 |
| igc | hi jam, jml | 21:47 |
| jml | igc, hi | 21:48 |
| igc | emmajane: my email from last week? Did I miss your reply or is it still coming? | 21:49 |
| emmajane | igc, email from last week? | 21:49 |
| emmajane | igc, on-list? | 21:49 |
| igc | emmajane: no, just to you | 21:49 |
| * emmajane checks the backlog of lsit email. | 21:49 | |
| emmajane | oh. hrm. | 21:49 |
| jam | morning igc | 21:49 |
| emmajane | igc, can you resend? | 21:49 |
| igc | emmajane: it was the one about templating, etc - shall do | 21:50 |
| GaryvdM | Hi jam - Thanks for the bzr-beta-ppa approval. | 21:50 |
| emmajane | igc, thanks. I don't remember getting one to me about templating. :/ | 21:50 |
| igc | emmajane: just re-forwarded it now - date was 12/Oct; title was "Next steps ..." | 21:51 |
| jam | GaryvdM: no problem | 21:51 |
| jam | easier than having you request a copy every month :) | 21:51 |
| GaryvdM | :-) | 21:51 |
| emmajane | igc, got it this time. I'm not sure where the other one went. :/ | 21:52 |
| * emmajane reads | 21:52 | |
| igc | jam, lifeless: OOo fast-imports now with latest trunk and cache of inventories cut down to 5 (was 100) | 21:52 |
| igc | jam, lifeless: I'm just trying qt now with a few different cache sizes to see memory and speed impact | 21:53 |
| emmajane | igc, Good list. I'll send a response back tonight with a plan. | 21:53 |
| igc | emmajane: thanks | 21:53 |
| emmajane | no problem! thanks for pinging me about it. | 21:54 |
| jam | igc: you're saying that it succeeds at importing w/ a cache of only 5? | 21:54 |
| jam | (and cache of what?) | 21:54 |
| * ToyKeeper ponders how to rebase a series of merges on top of a new upstream tarball... bzr-rebase seems to think the source branch (with new tarball) is a descendent of the target branch (with merges), and pulls instead of rebasing. | 21:54 | |
| jam | btw, it *might* be reasonable to handle a hunk stream by copying everything into the chk store, and then extracting it from there. | 21:54 |
| jam | though 'pack' won't gc those extra objects. | 21:55 |
| ToyKeeper | Hmm, I bet a null commit before the merges would un-confuse it. | 21:55 |
| himanshu__ | Hi, I am getting following error :bzr: ERROR: Unknown repository format: 'Bazaar repository format 2a (needs bzr 1.16 or later)\n' | 21:56 |
| himanshu__ | Not sure why? | 21:56 |
| ToyKeeper | himanshu__: It sounds like your version of bzr is too old to read the repository. | 21:57 |
| himanshu__ | bzr server is running on remote repository with version 2.0.1 | 21:57 |
| himanshu__ | my client machine is ubuntu with bzr version 1.6.1 | 21:58 |
| ToyKeeper | It's because your client is old, then. | 21:58 |
| himanshu__ | so new bzr version is not backward compatible with any bzr version? | 21:58 |
| ToyKeeper | It is if you're using a backward-compatible format. Format 2a is compatible back to bzr 1.16... | 21:59 |
| fullermd | (though you really would rather not use it with <2.0.0) | 22:00 |
| fullermd | _bzr_ is compatible; that _repo_ isn't. | 22:00 |
| ToyKeeper | Ah, okay. | 22:00 |
| ToyKeeper | himanshu__: Upgrading your client would probably be the best option, but you could also rebuilt the repo with an old format, like 1.6.1-rich-root. | 22:01 |
| ToyKeeper | s/rebuilt/rebuild/ | 22:01 |
| himanshu__ | so what do you suggest..Shoudl I rebuilt repo with old format or upgrade client | 22:02 |
| fullermd | Upgrade the client, definitely. | 22:02 |
| fullermd | 2a is a better format in a lot of ways, and unrelated to that 2.0.1 will be a lot faster etc. than 1.6.1 as well. | 22:02 |
| himanshu__ | what is the quickest way to upgrade client on ubuntu? | 22:03 |
| himanshu__ | I have installed using apt-get install bzr | 22:03 |
| fullermd | Older format mirrors are for when (for whatever reason) clients _can't_ be upgraded. | 22:03 |
| fullermd | That probably involves PPA's, but I don't know any details about it. | 22:04 |
| himanshu__ | ohk so I need to build it from source ? | 22:04 |
| ToyKeeper | Ubuntu backports may have it. | 22:04 |
| himanshu__ | what is backports? | 22:04 |
| ToyKeeper | https://help.ubuntu.com/community/UbuntuBackports | 22:04 |
| igc | jam: fastimport caches inventories | 22:04 |
| himanshu__ | ok cool let me check | 22:04 |
| himanshu__ | Also, 1 more question | 22:05 |
| GaryvdM | himanshu__: New versions can also be found in the ppa: https://launchpad.net/~bzr/+archive/ppa/ | 22:06 |
| himanshu__ | ok cool let me check | 22:06 |
| lifeless | jam: inventory cache | 22:07 |
| lifeless | jam: fast import has a huge one | 22:07 |
| ToyKeeper | BTW, know of any tools to modify fast-import files? It would be nice sometimes to remove files, revisions, and other stuff from history. | 22:08 |
| himanshu__ | I have 1 question related to supporting bzr repositor | 22:09 |
| ToyKeeper | It can be done by hand, but it's a lot of work. | 22:09 |
| himanshu__ | say if I have 10 users acess to bzr repository but I want to ensure that no user can have read/write access in other user's project | 22:10 |
| himanshu__ | how can that be possible? | 22:10 |
| jam | ToyKeeper: you may want to look at 'bzr replay' versus 'bzr rebase' | 22:10 |
| fullermd | himanshu__: Why do you need it in one repository? Or do you? | 22:10 |
| ToyKeeper | jam: Ooh, sounds promising. Thanks. :) | 22:10 |
| himanshu__ | so it possible to start bzr server with each user repository? | 22:11 |
| jam | igc: so you might be extra interested in the patch I'm about to propose again (chk_map changes). Providing you are caching chk inventories. | 22:11 |
| rockstar | ToyKeeper, I'm actually rather surprised you hadn't heard about bzr replay. | 22:11 |
| fullermd | himanshu__: The server and 'repositories' are almost completely decoupled. You serve a directory tree, which may have one, two, or six hundred repositories under it. | 22:12 |
| fullermd | himanshu__: Now, the bzr server doesn't itself do any AAA. You'd have to do that in a high level, via the web server for bzr+http, or the ssh daemon for bzr+ssh. | 22:12 |
| himanshu__ | what is AAA? | 22:13 |
| fullermd | himanshu__: I've never messed with bzr+http; I use bzr+ssh everywhere. | 22:13 |
| fullermd | himanshu__: Authentication, Authorization, Accounting. | 22:13 |
| himanshu__ | ok here is what i am doing rite now: I have created 1 bzr repository and executed following command | 22:14 |
| himanshu__ | nohup bzr serve --allow-writes --directory=/home/bzradmin/repository >> /home/bzradmin/logs/bzr_serve.log & | 22:14 |
| himanshu__ | nohup serve-branches /home/bzradmin/repository >> /home/bzradmin/logs/bzr_loggerhead.log & | 22:14 |
| himanshu__ | but this way I am giving everyone read-write access | 22:14 |
| igc | jam: cool | 22:14 |
| fullermd | Right. | 22:14 |
| * igc breakfast - bbl | 22:14 | |
| himanshu__ | but I just want to limit it to each user group | 22:15 |
| himanshu__ | I mean each user group should not have any read-write access of other usergroup | 22:15 |
| himanshu__ | not even on http | 22:15 |
| fullermd | I'd do it all via bzr+ssh (the writing, anyway). | 22:15 |
| fullermd | And use FS permissions. | 22:16 |
| ToyKeeper | rockstar: It was a hidden command... :( | 22:16 |
| rockstar | ToyKeeper, those are the ones you find first usually. | 22:16 |
| rockstar | :) | 22:16 |
| fullermd | Really, there's no way to provide meaningful security differentiation within a repository; if you can write into it, you can change anything. So you'd need one repo per slice of the auth domain. | 22:16 |
| himanshu__ | how do you use bzr+ssh? | 22:17 |
| fullermd | Oh, I just use regular system accounts. | 22:17 |
| fullermd | You COULD do it with a ssh daemon that uses PAM or some other auth, and refers to an external database rather than using regular system accounts. | 22:18 |
| fullermd | But that would be rather more complicated. | 22:18 |
| himanshu__ | so this way each usergroup will be having their own repository? | 22:19 |
| ToyKeeper | I haven't checked in a while, but if bzr-access ever got developed to a usable point, it might help. | 22:19 |
| fullermd | bzr-access can't provide control at a sub-repository level. | 22:19 |
| ToyKeeper | No, it can't. | 22:19 |
| fullermd | Nothing can, without bzr moving a ways. | 22:20 |
| lifeless | if you need privacy or integrity, use separate repos | 22:20 |
| lifeless | thats a design statement, not a feature statement | 22:20 |
| fullermd | himanshu__: You may be assigning more meaning to 'repository' than bzr does. It's not like cvs/svn, where the 'repository' is an important semantic unit. | 22:21 |
| lifeless | we can and will remove the VFS eventually, or at least make pushing with it disabled work [modulo plugins this is the case already] | 22:21 |
| lifeless | and with the VFS removed many middling hostile attacks are prevented | 22:21 |
| fullermd | Yah, VFS is a hole you can drive a 11-dimensional multiverse through. | 22:22 |
| fullermd | I didn't know we have all the core actions moved off it. That's pretty neat. | 22:22 |
| himanshu__ | I am getting little confure here: say I need to support 10 usergroup over same bzr server completly isolated from one another | 22:23 |
| lifeless | fullermd: 2.0.0. baby | 22:23 |
| fullermd | (well, aside from having to longcut to it to find out the !@&$ format of a remote branch...) | 22:23 |
| lifeless | himanshu__: then you have 10 repositories | 22:23 |
| lifeless | himanshu__: or more if you like :) | 22:23 |
| himanshu__ | then I should create 10 different respository setting read-write access according to group | 22:23 |
| fullermd | himanshu__: Remember, your users will [practically] never be interacting with repositories; they'll be dealing with branches. So think in terms of a directory hierarchy of branches, slicing that up how access control needs to be. | 22:24 |
| fullermd | Then you can see where it's worth creating repositories within that. | 22:24 |
| himanshu__ | then each user group can access their resporitory over the bzr+ssh | 22:25 |
| himanshu__ | I agree that users will always interact with branches but I need a way to make sure that set of branches are accesible to only 1 particular user group | 22:27 |
| fullermd | Yah, having those branches have all their data be 775/664 works well for that. | 22:28 |
| himanshu__ | ok cool | 22:28 |
| himanshu__ | so it seems 1 repository, within that I create sub directory fo reach user group | 22:29 |
| fullermd | No, that's a step backward, since they all have to write into the repository. | 22:30 |
| fullermd | Step back and forget about [explicit] repositories; just arrange a bunch of individual standalone branches. | 22:30 |
| himanshu__ | ok | 22:30 |
| fullermd | So you end up with $ROOT/team1/ and $ROOT/team2/ and $ROOT/team3/ etc. dirs, each full of branches. | 22:31 |
| himanshu__ | ok | 22:31 |
| fullermd | With everything under teamX set with that group having write access, and everybody else just read (or no access, if that's what you want) | 22:31 |
| fullermd | So, you can run with just that, and not create any repositories. | 22:31 |
| fullermd | That has its shortcomings, but it's functionally equivalent. | 22:32 |
| himanshu__ | what is the shortcoming here? | 22:32 |
| fullermd | Every branch has a full copy of the history, so (assuming that some/many/most/all of the branches are of the same project), you'll have a giant pile of copies of the same data. | 22:32 |
| fullermd | Which eats up disk space, and also means the users can end up having to push up more data to get their work done. | 22:32 |
| fullermd | But, ignoring space and time, everything acts just like it would with repos. | 22:33 |
| fullermd | Now, if we assume that most/all of these branches are of the same project, just creating a repo in each teamX/ branch means we have 10 copies of the history (one for each team), but that's not so bad probably. | 22:33 |
| himanshu__ | i want branches of same project in teamX directory only | 22:34 |
| fullermd | You could have a repo for teamX/ even if all the branches in it were of different projects of course, but it wouldn't gain anything in that case (since there's no common history to store only 1 copy of) | 22:34 |
| fullermd | So, it sounds like you want a tree sorta like that, with a repo per teams and its perms set as appropriate. | 22:35 |
| himanshu__ | so requirement is that if there is some projectX, then that projectX is just limited to TeamX, cannot be read/write by any other Team | 22:35 |
| himanshu__ | thanks a lot fullermd, i got your suggestions | 22:39 |
| himanshu__ | From my requirement, it makes sense to maintain 1 respoitory for each Team as they have nothing in common, I mean no project, no read-write access | 22:40 |
| fullermd | Sounds like a perfect fit then :) | 22:40 |
| himanshu__ | so when I start bzr server, this would be wrong choice" | 22:41 |
| himanshu__ | nohup bzr serve --allow-writes --directory=/home/bzradmin/repository >> /home/bzradmin/logs/bzr_serve.log & | 22:41 |
| himanshu__ | " | 22:41 |
| himanshu__ | so how should I start server? | 22:41 |
| himanshu__ | assume I have multiple respository | 22:42 |
| himanshu__ | should I give path of top level common directory maintaningg all user repos as underlying sub directory | 22:43 |
| fullermd | You don't 'start' the server. The users use bzr+ssh, which ssh's in and spawns bzr itself behind the scenes. | 22:44 |
| fullermd | So you just have bzr installed and in $PATH, and them able to login. | 22:45 |
| himanshu__ | ok cool | 22:45 |
| fullermd | Then they give whatever path they want. Even a path to one of the other teams if they want, but since the filesystem permissions won't let them write... | 22:45 |
| jml | lifeless, how's this: all patches need reviews from a committer who is not the author. If the author is a committer, there is a 24hr timeout on this rule. | 22:45 |
| himanshu__ | ok cool | 22:45 |
| fullermd | So they'd do something like "bzr branch bzr+ssh://me@server/bzr/team5/mainbranch mylocalbranch" | 22:45 |
| himanshu__ | ok cool~ | 22:46 |
| lifeless | jml: sounds fine to me | 22:46 |
| himanshu__ | Also, is it possible if I can expose this kind of view over http using loggerhead? | 22:46 |
| jml | lifeless, cool. | 22:46 |
| jml | lifeless, let's do that then. | 22:46 |
| fullermd | himanshu__: Well, since you've moved the devs to bzr+ssh, you don't need writes over the web (or over a 'bzr serve' bzr:// server, if you still want to run one), so that just needs read access. | 22:48 |
| fullermd | If you wanted write over bzr+http, you'd have to do access control via Apache (well, or whatever other httpd you have). | 22:48 |
| himanshu__ | ok cool | 22:48 |
| lamalex | is there a way to only get part of a branch? | 23:22 |
| beuno | mwhudson, https://code.edge.launchpad.net/~beuno/loggerhead/yui3-0-0/+merge/13744 | 23:32 |
| beuno | in case you have a little while | 23:32 |
| beuno | notifying oopsed | 23:32 |
| beuno | so I'm doing it manually :) | 23:32 |
| beuno | Peng_, ^ | 23:32 |
| lamalex | im trying to set up bzrbuilder, but our debian package branch is in a subdir of the branch | 23:32 |
| lamalex | is there a way to just get the debian dir of the branch or should i just use run to do an mv | 23:33 |
| beuno | lamalex, there's no way to get a specific dir with bzr at the moment | 23:33 |
| lamalex | so i guess run mv is the way for now | 23:34 |
| lamalex | thanks | 23:34 |
| lifeless | jml: is the new team subscribed for reviews to trunk ? | 23:35 |
| jml | lifeless, is now. | 23:37 |
| lifeless | :) | 23:37 |
| jml | g'night. | 23:37 |
| lifeless | night | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!