| thumper | james_w: ping | 00:06 |
|---|---|---|
| james_w | hi hi | 00:06 |
| === mthaddon is now known as afk | ||
| === BasicTheProgram is now known as BasicOSX | ||
| lifeless | meep | 00:42 |
| lifeless | something very odd: | 00:43 |
| jam | lifeless: I just set you an update about iter_interesting... did it make sense? | 00:43 |
| lifeless | g$ bzr info lp:~mordred/libcpuinfo/add-bindings | 00:43 |
| lifeless | bzr: ERROR: Server sent an unexpected error: ('error', 'No repository present: "lp-49592784:///~mordred/libcpuinfo/add-bindings"') | 00:43 |
| lifeless | but merging from http://b.l.n. works | 00:43 |
| lifeless | if someone could reproduce that would be great | 00:44 |
| jam | lifeless: 'bzr info lp:...' works here | 00:45 |
| jam | I do see: | 00:46 |
| jam | public branch: http://bazaar.launchpad.net/%7Emordred/libcpuinfo/add-bindings | 00:46 |
| jam | parent branch: lp-hosted:///%7Elibcpuinfo-developers/libcpuinfo/trunk/ | 00:46 |
| jam | stacked on: /~libcpuinfo-developers/libcpuinfo/trunk | 00:46 |
| jam | the 'lp-hosted' specifically looks weird | 00:46 |
| lifeless | jam: its plausible | 00:46 |
| lifeless | jam: the parent branch won't be followed though | 00:47 |
| lifeless | jam: are you lp-login'd? | 00:47 |
| jam | lifeless: yes | 00:47 |
| lifeless | [its plausible] - the iter_interesting | 00:47 |
| jam | lifeless: I figured | 00:47 |
| Peng_ | I just tried "bzr info" over lp: (logged in). I mostly concur with jam, except I saw a shared repo line, not a public branch line. | 00:47 |
| lifeless | yes, interesting things cannot be in *any* uninsteresting page | 00:47 |
| jam | lifeless: "bzr info http://b.l.n" works, too | 00:48 |
| lifeless | http:// works for me | 00:48 |
| mwhudson | i see the same as lifeless | 00:48 |
| lifeless | mwhudson: great. | 00:48 |
| mwhudson | i bet the difference here is that lifeless and i have branch super powers | 00:48 |
| mwhudson | and are seeing the hosted area | 00:48 |
| lifeless | https://code.edge.launchpad.net/~mordred/libcpuinfo/add-bindings | 00:48 |
| lifeless | it looks like it is a hosted branch | 00:49 |
| mwhudson | and well | 00:49 |
| mwhudson | there's no repository there | 00:50 |
| mwhudson | lifeless: https://pastebin.canonical.com/18971/ | 00:50 |
| lifeless | ?! | 00:50 |
| lifeless | I'll ask monty when he returns | 00:50 |
| jam | mwhudson: so you're saying that it didn't mirror the broken repo to the public side | 00:52 |
| jam | and thus non-super people like me and Peng see everything as ok | 00:52 |
| mwhudson | jam: i am not intepreting anything! | 00:52 |
| mwhudson | jam: but yes, that seems likely | 00:52 |
| mwhudson | there's probably an oops from the puller somewhere | 00:52 |
| jam | lifeless: could be in the middle of an upgrade? | 00:53 |
| lifeless | he asked me to look at it; I don't think he'd have done that just before starting an upgrade | 00:53 |
| jam | lifeless: unless he was asking you why it was broken :) | 00:54 |
| poolie | jam, want to resume? | 00:56 |
| jam | poolie: yes, though my wife is away, so I'm watching my son | 00:57 |
| lifeless | jam: no, he asked me to review it | 00:57 |
| jam | phone would probably work better | 00:57 |
| igc | morning | 01:17 |
| lifeless | jam: so, let me know when you're stopping working on the bug and I'll pick up from there | 01:19 |
| jam | lifeless: I'm done | 01:20 |
| lifeless | kk | 01:22 |
| jelmer | rocky: that's not specific to bzr-svn, deleting tags doesn't propagate inside of bzr in general | 01:42 |
| rocky | jelmer: so there's no way to delete a tag? | 01:43 |
| jelmer | rocky: push --overwrite might delete a tag | 01:44 |
| jelmer | IIRC | 01:44 |
| Peng_ | Yeah, I think so. | 01:45 |
| mwhudson | damn loggerhead's way of making you fix a bunch of bugs at once! | 01:48 |
| lifeless | because it has so many? | 01:48 |
| mwhudson | yes | 01:50 |
| mwhudson | still, it's only 250 lines | 01:54 |
| mwhudson | Peng_: want to review a branch? :) | 01:54 |
| Peng_ | mwhudson: Sure. | 01:54 |
| Peng_ | mwhudson: I'll probably wind up saying "it seems ok to me, but you should really ask beuno", though. :P | 01:54 |
| mwhudson | yeah | 01:55 |
| Peng_ | mwhudson: no-transport-sharing? | 01:59 |
| Peng_ | mwhudson: I think you have the logic backwards in check_serveable. | 01:59 |
| mwhudson | Peng_: yeah | 01:59 |
| mwhudson | oh yes | 01:59 |
| mwhudson | writing up a merge proposal now | 02:00 |
| Peng_ | If a thread exits, will its threading.local stuff automatically get cleaned up? | 02:01 |
| mwhudson | not sure | 02:02 |
| mwhudson | probably not | 02:02 |
| Peng_ | Leaking a transport every 100 requests (by default) wouldn't be very nice/ | 02:03 |
| lifeless | uhm | 02:06 |
| lifeless | I'd expect threading.local to get dereferenced | 02:06 |
| lifeless | otherwise its a huge bug in python :) | 02:07 |
| Peng_ | Haha. | 02:07 |
| lifeless | check the module source if you need to | 02:07 |
| Peng_ | I did once. I wasn't curious enough at the time to try to understand it. :P | 02:08 |
| Peng_ | And I only checked the Python version, not the C version that actually gets used on most platforms. | 02:08 |
| lifeless | so there is a wrapper around each thread | 02:11 |
| lifeless | I'd expect the wrapper to have a list of threading.local instances, and tell them all at thread exit | 02:11 |
| Peng_ | _threading_local.py uses attributes on threading.current_thread() to store the thread-local data, so it'd probably be okay? | 02:12 |
| mwhudson | the data is stored in the threadstate it seems | 02:13 |
| mwhudson | so it will die with the thread | 02:13 |
| mwhudson | (in the c implementation) | 02:13 |
| Peng_ | Wait, what broke HTTP serving was the stupid readonly+ decorator? Ouch. | 02:14 |
| mwhudson | Peng_: yes | 02:14 |
| mwhudson | Peng_: hey, you know what are really really great? | 02:15 |
| Peng_ | Cupcakes! | 02:15 |
| mwhudson | i was going to say tests, but you're also right | 02:15 |
| mwhudson | i guess docstrings are nice too | 02:15 |
| Peng_ | What's even better are interns to get you cupcakes, docstrings and unit tests. | 02:16 |
| jml | I would like a cupcake. | 02:22 |
| lifeless | Peng_: I did suggest not doing readonly+ :P | 02:29 |
| Peng_ | lifeless: :( | 02:29 |
| lifeless | Peng_: actually no. I suggested not requiring it :) | 02:29 |
| mwhudson | Peng_: LocationConfig doesn't open a transport afaict | 02:46 |
| mwhudson | it looks up locations by url in the ~/.bazaar/locations.conf file | 02:46 |
| Peng_ | mwhudson: Oh, OK. | 02:47 |
| Peng_ | mwhudson: ...If locations.conf is broken, will it explode, and do we care? | 02:47 |
| mwhudson | Peng_: so will everything else though? | 02:47 |
| mwhudson | i'm not sure i care very much | 02:48 |
| Peng_ | Heh, probably. I'm OK with that, then. :) | 02:48 |
| mwhudson | uh | 02:54 |
| mwhudson | the date on this launchpad bugmail is highly unbelievable | 02:54 |
| mwhudson | (i.e. it's in the future) | 02:55 |
| Peng_ | Oh? Which one? | 02:55 |
| mwhudson | Peng_: when you assigned the 'serve over http is broken' to me | 02:55 |
| Peng_ | I got "Date: Thu, 25 Jun 2009 01:36:37 -0000", which is correct. | 02:56 |
| mwhudson | Date: Thu, 25 Jun 2009 02:36:38 -0000 | 02:56 |
| Peng_ | Wow. | 02:56 |
| RenatoSilva | Is BzrEclipse compatible with Eclipse Galileo? | 02:56 |
| Peng_ | Hello, Daylight Saving Time. Meet Launchpad. | 02:56 |
| mwhudson | Peng_: i'm a little bit scared as to how this is possible :) | 02:57 |
| mwhudson | Peng_: which machine was yours sent from? | 02:57 |
| Peng_ | mwhudson: If you're receiving bugmail from the future, you could file bugs before people get the chance to and steal the credit! | 02:57 |
| mwhudson | mine was 'potassium' it seems | 02:57 |
| Peng_ | From what, the Recieved headers? | 02:58 |
| Peng_ | loganberry -> adelie (IIRC) -> my mail server. | 02:59 |
| Peng_ | Notably, both were BST (GMT+1) | 02:59 |
| mwhudson | ok, mine was a very different path | 02:59 |
| mwhudson | which is good, i guess | 02:59 |
| Peng_ | Might've been Adelaide or something. I can't remember, and my mail client is swapping. | 02:59 |
| Peng_ | Oh, adelie. | 02:59 |
| Peng_ | mwhudson: Oh, the message-id is indeed potassium. | 03:00 |
| mwhudson | <20090625013638.19816.53674.launchpad@potassium.ubuntu.com> ? | 03:00 |
| mwhudson | i guess the launchpad user's TZ is set wrong on that machine or something | 03:00 |
| Peng_ | Message-Id: <20090625013638.19816.85527.launchpad@potassium.ubuntu.com> | 03:00 |
| mwhudson | huh | 03:01 |
| mwhudson | i have no idea how this code works :) | 03:01 |
| * mwhudson emails the sysadmins | 03:01 | |
| * Peng_ brushes his teeth. | 03:03 | |
| Peng_ | brb | 03:03 |
| lifeless | abentley: is there a bug open for the fetch errors you're experiencing? | 03:09 |
| abentley | lifeless: I don't know. | 03:11 |
| === abentley1 is now known as abentley | ||
| abentley | lifeless: You know that this was discussed in the canonical-bazaar thread "Ongoing problems with inconsistent revisions in Launchpad trunk", right? | 03:35 |
| Peng_ | "canonical-bazaar"? | 03:36 |
| abentley | Peng: The canonical employees' list for discussions related to bazaar. | 03:39 |
| * Peng_ feels left out. :P | 03:39 | |
| abentley | Peng_: It doesn't get a lot of traffic. | 03:40 |
| fullermd | Peng_: Why? Obviously being on the list makes you have problems ;) | 03:40 |
| Peng_ | Heh. | 03:40 |
| abentley | fullermd: No, only people with problems are allowed on the list :-) | 03:40 |
| * fullermd quickly hides his invitation. | 03:41 | |
| === abentley1 is now known as abentley | ||
| === abentley1 is now known as abentley | ||
| lifeless | abentley: I've re-read the thread; it didn't seem to talk about the proposed solution | 04:59 |
| lifeless | abentley: I agree that this is an important thing to correct | 04:59 |
| === abentley1 is now known as abentley | ||
| abentley | lifeless: Yeah, it mostly covers the investigation of the situation. I thought that was what you were looking for. | 05:05 |
| lifeless | abentley: I want a backtrace I think; I want to make reconcile faster, but I need to make sure it will still catch these bits of data | 05:06 |
| lifeless | the new KnownGraph thing may be an easy-grasp item to make reconcile _much_ faster. | 05:07 |
| abentley | lifeless: backtrace is in the first message. | 05:08 |
| lifeless | abentley: ah cool. | 05:08 |
| lifeless | I'll turn it into a bug | 05:08 |
| abentley | lifeless: My problem repository is at devpad:/home/abentley/branches | 05:08 |
| === abentley1 is now known as abentley | ||
| poolie | lifeless: see you soon | 05:57 |
| lifeless | yeehaw | 05:59 |
| jml | spiv, I want to hook into the smart server so that I logged an OOPS on unexpected errors | 06:51 |
| jml | spiv, where's the best place to hook in? | 06:51 |
| jml | at the moment, I'm considering monkeypatching log_exception_quitely | 06:53 |
| jml | quietly. | 06:53 |
| ree | hi All! I pushed a branch to a different location (on launchpad) and it became stacked for some reason. Is there any way to make it non-stacked? I would not like it to depend on the old location | 06:57 |
| ree | I find no --nostacked option.... how is stacking prohibited? | 06:58 |
| lifeless | ree: there isn't a command line way to do it at the moment | 07:02 |
| lifeless | ree: I don't understand the issue though? | 07:02 |
| ree | ok, so is it a problem if it's stacked? The launchpad ui says it's stacked on the old location. What if the old location is removed? I would like to keep the new branch location independent from the old one | 07:03 |
| ree | lifeless, ^ | 07:04 |
| lifeless | ree: well, lp won't let you remove the series branch | 07:04 |
| lifeless | ree: as its used by other branches to stack on - not just branches of your own; anyone pushing to that project | 07:05 |
| ree | the trunk was under my own username, and I want to move it to under a group, so I can share access | 07:05 |
| ree | I thought in bzr the full branch history is stored in every repo... now this seems to be not like this with stacking. I also would like to find the way in general, to make a repo unstacked | 07:06 |
| ree | is there a way to "flatten out" a repo? Remove all stacking and get all history be local? | 07:07 |
| ree | lifeless, ^ | 07:08 |
| spiv | jml: yes, that's probably the best option at the moment. | 07:09 |
| spiv | jml: In the background I've recently started thinking about how to do that better, but for now hooking into where log_exception_quietly goes is the simplest route I can think of. | 07:10 |
| jml | spiv, thanks. | 07:23 |
| jml | spiv, why doesn't bzr use log.exception for that? | 07:23 |
| jml | (I'm guessing performance, but it's worth asking) | 07:24 |
| spiv | jml: you mean logging.exception? Not sure for this particular case. | 07:26 |
| spiv | I personally wouldn't expect log_exception_quietly to be performance-sensitive... if you're calling it, something has gone wrong, so speed isn't a massive concern. | 07:27 |
| jml | spiv, trace._bzr_logger.exception is what I mean in particular. | 07:28 |
| jml | hmm. I guess that's a simple patch to try out. | 07:29 |
| lifeless | ree: local branches on your pc will be not be stacked | 07:37 |
| lifeless | ree: for server side branches, stacking is a *huge* space saver | 07:37 |
| lifeless | ree: and you should be able to move the branch to a shared branch without problems; if you have any we can recover via the python API | 07:37 |
| lifeless | ree: (just ask a question on answers.launchpad.net/launchpad-code, if noone here or in #launchpad is around/able to help immediately) | 07:38 |
| lifeless | jml: do you mean logging.exception ? | 07:38 |
| lifeless | jml: because logging was a huge performance suck for us, IIRC | 07:38 |
| ree | lifeless, thanks! I have to go now, I'll experiment around. | 07:38 |
| jml | lifeless, logging is being used for note & error, just not log_exception_quietly | 07:40 |
| lifeless | jml: hmm, not sure then. | 07:41 |
| lifeless | jml: I do recall us having performance issues tied into using logging for multiple levels of output | 07:42 |
| jml | lifeless, I can easily believe that. :) | 07:42 |
| jml | lifeless, but as spiv says, I wouldn't expect log_exception_quietly to be particularly performance-sensitive. | 07:43 |
| jml | what'd be the best way of evaluating the performance impact? | 07:43 |
| lifeless | test? :P | 07:46 |
| lifeless | I'm struggling to think of a scenario where we'd be logging high volumes of exceptions though | 07:47 |
| spiv | Yeah, me too. | 07:47 |
| lifeless | as we stop what we're doing when we choose to log exceptions | 07:47 |
| spiv | I'd think any case where we're logging high volumes of exceptions that the right answer would be "stop doing that" rather than make it fast. | 07:48 |
| spiv | I'd expect the highest-volume producer of bzrlib exceptions is probably Launchpad :) | 07:48 |
| jml | :D | 07:49 |
| poolie | spiv, hi, still around? how did you go on network deltas? | 08:34 |
| jml | lifeless, just double checking: bug 365615 is fixed in trunk, should be CPd to Launchpad and should (not 'must') go into 1.16.1... | 08:36 |
| ubottu | Launchpad bug 365615 in bzr/1.16 "'AbsentContentFactory' object has no attribute 'get_bytes_as' errors with CHK repository on write operations" [Critical,Fix committed] https://launchpad.net/bugs/365615 | 08:36 |
| jml | bug 390563 still needs to be fixed (there's a cheap-but-slow fix and an expensive-but-performant fix), it has to go into 1.16.1 and be CPd to Launchpad | 08:37 |
| ubottu | Launchpad bug 390563 in bzr "absent factory exception from smart server when streaming 2a stacked branches" [Critical,Triaged] https://launchpad.net/bugs/390563 | 08:37 |
| lifeless | jml: 365615 yes | 08:38 |
| lifeless | 390563 is in progress | 08:38 |
| lifeless | no fixes completed yet; have code for a candidate in front of me now | 08:39 |
| jml | lifeless, sweet. | 08:39 |
| jml | any other bugs that I need to be watching, either as RM or as LP/Bazaar person? | 08:41 |
| * jml looks over the Critical bug list | 08:41 | |
| jml | I obviously don't know how to use "Target to release" | 08:43 |
| lifeless | jml: yes, but let me get this done first | 08:48 |
| jml | lifeless, no worries. | 08:48 |
| kfogel | poolie: you explained to me once why Bazaar trunk itself is not on 1.16, but I can't remember the answer. What was it? | 08:52 |
| kfogel | poolie: (a mere hint might be enough :-) ) | 08:53 |
| asabil | bialix: ping ? | 08:54 |
| lifeless | kfogel: because wee've moved on? | 09:03 |
| lifeless | kfogel: we don't release from trunk | 09:03 |
| kfogel | lifeless: not sure I understand. IIRC, if I branch Bazaar's bleeding-edge development trunk, the branch will not be in 2a, but in something older. Is that still right? | 09:04 |
| lifeless | kfogel: oh, that isn't what you asked | 09:04 |
| kfogel | lifeless: sorry | 09:04 |
| lifeless | kfogel: two reasons; one we know its broken at the moment. | 09:04 |
| kfogel | *nod* | 09:04 |
| lifeless | we're trying to fix it | 09:04 |
| lifeless | secondly, we knew it was broken, and were trying to fix it | 09:04 |
| kfogel | lifeless: :-) | 09:04 |
| lifeless | the check and reconcile steps make the upgrade process very traumatic | 09:05 |
| lifeless | and at the moment, without LOSA's to help, migrating would be fraught with risk | 09:05 |
| kfogel | lifeless: thanks | 09:05 |
| kfogel | lifeless: I do think dogfooding is important at some point, but obviously not when there are known problems. | 09:05 |
| === afk is now known as mthaddon | ||
| lifeless | there is another aspect which is that its hard for distros to track trunk until there is a version out there that they can use to pull trunk | 09:06 |
| lifeless | so I'm not at all convinced that dogfooding *trunk* in canididate formats makes sense | 09:06 |
| kfogel | lifeless: why would we want distros to track trunk? | 09:06 |
| lifeless | kfogel: daily builds | 09:06 |
| lifeless | or even release builds | 09:06 |
| lifeless | what I want is bzr to get to a rich root format ASAP | 09:06 |
| kfogel | lifeless: (2a is rich-root, right?) | 09:06 |
| lifeless | then we can dogfood 2a as developers without trunk changing to 2a | 09:07 |
| kfogel | ah | 09:07 |
| lifeless | and once we've got a clean bill of health as developers, then its much lower risk to change trunk | 09:07 |
| kfogel | sure | 09:07 |
| kfogel | okay, bedtime for me. Thanks for the explanation, lifeless. | 09:07 |
| lifeless | the rich root transition is really painful, as most trapdoors are | 09:07 |
| lifeless | hey, how is the mysql test going? | 09:07 |
| kfogel | lifeless: still going. ~/.bzr.log last touched 8 min ago | 09:08 |
| lifeless | cpu burning up? | 09:08 |
| kfogel | lifeless: yes, it looks like my process eats all available cpu | 09:15 |
| lifeless | good | 09:15 |
| lifeless | its busy | 09:15 |
| bialix | asabil: pong | 09:16 |
| asabil | bialix: I just checked bzr explorer, and it looks great ! thanks | 09:18 |
| bialix | asabil: kudos for igc! | 09:19 |
| bialix | it looks easy, but I agree -- it's great GUI | 09:19 |
| asabil | bialix: yes, but you are also the guy implementing it, am I wrong ? | 09:20 |
| bialix | I'm padavan here, and igc is master | 09:20 |
| bialix | I'm mostly working on qbzr | 09:20 |
| asabil | bialix: I see :) | 09:21 |
| bialix | it's so cool to see how fast bzr explorer growing into usable tool. mostly because we already have mature enough pieces in bzr-gtk and qbzr | 09:22 |
| asabil | bialix: I would like to suggest you take a look at the accurev ui | 09:22 |
| asabil | I have never used it myself, but it got some really awesome drag and drop features | 09:23 |
| asabil | you can basically drag and drop revisions between branches to merge/cherry pick | 09:23 |
| bialix | oh, I see | 09:23 |
| asabil | and that's something I would love to see integrated in qbzr's qlog and bzr explorer | 09:23 |
| bialix | it's related to qlog (from qbzr then) | 09:23 |
| bialix | you also need to ping garyvdm with this idea | 09:24 |
| asabil | http://www.accurev.com/virtualbooth/2min-demo/2min-demo.html | 09:24 |
| * bialix looks | 09:24 | |
| asabil | :) | 09:24 |
| asabil | it does more than version control, but there are some good ideas that could be used in the bzr gui world I think | 09:27 |
| bialix | hmmmmmm | 09:30 |
| bialix | why they're dragging offshore team back and forth? | 09:30 |
| bialix | what's the point? | 09:30 |
| bialix | looks interesting, but I don't understand something | 09:30 |
| bialix | anyway thanks, I'll send the link in qbzr ml so other people (garyvdm) can see it too | 09:31 |
| asabil | bialix: to allocate resources | 09:31 |
| bialix | allocate resources? | 09:32 |
| asabil | bialix: from what I understood, accurev does version control + bug tracking + resources management | 09:32 |
| bialix | and it supposed to be distributed? | 09:32 |
| asabil | bialix: I am not sure, never used it myself as I said earlier | 09:33 |
| bialix | ok | 09:33 |
| asabil | but basically they are dragging a Team on top of a Stream (branch) to say that "this is the team now working on this branch" | 09:33 |
| bialix | hm | 09:34 |
| bialix | I see the point | 09:34 |
| bialix | asabil, btw here is our ideas qbout qbzr gui http://groups.google.com/group/qbzr/browse_thread/thread/68987a67f323e287# | 09:35 |
| bialix | feel free to comment | 09:36 |
| bialix | the main problem with bzr is main bzr idea: one branch = one dir | 09:36 |
| asabil | will check it out, thanks | 09:36 |
| asabil | yep, I agree :/ | 09:36 |
| bialix | so you have to either work inside shared repo to get all branches | 09:36 |
| bialix | or create virtual project structure | 09:36 |
| bialix | though I think defining projects (including remote branches like in git) could be very powerful | 09:37 |
| bialix | I'm not sure how such project could be shared between several devs though | 09:37 |
| bialix | future colocated branches won't fix all rough edges | 09:38 |
| bialix | I think idea of registering remote branches in git is the right idea | 09:38 |
| bialix | although it's mostly local thing IIUC | 09:38 |
| asabil | yep | 09:39 |
| asabil | but I think each model has its flaws | 09:39 |
| bialix | as usual :-) | 09:39 |
| bialix | igc: ping | 09:45 |
| igc | hi bialix | 09:45 |
| bialix | hi, is there possible to pass current branch as argument to some commands? | 09:46 |
| bialix | in explorer | 09:46 |
| igc | bialix: yes | 09:47 |
| igc | bialix: see lib/app-suite-qbzr.ini in rev 113 | 09:47 |
| bialix | "add": "bzr qadd --ui-mode %(selected)s", | 09:47 |
| bialix | that is? | 09:48 |
| igc | bialix: we haven't populated the context with "current selection" information yet, but the command definitions support it when we do | 09:48 |
| igc | bialix: %(root)s is the current branch | 09:49 |
| igc | that bit is working now | 09:49 |
| igc | bialix: got to go, sorry | 09:49 |
| bialix | ok | 09:49 |
| igc | very hungry and dinner is ready :-) | 09:49 |
| * igc dinner | 09:49 | |
| bialix | bon appetit | 09:50 |
| === mthaddon is now known as afk | ||
| === afk is now known as mthaddon | ||
| poolie | night | 10:04 |
| lifeless | EOD() | 10:50 |
| mzz | I was wondering if putting unrelated projects into the same shared repository is good, bad or neutral? | 11:43 |
| mzz | I currently have most stuff in a single ~/bzr shared repo and am doing some belated digital spring cleaning, was wondering if I should change that | 11:44 |
| lifeless | neutral | 11:45 |
| vxnick_afk | mzz: I only ever put related projects within the same shared repo | 11:47 |
| === vxnick_afk is now known as vxnick | ||
| vxnick | related branches, even | 11:48 |
| ddaa | lifeless: If I understood correctly, at some point it was bad, if one project was large (e.g. launchpad) because the index bloat impacted performance with the branches of small projects. | 11:51 |
| mzz | also it makes it a bit hard to rm -rf a project | 11:51 |
| mzz | so I think I'm changing away from it | 11:51 |
| ddaa | But 1. maybe I misunderstood, or 2. maybe it's fixed now with some newer non-default repo format. | 11:51 |
| lifeless | ddaa: bzr runs out of steam with 16K projects | 11:52 |
| lifeless | (all of ubuntu) | 11:52 |
| lifeless | but other than that its really just total things to index, not project count; the steam issue on 16K projects is simply the total file-version count | 11:53 |
| lifeless | and B+Tree indices are much more robust than the flat file indices were | 11:53 |
| ddaa | I do not understand what you mean by the "16k projects" limit. I take your other reply as meaning "yes, index bloat can be an issue with the default repo format, but it's fixed with repo format >= 1.9". | 11:55 |
| lifeless | I put all of ubuntu into a single repo | 11:56 |
| lifeless | as 16K 1-commit long branches | 11:56 |
| lifeless | it uses a lot of memory to work with everything at once | 11:56 |
| lifeless | but you can commit to individual branches very quickly and successfully | 11:56 |
| ddaa | lifeless: with which repo format? | 11:57 |
| lifeless | 1.9+ | 11:57 |
| lifeless | I think | 11:57 |
| lifeless | pack-0.92 was worse | 11:57 |
| === mrevell is now known as mrevell-lunch | ||
| ddaa | Thanks. Sorry about being this insistent, but I think it's important to be very clear about what performance benefits from non-default repo formats. | 11:58 |
| lifeless | 1.9 memory caps the cache for indices | 11:58 |
| lifeless | speeds up locating data by 100x factor (200:1 rather than 2:1 fan out) | 11:59 |
| lifeless | 2a delivers similar changes to the inventory layer | 11:59 |
| ddaa | So, how are you going to market 2.0? Came with something better than "bzr, it's not slow anymore!"? | 12:00 |
| lifeless | no idea :) | 12:00 |
| ddaa | My 2¢, postpone 2.0 until you have a marketing angle. | 12:02 |
| ddaa | 2.0 is largely (not only, but largely) a marketing op, so better to fire that particular bullet when you have a good target. | 12:03 |
| lifeless | its mainly about fixing the rich root problem once and for all | 12:03 |
| lifeless | marketing is a small component | 12:03 |
| lifeless | 2.0's default format will be rich root; there will be no new formats added in 2.0 that are not rich root | 12:03 |
| ddaa | Oh. I thought it was more important to make the public reconsider its perception that "git and hg are so much faster than bzr". | 12:04 |
| lifeless | the way to do that is to be fast | 12:05 |
| ddaa | Which has proven disastrous for adoption. | 12:05 |
| lifeless | have you tried 2a out? | 12:05 |
| ddaa | Nope. Not interested in testing it before release. Bzr has been mostly fast enough for me since knitpacks. | 12:06 |
| lifeless | 2a is supported - its a released format | 12:06 |
| lifeless | it becomes default in 2.0 | 12:06 |
| lifeless | I encourage you to migrate to rich roots as soon as you can; it will mean you can test 2a more easily if you want to | 12:06 |
| ddaa | Oh right, it must have been just released. | 12:06 |
| lifeless | 18th June :) | 12:07 |
| ddaa | I set up repos for my current project just a couple of weeks ago. It was not out yet. | 12:07 |
| ddaa | BTW, I did have a performance problem. | 12:07 |
| lifeless | 1.16.1 will fix a key bug with 2a btw | 12:08 |
| lifeless | thats due out in the next dayish | 12:08 |
| ddaa | Specifically, initial push to as unpopulated repo through bzr+shh was MUCH slower than it should have been (with 1.9 repos). | 12:08 |
| lifeless | not a dataloss bug, just annoying | 12:08 |
| lifeless | big history? | 12:08 |
| lifeless | and what bzr version ? | 12:08 |
| ddaa | History ~1000 revs. Bzr from ppa as of one month ago. | 12:09 |
| ddaa | Import from hg using fast-import. | 12:09 |
| lifeless | ok | 12:09 |
| lifeless | its odd that that would be slow | 12:10 |
| ddaa | It was not as much slow as stalling. | 12:10 |
| lifeless | if you care to a) try with bzr 1.16 at both ends and b) if it is still slow, run with 'bzr -Dhpss' and file a bug with the .bzr.log contents for it | 12:10 |
| ddaa | At minutes at a time. | 12:10 |
| ddaa | Sure. I'll do that today. | 12:11 |
| lifeless | lan or internet? | 12:11 |
| ddaa | internet, but should be fast | 12:11 |
| lifeless | we had a hard-to-diagnose problem with the python trials | 12:11 |
| ddaa | i.e. remote host is a hosted server on the same ISP as my workstation. | 12:11 |
| lifeless | similar sounding symptoms | 12:11 |
| ddaa | I'd be happy to provide diagnostic. | 12:12 |
| lifeless | cool | 12:12 |
| lifeless | thanks | 12:12 |
| asabil | is it normal that bzr status takes 26sec to complete with a clean working tree ? | 12:12 |
| lifeless | asabil: it has to sha1sum the files the first time | 12:13 |
| lifeless | asabil: it should be near instant after that | 12:13 |
| asabil | lifeless: what is the 1st time ? | 12:13 |
| lifeless | asabil: after checkout, after manually copying the tree (destroys the stat cache) | 12:13 |
| asabil | right, it gets down to 1.1 seconds after that | 12:14 |
| lifeless | asabil: the other possibility is that your tree was cold and you're actually measuring the time to page in the dentries and inodes for the tree (and if its really cold, bzr is likely not in cache as well - thats a good 15-20 seconds there, because python *sucks* at loading many modules) | 12:14 |
| ddaa | also, if the tree has many files, it can take a while for the system to read directory entries into the cache. Cold-cache perf occurs e.g. after reboots or long periods not working on those files. | 12:15 |
| ddaa | (lifeless just said the same thing with more jargon) | 12:15 |
| asabil | lifeless: also I had a really weird issue with bzr-svn and the --development-6-rich-root format | 12:15 |
| vxnick | davidstrauss: ping | 12:15 |
| davidstrauss | vxnick: pong | 12:15 |
| asabil | I checked webkit over http, and it did result in an 11GB repository | 12:15 |
| vxnick | davidstrauss: did you package the fixed 1.16 installer? | 12:15 |
| * ddaa goes afk for an hour | 12:16 | |
| asabil | it went down to 800MB after running bzr pack | 12:16 |
| davidstrauss | vxnick: I haven't done anything since that venerable night | 12:16 |
| lifeless | asabil: hmm, shoulda gone smaller. | 12:16 |
| vxnick | davidstrauss: fair enough :) | 12:16 |
| davidstrauss | vxnick: It wasn't clear from the mailing list who was doing what | 12:16 |
| vxnick | davidstrauss: ah, ok | 12:16 |
| asabil | lifeless: the 11GB is not good in the 1st place I think | 12:16 |
| lifeless | anyhow, its bug https://bugs.edge.launchpad.net/bzr/+bug/376748 | 12:18 |
| ubottu | Ubuntu bug 376748 in bzr "after conversion chk formats are badly packed" [Critical,Fix released] | 12:18 |
| lifeless | bzr-svn needs to change as well | 12:18 |
| asabil | lifeless: it wasn't a conversion | 12:18 |
| asabil | it was a fresh checkout | 12:18 |
| lifeless | asabil: svn->bzr - thats a conversion | 12:18 |
| asabil | ah oki | 12:18 |
| asabil | thanks | 12:19 |
| lifeless | so what happens is | 12:19 |
| lifeless | bzr-svn copies some data | 12:20 |
| asabil | yes ? | 12:21 |
| lifeless | because of a couple of things, its not compressed beyond zlib | 12:21 |
| lifeless | then, when it hits a threshold (5000 commits I think), it commits the transaction, and repeats | 12:21 |
| lifeless | bzr's core causes an autopack when a certain number of transactions have occured | 12:22 |
| lifeless | probably bzr-svn needs some tuning to work better with 2a | 12:22 |
| lifeless | and it definitely needs to start doing the incremental autopack at the end of the fetch process as well | 12:22 |
| asabil | I see | 12:22 |
| lifeless | `night all | 12:30 |
| asabil | night, and thanks for the explanation | 12:32 |
| === abentley1 is now known as abentley | ||
| === mrevell-lunch is now known as mrevell | ||
| Peng_ | You mean the pack_hint stuff? bzr-svn and bzr-git do that now. | 13:26 |
| jrwren | I'm getting very strange behavior, bzr 1.16 on win32 installed via the setup program. nslookup resolves my host, an internal dns name, but bzr says "failed to lookup <hostname>:4155: getaddrinfo failed" | 15:02 |
| james_w | it shouldn't be adding the port to the lookup should it? | 15:06 |
| james_w | how many colons do you have in the host/user/password part of the URI? | 15:07 |
| jrwren | none. | 15:08 |
| jrwren | its connecting to a bzr://host/path | 15:08 |
| jrwren | an instance of bzr --serve running | 15:08 |
| jrwren | it appears to be python getaddrinfo is different from windows nslookup. | 15:08 |
| jrwren | ah! maybe a python bug. | 15:09 |
| jrwren | my win7 network interfaces were in bridge mode. | 15:09 |
| jrwren | I had both interfaces up and connected to the same network. | 15:09 |
| jrwren | when I took down an interface, it worked again. | 15:10 |
| === ja1 is now known as jam | ||
| jam | morning vila | 15:14 |
| jam | morning #bzr | 15:14 |
| james_w | morning jam | 15:14 |
| * vila waves and wonders how jam manage to pop up at the precise second I was clicking on ja1 to check :-) | 15:15 | |
| jam | vila: magic | 15:15 |
| vila | jam: Aren't you scared that my magic allows me to summon you with my mouse ? | 15:16 |
| vila | :D | 15:17 |
| jam | meh, such is life | 15:17 |
| jam | Being summoned at the whim of a Frenchman is just part of the mystery of the world | 15:17 |
| awilkins | Ca va | 15:19 |
| awilkins | And C'est la vie | 15:20 |
| * vila should stop magic, too much of it today anyway | 15:20 | |
| awilkins | Speaking of mouse magic, I've discovered Synergy and I' love it | 15:20 |
| vila | awilkins: you forgot: 'Et pour la ptite dame ce sera quoi ?' | 15:20 |
| vila | awilkins: yup, synergy rocks, despite some incompatibilities with virtualbox | 15:21 |
| awilkins | Ma Francais est tres merde | 15:21 |
| vila | awilkins: You certainly meant: "Mon francais n'est pas tres bon" :-D | 15:22 |
| awilkins | Ah, yes, I just called myself a girl | 15:22 |
| awilkins | No wonder they're obsessed with sex, it suffuses their language (ok, ok, that's gender) | 15:23 |
| vila | awilkins: nope, I'm a boy, yet, I can say: "Ma voiture est en panne" (my car is broken) | 15:23 |
| vila | awilkins: German is even worse, there is also neutral ;-) | 15:23 |
| awilkins | So "french" is mle | 15:23 |
| awilkins | I thought it was that way round | 15:23 |
| awilkins | I only studied it until I was 15 | 15:24 |
| Tak | yeah, I wonder why so many of the romance languages dropped the neuter gender from latin | 15:24 |
| awilkins | Wasn't romantic enough <ducks> | 15:24 |
| * Tak cry | 15:25 | |
| awilkins | verterok: I hate Eclipse sometimes | 15:27 |
| awilkins | "No repository found containing ...." WHY IS THE SOFTWARE IN THE LIST IF YOU CAN'T SEE ITT!!!!1 | 15:27 |
| awilkins | Ahem. | 15:27 |
| * awilkins calms down a bit | 15:27 | |
| verterok | awilkins: you'r not alone | 15:28 |
| jrwren | is there a way to spec a revno saying "last time this file changed"? | 15:34 |
| jrwren | i want to bzr diff MyFile, I know it changed recently, but I don't know if its -2, -3, -4... | 15:35 |
| jrwren | is there a way to say "-1 for this file" ? | 15:35 |
| vila | jrwren: no, but annotate will show you all revisions the modify you file | 15:36 |
| jrwren | ah! right! | 15:36 |
| jrwren | ty. | 15:36 |
| vila | jrwren: no, but annotate will show you all revisions the modified your file | 15:36 |
| vila | gee, typos all over the place | 15:36 |
| vila | s/the/that/ even or something | 15:37 |
| awilkins | You can log a file | 15:37 |
| awilkins | bzr qlog <file> and bzr log <file> work just fine | 15:37 |
| jrwren | annotate doesn't work in this case because I'm looking for a deleted line. | 15:37 |
| jrwren | yes, I was trying to avoid log then diff | 15:37 |
| vila | jrwren: try qannotate | 15:38 |
| vila | one more typo "-( | 15:38 |
| jrwren | i'm on win32 :( | 15:38 |
| awilkins | qannotate works on win32 | 15:38 |
| vila | qannotate from the qbzr plugin | 15:38 |
| jrwren | whoa! awesome! | 15:38 |
| awilkins | If you installed the .exe it's arleady instlled | 15:39 |
| jrwren | thanks, that helps a lot | 15:41 |
| james_w | chk seems to have changed the rules about the revprops you can supply | 15:44 |
| james_w | I have to supply unicode values now, and I thought I had to supply non-unicode with old formats | 15:44 |
| james_w | was I wrong before? | 15:45 |
| awilkins | Oh, I found a circumstance in 1.16 on windows where it just drops dead, something happening inside groupcompress_pyx.pyd | 15:53 |
| awilkins | Alas, no stack track, because it just drops a minidump | 15:54 |
| awilkins | Would that actually be any use to any bzr developers? | 15:55 |
| rockstar | jam, who designed the plugin model for bazaar? | 15:59 |
| vila | awilkins: did you check you .bzr.log ? | 15:59 |
| vila | awilkins: did you check your .bzr.log ? | 15:59 |
| awilkins | vila: yes | 15:59 |
| jam | rockstar: I wrote the original code | 15:59 |
| jam | james_w: Revision property *values* were *always* Unicode | 16:00 |
| jam | we may have not asserted that in the past | 16:00 |
| jam | but they were meant to be | 16:00 |
| jam | and the decoder would always turn them into Unicode | 16:00 |
| awilkins | vila: It doesn't write a stack dump to the log. I suppose a debug-on log would be ok | 16:00 |
| james_w | jam: ok, thanks | 16:00 |
| jam | awilkins: a copy of the *data* you were using would be helpful | 16:00 |
| jam | if that is possible | 16:00 |
| jam | awilkins: and you can rm groupcompress_pyx.pyd and you should then get a stacktrace | 16:01 |
| rockstar | jam, so, if I wanted to, say, steal the plugin loading code, where would I need to look? | 16:01 |
| jam | Though I recommend *moving* it away | 16:01 |
| jam | rockstar: bzrlib/plugin.py | 16:01 |
| vila | rockstar: groupcompress is not a plugin anymore | 16:01 |
| jam | mv groupcompress_pyx.pyd groupcompress_pyx.old.pyd | 16:01 |
| rockstar | jam, okay. | 16:01 |
| jam | rockstar: different threads :) | 16:02 |
| jam | awilkins: We have a pure-python fallback that will be in library.zip | 16:02 |
| rockstar | vila, ? | 16:02 |
| jam | So we should recover just fine from the .pyd going missing | 16:02 |
| awilkins | jam: Alas, the data is rather large | 16:02 |
| jam | awilkins: my guess is an out-of-memory error or something weird like that | 16:02 |
| jam | awilkins: but again, the pure-python is more "segfault" tolerant | 16:02 |
| awilkins | jam: That was my guess too ; it's also a bzr-svn branch | 16:02 |
| jam | so try that and see if it gives anything interesting | 16:03 |
| vila | rockstar: err, sorry, misread your first message, forget me | 16:03 |
| awilkins | jam: Ok, I'll have to tinker with library.zip | 16:03 |
| jam | awilkins: you shouldn't have to tinker with library.zip | 16:03 |
| awilkins | jam: Can you just unpack it and delete the zip | 16:03 |
| jam | I was just saying where the python code is | 16:03 |
| awilkins | Ah, yes | 16:03 |
| awilkins | so just rename it to pyd_off ? | 16:03 |
| jam | awilkins: yep | 16:04 |
| rockstar | vila, c'est bon | 16:04 |
| jam | vila: any chance you could look at https://code.edge.launchpad.net/~jameinel/bzr/bug-390563/+merge/7889 | 16:04 |
| jam | It should unblock the launchpad devs | 16:04 |
| jam | so I'd like to get it merged in | 16:04 |
| jam | and probably end up cherrypicking it to 1.16.1 | 16:04 |
| jam | Then I need to look at a more complete fix | 16:04 |
| jam | abentley: https://code.edge.launchpad.net/~jameinel/bzr/bug-390563/+merge/7889 | 16:04 |
| jam | That is the branch Robert & I put together | 16:05 |
| jam | which probably fixes your issue about texts getting fetched that have already been fetched. | 16:05 |
| abentley | jam: That approach isn't as robust as simply skipping duplicates when inserting records. For example, the target repository may have text versions that cannot be predicted from its inventory data. | 16:09 |
| jam | abentley: I think erroring is the right approach if you have data that is inconsistent with what we want to insert that "cannot be predicted from the inventory data" | 16:09 |
| * vila can't parse robust == ignoring errors | 16:10 | |
| abentley | jam: I disagree. | 16:10 |
| jam | abentley: if you have something that isn't referenecd | 16:11 |
| jam | which then *disagrees* with data that *is* referenced | 16:11 |
| jam | then you have something very strange going on | 16:11 |
| jam | and it would be better to error than to warn | 16:11 |
| jam | warning == do nothing | 16:11 |
| jam | (most people ignore warnings) | 16:12 |
| abentley | jam: Erroring makes it harder to fix such situations. It also requires the code that determines what to send to be bug-free. | 16:12 |
| jam | abentley: having different content be "acceptible" means that broken repositories are never "found" | 16:13 |
| abentley | jam: Since you acknowledge that your code isn't bug-free, I'm not happy with such a solution. | 16:13 |
| jam | abentley: code is never bug free | 16:13 |
| jam | I would rather have it fail | 16:13 |
| jam | than silently propagate corruption | 16:13 |
| vila | corrupted data are harder to fix and diagnose than corrupted code | 16:13 |
| abentley | jam: I didn't say we should do it silently. | 16:14 |
| jam | abentley: a warning won't generate a bug report | 16:14 |
| jam | nor push us to fix the code | 16:14 |
| abentley | jam: It's not silent. Users who care about corruption will notice and do something about it. Users who don't care won't bother. Everyone wins. | 16:15 |
| jam | cprov: I think the "crimson-and-clover" branch was yours, right? I've confirmed that lp:~jameinel/bzr/bug-390563 on the server side allows me to branch your stacked branch. | 16:15 |
| jam | beuno: ^^ | 16:15 |
| jam | abentley: I honestly doubt it. | 16:15 |
| jam | Simple warnings get ignored | 16:15 |
| abentley | jam: Also, your patch means that a bzr 1.16 server will break a newer client. | 16:16 |
| jam | abentley: nope | 16:16 |
| abentley | jam: Doesn't the server decide what to send? | 16:16 |
| jam | abentley: so an older server will send more data than necessary to a client | 16:16 |
| jam | no breakage | 16:17 |
| jam | an older server will *break* just as it is breaking today | 16:17 |
| jam | when you push minimal data | 16:17 |
| jam | but then fetch more data than that | 16:17 |
| jam | client determines what data to push | 16:17 |
| jam | server determines what data to pull | 16:17 |
| abentley | jam: Right. I don't want it to break the way it breaks today. | 16:17 |
| jam | aka, source determines data | 16:17 |
| jam | abentley: and upgrading the *server* to this patch will fix it | 16:17 |
| abentley | jam: I encountered this bug when pulling, not when pushing. | 16:17 |
| jam | abentley: to give details | 16:18 |
| jam | when pushing up 1 rev | 16:18 |
| jam | we pushed up the minimal data | 16:18 |
| jam | when fetching 10 revs | 16:18 |
| jam | we suddenly started fetching more data than the minimal set | 16:18 |
| jam | so doing "bzr push; bzr commit; bzr push" would send a minimal amount of data to the server | 16:18 |
| jam | and then doing "bzr pull" would break | 16:18 |
| jam | (for someone that didn't have the data) | 16:18 |
| jam | if you did "bzr commit; bzr commit; bzr push" | 16:19 |
| jam | everyone would be happy | 16:19 |
| jam | the server would have "more data than necessary" | 16:19 |
| jam | but that doesn't *break* things | 16:19 |
| abentley | jam: As I said earlier, this approach is not robust. I'm not happy with it. | 16:19 |
| jam | abentley: having the same text twice in a repository with identical details does not harm anything | 16:19 |
| jam | attempting to insert it with *different* details does | 16:20 |
| jam | I'm against not aborting under that circumstance | 16:20 |
| abentley | jam: It does no harm if you don't insert it. | 16:20 |
| jam | abentley: Except if *you're* the one that is wrong | 16:20 |
| jam | and the only way to find that out | 16:20 |
| jam | is to fetch someone else who is actually right | 16:20 |
| abentley | But you're damaging the case where I'm the one who is actually right. | 16:21 |
| jam | unlike the justice system, I'd rather presume guilty than innocent | 16:22 |
| jam | I realize this has blocked LP devs for a couple of days | 16:23 |
| jam | and that is certainly annoying | 16:23 |
| jam | I'd rather block some people and get a fix | 16:23 |
| jam | than not block, and have the problem spread | 16:23 |
| abentley | jam: It is not reasonable to prevent people from pulling good data from a server, just because the server also happens to have bad data. | 16:24 |
| abentley | It makes it much harder for us to fix the data. | 16:24 |
| abentley | And this won't detect most forms of bad data. It will only detect it in edge cases. | 16:25 |
| abentley | In fact, it won't even detect bad that we are inserting. It will only detect potentially bad data that we *aren't* inserting. | 16:27 |
| abentley | I'm all for improving consistency, but this is not contributing to that cause significantly. | 16:28 |
| vila | jam: I was looking at Robert's branch already, I approved yours | 16:28 |
| mxpxpod | is there a way to register a directory type with the directory service and have certain urls initialize a shared repository with multiple branches in it? | 16:34 |
| abentley | jam: I also don't understand why you think my fix would cause the corruption to spread. Your fix would cause us to silently ignore the bad data, while my fix makes us warn about it. | 16:49 |
| jam | abentley: my fix is not specifically proposed for your work, though I think it will get you to where you want to be | 16:50 |
| jam | the problem is cases where we should be fetching things and they turn out to be inconsistent | 16:51 |
| jam | yours will still only warn | 16:51 |
| abentley | The problem is that I don't trust bzr to figure out what things we should be fetching. Especially if I don't have control over the copy of bzr determining what to fetch. That code is complex and you've already said it still needs work. | 16:55 |
| === Kissaki^0ff is now known as Kissaki | ||
| === mthaddon is now known as afk | ||
| vxnick | is it best to use 'bzr bundle' or 'bzr send' for saving patches? | 18:35 |
| vxnick | creating* | 18:35 |
| dash | i think the main difference is that 'send' mails it | 18:36 |
| vxnick | I can't get either to output the patch info in the output file - I don't know what I'm missing | 18:37 |
| * Tak always use bzr diff | 18:37 | |
| vxnick | I've tried "bzr bundle -o changes.diff" and "bzr bundle -r-1 -o changes.diff" | 18:37 |
| vxnick | so something like "bzr diff -r-1 > changes.diff" ? | 18:38 |
| LarstiQ | vxnick: bzr send | 18:38 |
| fullermd | You want 'send -o$FILE' | 18:38 |
| fullermd | bundle is deprecated since about 2 weeks after dirt was invented. | 18:39 |
| dash | why doesn't it say anything about that then | 18:39 |
| vxnick | ah I didn't know that | 18:39 |
| LarstiQ | vxnick: and you might want to supply the submit branch | 18:39 |
| LarstiQ | dash: bundle is a hidden command | 18:40 |
| fullermd | It maybe should. It's been taken out of the 'commands' list since... I don't even know. | 18:40 |
| fullermd | 0.11 maybe, something in that era. | 18:40 |
| vxnick | LarstiQ: there isn't a public branch | 18:40 |
| LarstiQ | vxnick: send needs to know which revisions to include | 18:40 |
| vxnick | LarstiQ: I'm using "-r -1" for that | 18:41 |
| vxnick | assuming that'll do the last rev | 18:41 |
| LarstiQ | vxnick: not exactly | 18:42 |
| vxnick | "bzr send -r -2.. -o changes.diff" works | 18:43 |
| fullermd | And note 'submit branch' != 'public branch'. | 18:43 |
| vxnick | fullermd: yeah I'm aware of that bit | 18:43 |
| LarstiQ | vxnick: say you have a branch that is 2 revisions behind, if you made a merge directive with just the last revision, it wouldn't be able to apply that in the 2-behind branch | 18:43 |
| fullermd | And if that works, it probably means it already has a submit branch, so you don't need the -r at all (unless you're intending a cherrypick). | 18:43 |
| vxnick | ok, so assume I've branched someone's code - if I want to create a patch with my changes in it since their last update, what would I use for the revision argument? | 18:44 |
| LarstiQ | vxnick: nothing | 18:45 |
| LarstiQ | vxnick: just `bzr send` | 18:45 |
| fullermd | You wouldn't need any. send checks the submit branch (which default to what you branched from), and includes everything that isn't in it already. | 18:45 |
| vxnick | ah, thanks :) | 18:45 |
| LarstiQ | vxnick: now, if your last couple of revisions were bogus, but you wanted to send the rest, you would do `bzr send -r -4` | 18:45 |
| LarstiQ | which means, everything up to -4 that the submit branch doesn't have | 18:45 |
| vxnick | gotcha | 18:46 |
| * LarstiQ goes for dinner | 18:46 | |
| vxnick | thanks for your help guys | 18:46 |
| LarstiQ | vxnick: np | 18:46 |
| glyph | "DoS attack"? | 18:51 |
| glyph | whoops | 18:51 |
| glyph | I was responding to something twenty hours ago on a different channel :) | 18:51 |
| alf | Hello, I was wondering if there is a preferred way to handle feature branches in very large (disk-space wise) trees. Creating lots of feature branches creates lots of large trees which can be a problem. Any thoughts? | 19:02 |
| FibeRichio | Is it possible to integrate the "bzr-push-and-update"-plugin to Turtoise Bazaar on Windows? Or do I have to use the commandline for that? | 19:09 |
| beuno | alf, because of the working tree, or the revision information? | 19:10 |
| alf | beuno: the working tree | 19:11 |
| beuno | alf, you can use bzr switch\ | 19:11 |
| alf | beuno: thanks, I am reading about it now in the user guide | 19:16 |
| jskulski | is this possible: bzr branching from a checkout of svn? | 19:38 |
| LarstiQ | jskulski: if you have bzr-svn installed, yes | 19:39 |
| jskulski | LarstiQ:: so when you bzr push you modify the files in teh checkout (which will sit and wait to be committed manually?) | 19:41 |
| kirkland | i'm in a local bzr branch, and i want to change the location it pushes to when i just type "bzr push" | 19:43 |
| kirkland | how do i change the stuff cached and reported in 'bzr info' ? | 19:43 |
| vxnick | kirkland: bzr push --remember <new location> | 19:43 |
| kirkland | vxnick: rocking, thanks. | 19:43 |
| LarstiQ | jskulski: no, it will push to the svn server then | 19:43 |
| LarstiQ | jskulski: (and update the checkout) | 19:43 |
| LarstiQ | jskulski: you need not touch the svn checkout anymore after you branch from it though | 19:44 |
| jskulski | LarstiQ:: ok, so for bzr-svn, the workflow requiires svn commit access | 19:44 |
| LarstiQ | jskulski: how so? (and what workflow?) | 19:45 |
| jskulski | is that correct? | 19:45 |
| LarstiQ | jskulski: you don't need to have svn commit access to use bzr-svn, no | 19:45 |
| LarstiQ | jskulski: you need it to write back to the svn repo though | 19:45 |
| jskulski | LarstiQ:: yeah | 19:45 |
| jskulski | LarstiQ:: ok thanks for your help | 19:45 |
| LarstiQ | jskulski: and pushing to a checkout implies pushing to it's master, both in bzr and svn | 19:45 |
| jskulski | right on | 19:46 |
| jskulski | seriously this channel is rocking, consistently helpful and friendly advice to a newb. | 19:46 |
| jskulski | thanks! | 19:46 |
| LarstiQ | jskulski: but it's fine to just branch from svn, develop, publish, and let someone else bother with pushing back into svn. It's what I do ;) | 19:46 |
| LarstiQ | jskulski: thanks :) | 19:46 |
| jskulski | LarstiQ:: oo that is what i'm waiting for | 19:46 |
| jskulski | err looking for | 19:47 |
| jskulski | hey again, I am trying to bzr branch file:///var/www/project where /var/www/project is a svn checkout of an external repository and I keep getting a segementation fault. | 20:05 |
| jskulski | i have bzr-svn installed | 20:06 |
| jskulski | and i've done this process berfore with local svn repositories | 20:06 |
| LarstiQ | jskulski: which version of bzr, bzr-svn (and possibly subvertpy) does this happen with? | 20:08 |
| jskulski | bzr 1.5 | 20:09 |
| jskulski | 1.5.1 | 20:10 |
| jskulski | 0.4.10-2 | 20:10 |
| jskulski | sorry 0.4.10-2 is bzr-svn | 20:10 |
| schmoonior | so I was doing a bzr add when my Mac had the equivalent of a BSOD (not related to bzr) and now when I run bzr status I get: bzr: ERROR: The dirstate file (DirState(u'/Users/drew/Documents/working/.bzr/checkout/dirstate')) appears to be corrupt: failed to find trailing NULL (\0). Trailing garbage: '\n' | 20:14 |
| schmoonior | any suggestions? | 20:14 |
| jskulski | subversion is also 1.5, but not sure what the external reposiotry version is | 20:14 |
| Peng_ | schmoonior: If you don't mind losing some of the working tree's uncommitted meta data (e.g. bzr adds), and aren't using a lightweight checkout, getting rid of .bzr/checkout and running "bzr co" is probably easiest. | 20:15 |
| Peng_ | schmoonior: Note: if it opens a black hole and destroys the planet, it's not my fault. :) | 20:16 |
| schmoonior | fortunately I'm not at LHC ;) | 20:16 |
| schmoonior | if I do the bzr co, it won't mess with any of the uncommitted changes in files? | 20:16 |
| Peng_ | schmoonior: I don't know. I'd be surprised if it *destroyed* anything, but it might rename stuff to backup files or generate conflicts or something. | 20:18 |
| Peng_ | schmoonior: Again, black holes, not my fault, etc. | 20:18 |
| schmoonior | ok, I might just make a simple copy of my tree before I do anything | 20:18 |
| SamB | schmoonior: was just about to suggest that myself ;-) | 20:18 |
| Peng_ | Yeah, backups are good. :) | 20:19 |
| schmoonior | thanks guys, I will let you know how it goes | 20:19 |
| LarstiQ | jskulski: sorry, I didn't get highlighted so didn't get drwan back here | 20:33 |
| LarstiQ | jskulski: bzr-svn 0.4 is a dead end, preferably use 0.6.x or if not that then at least 0.5.x | 20:33 |
| kfogel | anyone: if you had to point people to just one page to say what brisbane-core is all about, what page would it be? http://jam-bazaar.blogspot.com/2009/03/brisbane-core.html ? | 20:34 |
| LarstiQ | jskulski: I can't promise all bugs will be fixed in newer versions, but many have | 20:34 |
| LarstiQ | kfogel: if one page, then yes that one | 20:34 |
| kfogel | LarstiQ: thanks | 20:34 |
| LarstiQ | jskulski: are you on suse by chance? | 20:35 |
| jskulski | LarstiQ:: sorry stepped out, i will look into updating. We are debian 5 | 20:49 |
| schmoonior | Peng_ and SamB: it appears to work. I'll have to readd everything like you suggested and I had to fix a bunch of conflicts. Thanks again | 20:50 |
| LarstiQ | jskulski: ah good, I run Lenny myself too | 20:51 |
| SamB | jelmer: if I do a "bzr svn-import" with a destination repository that contains a branch of my own in addition to the branches imported from SVN, is my branch in any danger? | 21:15 |
| synic | is there an easy way to serve bzr via http with access control? | 21:27 |
| dash | sure | 21:28 |
| dash | use any http server with access control :) | 21:28 |
| synic | I see. Just the regular Auth in apache would work? What about limiting writes to some users and read to others? | 21:29 |
| SamB | bazaar supports commit-by-PUT now? | 21:31 |
| synic | anyone? | 21:32 |
| dash | synic: i don't remember if you can push to a bzr branch via http | 21:32 |
| LarstiQ | SamB: with smartserver enabled, or with webdav | 21:32 |
| dash | but yes, just regular auth will work. | 21:33 |
| synic | I'm trying to find the best way to serve a bzr repo to windows users with access control | 21:33 |
| synic | ssh doesn't really work because lol windows | 21:33 |
| LarstiQ | windows can do ssh | 21:33 |
| LarstiQ | synic: bzr has support for putty/pageant | 21:33 |
| synic | oh, pageant? Sweet, this will work then | 21:34 |
| synic | LarstiQ: is there a doc on that? I'd like to use ssh keys | 21:35 |
| LarstiQ | synic: userguide perhaps, but if pageant is in your PATH, it should just work? | 21:36 |
| LarstiQ | synic: and yes, with keys :) | 21:36 |
| synic | LarstiQ: do you have to tell bzr to use pageant? | 21:45 |
| lifeless | jelmer: bug 376748, just checking - you call the partial pack function? | 21:47 |
| ubottu | Launchpad bug 376748 in bzr "after conversion chk formats are badly packed" [Critical,Fix released] https://launchpad.net/bugs/376748 | 21:47 |
| LarstiQ | synic: should not be needed. But in case you also have openssh on windows (which it will prefer) you can use BZR_SSH=plink | 21:48 |
| synic | mk | 21:48 |
| === afk is now known as mthaddon | ||
| LarstiQ | synic: but afaik all you should need is to have PATH set up | 21:53 |
| synic | yeah, it's working now. Thanks :) | 21:53 |
| LarstiQ | cool :) | 21:54 |
| synic | one more question, is there a way to "bzr push" in tortoise bzr? | 22:01 |
| synic | it's got pull, update, commit, add, delete. No push? | 22:04 |
| LarstiQ | synic: called 'publish' maybe? | 22:06 |
| * LarstiQ is not well versed in windows/Tortoise :/ | 22:06 | |
| synic | yeah, no publish | 22:06 |
| synic | I'm not very good with windows either | 22:06 |
| synic | I'm probably missing something obvious | 22:07 |
| jam | lifeless: ping | 22:16 |
| lifeless | hi | 22:16 |
| lifeless | timing :P I wass just about to go grab food | 22:16 |
| jam | Sorry I was away, my wireless on my laptop dies every now and then | 22:17 |
| jam | so I just hacked hidden without it for a while | 22:17 |
| jam | lifeless: so you may want to look at lp:~jameinel/bzr/1.17-chk-multilevel | 22:17 |
| lifeless | thats cool | 22:17 |
| lifeless | so | 22:17 |
| jam | I'm pushing it now | 22:18 |
| jam | anyway, it is an attempt at using the same heapq strategy | 22:18 |
| jam | for iter_interesting_nodes | 22:18 |
| lifeless | I was wondering why you remove any uninteresting nodes | 22:18 |
| jam | any? | 22:18 |
| jam | so that you don't have to walk the entire uninteresting set | 22:18 |
| jam | the way the code was structured | 22:18 |
| jam | it made sure to get the 'largest possible uninteresting' set | 22:19 |
| jam | and then filtered the interesting nodes as it read the rest in | 22:19 |
| lifeless | well | 22:21 |
| lifeless | let me rephrase | 22:21 |
| lifeless | 'I wasn't awake' | 22:21 |
| lifeless | clearly an interesting tree may have uninteresting nodes, so you have to trim from both sides | 22:22 |
| === vxnick is now known as vxnick-AFK | ||
| lifeless | so, all good | 22:22 |
| lifeless | let me know when its pushed, and I'll give it a review | 22:22 |
| lifeless | I wanted to ask you about abentley's skip-dupes; reading scrollback it looks to me like you have similar concerns to what I expressed about the first version of the patch | 22:23 |
| jam | lifeless: the basic fix I wrote, and you managed to write tests for has been landed in bzr.dev | 22:23 |
| jam | as it at least fixes the common cases we are running into | 22:23 |
| jam | lp:~jameinel/bzr/1.17-chk-multilevel is a pretty major rewrite | 22:24 |
| jam | and it is going to be a while before I'm specifically ready to land it | 22:24 |
| jam | It currently reads nodes 1-at-a-time | 22:24 |
| jam | which isn't appropriate for what we are doing | 22:24 |
| jam | (especiallly yielding *keys* one-at-a-time) | 22:24 |
| lifeless | heh yes | 22:24 |
| lifeless | I think the crisis is over, I'm helping[nagging?] mwhudson to land the common case fix | 22:25 |
| jam | lifeless: generally, I think the check we have is better than a simple warning. I could be convinced that it isn't the perfect time to be doing the check, and that we should have better ways of handling it. | 22:26 |
| jam | like having a "reconcile my repo with this repo over here" | 22:26 |
| jam | and "I know you don't like it, but stop getting in my way" flag. | 22:27 |
| lifeless | jam: Could you do me a favour, and review aarons new version; I don't like being the only bad guy :) | 22:28 |
| abentley | lifeless: Dude, I did what you asked. | 22:28 |
| lifeless | abentley: you did, but the basic concern I expressed is still there | 22:29 |
| lifeless | which is fundamental | 22:29 |
| lifeless | the trace version has no performance issues - and thats great | 22:29 |
| lifeless | if its conceptually ok to do this, then it passes muster | 22:29 |
| abentley | lifeless: You expressed concern about it being silent. It's not silent. | 22:29 |
| lifeless | abentley: your revised version is massively better than the first one. I'm ecstatic on that basis. | 22:31 |
| === Kissaki is now known as Kissaki^0ff | ||
| lifeless | I think one of the concerns I have that I haven't adequately expressed so far is this: | 22:33 |
| lifeless | for revisions is really serious to have this wrong | 22:33 |
| lifeless | for texts it affects annotate and log | 22:33 |
| lifeless | so I'm going to ask you to do one smallish further change, which is to note whether we care in a particular GCVF object, and then I'll be happy | 22:34 |
| SamB | have what wrong? | 22:35 |
| abentley | lifeless: for revisions, it would be a pretty big bug to miscalculate what revisions to send. | 22:36 |
| jam | abentley: it would be an even bigger bug to have different ancestries | 22:36 |
| abentley | jam: I'm not sure that's even true. | 22:37 |
| SamB | sending the wrong revisions doesn't sound like it ought to do any permanent damage to *me* | 22:37 |
| jam | for the same revision to have different parents... | 22:37 |
| jam | SamB: sending revisions you don't need, or duplicates with what you already have doesn't seem like a problem, as long as they are identical | 22:37 |
| SamB | corrupting the revisions sent is indeed *bad* | 22:37 |
| lifeless | abentley: it would; and this was an inarticulated concern, which is why you couldn't fix it ;) | 22:38 |
| SamB | jam: exactly | 22:38 |
| lifeless | abentley: now I've figured it out, its possible to fix it. | 22:38 |
| lifeless | abentley: I've proposed one way in the merge | 22:38 |
| SamB | jam: not sending what you do need is a problem but presumably the other end will catch it | 22:38 |
| lifeless | abentley: other ways are likely possible, and if you have one please propose it. Though what I'm proposing is pretty lightweight. | 22:38 |
| jam | and at least in our "theoretical" prototypes, we have discussed sending extra data in exchange for not having to query to determine what you do/don't have | 22:39 |
| abentley | lifeless: I will update my branch as you requested. I think my fix is appropriate for CPing into Launchpad, because it lets us reconcile trunk. | 22:39 |
| SamB | jam: like the way git defaults to behaving? | 22:40 |
| lifeless | abentley: as long as we deploy the full version rapidly thereafter I'm fine with that | 22:40 |
| lifeless | abentley: I would be concerned about running with trace-for-revisions for extended periods | 22:40 |
| lifeless | SamB: that isn't what git does | 22:40 |
| lifeless | abentley: sorry for giving your a runaround here; it wasn't intentional. | 22:41 |
| lifeless | s/your/you/ | 22:41 |
| abentley | lifeless: Okay. | 22:41 |
| SamB | lifeless: well, it doesn't involve going down the list and asking the recieving end "do you have this? do you have this?" | 22:42 |
| abentley | lifeless: I will try to set up a cron job to run "bzr check" on trunk. | 22:42 |
| lifeless | SamB: it does | 22:42 |
| lifeless | abentley: I think thats a good precaution. | 22:42 |
| SamB | lifeless: git-to-git? no... | 22:43 |
| lifeless | SamB: yes | 22:43 |
| lifeless | SamB: it has a bidirectional stream where both sides say 'I have X\nI have Y\n'... | 22:43 |
| lifeless | SamB: and that goes on until the sender knows precisely what the reciever doesn't have, when it stops sending 'I have' messages, goes and creates a pack on the fly and transmits it. | 22:44 |
| SamB | well, it doesn't go and then ask you what blobs you have ... | 22:44 |
| lifeless | SamB: neither does bzr | 22:44 |
| lifeless | SamB: it walks the commits and tree content to determine what blobs to send; bzr does similar. | 22:44 |
| SamB | ... which can be annoying if you're rewriting ancestry ;-P | 22:45 |
| lifeless | so yes, the same blob will be sent if you rebased or similar the only refs that had it | 22:45 |
| lifeless | and bzr will do the same in the same situation | 22:45 |
| lifeless | what jam is talking about is quite different | 22:46 |
| SamB | so, what approximation do you mean ? | 22:46 |
| lifeless | its about *deliberately* cutting the calculation for 'what the receiver has' short (either at the revision level, or doing less work analysing the commits), and just sending what we have on disk | 22:46 |
| lifeless | e.g. send the entire compression group, rather than the 3 texts from within it that the receiver needs | 22:47 |
| SamB | oh, you mean the sender deciding "screw this, I'm just sending the pack"? | 22:47 |
| lifeless | for instance, yes. | 22:48 |
| === davidstrauss_ is now known as davidstraus | ||
| === davidstraus is now known as davidstrauss | ||
| lifeless | jam: I really must eat now, bbs | 22:52 |
| jam | lifeless: eat hearty | 22:52 |
| lifeless | 87.1kg today | 22:52 |
| lifeless | slowly slowly | 22:52 |
| jam | that is a lot of food to eat | 22:52 |
| jam | and it isn't even 8am there | 22:52 |
| jam | lifeless: you should slow down indeed :) | 22:53 |
| lifeless | jam: ! | 22:53 |
| lifeless | bbs | 22:53 |
| thewrath | hey all i have linux commands i need to run | 23:24 |
| thewrath | can i run bzr diff commands | 23:25 |
| lifeless | what do you mean? | 23:29 |
| thewrath | is there a such thing as bzr diff | 23:29 |
| thewrath | want to run something liek this svn diff -r 36:69 URLgoesHere | grep "^+" | grep -v "^+++" | wc -l | 23:30 |
| thewrath | but im using bzr | 23:31 |
| lifeless | yes there is | 23:31 |
| thewrath | pefecto | 23:33 |
| thewrath | i need the url like this hold on | 23:33 |
| thewrath | https://code.launchpad.net/~mikesats-coders/mikesats/stableversion | 23:33 |
| thewrath | what would the url be for that | 23:34 |
| thewrath | would it be bzr diff -r 4:5 lp:mikesats | grep "^+" | grep -v "^+++" | wc -l ? | 23:35 |
| lifeless | bzr diff -r 4..5 lp:mikesats | 23:35 |
| lamalex | does anyone know the name of the project for code hosting on lp? | 23:35 |
| lamalex | whooops | 23:35 |
| lamalex | meant to join #launchpad | 23:35 |
| lifeless | lamalex: launchpad-code | 23:35 |
| thewrath | lifeless but i want the number of added lines | 23:35 |
| thewrath | that is where the greps come in handy | 23:35 |
| lamalex | lifeless: thanks | 23:36 |
| lifeless | thewrath: sure, so use them | 23:36 |
| thewrath | is that supposed to be 4.5 or 4:5 lifeliess | 23:36 |
| lifeless | 4..5 | 23:36 |
| thewrath | that is how bzr does it? | 23:36 |
| lifeless | yes | 23:36 |
| thewrath | bzr diff -r 4..5 lp:mikesats | grep "^+" | grep -v "^+++" | wc -l ? | 23:36 |
| lifeless | yes | 23:37 |
| thewrath | lifeless: u still around | 23:50 |
| lifeless | thewrath: sure | 23:50 |
| thewrath | i get a dont know how to handle ssh connection | 23:50 |
| thewrath | please set bzr_ssh enviroemnt variable | 23:50 |
| lifeless | thewrath: are you on windows? | 23:51 |
| thewrath | yes sir | 23:51 |
| thewrath | i have pageant key list running with my key | 23:51 |
| lifeless | ok | 23:51 |
| thewrath | how do i correct the error | 23:51 |
| lifeless | uhm, I'm not really fluent about using bzr on windows | 23:51 |
| lifeless | how did you install bzr? | 23:51 |
| thewrath | normal windows install | 23:53 |
| lifeless | we have a couple of different installers; can you be more precise? was it a .exe? or the python installer or? | 23:53 |
| lifeless | jam: are you still around? ^ | 23:54 |
| thewrath | exe | 23:54 |
| thewrath | i think its sometihng to dow ith cygwin but not sure | 23:54 |
| lifeless | thewrath: its meant to detect pageant automatically I thought | 23:54 |
| thewrath | yea | 23:56 |
| thewrath | it is | 23:56 |
| thewrath | damn it | 23:56 |
| lifeless | so you could try | 23:59 |
| lifeless | set BZR_SSH=paramiko | 23:59 |
| lifeless | then run your bzr commands | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!