| === davidstrauss_ is now known as davidstrauss | ||
| * venia greets everyone. | 01:33 | |
| eyda|mon | is there a good way to do a side by side diff? (example: tkdiff, vimdiff) | 02:01 |
|---|---|---|
| spiv | eyda|mon: you can use 'bzr diff --using=gvimdiff' | 02:03 |
| spiv | There are also plugins to extend bzr diff in various ways. | 02:04 |
| spiv | http://bazaar-vcs.org/BzrPlugins | 02:04 |
| spiv | Also, the bzr-gtk and qbzr plugins provide that sort of functionality too. | 02:05 |
| * igc lunch | 02:46 | |
| igc | back | 03:44 |
| spiv | Hmm, lunch. That's a good idea. | 04:17 |
| mtaylor | bzr: ERROR: exceptions.AssertionError: second push failed to complete a fetch set([('inventories', 'brian@gaz-20091012224641-gjo56i190y8c98xg'), ('inventories', 'brian@gaz-20091012172541-ta8k2ejioknnexab')]). | 07:12 |
| mtaylor | that's not fun | 07:12 |
| spiv | mtaylor: huh | 07:21 |
| mtaylor | spiv: repeatable for me at the moment | 07:21 |
| spiv | mtaylor: ooh, good. | 07:21 |
| mtaylor | spiv: I have a copy of that branch on another machine, so I could re-push - but I thought I'd leave it there for you guys :) | 07:21 |
| spiv | mtaylor: I think there's an unsolved bug about that at the moment, IIRC it's stalled due to not being able to reproduce | 07:21 |
| mtaylor | spiv: yay! maybe I'll be helpful then :) | 07:22 |
| spiv | https://bugs.edge.launchpad.net/bzr/+bug/437626 | 07:22 |
| ubottu | Launchpad bug 437626 in bzr "exceptions.AssertionError: second push failed to complete a fetch set" [Undecided,New] | 07:22 |
| mtaylor | hey look at that | 07:22 |
| spiv | mtaylor: if you can provide something along the lines of tarballs and a recipe to reproduce with them I will be very grateful! | 07:23 |
| mtaylor | spiv: you want me to tar up my local repo .bzr ? lemme try to see if that does it | 07:24 |
| spiv | mtaylor: yeah, please do | 07:24 |
| Peng_ | Somebody should mark the new bug as a dupe, then, no? | 07:24 |
| mtaylor | Peng_: yeah... I can do that | 07:24 |
| spiv | Peng_: probably, I haven't seen it yet.. | 07:24 |
| spiv | Actually, | 07:25 |
| spiv | Well, I guess it's probably the same bug, but it's not certain. | 07:25 |
| spiv | But I note that mtaylors' bug report only involves inventory records, which *might* mean it's a different issue. I guess it's easy to unmark it as a dupe later if necessary. | 07:26 |
| mtaylor | spiv: shit. sorry. I have altered my local repo already | 07:27 |
| spiv | mtaylor: that's ok | 07:28 |
| spiv | mtaylor: can you still reproduce? | 07:28 |
| mtaylor | spiv: I branched a different branch, which I'm guessing filled in something | 07:28 |
| mtaylor | spiv: nope | 07:28 |
| spiv | mtaylor: if not, a tarbll will still be handy | 07:28 |
| mtaylor | k. well, I can give you that | 07:28 |
| spiv | mtaylor: along with the details of the last change you made to it. | 07:28 |
| spiv | Chances are I can take out the most recent pack file with some simple surgery and get it back to the problematic state. | 07:29 |
| mtaylor | spiv: last thing I did was "bzr branch lp:drizzle/build fix-include-issues" | 07:29 |
| mtaylor | which is the only repo operation I did on it since the problem was reproducable | 07:29 |
| spiv | But it's also interesting to know that it's so easy to lose the state that triggers the bug. | 07:29 |
| vila | hi all | 07:32 |
| phretor | hi, how do I branch a specific revision? For instance when I bzr branch lp:django-modeltranslation I always get the latest stable branch rather than the trunk. | 08:29 |
| happyaron | hi, I got Format <RepositoryFormatKnit1> for file:///home/aron/main/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance when checkout a branch, what's this mean? | 09:01 |
| Peng_ | happyaron: Exactly what it says. | 09:02 |
| Peng_ | happyaron: /home/aron/main/ is using an old, slow, inefficient repository format. Upgrading will make things faster and use less disk space. | 09:03 |
| happyaron | Peng_: so run "bzr upgrade"? but this will only effect in my local copy I think | 09:03 |
| Peng_ | happyaron: What version of bzr are you on? | 09:04 |
| happyaron | Peng_: I have 1.13.1 installed | 09:04 |
| * happyaron on my box | 09:05 | |
| Peng_ | Ah. Uh. Err. If you were on 2.0, by default "bzr upgrade" would upgrade to a format that you can't downgrade back to RepositoryFormatKnit1 from, but that's not the case in 1.13.1. | 09:06 |
| Peng_ | So, sure, upgrade, if you don't need your repo to be compatible with really old (<0.92) bzr versions. Take a backup first, of course, and run "bzr check". | 09:07 |
| Peng_ | And yes, it would only upgrade your local copy. Perhaps the remote copy already has been upgraded. If not, you can go and upgrade it too. | 09:08 |
| happyaron | Peng_: how to upgrade the remote one? | 09:08 |
| Peng_ | Also.. 1.13.1 is rather old. You might want to upgrade to a newer version. That'll offer even faster and more disk-efficient formats, too. | 09:08 |
| happyaron | Peng_: the branch is hosted on launchpad | 09:08 |
| Peng_ | happyaron: "bzr upgrade bzr+ssh://..." | 09:09 |
| Peng_ | happyaron: It won't be very fast, but it'll work fine. | 09:09 |
| happyaron | oh | 09:09 |
| happyaron | I know, I will first upgrade my bzr package, then run check, and finally upgrade the format | 09:09 |
| happyaron | Peng_: thanks | 09:09 |
| Peng_ | happyaron: Sounds good. Like I said, though, if you upgrade to 2.0, by default "bzr upgrade" will switch to a format that you can't downgrade back to RepositoryFormatKnit1 from. | 09:10 |
| Peng_ | Not that there's anything wrong with that, unless you have a really ancient bzr install somewhere. | 09:10 |
| Peng_ | See http://doc.bazaar-vcs.org/latest/en/upgrade-guide/index.html about that. | 09:11 |
| happyaron | Peng_: so if I upgrade the one using a 2.0 version, will it accessable for those who still run like 1.13? | 09:11 |
| Peng_ | happyaron: By default, 2.0 uses the 2a disk format, which was only added in, uhh, 1.17, IIRC. Maybe 1.18. | 09:12 |
| Peng_ | happyaron: You could use an older format if you need to, such as 1.9. | 09:12 |
| happyaron | Peng_: oh | 09:12 |
| Peng_ | It'd still be much better than the one you're currently on. Just not as awesome as 2a. | 09:12 |
| happyaron | Peng_: thanks | 09:13 |
| Peng_ | FWIW, even if you do upgrade to 2a, you can downgrade it back down to 1.9-rich-root (added in 1.9) or rich-root-pack (added in 1.0). | 09:17 |
| happyaron | oh | 09:18 |
| Peng_ | I suck at explaining things. Upgrading to a rich-root format like 2a is a bit inconvenient (particularly if a lot of other people have copies of your branches), but not a big deal. The upgrade guide I linked to goes into more detail. | 09:27 |
| Peng_ | (FYI, rich-root formats contain a bit more meta data. Specifically, the root directory of the branch gets a file ID like all other directories do. It's not that important for most uses, but once you upgrade to a rich format, you can't just downgrade to a non-rich format again, throwing out that information.) | 09:28 |
| happyaron | Peng_: I am now upgrading it to the 2a format since this branch wasn't used by more than 5 persions, I will notify them (we were blaming the low speed, hope this can help) | 09:29 |
| Peng_ | happyaron: It will. 2a rocks! | 09:29 |
| happyaron | freeflying: :) | 09:30 |
| * Peng_ goes /away | 09:33 | |
| * igc dinner | 09:56 | |
| bialix | hello all | 09:57 |
| awilkins | join : after you join a subtree, can you continue to pull revisions from it's original branch... particularly, I'm thinking of trees derived from SVN branches | 10:42 |
| * awilkins is about to try this anyway | 10:42 | |
| awilkins | Neato, that works really well | 10:46 |
| awilkins | I'm guessing that pushing it to the SVN repo would be a bit of a disaster though | 10:47 |
| jml | hmm | 11:42 |
| tmartin | Hi there, I'm an engineering student and I'm starting a computing project with two other people. We could do with a some sort of (very basic) distributed revision control. Is Bazaar more or less what I'm looking for? | 12:16 |
| jelmer | igc: I've pushed the updated subvertpy | 12:16 |
| jelmer | igc: (including bin/subvertpy-fast-export.py) | 12:16 |
| Peng_ | tmartin: Those aren't very complicated requirements, so many DVCSes would work, including Bazaar. | 12:18 |
| Peng_ | tmartin: Bazaar has the advantage of working over plain old SFTP or (god forbid) FTP, though. | 12:18 |
| tmartin | Peng_: cool. The reason I'm keen on Bazaar is that the other two people I'm working with aren't familiar with version control, so it's useful that the clients are the same across platforms so I can talk them through it | 12:19 |
| Peng_ | Well, hg has that advantage too. | 12:20 |
| tmartin | hg? | 12:20 |
| tmartin | ah, mercury | 12:20 |
| Peng_ | Well, the VCS is called "Mercurial", but yes. | 12:20 |
| Peng_ | Erm. I am a bzr proponent, but it's not the only good VCS, and which one you like best is a personal thing. | 12:23 |
| Peng_ | me sucks at advertising. :P | 12:23 |
| bialix | tmartin: bzr has very good giu | 12:23 |
| bialix | gui | 12:23 |
| bialix | bzr-explorer | 12:23 |
| bialix | if it matters | 12:23 |
| tmartin | My main issue is with hosting. I can't host myself because I'm behind a NAT that I can't forward ports through (we're just using the leftover Internet in our flat from the last tenants until the new line rental comes through) so I need some project hosting. Using the Bazaar hosting for a small university project wouldn't be considered abuse of the service, would it? | 12:24 |
| Peng_ | ...Is it a software project? | 12:25 |
| bob2 | s/a/a free/ | 12:26 |
| tmartin | it's definitely a software project. It's of dubious use to anyone but us. Basically it models the performance of a Rover 826 accelerating to 100 kph subject to various conditions | 12:28 |
| SamB_XP | but is it free software? | 12:29 |
| tmartin | At the moment it's as-is, but yeah, I can BSD it if I need to | 12:29 |
| bialix | tmartin: you can use `bzr send` command to send new revisions via e-mail. in this case you won't need separate hosting | 12:32 |
| bialix | although it can be a bit tedious | 12:32 |
| tmartin | bialix: Perfect! | 12:32 |
| tmartin | no, it won't be | 12:32 |
| tmartin | It's such a ridiculously small project | 12:32 |
| bialix | tmartin: then you need to have one reference branch and one working branch and create bundle to send against reference branch | 12:33 |
| tmartin | bialix: you've lost me a bit there, hang on, i'm looking it up in the manual | 12:33 |
| bialix | there is nothing in manual | 12:33 |
| bialix | `bzr send` require reference branch to produce valid output | 12:34 |
| bialix | your reference branch should be equal to other people unupdated branch | 12:34 |
| tmartin | bialix: okay, i think that's clear | 12:35 |
| bialix | `bzr send` automatically determines then what revision missing based on the info from reference branch | 12:36 |
| bialix | that's why it can be tedious | 12:36 |
| bialix | maybe using Launchpad.net will be much simpler solution | 12:37 |
| bialix | just set free licenseon your code | 12:37 |
| SamB_XP | like the MIT one | 12:37 |
| bialix | or Apache 2 | 12:37 |
| SamB_XP | it's nicer than BSD because you don't have any blanks to fill in, I believe | 12:37 |
| bialix | new BSD does not require any blanks, IMO but IANAL | 12:38 |
| Peng_ | MIT is still shorter. | 12:38 |
| * bialix nods | 12:38 | |
| Peng_ | Besides, we all know MIT is cooler than Berkeley. :P | 12:39 |
| bialix | this tiny details is out of understanding of non-US guy like me | 12:41 |
| SamB_XP | I'm not sure MIT really is ;-P | 12:43 |
| === tonyyarusso is now known as Guest93713 | ||
| Peng_ | I was just kidding anyway. | 12:43 |
| SamB_XP | I suppose it may depend on where your allegience lies: Lisp, or *nix | 12:43 |
| SamB_XP | are you in the "worse is better" camp, or the "oops we never got around to adding syntax" camp? | 12:44 |
| SamB_XP | ... though I guess MIT did make X, but then again that might just be a reason to hate them ;-P | 12:45 |
| Peng_ | Well, MIT has Clocky, the alarm clock that rolls away from you, and Berkeley has, what, LSD? | 12:46 |
| * bialix wonders why fullermd does not say anything yet | 12:46 | |
| SamB_XP | is that because MIT is so demanding you would oversleep without a clock that evades you? | 12:46 |
| Peng_ | But Berkeley is so demanding you need drugs. :D | 12:47 |
| fullermd | Hmmwhat? Sorry, I was off doing LSD... | 12:50 |
| fullermd | I long ago developed remarkable agility while asleep. I don't think it would be very easy for an alarm clock to evade me... | 12:52 |
| Peng_ | The only thing I can do while asleep is drool. :( | 12:53 |
| SamB_XP | hmm. I can sleep | 12:54 |
| SamB_XP | and have strange dreams | 12:54 |
| fullermd | I had an alarm clock in college that I measured at around 145dB/1 meter. | 12:54 |
| fullermd | It worked, in a roundable way. It woke up my whole hall, who then got the RA to open my door and woke me up. | 12:55 |
| Peng_ | That causes hearing damage! | 12:55 |
| fullermd | Once, famously, by picking me up, carrying me out of the dorm, down the hill, and throwing me in the lake. | 12:55 |
| SamB_XP | fullermd: roundabout, you mean | 12:55 |
| fullermd | I woke up about the time I hit the water. I guess I was kinda tired or something. | 12:55 |
| SamB_XP | that's an understatement ... | 12:56 |
| Peng_ | You're lucky you woke up instead of drowning. :\ | 12:56 |
| SamB_XP | I hope you didn't have any 7:00 classes | 12:56 |
| fullermd | Oh, I'm a good swimmer. I can probably do that in my sleep too :p | 12:56 |
| fullermd | Anyway, it was college; if you're not exhausted, you're doing it wrong, right? | 12:56 |
| fullermd | 7:00 classes are easy. You just stay up late for 'em. | 12:56 |
| Peng_ | I once slept through a fire alarm (no fire; it was broken), but I have no problems with my quiet alarm clock. | 12:57 |
| SamB_XP | fullermd: I meant 7:00 AM | 12:58 |
| fullermd | SamB_XP: So did I :p | 12:58 |
| SamB_XP | oh | 12:58 |
| SamB_XP | what if you have OTHER classes that day? | 12:58 |
| fullermd | Well, I went a couple months sleeping 4 hours a night, on Tue and Fri... I made it to all my classes, though it's possible I might not have been entirely lucid on occasion. | 12:59 |
| fullermd | (but then, it's _me_. I'm not sure you could tell the difference anyway.) | 13:00 |
| SamB_XP | meaning you're never sane ? | 13:02 |
| fullermd | Sanity is for the unimaginative. | 13:03 |
| SamB_XP | yeah, it does seem overrated ;-P | 13:03 |
| fullermd | Anyway, back to only vaguely off-topic, the MIT license and the 2-claues BSD license are isomorphic, so that's a matter of taste. 3-clause BSD is slightly more restrictive. | 13:06 |
| fullermd | ... and the main reason to choose a 4-clause is to tick rms off :p | 13:06 |
| SamB_XP | sadly it will also tick a lot of others off if they for some reason end up wanting to combine your software with something that's under the GPL ... | 13:08 |
| fullermd | Their own fault for picking such a B&D license :p | 13:08 |
| SamB_XP | they might not have written that part | 13:08 |
| Peng_ | ...ISC! :D | 13:08 |
| fullermd | We should write an Escher license, granting all rights to users in a 4-dimensional space. | 13:10 |
| SamB_XP | or on a mobius strip? | 13:11 |
| Peng_ | The ISC license is nice. It's equivalent to 2-clause BSD, but shorter. http://en.wikipedia.org/wiki/ISC_license | 13:12 |
| bob2 | ...from the Internet Systems Consortium, or NAMBLA... | 13:14 |
| === menesis1 is now known as menesis | ||
| Torne | is the right syntax for a password for svn:// repo just scheme=svn ? | 13:33 |
| Torne | if i put my credentials for this svn repo in authentication.conf and try to push, bzr-svn dies with TypeError: password should be string | 13:34 |
| Torne | it works if i just let it prompt me for it | 13:34 |
| bob2 | if the svn command line tool caches it, I belive bzr-svn will pick that up | 13:35 |
| jelmer | Torne: Sounds like a bug in bzr-svn | 13:35 |
| Torne | bob2: i've never touched this one with actual svn, so i don't have it stored there :) | 13:35 |
| jelmer | Torne: please file a bug and include the backtrace | 13:35 |
| jelmer | with a bit of luck we should be able to fix it for the 1.0.1 release | 13:36 |
| Torne | jelmer: ok | 13:36 |
| Torne | jelmer: submitted, https://bugs.launchpad.net/bzr-svn/+bug/452121 | 13:40 |
| ubottu | Launchpad bug 452121 in bzr-svn "Putting svn password in authentication.conf doesn't work" [Undecided,New] | 13:40 |
| jelmer | Torne: thanks | 13:40 |
| Torne | I *nearly* copypasted my password into the report. :) | 13:40 |
| jelmer | heh | 13:41 |
| Torne | while i'm here: bzr-svn is fantastic other than that :) | 13:42 |
| Torne | i've just never had to actually push before ;) | 13:42 |
| jelmer | cool, great to hear :-) | 13:44 |
| Torne | anyway, bye for now ;) | 13:44 |
| bialix | spiv is here? | 13:49 |
| bialix | spiv: when you'll back here: please comment somehow on bug #430382 | 13:53 |
| ubottu | Launchpad bug 430382 in qbzr "qcommit crashes during Cancel" [High,Confirmed] https://launchpad.net/bugs/430382 | 13:53 |
| === mrevell-lunch is now known as mrevell | ||
| jelmer | jam: If you have time, any chance you could have a quick look at my lp:~jelmer/bzr/foreign-tests1 branch and see if the way the tests are set up is ood? | 14:17 |
| awilkins | Ood? http://tardis.wikia.com/wiki/File:Ood.jpg (joke) | 14:21 |
| jelmer | *good | 14:21 |
| jelmer | awilkins: :-) | 14:22 |
| idnar | Peng_: the thing I find stupid about all of those licenses is that the DISCLAIMER OF WARRANTY WHICH IS IN ALL CAPS FOR SOME BIZARRE REASON is longer than the actual license | 14:30 |
| fullermd | Well, that's easily solved, just make the actual license part 10 or 15 pages long. Then it's shorter :p | 14:37 |
| === tchan1 is now known as tchan | ||
| gnomefreak | n/win 3 | 14:46 |
| Pegasus_RPG | howdy | 14:51 |
| === jblount is now known as jblount-bot | ||
| === jblount-bot is now known as jblount | ||
| Anteru | Hi | 15:12 |
| Anteru | Probably one for the FAQ, but I cannot find it: How do I remove a local branch? Just deleting the folder works -- I wonder whether there are any ill effects of that? | 15:13 |
| Anteru | i.e. I have /trunk, /feature-branch locally, and I merged /feature-branch back into trunk, so I don't need it | 15:14 |
| awilkins | Anteru: No ill effects, if you merged it the revisions are all somewhere else. If it's in a shared repo, the revisions don't evaporate, the branch is a pointer. | 15:44 |
| Anteru | ok, cool, thanks! | 15:45 |
| bialix | fullermd: ping? | 15:47 |
| === e-jat is now known as norly | ||
| === mfer is now known as mfer-lunch | ||
| jam | jelmer: I'll try to get to the review. Sorry about the delay | 16:29 |
| jam | /cry, wordpress doesn't auto-save your document, and it crashed while trying to insert and move an image... | 16:29 |
| jam | back to blogger for me.... | 16:29 |
| jam | I liked parts of the interface better, but crashing w/ no autosave is just out | 16:30 |
| jam | heck, this post may never be written now... | 16:31 |
| bialix | jam: blogger has feature to send post via e-mail | 16:32 |
| jam | I was writing up a fairly involved post about what it took to release 2.0.1 and 2.1.0b1 | 16:33 |
| bialix | but I'm unable to send images with my post | 16:33 |
| jam | I got things mostly written, was inserting an image, tried to move it.... | 16:33 |
| jam | and then firefox hung with 100% cpu | 16:33 |
| bialix | bad | 16:33 |
| bialix | I like your posts | 16:33 |
| jam | w/ blogger, at least it would have saved for me | 16:34 |
| bialix | do you have twitter account? | 16:34 |
| jam | perhaps WP has a ^S | 16:34 |
| jam | I do not have twitter | 16:34 |
| bialix | np | 16:34 |
| jam | seems... silly to me so far | 16:34 |
| Anteru | wp has autosave, at least my installation saves every 5 minutes or so | 16:36 |
| jml | where's my bzr-backed wiki | 17:11 |
| jml | it's almost 2010 and I have no flying cars, no hoverboards, no pony and no bazaar-backed wiki | 17:12 |
| Tak | trac? | 17:12 |
| beuno | jml, you mean ikiwiki? | 17:12 |
| jml | beuno, maybe I do. | 17:12 |
| beuno | http://ikiwiki.info/ | 17:13 |
| beuno | I think it's in perl though | 17:13 |
| jam | I know people have worked on a bzr back end | 17:26 |
| LarstiQ | james_w (and myself very minimally) | 17:27 |
| LarstiQ | of course, it has a svn and git backend, so.. | 17:27 |
| awilkins | Was there a plugin that pushes the revisions AND the current working tree to another machine? | 17:27 |
| LarstiQ | jml: there is als Hatta, which is hg backed | 17:28 |
| james_w | awilkins: push-and-update? | 17:30 |
| james_w | I can't remember now if the bzr backend for ikiwiki was merged | 17:30 |
| awilkins | james_w: Not quite, I have uncommitted state that I want to end up in the target | 17:30 |
| jam | awilkins: rsync ? | 17:30 |
| awilkins | jam: I was just using a tree-comparision client :) | 17:31 |
| jam | pushing uncommitted changes isn't something that is likely to be supported 'out-of-the-box' for us | 17:31 |
| jam | if you want them pushed, why not commit and push ? | 17:31 |
| jam | (why is it important that they not be committed ?) | 17:32 |
| === beuno is now known as beuno-lunch | ||
| jml | LarstiQ, yeah, I saw a talk about Hatta at EuroPython, you probably did too | 17:34 |
| LarstiQ | jml: yup | 17:36 |
| * LarstiQ forgot there was lightning talk about it | 17:36 | |
| awilkins | jam: Just my inner voice saying "no, don't push incomplete changes!" | 17:37 |
| awilkins | jam: Or commit them, rather | 17:37 |
| LarstiQ | awilkins: yet you want to deploy them? | 17:37 |
| awilkins | LarstiQ: It's not deployment, it's moving workstation | 17:38 |
| awilkins | I suppose what I really want is shelve-and-move-to-another-machine | 17:38 |
| LarstiQ | awilkins: ah, yes | 17:39 |
| LarstiQ | awilkins: or just diff, rsync, apply | 17:39 |
| awilkins | Shelves are basically orphaned revisions (as I understand them now) | 17:39 |
| jam | awilkins: I don't think they are put into the repo, but otherwise, yeah | 17:39 |
| Keybuk | so you know those archive inconsistencies I keep getting | 17:50 |
| Keybuk | theory: they're ghost revisions | 17:50 |
| Keybuk | ie. where I've overwritten one head with another | 17:50 |
| jam | awilkins: bzr commit; bzr push; bzr uncommit... | 17:50 |
| awilkins | jam: More ghost revisions :-) | 17:51 |
| jam | awilkins: those aren't ghosts | 17:51 |
| jam | ghosts are ancestors we don't have | 17:51 |
| Keybuk | jam: what are those? | 17:51 |
| jam | those are just heads that aren't in a branch | 17:51 |
| Keybuk | bzr commit; bzr push; bzr uncommit; bzr commit; bzr push --overwrite | 17:51 |
| awilkins | Ah, loose heads | 17:51 |
| Peng_ | Keybuk: A ghost is a revision in the branch's history, except we don't actually have a copy of that revision. | 17:52 |
| Peng_ | Or something! | 17:52 |
| Keybuk | hmm, actually I'm not sure that's right | 17:52 |
| jam | Peng_: something spookier I believe :) | 17:52 |
| Keybuk | so I have the following error on push now | 17:52 |
| jam | not sure how... | 17:52 |
| Keybuk | inconsistent details in skipped record: ('scott@netsplit.com-20091014154035-x6fdt088smfxy63j',) ('518 291 0 266', ((('scott@netsplit.com-20091014154020-3j2udgsm15lbdfm4',),),)) ('93400 238 0 266', ([('scott@netsplit.com-20091014154020-3j2udgsm15lbdfm4',)],)) | 17:52 |
| Keybuk | but the revision ids on each side *do* match | 17:52 |
| Keybuk | what's more interesting is that each of the revisions were made *after* I upgraded to bzr 2.0 | 17:53 |
| jam | Keybuk: the warning there is saying that we have revision ids which claim to match, but *content* which claims to differ | 17:53 |
| Keybuk | jam: isn't that bad? | 17:53 |
| jam | Keybuk: potentially, though abentley claims that there were ways of getting into this situation that weren't terribly | 17:53 |
| jam | terrible | 17:53 |
| Keybuk | I'm getting into this situation with ordinary use of bzr | 17:53 |
| jam | hence why he made it a warning when it used to be an error | 17:53 |
| Keybuk | I'm really worried that bzr 2.0 has some *serious* data corruption issues now | 17:54 |
| jam | the way of triggering it that he knew of | 17:54 |
| jam | was that launchpad had bad history | 17:54 |
| jam | and different people had different *amounts* of bad history | 17:54 |
| Keybuk | this is on *new* revisions | 17:54 |
| jam | Keybuk: right, but if you base a commit off of X, and someone else sees that as X' | 17:54 |
| jam | the new commits can disagree | 17:54 |
| Keybuk | but that hasn't happened here | 17:54 |
| Keybuk | this is just an archive | 17:54 |
| Keybuk | one is the LP push of the other | 17:55 |
| Keybuk | and bzr is throwing up all sorts of errors with it | 17:55 |
| jam | Keybuk: so to start with, try to get a tarball snapshot of the state, so that one of us can take a look at it | 17:55 |
| Keybuk | jam: it's on LP | 17:55 |
| Keybuk | I can't login to that and give you a tarball | 17:55 |
| Keybuk | I suspect you can | 17:55 |
| jam | Keybuk: I don't have access to your branches | 17:55 |
| jam | you can use "lftp" to mirror the remote to local | 17:56 |
| jam | and then tarball that | 17:56 |
| Keybuk | afaict it's the LP-hosted branch that has the issues | 17:56 |
| jam | Keybuk: right, and I can only see the "LP-mirror" of your branch | 17:56 |
| Keybuk | got an example lftp incantation? | 17:56 |
| === dorins_ is now known as dorins | ||
| jam | Keybuk: I think "lftp -c mirror sftp://bazaar.launchpad.net/~keybuk/... local" | 17:57 |
| jam | is what you can use to get an exact copy of the launchpad branches | 17:57 |
| Keybuk | ok, grabbing that down | 17:57 |
| Keybuk | reconcile on this fails | 17:59 |
| Keybuk | http://people.canonical.com/~scott/ubuntu-core-dev--upstart--ubuntu.tar.gz | 18:00 |
| Keybuk | there you go | 18:00 |
| Keybuk | that's the .bzr | 18:00 |
| jam | Keybuk: it says it is stacked on "~scott/upstart/trunk" can I get a copy of that as well? | 18:02 |
| Keybuk | yup | 18:02 |
| Keybuk | that one happens to fail reconcile too iirc | 18:02 |
| jfroy|work | verterok: ping | 18:03 |
| Keybuk | (this is somewhat larger, so give me a few minutes for it :p) | 18:03 |
| verterok | jfroy|work: pong | 18:04 |
| jfroy|work | I just made a few fixes to my packaging branch | 18:04 |
| jfroy|work | including a critical fix for an issue I just found in the current distribution / build.py script | 18:04 |
| jfroy|work | that would replace /usr/local/share/man/man1 with the bzr man page (instead of installing it into that directory) | 18:05 |
| jfroy|work | fortunately, Installer is smart enough to move man1 to "man1 1", so I also added a pre-install script to the distro to fix up that mess. | 18:05 |
| jfroy|work | Anyways, I merged your branch into mine, made the fixes and pushed to LP. | 18:05 |
| jfroy|work | Trying to find how to send you a merge request... | 18:06 |
| jam | Keybuk: so it is possible, that the above warning is bogus. I have to dig into it, but I'm noticing that one side says: | 18:06 |
| jam | (((revid,),),) | 18:06 |
| jam | and the other side says | 18:06 |
| jam | ([(revid,)],) | 18:06 |
| jam | (one side has a tuple, the other has a list) | 18:06 |
| Keybuk | jam: why does reconcile fail on that branch? | 18:06 |
| jam | it is possible that it is comparing the objects and failing. | 18:07 |
| verterok | jfroy|work: oh, nice! | 18:07 |
| jam | Keybuk: I haven't gotten that far yet. And certainly there is a bug if [] vs () was triggering a warning | 18:07 |
| verterok | jfroy|work: as there is no project we can't do merge proposals | 18:07 |
| Keybuk | jam: the branch it's stacked on seems to not fail reconcile fwiw | 18:07 |
| jfroy|work | verterok: ahhh, that explains a lot :p | 18:07 |
| Keybuk | just uploading for you atm | 18:07 |
| stianhj | i just installed Bazaar 2.0.0.2 on a Vista 64-bit machine. Running bzr st in an existing bzr repo gives this: "No module named commands" and "Unable to load plugin u'explorer' from u'C:/Program Files/ .. etc'. Bazaar Explorer doesn't seem to be working either. Any ideas? | 18:07 |
| jam | thx | 18:07 |
| jfroy|work | just merge lp:~jeanfrancois.roy/+junk/SnowLeopard-package then | 18:07 |
| jam | stianhj: you might try "bzr -Derror status" | 18:08 |
| jam | it sounds like it is unable to load bzrlib | 18:08 |
| jam | which is fairly serious | 18:08 |
| jam | I'm wondering about a permissions issue | 18:08 |
| jfroy|work | I was going to submit Bazaar-2.0.0-5 | 18:08 |
| jam | do you have any other copies of bazaar? | 18:08 |
| jfroy|work | but with 2.0.1 around then corner, I guess we could wait for that. | 18:08 |
| jam | jfroy|work: 2.0.1 has 'gone gold' | 18:09 |
| jfroy|work | jam: my point exactly | 18:09 |
| jam | so feel free to package Bazaar-2.0.1-1 | 18:09 |
| jfroy|work | verterok: want to do it? | 18:09 |
| jam | the tarballs should be uploaded, etc. | 18:09 |
| jam | also, packaging Bazaar-2.1.0b1-1.pkg would be nice | 18:09 |
| verterok | jfroy|work: the merge or the build? :) | 18:09 |
| jfroy|work | both :p | 18:10 |
| verterok | jfroy|work: :) | 18:10 |
| jfroy|work | well you *need* to merge | 18:10 |
| jfroy|work | trashing man1 is *bad* | 18:10 |
| stianhj | jam: http://pastebin.org/46041 | 18:10 |
| jfroy|work | Oh, the distro version is in config.py | 18:10 |
| jfroy|work | (I added it) | 18:10 |
| verterok | jfroy|work: I'll merge it in my next boot into OS X, proably to build 10.5 installer ;) | 18:10 |
| jfroy|work | I guess I can build the 10.6 one | 18:10 |
| jfroy|work | so, let's see | 18:11 |
| jfroy|work | how would I get the 2.0.1 sources? | 18:11 |
| stianhj | jam: bzrlib seems to be the problem I guess | 18:11 |
| jfroy|work | erm, I mean, w/r to your auto-fetch thing | 18:11 |
| verterok | jfroy|work: please, I don't have 10.6 and I'm not sure if it will work if I build it against non system python | 18:11 |
| jfroy|work | verterok: it won't | 18:11 |
| jam | stianhj: so it would look like 'bzr' itself is working, but that explorer is failing to find something | 18:11 |
| verterok | jfroy|work: PYTHONPATH=. python tools/fecth-external.py -p | 18:12 |
| jam | specifically, it is looking for: from bzrlib.plugins.qbzr.lib.commands import ( | 18:12 |
| jfroy|work | verterok: oh, I moved fetch-external.py out of tools :p | 18:12 |
| jam | so it is *qbzr* which it isn't finding | 18:12 |
| verterok | jfroy|work: heh, ok | 18:12 |
| verterok | jfroy|work: so, python fecth-external.py -p :) | 18:12 |
| jfroy|work | yeah basically | 18:12 |
| verterok | *fetch-external.py -p | 18:12 |
| jam | stianhj: can you try just doing "bzr qbrowse" ? | 18:12 |
| jam | or "bzr qlog" ? | 18:13 |
| jfroy|work | I just tweaked config.py to get 2.0.1 | 18:13 |
| verterok | jfroy|work: and you can get the docs too, I don't remember the switch | 18:13 |
| jfroy|work | I'll check the plug-ins and update them as well | 18:13 |
| jfroy|work | I don't bundle the docs in the core package | 18:13 |
| verterok | jfroy|work: right, I missed that...update config, run the script | 18:13 |
| jfroy|work | but I saw the o[tion | 18:13 |
| jfroy|work | *option | 18:13 |
| verterok | jfroy|work: ok | 18:13 |
| stianhj | jam: yes, bzr seems to be working. qbrowse seems to be working, as well as qdiff, qcommit, etc | 18:14 |
| stianhj | qlog as well | 18:15 |
| jam | stianhj: and I assume that doing "bzr explorer ." is failing? | 18:15 |
| stianhj | no wait, qlog doesn't work | 18:15 |
| stianhj | jam: i get a bunch of errors on the console about drawDisplay, and my commit messages aren't showing | 18:16 |
| jfroy|work | oh well, the tar.gz isn't up yet :p | 18:16 |
| jfroy|work | or the URL is wrong, lol | 18:16 |
| verterok | jfroy|work: you need to update the url in the config too | 18:16 |
| jam | Keybuk: so I don't know why 'reconcile' is failing, but it does look like the warning is triggering because of () != []. I don't quite understand how we are getting a list there, though. As we generally always use tuples. | 18:16 |
| stianhj | jam: the commit messages in the list that is. clicking on items gives me all the info at the bottom of the screen | 18:16 |
| jfroy|work | verterok: I did, with a wrong one ;p | 18:16 |
| jam | So bug #1 is that the comparison is giving you a bogus warning. | 18:16 |
| ubottu | https://bugs.launchpad.net/ubuntu/+bug/1 (Timeout) | 18:16 |
| verterok | jfroy|work: heh | 18:17 |
| jfroy|work | worked fine with the actual URL. | 18:17 |
| jam | stianhj: do you know if you have another copy of 'qbzr' installed? Say in your $APPDATA folder? | 18:17 |
| jam | You can try "bzr plugins -v" to help figure it out | 18:17 |
| Keybuk | http://people.canonical.com/~scott/scott--upstart--trunk.tar.gz | 18:17 |
| Keybuk | jam: that's the stacked branch | 18:17 |
| Keybuk | or the under-stacked | 18:17 |
| Keybuk | dunno the term there ;) | 18:18 |
| jam | Keybuk: stacked vs stacked-on | 18:18 |
| jfroy|work | verterok: pushed the update for bzr 2.0.1 to my branch | 18:19 |
| verterok | jfroy|work: ok | 18:19 |
| stianhj | jam: appdata only has one bazaar folder that is from the 2.0 installation. Just before installing Bzr 2.0.0.2 I uninstalled Bzr 1.7.1 and rebooted. | 18:19 |
| stianhj | jam: was QBzr a part of Bzr 1.7.1 or did I install it seperately? | 18:20 |
| jam | stianhj: 1.7 ? probably installed separately. "bzr plugins -v" should show you what qbzr we are finding | 18:21 |
| === mfer-lunch is now known as mfer | ||
| stianhj | jam: qbzr is version 0.9.3, and is in $APPDATA\Bazaar\2.0\plugins\qbzr. So doesn't seem to be any conflicts | 18:22 |
| stianhj | i think | 18:22 |
| === beuno-lunch is now known as beuno | ||
| stianhj | jam: here's the error from qlog http://pastebin.org/46047 | 18:27 |
| mtaylor | can a shared repo dir be somewhere other than in a directory ancestor and specified explicitly? | 18:28 |
| jam | stianhj: we bundle qbzr 0.14.3 and it should be in C:/Program Files/Bazaar/... | 18:30 |
| jam | mtaylor: no | 18:30 |
| jam | though you could use a lightweight checkout | 18:30 |
| jam | etc | 18:30 |
| mtaylor | jam: k. that's what I thought, but I thought I'd check | 18:31 |
| jam | stianhj: so try moving the qbzr in "$APPDATA/Bazaar/2.0/plugins/" to another directory | 18:31 |
| Keybuk | http://people.canonical.com/~scott/scott--upstart--0.6.tar.gz | 18:37 |
| Keybuk | jam: ^ that one also fails reconcile, and may be stacked on the same branch? | 18:37 |
| Keybuk | random thought, could the [] vs () thing be across the stack point | 18:37 |
| jam | Keybuk: it *is* stacked, I'll let you know the rest as I get a chance to investigate | 18:38 |
| dash | i'm trying to convert twisted's bzr mirror to 2a | 18:39 |
| dash | I initially used bzr upgrade | 18:40 |
| dash | but when that proved slow, I decided to just do a fresh svn import | 18:40 |
| dash | problem is, bzr consumes about 10G of memory when doing so | 18:40 |
| dash | and this box only has 6G of RAM. :) | 18:40 |
| dash | so it's really unable to make any headway | 18:41 |
| LarstiQ | dash: did you talk about that with jelmer? | 18:41 |
| jam | Keybuk: so I see reconcile fail @ | 18:41 |
| jam | source_parents = file_id_parent_map[key] | 18:41 |
| jam | KeyError: ('test_job.c-20060802025841-69d13b49cc35d5ec', 'scott@netsplit.com-20090709110153-7dcfrdmjwojak3ud') | 18:41 |
| dash | LarstiQ: apparently I am never on IRC at the same time as him :) | 18:41 |
| jam | sound about like what you are seeing? | 18:41 |
| LarstiQ | dash: shoot him a mail? | 18:43 |
| Keybuk | jam: that looks right yes | 18:44 |
| dash | LarstiQ: Oh email | 18:44 |
| dash | LarstiQ: I guess that's still around. | 18:44 |
| jam | Keybuk: so my initial impression.... is that something about the upstart-0.6 branch thinks that 'test_job.c' was modified in 200907 | 18:45 |
| jam | however, that revision is not in the stacked branch | 18:45 |
| jam | so I assume it should be in trunk | 18:45 |
| jam | (revision-info says rev 1173) | 18:45 |
| jam | my quick guess is that whatever source upstart-0.6 was created from | 18:45 |
| jam | different from the source that '~scott/upstart/trunk' was created from | 18:46 |
| LarstiQ | dash: he has an identi.ca account if you prefer :) | 18:46 |
| jam | *specifically* about the revision 200907 | 18:46 |
| dash | LarstiQ: Heh hee. | 18:46 |
| Keybuk | jam: let me check the histories | 18:47 |
| Keybuk | jam: the branches should be identical up to -r1204 | 18:48 |
| Keybuk | 1205 in both branches is where they diverge | 18:48 |
| Keybuk | 2009/08/02 | 18:48 |
| Keybuk | that fits with my zsh history as well | 18:49 |
| Keybuk | the last time test_job.c was changed was -r1173 | 18:49 |
| Keybuk | that was before, even, the release of 0.6.0 | 18:49 |
| Keybuk | so that would have been from trunk | 18:49 |
| Keybuk | just to confirm, the branch point of trunk and 0.6 is well after that revision | 18:50 |
| Keybuk | so they should be identical | 18:50 |
| LarstiQ | Keybuk: how far back does your zsh history go? | 18:53 |
| Keybuk | LarstiQ: I allow 1MB for it | 18:54 |
| * LarstiQ already feels like SAVEHIST/HISTSIZE=50000 is a lot | 18:54 | |
| LarstiQ | Keybuk: I see | 18:54 |
| Keybuk | you can never have too much history | 18:55 |
| Keybuk | "I want the command I ran last month that did foo" :p | 18:56 |
| LarstiQ | I entirely agree, but I'm not sure my acer ssd does ;) | 18:56 |
| Keybuk | pah, your SSD will last just as long as a hard drive these days | 18:57 |
| LarstiQ | not quite :/ | 18:57 |
| LarstiQ | it's already becoming very slow | 18:57 |
| LarstiQ | Keybuk: so yeah, rewrites is not a problem, but at this point vim writing to its swap file when I build my tex can take up to two seconds | 18:58 |
| LarstiQ | which is starting to become irritating | 18:59 |
| Keybuk | yeah, don't bother with swap on ssd | 18:59 |
| Keybuk | it's rarely a good idea | 18:59 |
| Keybuk | or use swap files | 18:59 |
| LarstiQ | right | 18:59 |
| * fullermd is looking forward to SSD's, in about 6 or 8 years when he comes to trust them. | 18:59 | |
| LarstiQ | same thing goes for firefox cache etc | 18:59 |
| LarstiQ | fullermd: I'm just waiting for trim support | 19:00 |
| fullermd | I'm still iffy on the longevity of SLC. MLC is right out. | 19:00 |
| dash | fullermd: really? why | 19:01 |
| fullermd | Because they wear way too fast. | 19:02 |
| fullermd | (I mean, the prices are still way high, but that's just waiting; I'm sure they'll be reasonable in a few years) | 19:03 |
| fullermd | But still. In June I retired some hard drives I bought in 1998, and they worked hard their whole life. I have zero faith a MLC SSD will be holding data for crap at that point. | 19:04 |
| fullermd | Think about how flash wears; it's not like you write, and write and write and write, and one day it just *ploop* stops working suddenly. | 19:05 |
| stianhj | jam: deleting the $APPDATA\bazaar folder worked. Bzr Qlog works fine, as well as Bzr Explorer, and I get no error messages in the console. Thanks | 19:05 |
| jam | stianhj: always happy to help | 19:06 |
| jam | fullermd: well they load balance while they are wearing | 19:06 |
| fullermd | Every write reduces the time the charge holds, so you're in trouble long before they "wear out" totally. | 19:07 |
| Keybuk | fullermd: that's the same for a hard drive though ;) | 19:07 |
| fullermd | Strictly speaking, yes, but there are orders of magnitude difference. It's not technically a different of kind, but it's practically equivalent. | 19:08 |
| === Guest93713 is now known as tonyyarusso | ||
| jam | I thought http://www.anandtech.com/storage/showdoc.aspx?i=3631 was a pretty good article on it. | 19:09 |
| jam | http://www.anandtech.com/storage/showdoc.aspx?i=3631&p=6 has a specific focus on wear leveling | 19:09 |
| jam | which is "writing 7GB of data to disk per day will take ~986 years to wear out all 10k cycles" | 19:09 |
| jam | so even if that is off by 20x or so | 19:10 |
| jam | it still has a reasonable safety margin | 19:10 |
| fullermd | I'm aware of the claims made. I don't buy them yet, by quite a ways. | 19:10 |
| jam | the main thing for me was that I could get a 250GB drive as a "free upgrade" or pay $300 for an 80GB SSD for my laptop | 19:11 |
| jam | at $1k for the laptop, 30% for the hardrive was a bit more than I wanted to spend | 19:11 |
| jam | though sometimes I sure wish I had... | 19:12 |
| jam | note, though, that I don't expect my laptop to last me 10 years anyway. | 19:12 |
| fullermd | Well, a laptop would be a different story :p | 19:12 |
| fullermd | I don't expect that much longevity, don't put important data on it, and laptop drives are scary crap in the first place. | 19:12 |
| jam | fullermd: besides, if you really cared, you'd put it all on tape with a lifetime of 30 years and a rewrite of 1M cycles :) | 19:13 |
| fullermd | But I've got Velociraptors in this workstation, and SCSI drives for the years before that. More IOPS would be nice, but I don't spend all that much time waiting on them. | 19:13 |
| fullermd | Man, I've used *WAY* too much tape to trust a 30 year figure for that :p | 19:13 |
| jam | fullermd: well it depends if you put it in controlled storage | 19:14 |
| jam | or leave it on your desk under the coffee cup | 19:14 |
| fullermd | Yeah, I don't have quite enough free cash to build a climate controlled storage closet for backup tapes in my house... | 19:15 |
| fullermd | Maybe after I win the lottery. | 19:15 |
| LarstiQ | :) | 19:15 |
| LarstiQ | fullermd: mine is, of course, a laptop | 19:16 |
| jam | fullermd: I would think a cardboard box full of LTO tapes would still out-last your raptors :) | 19:16 |
| jam | LarstiQ: mine is launchpad | 19:16 |
| jam | ... | 19:16 |
| fullermd | Unless you've got a 7 digit backup budget, hard drives are the best and most reliable backup means around these days. | 19:16 |
| fullermd | I wouldn't. I don't have faith in tapes lasting more than a year or two (never mind the relative costs of tape vs. HDD) | 19:17 |
| Peng_ | Was this the channel that suggested beaming your data into space, then inventing FTL travel to go record the signal whenever you need it? | 19:18 |
| fullermd | What a terrible idea. Who wants to look at a bunch of red-shifted pr0n? | 19:18 |
| * Peng_ wonders why pushing the last 2 revs of bzr.dev took 1100+ KB of data transfer. | 19:21 | |
| luks | indexes? | 19:23 |
| jam | Peng_: the last 2 revs probably include the merges from the releases I made | 19:25 |
| jam | so it is a bunch of changes to NEWS, and probably some non-trivial amount of history | 19:25 |
| jfroy|work | verterok: pushed another revision to update the package content and readmes :| | 19:29 |
| Peng_ | jam: Duh, you're right. jam++. Pulling them was quick because I already had most of the revisions in the repo from the 2.0 etc. branches, but the repo I pushed to didn't. | 19:30 |
| verterok | jfroy|work: ok, I'll merge it tonigh. thanks! | 19:30 |
| Peng_ | Although it was still barely 300 KB of packs+indices. | 19:30 |
| jam | jelmer: ping if you are around. 'lp:bzr-rewrite' has a tag for 'bzr-rewrite-0.5.4' but that revision is not in the ancestry of "bzr branch lp:bzr-rewrite" | 19:49 |
| jam | which points over to your http://people.samba.org branches | 19:49 |
| jam | jfroy|work: are you working on 2.1.0b1 packages? | 19:51 |
| jfroy|work | No | 19:51 |
| jfroy|work | Well, not today. | 19:51 |
| jfroy|work | I have very limited time for doing packaging... | 19:51 |
| jfroy|work | (not my day job, etc.) | 19:51 |
| jfroy|work | I'll try to get around to it | 19:52 |
| jam | LarstiQ / jelmer: Where is the 'bzr.debian.org' branches? | 19:56 |
| === oubiwann_ is now known as oubiwann | ||
| LarstiQ | jam: http://bzr.debian.org/pkg-bazaar/ you mean? | 19:56 |
| jam | probably | 19:57 |
| jam | thanks | 19:57 |
| jam | mostly I'm trying to find the 0.5.4 revision | 19:57 |
| jam | which doesn't seem to exist anywhere I can get to yet | 19:57 |
| jam | (I'm guessing jelmer merged it to trunk, but forgot to commit before pushing) | 19:57 |
| jam | it seems his "unstable" branch also has the tag but not the revision... :( | 20:01 |
| LarstiQ | jam: and his samba.org branches? | 20:09 |
| jam | LarstiQ: well, the official trunk doesn't have it | 20:10 |
| jam | are there other samba branches to check? | 20:10 |
| LarstiQ | ah no, sorry | 20:11 |
| jam | anyway, for now I'll just downgrade to 0.5.3 since I can find that one | 20:13 |
| jam | brb, rebooting | 20:13 |
| mathepic | For fixing a small bug (which is more of a feature request), for NEWS, do I put the bugfix under 2.1.0 or 2.0.2? | 20:15 |
| === sdboyer_ is now known as sdboyer | ||
| Peng_ | jam: <333 | 21:20 |
| Peng_ | (I hope that didn't make his computer beep.) | 21:21 |
| jam | Peng_: of course it did, but why the love? | 21:21 |
| Peng_ | jam: "(jam) Start using StaticTuple as part of the btree_index parsing code." | 21:22 |
| Peng_ | Plus, why not? Love is fun! | 21:22 |
| === jam changed the topic of #bzr to: Bazaar version control system | 2.0.1 and 2.1.0b1 has gone gold! start building those installers | try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | ||
| === jam changed the topic of #bzr to: Bazaar version control system | 2.0.1 and 2.1.0b1 have gone gold! start building those installers | try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | ||
| jam | Peng_: love is grand, I just figured you had a specific reason :) | 21:24 |
| * Peng_ wonders how many StaticTuples Loggerhead will create. | 21:24 | |
| awilkins | Will that make things fast? It has C in it. Vitamin C. | 21:25 |
| mwhudson | it will make things small, is the idea | 21:25 |
| mwhudson | small is fast to some extent though | 21:25 |
| jam | mwhudson: actually it makes things faster than smaller | 21:25 |
| jam | as an interesting side effect | 21:25 |
| mwhudson | jam: really? | 21:25 |
| mwhudson | oh right | 21:25 |
| Peng_ | All the StaticTuples in the world wouldn't make Loggerhead "small". | 21:25 |
| jam | mwhudson: well for "bzr branch launchpad" it made it 17% smaller and 40% faster | 21:25 |
| mwhudson | oh yeah, less objects doing gc | 21:25 |
| jam | mwhudson: right | 21:26 |
| awilkins | I find the smaller you make things the more they fit in the CPU cache | 21:26 |
| jam | awilkins: true, but in this case it is GC overhead | 21:26 |
| jam | and when you have 500MB, *nothing* fits in CPU cache :) | 21:26 |
| Peng_ | That'd be an awesome CPU. | 21:27 |
| mwhudson | jam: is there any progress on ways to do branch without the whole index? | 21:27 |
| awilkins | I think modern CPUs are pretty awesome anyway | 21:28 |
| jam | *argh* the windows installers just refuse to build... | 21:28 |
| jam | mwhudson: even if we do it in pieces, I think we'll end up caching most of the index | 21:28 |
| awilkins | Bah, I deleted my win32 build VM | 21:28 |
| jam | however, last check shows that bulk of memory is in the groupcompress block caches | 21:28 |
| jam | w/ ~160MB in or "LRUSizeCache(50MB)" | 21:28 |
| Peng_ | So far, peak of 110,000 tuples. Dozer doesn't see any StaticTuples. | 21:28 |
| jam | in our | 21:28 |
| jam | Peng_: you did "make" again, right? | 21:29 |
| jam | Peng_: and Dozer won't see StaticTuples | 21:29 |
| jam | because they aren't in gc.get_objects() | 21:29 |
| Peng_ | Oh, of course. No fun! | 21:29 |
| jam | just as, I'm pretty sure, it won't see Strings | 21:29 |
| jam | mwhudson: though I'm still concerned that Meliae shows 250MB when 'debug_memory()' shows 500MB in use. | 21:29 |
| Peng_ | You're right, no __builtin__.str or __builtin__.int. | 21:30 |
| jam | Peng_: yeah, and for us, a *lot* of memory can be in strs | 21:30 |
| jam | mwhudson: anyway, my target is to cut memory consumption to about 50% for 'bzr branch launchpad', which should be reasonably attainable | 21:30 |
| jam | I'm just worried that I'll cut X amount of memory, and have no clue where the rest is | 21:31 |
| mwhudson | jam: still, that'd be cool | 21:31 |
| jam | sure | 21:32 |
| jam | Peng_: and we still have quite a few code paths that can be tweaked to use StaticTuple | 21:33 |
| jam | like the fetch code re-converts all the StaticTuples back to regular tuples for the target repo, etc. | 21:33 |
| fullermd | Well, you want it cut it in half, and Meliae is showing half of the usage. So just eliminate everything it shows, and you're done ;) | 21:35 |
| dash | Hm | 21:35 |
| dash | is is safe to delete things in .bzr/repository/obsolete_packs or do those still contain actual data | 21:36 |
| jam | dash: generally you can remove the files from obsolete_packs, just don't remove the directory itself | 21:36 |
| dash | OK | 21:36 |
| dash | it's just bigger than the 'packs' dir now :) | 21:37 |
| jam | they contain the "previous copy", as we can't really be sure that the OS will sync things in the order that we've written them | 21:37 |
| dash | cool | 21:37 |
| jam | (if we deleted them ourselves, the OS may decide to write the 'delete' down before it writes the "and write all this data over here".) | 21:38 |
| dash | well it looks like 'bzr upgrade' worked fine on a machine with a decent amount of RAM. | 21:38 |
| dash | filesystems are pretty bad, yeah. | 21:38 |
| jam | naoki: ping, I'm having some troubles building the win32 installers, I'm getting an error of: | 21:41 |
| jam | "no module named 'tbzr'" | 21:41 |
| jam | any ideas? | 21:41 |
| jam | mwhudson: what is "ellipsis" ? | 22:01 |
| mwhudson | jam: a total weird appendix-like useless thing | 22:01 |
| jam | mwhudson: hm... I have a list that 1.5MB in size, and the first entry is "ellipsis" and the next two are "imp.NullImporter"... | 22:02 |
| mwhudson | jam: weird | 22:02 |
| mwhudson | jam: it's used by numeric | 22:02 |
| mwhudson | http://pastebin.ubuntu.com/294223/ | 22:02 |
| mwhudson | jam: and, it seems, by something else! | 22:03 |
| mwhudson | jam: is it sys.path_importer_cache or something? | 22:03 |
| jam | at the end of this list is some big strings | 22:03 |
| jam | I'm almost wondering if it something like a stack frame | 22:03 |
| jam | ah... I think I did 'gc.get_objects()' in the debugger | 22:06 |
| jam | and it is dumping extra stuff | 22:06 |
| jam | probably self refers to the local function refers to the local frame, and that makes things screwy | 22:06 |
| jam | not sure ,though | 22:06 |
| jam | mwhudson: One sucky thing about debugging memory in meliae, is that normal objects have a dict attribute, which is "in the way" between the instance and its attributes | 22:11 |
| jam | I'm wondering if there would be a reasonable way to collapse that structure | 22:11 |
| mwhudson | jam: yeah | 22:11 |
| mwhudson | you get that when debugging via gc.get_referrents too | 22:11 |
| jam | especially since most members will have one reference to a string, as the name of the member | 22:11 |
| mwhudson | jam: there are probably some heuristics we could use | 22:11 |
| jam | and the next entry is the actual object | 22:11 |
| jam | which means you *could* recreate something nice looking | 22:11 |
| jam | maybe | 22:11 |
| jam | anyway, I *think* I'm seeing that GroupCompressBlock somehow contains a direct pointer to itself | 22:12 |
| mwhudson | jam: also, when tp_traverse yields the object at tp_dictoffset in the object, you can treat that specially | 22:12 |
| jam | which is probably screwing up GC | 22:12 |
| jam | mwhudson: interesting thought | 22:12 |
| mwhudson | jam: you mean instance.attribute = instance ? | 22:13 |
| jam | mwhudson: that is what it looks like | 22:13 |
| mwhudson | jam: the gc should cope fine with that | 22:13 |
| mwhudson | i guess it won't be terribly performant | 22:13 |
| mwhudson | but it shouldn't leak | 22:13 |
| jam | ah, I see what it was | 22:14 |
| jam | I was getting "refs" confused with "referrers" | 22:14 |
| jam | because of wrapping issues | 22:14 |
| jam | so it was just me | 22:14 |
| mwhudson | :) | 22:14 |
| jam | mwhudson: anyway, I'd really like to get a gui on this | 22:14 |
| jam | but I'm not sure how to represent it | 22:15 |
| jam | having a "dot" graph that I could expand would be cool | 22:15 |
| mwhudson | pypy has a pygame graph viewer | 22:15 |
| jam | I've looked a bit at "runsnakerun" which has a square-map stuff | 22:16 |
| jam | the main problem is the cycles | 22:16 |
| jam | as you end up with infinite recursion which doesn't display so well :) | 22:16 |
| mwhudson | well, i'd hope a graph viewer would expect cycles really | 22:17 |
| jelmer | jam: bzr-rewrite tag should be fixed; sorry about that | 22:20 |
| jam | well, runsnakerun is meant to track how time is spent (similar to kcachegrind), and there is some recursion there, but not really infinite cycles :) | 22:21 |
| jam | mwhudson: anyway, thanks for the pointer, I'll take a look | 22:21 |
| mwhudson | jam: ah | 22:23 |
| mwhudson | jam: it'll probably require some head scratching and hacking | 22:24 |
| jam | mwhudson: and pygame and numpy and ... | 22:24 |
| jam | but I'll get there | 22:24 |
| jam | also, I'm doing a checkout of pypy and it... just keeps going | 22:24 |
| jam | I'm only grabbing "dist" and its already at 20MB | 22:25 |
| mwhudson | it's pretty heft | 22:25 |
| mwhudson | y | 22:25 |
| mwhudson | my svn checkout is 192 megs | 22:26 |
| mwhudson | probably has some .o files and so on in it though | 22:26 |
| jam | mwhudson: argh.... and pygame may not even be *in* dist... | 22:26 |
| jam | pypy/translator/tool/pygame/ isn't in my checkout yet, at least, though pypy/translator/tool/ is | 22:26 |
| mwhudson | oh maybe it's an external | 22:26 |
| jam | download done, and I did set 'fully recursive'.... | 22:27 |
| jam | hm... .../pygame isn't in trunk either | 22:30 |
| jam | maybe they just deleted it? | 22:30 |
| jam | the mailing list entry I see is from 2004 | 22:31 |
| jam | naoki: it is probably your recent change to setup.py that I need.... damn, out-of-order changes... | 22:33 |
| Peng_ | Loggerhead's peak number of tuples is still over 400,000, so I'm not sure StaticTuple helped much. OTOH, RAM usage might be suspiciously low. | 22:36 |
| jam | mwhudson: do you have a copy of it in your checkout, such that you might help point me to the correct location | 22:37 |
| jam | ? | 22:37 |
| jam | Peng_: what branch are you viewing? | 22:37 |
| mwhudson | jam: i can try and find it | 22:37 |
| jam | "bzr branch launchpad" can create 1.8M tuples | 22:37 |
| Peng_ | jam: I'm just looking at my Loggerhead instance, which gets random traffic from Googlebot. | 22:39 |
| Peng_ | Because I'm being completely unscientific, it's hard to say anything for sure. :\ | 22:39 |
| jam | Peng_: so StaticTuple isn't a 'it just works' you have to go around using it... :) | 22:39 |
| mwhudson | jam: probably you should ask in #pypy when europe is awake | 22:39 |
| jam | however, the Btree reader uses it, which is generally a main source of tuples | 22:39 |
| jam | mwhudson: what is 'pyrepl' given that it is (c) you and imports pygame | 22:43 |
| jam | otherwise it looks like "translator/goal/translate" may be what I want | 22:44 |
| jam | or maybe "dotviewer" up above the 'pypy' sources | 22:46 |
| Peng_ | I'm afraid to look at Dozer's HTML page listing all of the thousands of tuples. | 22:47 |
| jam | mwhudson: it looks like "dotviewer.py" is a generic method for viewing .dot files, which I can easily generate | 22:48 |
| Peng_ | OK, I stopped loading the list of tuples after 400 MB of RAM was used. :D | 22:58 |
| Peng_ | That was about...35 MB of HTML total. | 22:59 |
| Peng_ | I have lots of lists with tuples with revids and stuff in them, from Loggerhead's graph caches. | 23:05 |
| Peng_ | I have lists of stuff like "('equal', 507, 510, 511, 514)". Diffs, I guess? | 23:08 |
| Peng_ | That looks like a nice place for StaticTuple. | 23:08 |
| mwhudson | jam: yeah, dotviewer | 23:09 |
| mwhudson | jam: pyrepl is a command line interface that supports multiline editing | 23:09 |
| jam | Peng_: well, ATM StaticTuple won't accept ints, but we can change that | 23:13 |
| jam | and yes, both places would be good for ST | 23:13 |
| Peng_ | FWIW, anyone else can wade through my Dozer stuff too, if you want to: http://bzr.mattnordhoff.com/loggerhead/_dozer/index | 23:14 |
| Peng_ | Seems Dozer *is* aware of strings, when it's aware of an object referring to one. | 23:14 |
| Peng_ | StaticTuple too. | 23:15 |
| Peng_ | but it can't actually show any information about them. | 23:16 |
| jam | well they aren't in the GC so "gc.get_referents()" returns nothing | 23:16 |
| jam | though I *do* implement tp_traverse | 23:16 |
| jam | and meliae knows how to use that | 23:16 |
| jam | my system is unhappy about my 30MB dot dump :) | 23:17 |
| jam | no doubt having 1 object referring to *everything* doesn't help :) | 23:17 |
| jam | anyway, EOD | 23:17 |
| jam | thanks for the pointer mwhudson | 23:17 |
| mwhudson | jam: np | 23:18 |
| awilkins | Heh, I'm also memory optimizing on my Java stuff, must be catching | 23:18 |
| Peng_ | A large portion of LH's tuples are just normal stuff, not torrents of data. | 23:18 |
| mwhudson | Peng_: a lot of loggerheads tuples will be the merge sorted revision graph i bet | 23:19 |
| mwhudson | which could use static tuples i guess | 23:20 |
| Peng_ | Maybe 40%. | 23:20 |
| Peng_ | There's a frightening amount of the "normal stuff". | 23:20 |
| mwhudson | Peng_: what do you mean by that? | 23:20 |
| Peng_ | mwhudson: There are tens of thousands of tuples with stuff like None or VfsRequest or docstrings or bits of TAL templates. | 23:21 |
| Peng_ | mwhudson: Things like the graph are in the minority. | 23:21 |
| Peng_ | Actually, I forgot, I stopped loading the page 4 MB before the end. So maybe things like the graph are, ehh, up to 60%? | 23:23 |
| Peng_ | Lists, OTOH, are dominated by the revision graph. | 23:24 |
| mwhudson | jam: i'm told that http://codespeak.net/svn/pypy/trunk/pypy/translator/tool/reftracker.py might be interesting | 23:25 |
| mwhudson | loggerhead should use statictuple for that if it can | 23:25 |
| mwhudson | it may not help much but it will certainly help and not hurt | 23:25 |
| Peng_ | Software sure is complicated. | 23:27 |
| Peng_ | I never really think about the _scale_ of it all. | 23:27 |
| mwhudson | jam: and http://domino.research.ibm.com/comm/research_people.nsf/pages/nickmitchell.pubs.html | 23:27 |
| mwhudson | "Making Sense of Large Heaps" | 23:28 |
| Peng_ | What should Loggerhead do for static tuples when used with older versions of bzr? Storing a copy of _static_tuple_py.py is actualyl pretty reasonable. | 23:34 |
| Peng_ | s/storing/bundling/ | 23:34 |
| mwhudson | Peng_: yeah, that might work | 23:36 |
| * Peng_ goes with that. | 23:43 | |
| Peng_ | Peng_ almost wants to go crazy and use StaticTuples *everywhere* possible. | 23:45 |
| igc | morning | 23:47 |
| === oubiwann_ is now known as oubiwann | ||
| Peng_ | Is it just me or is "_revision_graph.keys()" a somewhat bad idea? | 23:56 |
| mwhudson | Peng_: yes, probably | 23:57 |
| Peng_ | Such a bad idea that mwhudson ran away? | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
