| beuno | now, if we could only get it to stop crashing... | 00:00 |
|---|---|---|
| beuno | mwhudson, wow, pretty big | 00:00 |
| beuno | are you testing on diff? | 00:00 |
| mwhudson | beuno: yeah, definitely a surprise | 00:00 |
| igc | morning | 00:00 |
| mwhudson | beuno: yes | 00:00 |
| beuno | mwhudson, interesting... I wonder if that will suffice to make it stop crashing | 00:01 |
| beuno | mornin' igc | 00:02 |
| igc | morning beuno! | 00:02 |
| beuno | I like the templating layout for zpt much better, seems cleaner | 00:02 |
| mwhudson | it's a lot more verbose | 00:05 |
| beuno | mwhudson, did you update the branch, or as-is? | 00:05 |
| mwhudson | so after rendering a 30002 line diff richly with kid loggerhead is using 711m virt, 493m resident | 00:06 |
| mwhudson | after rendering the same diff with zpt-templating, it's 375m, 152m | 00:07 |
| mwhudson | beuno: i merged trunk into it and fixed the text conflicts | 00:07 |
| mwhudson | (oh and 50 s vs 16s) | 00:08 |
| beuno | heh, very interesting | 00:08 |
| mwhudson | yes | 00:08 |
| beuno | I've been thinking how much we could reduce our memory usage if, instead of looping into a variable all the lines, we somehow start building the HTML as we loop | 00:09 |
| lifeless | moin | 00:09 |
| beuno | I think it may worth testing, should scale better | 00:11 |
| beuno | hey lifeless | 00:11 |
| mwhudson | mmf, two concurrent requests to that diff page still chew a lot of ram | 00:13 |
| mwhudson | well, about twice as much, no real surprise there | 00:13 |
| beuno | mwhudson, I'm going away for a few hours, but I'll probably work for a few when I come back. Anything specific you want me to look in to? | 00:15 |
| mwhudson | beuno: not that springs to mind immediately | 00:15 |
| mwhudson | beuno: i'll send you email if anything comes up | 00:15 |
| beuno | mwhudson, cool. If not, I'll play around with some of the ideas I have and see if we can get a significant memory usage reduction | 00:16 |
| mwhudson | cool | 00:16 |
| beuno | later! | 00:16 |
| poolie | lifeless: hi! | 00:17 |
| poolie | lifeless: feeling any better? | 00:17 |
| lifeless | the fever seems broken | 00:24 |
| lifeless | so yes, but not 'well' | 00:24 |
| lifeless | spiv: ping | 00:28 |
| spiv | lifeless: pong | 00:30 |
| lifeless | I'm just pushing up a new snapshot of versioned_files | 00:30 |
| lifeless | poolie said you were interested in network edition of same | 00:31 |
| spiv | Yeah, definitely. I want to use the new streaming stuff. | 00:32 |
| lifeless | there are two layers that need doing | 00:33 |
| lifeless | a 'fetch' level layer, which replaces repository.get_data_stream | 00:33 |
| spiv | I have some cheap hacks that implement a couple of pack specific RPCs (to e.g. autopack) that get significant improvements, but the long term solution is to use your stuff. | 00:34 |
| lifeless | and a text/inventory/revision/signature level layer, for use by e.g. diff | 00:35 |
| lifeless | there are some open questions | 00:35 |
| lifeless | tree building for instance commonly needs all the texts for one revision | 00:35 |
| lifeless | so it could use the repository level api to minimise the request size | 00:36 |
| lifeless | OTOH when we have even a couple of local commits and the rest is on the network we won't need *all* the texts for one revision to cross the wire, but sending a whole inventory of .oO over the wire to ask for its tree probably outweighs the retransmission cost | 00:37 |
| lifeless | and that doesn't even address the conceptual layering that would be needed to do that | 00:38 |
| lifeless | Using saved location: sftp://rookery/~/public_html/baz2.0/versioned_files | 00:38 |
| lifeless | Now on revision 3375. | 00:38 |
| lifeless | 'punt' | 00:38 |
| lifeless | :) | 00:38 |
| spiv | Thanks! | 00:38 |
| lifeless | I'm going to try to work today | 00:39 |
| lifeless | there is much to do | 00:39 |
| lifeless | note that that branch is currently in the middle of eliminating get_inventory_weave | 00:39 |
| lifeless | specifically bundles are bust while I adapt the multiparent code | 00:40 |
| spiv | Ok | 00:40 |
| lifeless | hmm, how best to collaborate here; I think if you have a look at the code | 00:41 |
| lifeless | and get a feel for it | 00:41 |
| lifeless | then we can chat on IRC? | 00:42 |
| spiv | I think so. I'm currently focusing on getting my various push acceleration work so far to the list. Digging into using your branch would be next on the list, though. | 00:44 |
| lifeless | cool | 00:45 |
| lifeless | also for the network apis we may likely want to use the single key space aaron advocates, because for the smart server there is no arbitrary split between indices (in some regards ideally no index at all) | 00:46 |
| spiv | That makes sense to me. | 00:46 |
| lifeless | poolie: talking is still unpleasant; if you want to catch up IRC would be massively preferable | 00:53 |
| jelmer | Jc2k: ping | 01:11 |
| jelmer | beuno, sorry about that, the server I'm running it on appears to've been assigned a new IP again | 01:14 |
| === cammoblammo` is now known as cammoblammo | ||
| === kiko-afk is now known as kiko | ||
| lifeless | poolie: ping in fact | 01:42 |
| === mw is now known as mw|out | ||
| igc | abentley: can you check BB please? It appears to be down again | 01:57 |
| abentley | igc: Should be back in a minute. | 01:59 |
| igc | thanks | 01:59 |
| poolie | lifeless: sorry you were minimized :) | 01:59 |
| Pilky | Who is it that updates the downloads page on the bzr site? | 02:00 |
| poolie | Pilky: whoever is making the release; for the last one that was jam | 02:00 |
| lifeless | poolie: must be offscreen rendering, I hadn't noticed | 02:00 |
| poolie | lifeless: igc was wanting to know if there was anything he can do to help with merging stacks | 02:00 |
| Pilky | ok | 02:00 |
| lifeless | poolie: updating it to bzr.dev would be good | 02:01 |
| Pilky | in that case, jam the OS X 10.5 installer link on the download page still points to 1.4 not 1.5 | 02:01 |
| lifeless | let me make sure its recorded and pushed | 02:01 |
| lifeless | ssh: connect to host bazaar.launchpad.net port 22: Connection refused | 02:03 |
| lifeless | bzr: ERROR: Unable to connect to SSH host bazaar.launchpad.net; EOF during negotiation | 02:03 |
| lifeless | ? | 02:03 |
| poolie | jml ^^ | 02:04 |
| lifeless | oh yeah, downtime | 02:04 |
| poolie | oh | 02:04 |
| lifeless | 2 hour window | 02:04 |
| lifeless | I would so love to fix that | 02:04 |
| lifeless | igc: poolie: sftp://rookery/~/public_html/baz2.0/shallow-branch updated | 02:45 |
| === kiko is now known as kiko-zzz | ||
| igc | thanks lifeless. I'll take a look after I finish reviewing jam's patches | 02:46 |
| lifeless | it needs bzr.dev merged into the bottom thread and propogated up | 02:47 |
| igc | yup - shall do | 02:47 |
| poolie | jam, in your mail about merge annotations (if you're still here) you say "merge node gets annotate (current)" - do you mean that's what we do now? | 03:08 |
| poolie | iirc it is | 03:08 |
| lifeless | I believe thats what it got updated to do | 03:08 |
| lifeless | I would really like to see multi-ancestor annotations | 03:08 |
| lifeless | but thats not trivial :) | 03:09 |
| * RAOF queues up a strange bzr issue for later. | 03:11 | |
| lifeless | shoot | 03:14 |
| lifeless | no need to queue :P | 03:14 |
| RAOF | Actually, it's queuing on _me_. | 03:16 |
| RAOF | But public acknoledgement makes it easier for me to remember :) | 03:16 |
| lifeless | RAOF.pop() | 03:18 |
| jam | poolie: (current) means it is what we do now, yes | 03:27 |
| jam | the 'last modified' for that line is set to the merge revision id | 03:27 |
| lifeless | so | 03:29 |
| poolie | ok | 03:29 |
| poolie | replying now | 03:29 |
| lifeless | I seem to have a bug with left_matching_block stuff | 03:29 |
| poolie | btw is there a bug number for the current failure? | 03:29 |
| lifeless | I'd like to run this past someone :P | 03:29 |
| lifeless | a left_matching_blocks of: | 03:29 |
| lifeless | [(0,0,1), (1,1,0)] | 03:30 |
| lifeless | means from 0, to 0, for 1 line | 03:30 |
| lifeless | and from 1, to 1, for 0 lines | 03:30 |
| lifeless | yes? | 03:30 |
| poolie | from memory yes | 03:39 |
| poolie | that seems odd | 03:39 |
| poolie | i vaguely recall there is always a match anchored at the end even if it's 0 lines | 03:40 |
| poolie | ^^ this may be completely wrong | 03:40 |
| poolie | lifeless: ^^ | 03:40 |
| lifeless | this is for ['line'] to ['line'] | 03:40 |
| lifeless | which is why it smells excruciatingly odd to me | 03:40 |
| lifeless | its being generated from multiparentversionedfile though, which is unfamiliar code to me | 03:41 |
| lifeless | and I've got cold sweats right now; I think I'm going to call it in a few minutes | 03:41 |
| poolie | jam, replied to your annotation mail, hope that helps | 03:43 |
| poolie | igc, speaking of faster local branch, it would be nice to show better progress there too | 03:45 |
| igc | poolie: progress as in UI, or progress as in 'faster before 1.6 ships'? | 03:46 |
| poolie | heh | 03:47 |
| poolie | :) | 03:47 |
| poolie | i meant progress bars; it's just wishlist though | 03:47 |
| igc | my patch cuts the phases from 2 to 1 so ui progress is better IMO | 03:47 |
| poolie | oh nice | 03:47 |
| * igc lunch | 03:50 | |
| * poolie lunches | 04:05 | |
| lifeless | I'm calling it a day | 04:25 |
| lifeless | fading too much | 04:25 |
| lifeless | I have at least tracked down the failure | 04:26 |
| lifeless | we were generating a non-normalised line fulltext | 04:26 |
| lifeless | due to a bug in annotation merging | 04:26 |
| lifeless | it may well be the cause of some reports in launchpad | 04:26 |
| igc | get well soon lifeless | 04:39 |
| jml | lifeless: see ya | 04:45 |
| beuno | mwhudson, still around? | 04:54 |
| mwhudson | beuno: yep | 04:55 |
| beuno | so, I'm about to jump into code, but I wanted to run by you what I'm getting into | 04:56 |
| beuno | in the revision view (diff), we might have multiple files | 04:57 |
| beuno | and now, we show the diff for all of them | 04:57 |
| beuno | so, I'd like to try the following: | 04:57 |
| beuno | by default, just show what files where changed, and add a "View Diff" to each | 04:58 |
| mwhudson | i'm writing a long-ish mail to the bazaar list currently | 04:58 |
| beuno | we would get the diff through ajax to make it nicer for the user and the server, and, we generate *just* the diff HTML on the server, most probably skipping the templating engine all together | 04:59 |
| beuno | as it should be fairly straightforward to generate | 04:59 |
| beuno | on LP specifically, that should reduce resource consumption a *lot* | 04:59 |
| beuno | as you wouldn't get every single diff every time, even when the user doesn't want it | 05:00 |
| mwhudson | yeah, i think that's probably a sensible idea | 05:01 |
| beuno | and, if we find out that getting the same diff multiple times is expensive, we can just cache the diff itself | 05:02 |
| beuno | which will be fairly space efficient | 05:02 |
| mwhudson | beuno: i sent the mail, see what you think of it | 05:03 |
| * beuno reads | 05:03 | |
| beuno | mwhudson, wonderful. Now we take a 2 week vacation and come back with that solved, right? :) | 05:07 |
| mwhudson | beuno: heh, i doubt it | 05:07 |
| beuno | mwhudson, sums it up very well, can't think of anything I'd add | 05:08 |
| mwhudson | cool | 05:08 |
| mwhudson | now i think i'm going to work on bringing zpt-templating up to date | 05:08 |
| beuno | ok, so I'm going to dive into what I explained above, on the zpt branch, which seems like the most promising | 05:08 |
| beuno | ah, perfect | 05:09 |
| beuno | can you push whatever you have so far? | 05:09 |
| mwhudson | ok, it's not much | 05:11 |
| beuno | it's just so I diverge as little as possible, not expecting anything new other than resolved conflicts :) | 05:12 |
| mwhudson | beuno: ~mwhudson/loggerhead/zpt-templating/ is up to date with what i have | 05:19 |
| mwhudson | aargh, i just want to stab things :/ | 05:23 |
| * RAOF .pop() | 05:24 | |
| RAOF | So, sometime in the last couple of weeks I've lost the ability to push a bzr tree to my vfat-formatted USB stick. | 05:24 |
| RAOF | bzr push will error out with errno 1: operation not permitted. | 05:25 |
| RAOF | I'll pastebin the actual error, but it looks like somewhere around bzr 1.4/1.5 this broke; it previously worked. | 05:26 |
| beuno_ | server seems to have died :/ | 05:29 |
| * igc pick up kids | 05:46 | |
| beuno_ | mwhudson, I can't seem to get the zpt branch working, I've narrowed it down to: http://paste.ubuntu.com/15471/ | 05:48 |
| beuno_ | any ideas? | 05:48 |
| === beuno_ is now known as beuno | ||
| mwhudson | beuno: ah right, you need zope.pagetemplate installed | 05:49 |
| beuno | ah, it's in zope-replacesupport | 05:50 |
| beuno | thanks :) | 05:50 |
| mwhudson | what an obvious package name | 05:50 |
| beuno | yes, I thought so | 05:51 |
| mwhudson | as in this package? http://packages.ubuntu.com/hardy/zope-replacesupport | 05:52 |
| beuno | and the fact that it depends on zope 2.10 makes me think something is going to go wrong | 05:52 |
| beuno | mwhudson, yeap | 05:52 |
| mwhudson | i find this a little hard to believe | 05:52 |
| beuno | that's what apt-cache tells me | 05:52 |
| beuno | ah, it lied to me | 05:52 |
| beuno | beuno@beuno-laptop:~/bzr_devel/loggerhead.zpt$ apt-cache search pagetemplate | 05:53 |
| beuno | zope-replacesupport - Add search and replace functionality to TTW Zope objects | 05:53 |
| mwhudson | i think my money is more on zope3 | 05:53 |
| beuno | I already have that :) | 05:54 |
| mwhudson | then you should have pagetemplates | 05:54 |
| mwhudson | ah, perhaps you're running with python 2.5 ? | 05:55 |
| beuno | yes, turbogears explodes with 2.5 | 05:56 |
| beuno | er, 2.4 | 05:56 |
| bob2 | that is definitely not zpt | 05:56 |
| mwhudson | beuno: not for me it doesn't | 05:56 |
| beuno | it only works for 2.4? | 05:56 |
| mwhudson | zope3 only works for 2.4 yes | 05:57 |
| mwhudson | i suspect page templates would be fine with 2.5 | 05:57 |
| mwhudson | gah, why is everything horrible | 05:58 |
| bob2 | easy_install-2.5ing zope.tal should work | 05:58 |
| lifeless | mwhudson: why is everything horrible? 'zope' | 05:59 |
| mwhudson | lifeless: it has help | 06:00 |
| bob2 | harsh! | 06:00 |
| lifeless | whats the relationship between kid and genshi? | 06:00 |
| beuno | mwhudson, well, hardy seems to come with turbokid 1.0.1, and loggerhead requieres 1.0.4 | 06:00 |
| beuno | pkg_resources.VersionConflict: (TurboKid 1.0.1 (/var/lib/python-support/python2.4), Requirement.parse('TurboKid>=1.0.4')) | 06:00 |
| lifeless | RAOF: please do pastebin the error :P | 06:01 |
| beuno | on the other hand, it does work with 2.5 :( | 06:01 |
| mwhudson | lifeless: they're more or less equivalent, they're both templating engines | 06:01 |
| mwhudson | beuno: eh? it all works ok for me | 06:01 |
| lifeless | mwhudson: at EP some guy whose name escapes me right now - the one that did the input locale which uses brackets not whitespace - was saying that kid was terribly slow and genshii rocked | 06:02 |
| beuno | meh, I'll easy_install | 06:02 |
| mwhudson | lifeless: i went to the genshi talk at ep, but i think i was still drunk | 06:03 |
| lifeless | mwhudson: this was over lunch | 06:03 |
| lifeless | SteveA was there | 06:03 |
| lifeless | we had pizza | 06:03 |
| mwhudson | genshi is much nicer than kid, but it doesn't seem to be much faster or less of a pig resource-wise | 06:03 |
| RAOF | lifeless: Sorry; http://pastebin.com/m69b6b5ea | 06:04 |
| lifeless | mwhudson: ah, you've tested I presume ? | 06:04 |
| mwhudson | whereas my zpt branch is 2-3x faster and uses 2-3x less ram | 06:04 |
| lifeless | RAOF: note the temp file name | 06:04 |
| RAOF | jml has pointed me at https://bugs.edge.launchpad.net/bzr/+bug/59424 , which isn't my bug but may well be the cause; this seems to be a regression from 1.3 | 06:04 |
| ubottu | Launchpad bug 59424 in bzr "repository_implementations.test_vfat* is broken." [Medium,Confirmed] | 06:04 |
| mwhudson | it's possible the genshi tests were flawed somehow, we haven't spent very long on them | 06:05 |
| lifeless | RAOF: one possible cause the multiple dots | 06:05 |
| beuno | mwhudson, sorry to be such a pain, but I can't seem to get it working... :( Am I missing something else? http://paste.ubuntu.com/15473/ | 06:05 |
| lifeless | RAOF: but essentially we need to trap and diagnose the bug | 06:05 |
| mwhudson | beuno: oh yeah, only the annotate and revision views really work now :) | 06:06 |
| mwhudson | beuno: i'm fixing | 06:06 |
| jml | RAOF: run the command again with -Derror | 06:06 |
| beuno | hahah | 06:06 |
| beuno | alright | 06:06 |
| jml | RAOF: that'll give you a full traceback | 06:06 |
| lifeless | RAOF: the bug is orthogonal | 06:06 |
| lifeless | RAOF: you are not even creating your repo | 06:06 |
| * beuno breaths | 06:06 | |
| lifeless | RAOF: have you tried an old bzr to see if it is better | 06:07 |
| RAOF | lifeless: It works in 1.3 | 06:07 |
| RAOF | lifeless: I'm not sure whether it works in 1.4, but this is 1.5 | 06:07 |
| lifeless | RAOF: if you have the time, it would be great if you could bisect down the mainline of bzr.dev to find the death point | 06:07 |
| beuno | mwhudson, cool, works, thanks. I am a bit worried that it doesn't work with python 2.5 by default though (although the speed difference justifies it) | 06:08 |
| lifeless | RAOF: I wager it will be a change in tmp file usage, mode management, or object creation | 06:08 |
| RAOF | lifeless: Yeah, that's what I was thinking. I don't have the time right now, but I'll check out the bzr-bisect plugin. :) | 06:08 |
| lifeless | RAOF: the plugin just does the math :P. all you need to do is: bzr branch lp:bzr foo; foo/bzr push | 06:09 |
| bob2 | beuno: it does, just not with ubuntu's zope3 package | 06:09 |
| lifeless | bzr revert -r -400 foo | 06:09 |
| lifeless | foo/bzr push | 06:09 |
| mwhudson | beuno: yeah, that part hadn't occurred to me | 06:09 |
| lifeless | bzr revert -r -200 foo | 06:09 |
| lifeless | etc | 06:09 |
| mwhudson | bob2: oh good | 06:09 |
| beuno | well, how would we package it then? | 06:09 |
| bob2 | mwhudson: afaik the only part of zope3 that doesn't run under 2.5 is some zope2 thing | 06:10 |
| RAOF | lifeless: I know. But I liked git's automated bisect (essentially the only git feature I liked). | 06:10 |
| mwhudson | beuno: later | 06:10 |
| mwhudson | :) | 06:10 |
| mwhudson | let's make it work first | 06:10 |
| bob2 | this sounds like a job for buildout | 06:10 |
| beuno | mwhudson, right, fair enough. Just thought I'd throw it out there. Back to work. | 06:11 |
| lifeless | RAOF: AIUI bzr-bisect is feature equivalent; I haven't used it enough to say | 06:11 |
| lifeless | RAOF: I have my own ideas on what would be nice; time FTL | 06:11 |
| RAOF | lifeless: I'm not sure what 'time FTL' expands to :) | 06:12 |
| poolie | abentley: bb is down.... | 06:12 |
| abentley | poolie: working on it... | 06:13 |
| bob2 | RAOF: "but I am very busy" | 06:14 |
| abentley | load averag is 7.42 | 06:14 |
| RAOF | bob2: Thanks. For some reason I was translating as 'Faster Than Light (travel)' :) | 06:14 |
| Slant | Can anyone point me toward where to read about how to implement a new transport? | 06:33 |
| Slant | Or which source files to start reading from? | 06:33 |
| spiv | Slant: bzrlib/transport/__init__.py | 06:37 |
| spiv | And other files in that directory. | 06:37 |
| abentley | poolie: back. | 06:43 |
| === jamesh_ is now known as jamesh | ||
| beuno | alright, time to get some sleep | 06:49 |
| beuno | mwhudson, hopfully I'll have a proof-of-concept branch by tomorrow, based off zpt | 06:50 |
| mwhudson | beuno: cool | 06:50 |
| beuno | cya tomorrow :) | 06:50 |
| sili | how do I undo a commit? | 06:57 |
| vila | sili: for the last commit, you can do: bzr uncommit | 06:58 |
| liw | if you want to undo an earlier commit, but keep everything that came after that, you should do a "reverse merge": bzr merge -r 10..9 (if I rembember the syntax correctly) | 07:00 |
| sili | ah just found it. thanks | 07:00 |
| sili | cool | 07:00 |
| mwhudson | beuno: my zpt-templating branch has all views seeming to work again now | 07:03 |
| mwhudson | beuno: some have formatting issues | 07:03 |
| dato | jelmer: bzr-launchpad??? | 07:53 |
| dato | jelmer: can you explain to me, wtf? | 07:53 |
| dato | (why the split, I mean) | 07:53 |
| Jc2k | jelmer: pong | 08:12 |
| Jc2k | jelmer: i'll be at work in an hour, and so available for about 7 hours.. | 08:12 |
| * igc dinner | 08:53 | |
| Jc2k | jelmer: oooh, nm.. just saw my email :D | 08:59 |
| === AfC is now known as AfC|wine | ||
| === weigon_ is now known as weigon | ||
| gour | anyone can suggest something in favor of bzr for http://article.gmane.org/gmane.emacs.dvc.devel/2164 ? | 11:18 |
| liw | "Merges look terrible in the bzr log output." -- I, on the other hand, find them beautiful and informative | 11:23 |
| LarstiQ | gour: and the branch nick defaults to the dirname of a branch, but you can set it with `bzr nick nickname`. | 11:28 |
| LarstiQ | gour: Like Aaron does with "Aaron's mergeable stuff" for example | 11:28 |
| gour | heh, it would be nice if someone can post something. DVC uses bzr atm, but there is quite a bashing of bzr in favour of git | 11:29 |
| gour | i replied recently showing how tailor can be used for git <--> bzr | 11:30 |
| liw | I suspect that bashing is not going to stop just because someone injects facts or opposing opinions | 11:30 |
| gour | well, facts are facts | 11:31 |
| liw | in advocacy, facts are always debatable :) | 11:32 |
| luks | I just wonder how did he manage to get that 'git log' output, if it's a 1:1 copy of the bzr branch | 11:32 |
| === yacc_ is now known as yacc | ||
| awilkins | re: git/DVC post i) Doesn't --short cut indented merge info out of the log ii) alias merge to merge --pull if you want that behaviour iii) nick is useful information if it's used right - an informative name tells you what the branch was being used for | 12:21 |
| awilkins | But I think all that's already been said | 12:21 |
| * Mez wonders how badly he can kill bzr running bzr gannotate on a file in a svn repository | 13:17 | |
| jelmer | Mez, you can't, since annotate doesn't work on svn stuff atm :-) | 13:19 |
| Mez | jelmer - well - it TRIES to do stuff.. | 13:20 |
| Mez | and then finally fails with a "database locked" | 13:20 |
| Mez | 2nd try just finishes up with a locked X window ;) | 13:22 |
| Mez | Exception exceptions.KeyboardInterrupt in <bound method apr_pool_t.__del__ of <libsvn.core.apr_pool_t; proxy of <Swig Object of type 'apr_pool_t *' at 0x915c598> >> ignored | 13:22 |
| Mez | jelmer, I must say - checking out a svn branch with bzr is a helluva lot slower than with svn | 13:23 |
| jelmer | Mez: It fetches all history | 13:23 |
| jelmer | Mez: "bzr co --lightweight" is more like a real svn checkout | 13:24 |
| Mez | will that make me something I can work with though (and branch) | 13:24 |
| jelmer | yes, but it will contact the remote server a lot more often | 13:25 |
| jelmer | (it's similar to a bzr lightweight checkout) | 13:25 |
| jelmer | dato: to allow people who don't want to have the launchpad plugin to not have it installed | 13:39 |
| jelmer | dato: it also makes sense since the launchpad plugin is totally separate from the rest of the code | 13:40 |
| dato | jelmer: I think it's totally a waste an an overkill | 14:05 |
| awilkins | dato: What, fetching full history from SVN repo? | 14:16 |
| awilkins | It would be nice to see history horizons make an appearance. | 14:16 |
| visik7 | is there a bisect command like git | 14:24 |
| Jc2k | https://code.launchpad.net/bzr-bisect | 14:24 |
| dato | awilkins: uh, no. creating a bzr-launchpad package in Debian. | 14:27 |
| Jc2k | debian folks dislike launchpad | 14:28 |
| rockstar | debian folks dislike * | 14:30 |
| LarstiQ | jelmer: If people really object, they can remove the python files themselves. Have you encountered people who object so strongly that it warrants the (archive) overhead of an extra package? | 14:32 |
| LarstiQ | jelmer: if I understand you correctly, it is never the case of wanting to install the plugin extra, but only to remove it. | 14:33 |
| Jc2k | thats a bit ewww, tho | 14:34 |
| Jc2k | it would be trivial to have the bzr source package build a bzr and bzr-launchpad, not really a hardship at all.. | 14:35 |
| jelmer | dato, http://lists.alioth.debian.org/pipermail/pkg-bazaar-maint/2008-May/000843.html | 14:36 |
| jelmer | dato: perhaps I'm underestimating the overhead on the archive | 14:36 |
| jelmer | It just seems cleaner to give plugins their own package | 14:36 |
| LarstiQ | Jc2k: we (Debian) need less packages, not more. | 14:40 |
| jelmer | Jc2k, the bug you reported that affected a bunch of gnome svn branches should be fixed now, btw | 14:43 |
| Jc2k | jelmer: i saw, rerunning my script now - all perfect so far | 14:43 |
| Jc2k | jelmer: if i want to keep a bunch of branches up to date, is there anything cheaper than keep running svn-import ? | 14:43 |
| jelmer | Jc2k: bzr multi-pull | 14:44 |
| jelmer | that will update the existing branches | 14:44 |
| Jc2k | i was looking at multi-pull, but that won't take account of new branches | 14:44 |
| jelmer | but it will not fetch new branches | 14:44 |
| Jc2k | right | 14:44 |
| jelmer | other than that, svn-import is the cheapest available - it should be pretty quick when branches are up to date | 14:45 |
| Jc2k | jelmer: its quite slow against evolution | 14:45 |
| Jc2k | about an hour.. | 14:45 |
| jelmer | wow.. | 14:45 |
| Jc2k | 23,000 revisions | 14:45 |
| Jc2k | quite a lot of branches too | 14:45 |
| Pieter | it imports 23000 revisions in an hour? | 14:45 |
| jelmer | Jc2k, it's probably somthing funny in the repository layout | 14:46 |
| Jc2k | Pieter: no, it already has 23000 revisions | 14:46 |
| Pieter | oh.. then I'm less surprised :) | 14:46 |
| Jc2k | Pieter: about 1,000 revisions per 5 minutes iirc | 14:47 |
| Jc2k | jelmer: any suggestions? | 14:47 |
| Jc2k | jelmer: you can grab my evolution repo clone if you want | 14:47 |
| Jc2k | actually, i dont know how you clone a repo in bazaar.. | 14:48 |
| Jc2k | there needs to be a bzr import-bzr :D... | 14:48 |
| jelmer | Jc2k: Any chance you can run with -Dtransport and send me the output in ~/.bzr.log ? | 14:48 |
| jelmer | Jc2k, there's no easy way but Odd_Bloke worked on a plugin to allow cloning of repositories | 14:48 |
| Jc2k | cool | 14:49 |
| jelmer | dato: Anyway, if everybody else objects to this I'd be happy to pull it out again | 14:49 |
| jelmer | dato: but nobody yelled on the list, that's why I went ahead and put it in | 14:49 |
| dato | jelmer: well, I follow -commits more closely than -maint :P | 14:49 |
| dato | jelmer: anyway, splits in Debian are normally done because of (a) size, to allow users to unbloat their systems, (b) dependencies, same "bloat" argument | 14:50 |
| dato | jelmer: but I'm slowly getting uninvolved, so I guess it's your call... | 14:51 |
| jelmer | dato: Ok, I'll see if I cna revert it | 14:52 |
| jelmer | dato: Getting uninvolved with Debian or just Debian+Bazaar? | 14:52 |
| dato | Debian+Bazaar | 14:53 |
| dato | using that I am, *cough*, using mostly git nowadays... | 14:53 |
| jelmer | well, same here but that's not by choice :-) | 14:54 |
| * dato goes for lunch | 14:54 | |
| dato | yay spain :P | 14:54 |
| jelmer | lol, I know some folks here in .nl that eat dinner at 5... | 14:55 |
| === kiko-zzz is now known as kiko | ||
| james_w | if I want to find whether two branches have diverged is this correct?: | 15:34 |
| james_w | graph = branch1.repository.get_graph() | 15:34 |
| james_w | diverged = len(graph.heads([branch1.last_revision(), branch2.last_revision()])) > 1 | 15:35 |
| james_w | also, do I need to do a fetch beforehand if they don't share all ancestory? | 15:36 |
| lamont | in keeping with the whole english vs english thing, bzr vizualize should work. :-) | 15:37 |
| abentley | james_w: If branch1's repository may not have the relevant revisions for branch2, you should do branch1.repository.get_graph(branch2.repository). | 15:43 |
| abentley | The branch1 repository will be preferred. | 15:43 |
| james_w | ah great, thanks. | 15:43 |
| abentley | heads > 1 is a valid test for divergence. | 15:44 |
| Pieter | how can I check out a previous revision? | 15:47 |
| james_w | if you want a separate working area then "branch -r" will get you that, if you just want to look at one then "revert -r", if you want to move to an old one and discard the revisions after then "pull --overwrite -r ." or "bzr uncommit -r && bzr revert" will do it. | 15:49 |
| Pieter | right, revert -r it is | 15:53 |
| Pieter | thanks | 15:53 |
| MattCampbell | Is there any way to convert a Perforce repository to bzr, preserving history? | 16:32 |
| pasky | http://bazaar-vcs.org/BzrFastImport/FrontEnds | 16:34 |
| pasky | or if you want to be particularly elaborate, there's git importer and git has p4 importer ;) | 16:34 |
| Pieter | are there any git importers other than through the fastimport frontend? | 16:34 |
| pasky | (oh, actually, the p4 importer on the frontend page is git's one; it's nice idea to reimplement the fast-import interface in bzr) | 16:35 |
| Pieter | bazaar has a fast-import | 16:35 |
| Pieter | but it's kinda crashy and eats tons of memory | 16:35 |
| MattCampbell | So the only option is to go from p4 to git and then to bzr? | 16:36 |
| Pieter | no, you can use the p4 fast-export and bzr fast-import | 16:37 |
| Pieter | it might work | 16:37 |
| luks | doesn't look like the git-p4 has a standalone exporter | 16:40 |
| === mw|out is now known as mw | ||
| emgent | heya | 16:49 |
| awilkins | I could just go for a slush puppie | 17:08 |
| === cprov is now known as cprov-out | ||
| dennda | Hi | 18:09 |
| dennda | I got a branch with several revisions | 18:09 |
| dennda | I now discovered that, by magic, one important file got lost | 18:09 |
| dennda | How would I best go about restoring that single file from a previous revision? | 18:09 |
| jam | dennda: bzr revert -r XXX filename | 18:16 |
| jam | bzr commit -m "restore filename" | 18:16 |
| dennda | thanks | 18:20 |
| ehazlett | greetings... i am getting an error when trying to import a svn repo ERROR: Invalid revision-id {None} | 18:29 |
| jelmer | ehazlett: What version are you using? | 18:30 |
| ehazlett | Bazaar (bzr) 0.90.0 -- ubuntu | 18:31 |
| jelmer | ehazlett: this bug was fixed recently - it's not in any bzr-svn release yet | 18:32 |
| ehazlett | ok | 18:32 |
| jelmer | ehazlett: you can use the 0.4 branch of bzr-svn but that will requires bzr >= 1.4 | 18:32 |
| ehazlett | cool. | 18:32 |
| ehazlett | i will build from svn :) | 18:32 |
| ehazlett | ... bzr ;) | 18:33 |
| ehazlett | is the release on the bzr site (ubuntu) 1.4? | 18:33 |
| jelmer | no, 1.5 | 18:33 |
| jelmer | but 1.5 should work just as well | 18:33 |
| ehazlett | ok. thanks for all of your help! | 18:33 |
| dvheumen | hi, I was wondering... I know that bzr currently does not support large (binary) files. Is there any indication when this support may be added? (few months? few years?) (If I could contribute, I would, but I am not at all familiar with Python or bazaar, so I think that would be kind of a long shot) | 18:45 |
| beuno | dvheumen, well, it supports them, just needs a lot of RAM to do so | 18:45 |
| dvheumen | beuno: yeah i figured that much out already reading the mailinglist and sorts | 18:46 |
| dvheumen | but I was wondering ... at the moment there's no mention yet of it being implemented any time soon? | 18:46 |
| dvheumen | (or not soon :P) | 18:47 |
| beuno | a lot of work is being done on performance these cycles, but I'm not sure that's a part of it | 18:47 |
| dvheumen | I think I read something about that on the 1.6 milestone list | 18:47 |
| beuno | dvheumen, I'd say, make sure there is a bug open about it with enough information, and suscribe/comment on it | 18:48 |
| dvheumen | beuno: I found this bug description and I think this is quite accurately described: https://bugs.launchpad.net/bzr/+bug/109114 But it says 'Nominated for 0.90' although I think it isn't of any significance | 18:51 |
| ubottu | Launchpad bug 109114 in bzr "commit holds whole files in memory" [Medium,Confirmed] | 18:51 |
| beuno | dvheumen, follow up on that. Someone randomly nominated it, but it seems it didn't get done | 18:53 |
| dvheumen | beuno: what do you mean exactly with follow up, I have subscribed but do you mean to post more information or something else? | 18:54 |
| beuno | dvheumen, yes, that usually helps | 18:55 |
| beuno | more ways to reproduce it, attaching your .bzr.log, resource usage, etc | 18:55 |
| beuno | it makes it more likely someone will pick it up | 18:55 |
| dvheumen | hmmm... okay, posting more resource usage sounds useful... at least it's better than just saying "Hey, ... I'd like this to be fixed too!" :P | 18:56 |
| dvheumen | okay, thanks I will do that | 18:57 |
| beuno | thanks :) | 18:57 |
| beuno | (I run into that bug quite frequently too, btw) | 18:58 |
| dvheumen | well, the thing is that I wanted to use it for something else than just simple source code file storage, but I found out larger files aren't supported yet so that's quite a bummer... other than that this seems to be the VCS I'm looking for | 18:59 |
| dvheumen | I'm using SVN at the moment, but I would like to have some more distributed features and such | 19:00 |
| beuno | yes, it's definetly something we want ASAP | 19:00 |
| pickscrape | Won't the streaming stuff I've read about help there, or is that a different part of the code? | 19:02 |
| dvheumen | I've read something about a MemoryError fix for HTTP Proxy something | 19:02 |
| dvheumen | but I thought that it was about a different function, mainly because it specifically names HTTP | 19:03 |
| === cprov-out is now known as cprov | ||
| dvheumen | although I think these kind of things can be fixed with doing a streaming diff with a fixed window | 19:04 |
| dvheumen | I think the fix you just talked about is this one: https://bugs.launchpad.net/bzr/+bug/215426 | 19:05 |
| ubottu | Launchpad bug 215426 in bzr "MemoryError - recv for HTTP through Proxy" [Medium,Fix released] | 19:05 |
| beuno | yeah, I think that's unrelated | 19:07 |
| dvheumen | I have to go, thanks for the information ... it may take a few weeks because of examinations, but after that I'll try to post some performance/resource information if it helps you | 19:08 |
| jam | vila: earlier you talked with abently about how the LP mirror of bzrtools seems out of date | 19:34 |
| jam | I believe that is because it is a manual upload | 19:34 |
| jam | not an lp mirror | 19:34 |
| jam | At least looking at: https://code.edge.launchpad.net/~abentley/bzrtools/bzrtools.dev | 19:34 |
| jam | It doesn't show it as a mirror branch | 19:34 |
| jam | You cannot upload to this branch. Only Aaron Bentley can upload to this branch. | 19:34 |
| jam | vila: do you remember the official location Aaron gave? | 19:35 |
| jam | http://bazaar-vcs.org/BzrTools | 19:35 |
| jam | has the launchpad one | 19:35 |
| jam | I suppose I found http://code.aaronbentley.com/bzr/bzrrepo/bzrtools/ by poking around manually | 19:36 |
| === AnMaster is now known as AnMaster_ | ||
| === AnMaster_ is now known as AnMaster | ||
| vila | jam: that's the one aaron gave me (I was having dinner, sorry for the delay ;-) | 19:41 |
| jam | vila: I'm deeply offended that you would think to go away from IRC for long enough to eat | 19:41 |
| jam | I expected more from you, vila | 19:41 |
| jam | :) | 19:41 |
| jam | I hope the food was good | 19:41 |
| vila | apache2 was giving an headache, I had to eat :-) | 19:42 |
| vila | It seems I can't explain him that I want directory listings... | 19:42 |
| jam | vila: <Directory "/srv/bzr/public"> | 19:44 |
| jam | Options Indexes FollowSymLinks | 19:44 |
| jam | Isn't that enough? | 19:45 |
| vila | no :-( | 19:45 |
| beuno | vila, maybe it has NoOverride set? | 19:45 |
| vila | beuno: Hi | 19:46 |
| vila | beuno: How can I check that ? | 19:46 |
| vila | It's a test server with a very limited configuration | 19:46 |
| fullermd | jam: re: bug 235715; could well be a 'cherrypick' in the form of 'add --file-ids-from'... I do that from time to time when I find I want a file on 2 branches that will be merging somewhere down the road. | 19:46 |
| ubottu | Launchpad bug 235715 in bzr ""bzr merge --lcs" (criss-cross merge) stops with error "bzr: ERROR: Reserved revision-id {null:}"" [High,Confirmed] https://launchpad.net/bugs/235715 | 19:46 |
| jam | fullermd: well, this was converted from another source | 19:47 |
| jam | so there are lots of ways it *might* happen | 19:47 |
| beuno | vila, let me see how to check for that... (it's very normal in shared hosts) | 19:47 |
| beuno | vila, can you see the apache conf file? | 19:48 |
| vila | just a sec | 19:48 |
| gour | how does lighttpd play with bzr? | 19:48 |
| beuno | vila, check for: "AllowOverride None" | 19:48 |
| vila | !paste | 19:49 |
| ubottu | pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic) | 19:49 |
| beuno | /etc/apache2/sites-enabled/000-default would be the default location | 19:49 |
| vila | http://paste.ubuntu.com/15607/ | 19:49 |
| beuno | vila, check in the location above ^ | 19:50 |
| vila | ...and don't tell me 66 lines is evil :-) | 19:50 |
| vila | beuno: it's not included | 19:50 |
| vila | it's a test server I setup myself, not the default apache2 server | 19:51 |
| vila | from http://localhost/doc/apache2-doc/manual/mod/mod_autoindex.html#indexoptions all I have to do is to laod the module and use 'Options Indexes' I put a '+' just to be sure :-/ | 19:52 |
| beuno | vila, I always add that within the <Directory> bit, which you seem to not have setup | 19:53 |
| jelmer | abentley: anything in particular that's blocking rich-root-pack as default in 1.6 ? | 19:54 |
| james_w | I'm working on the SRU for bug 230294, and I need a test case for verification of the fix, a checkout over http doesn't trigger it, are there more conditions that need to be true? | 19:54 |
| ubottu | Launchpad bug 230294 in bzr "ERROR: bzrlib.errors.KnitCorrupt: Knit <bzrlib.knit.KnitGraphIndex object at 0x86e1e2c> corrupt: attempt to add line-delta in non-delta knit" [Undecided,Fix released] https://launchpad.net/bugs/230294 | 19:54 |
| vila | beuno: Because I presumed <directory> inherits from server settings and, as it is a test server, I don't know what directories will exist | 19:55 |
| gour | huh, more bzr rant in dvc-thread http://article.gmane.org/gmane.emacs.dvc.devel/2166 | 19:55 |
| jam | statik: we on for "this week" in 5 min? | 19:55 |
| vila | gour: If you read the thread, you'll see that mwolson is not an example of impartiality, I will not continue that discussion | 19:57 |
| beuno | vila, try adding a <Directory> config | 19:57 |
| abentley | jelmer: http://bundlebuggy.aaronbentley.com/request/%3C48221A5F.60208@aaronbentley.com%3E and uncertainty about whether we should do a new format just be be safer. | 19:57 |
| vila | beuno: I tried it (deleted it in the pastedbin), same results | 19:58 |
| vila | the error log says Attempt to serve directory: /v/home/vila/.bazaar/plugins/local_test_server/work/apache2/www/tagada/ | 19:58 |
| vila | or without 'tagada' :-) | 19:58 |
| vila | in the apache sources that string appears in asingle place>: when serving a GET request for a directory in the default handler | 19:59 |
| beuno | vila, well, the only other configs I ahve related to Indexes are: "IndexOptions FancyIndexing VersionSort" and "" | 19:59 |
| vila | tell me more about "" | 20:00 |
| vila | :-) | 20:00 |
| beuno | vila, lol | 20:01 |
| beuno | I was expecting for 2 config options, but it was unrelated | 20:01 |
| gour | vila: you're right. "not possible to teach old dog new tricks..." | 20:01 |
| vila | too bad :-/ | 20:01 |
| beuno | and it's a bit crazy at the office today, so I was talking to someone while typing :p | 20:01 |
| beuno | vila, any symlinks involved? if there is: add: FollowSymLinks | 20:02 |
| beuno | and I'm out of ideas :) | 20:02 |
| vila | beuno: thanks for the help, I tried all of that, thanks for confirming these solutions, may be something else is wrong in my setup | 20:03 |
| jam | james_w: generally you have to push from a pack repository into a knit repository | 20:04 |
| jam | I *think* you have to push multiple revisions | 20:04 |
| beuno | vila, one last thing that may have something to do with it: DirectoryIndex index.html index.cgi index.pl index.php index.xhtml | 20:04 |
| statik | jam: sorry i had to run downstairs for a minute, i'm back | 20:04 |
| jam | and then it will create one with a 'line-delta' when it shouldn't | 20:04 |
| jelmer | abentley, thanks | 20:04 |
| jam | then when you pull back from the knit repo => pack repo | 20:04 |
| james_w | jam: ah, thanks, I got a failure with bzr+ssh:// | 20:05 |
| jam | it fails because it shouldn't have had the line-delta in the first place | 20:05 |
| jam | statik: so you ready for thisweek? | 20:06 |
| james_w | the problem now is that the patch doesn't apply to 1.3.1 | 20:06 |
| jam | james_w oops, why not? | 20:06 |
| jam | I'm guessing it is close to correct | 20:06 |
| james_w | I can't find any of the context from the diff -c of the revision that claims to fix it from bzr.dev | 20:07 |
| jam | james_w: don't you mean bug 217701? | 20:07 |
| ubottu | Launchpad bug 217701 in bzr "attempt to add line-delta in non-delta knit" [Critical,Fix released] https://launchpad.net/bugs/217701 | 20:07 |
| james_w | jam: yep, this is a duplicate, but it's already set up for an SRU, so I'll just carry on. | 20:08 |
| vila | statik: ping, do you have a few minutes ? | 20:08 |
| jam | vila: statik and I are working on "This Week" in bazaar right now, but he might have some time | 20:08 |
| vila | jam: remind me the url again :) | 20:09 |
| jam | jam-bazaar.blogspot.com | 20:10 |
| vila | thks | 20:10 |
| jam | statik: you got to "probably gonna drop my".... static | 20:15 |
| vila | YES | 20:36 |
| vila | stupid apache doc | 20:36 |
| vila | they say: "so you can use or desactivate module A and/or B" but they forget to say: if you want module B only, load module A anyway :-) | 20:37 |
| vila | soooo, if you need autoindex_module, load dir_module, just because | 20:38 |
| vila | and with that apache2 pass the bzr test suite (well, the 70 tests triggered by bzr selftest -s bzrlib.tests.test_transport_implem -v Apache2 ) | 20:40 |
| === mw is now known as mw|food | ||
| felipec | how can I clone this? http://stephan.kochen.nl/bzr/gstraopsink/ | 20:47 |
| beuno | felipec, bzr branch http://stephan.kochen.nl/bzr/gstraopsink/ | 20:47 |
| felipec | beuno: thanks | 20:48 |
| beuno | felipec, welcome' | 20:49 |
| felipec | I tried with .bzr =/ | 20:49 |
| vila | beuno: the fix was to 'LoadModule dir_module /usr/lib/apache2/modules/mod_dir.so' :-/ | 20:49 |
| beuno | vila, ah, I would ov never guessed that :) | 20:50 |
| jam | vila: all that to test against the test suite | 20:50 |
| jam | ouch | 20:50 |
| vila | now that you mention it, I have already forgotten why the hell I tried that... | 20:50 |
| jam | Do we need indexes to be able to run against apache? | 20:51 |
| jam | We shouldn't | 20:51 |
| vila | jam: strange isn't it, before I activated it the failing test was: test_has_root_works | 20:51 |
| lifeless | jam: that mpdiffs stuff you are doing; the extra try:finally also seems redundant to me | 20:52 |
| jam | lifeless: it was already there, if you want, I could just get rid of it | 20:52 |
| lifeless | jam: I have found an apparent bug leading to deltas with 1 line too few in that code though - with annotated knits | 20:53 |
| lifeless | jam: I'm replacing the entire code section | 20:53 |
| vila | jam: but being able to plug a real server in the test suite will greatly simplify writing test servers for https and webdav, simplifying writing correct client implementations, simplifying writing robust ftp client implementation, etc, etc, | 20:53 |
| jam | lifeless: I'm fine with seeing it go, but we may want to patch it until your stuff lands | 20:53 |
| lifeless | jam: don't wait | 20:53 |
| jam | vila: sure, I think it is a great thing to have. I'm trying to understand why we would need indexes | 20:53 |
| jam | vila: because if we do, it means we have a bug | 20:53 |
| jam | lifeless: for this week in bazaar, I'm writing about Stacked Branches | 20:54 |
| jam | do you have any URLs I could give? | 20:54 |
| vila | jam: I don't think we really *need* indexes, but I don't want to gratuitously skip some tests either | 20:55 |
| jam | vila: sure. something called "has_root" sounds like something that we shouldn't be doing anyway | 20:55 |
| vila | I'm interested in understanding why test_has_root_works (which test transport.has("/") is needed though | 20:55 |
| jam | It might be a carry over from old transport tests | 20:55 |
| statik | vila: i suck, i'm on the phone solid all day today | 20:56 |
| jam | vila: I would say that we *don't* need it, but we probably had a bug with passing an absolute path at one point | 20:56 |
| vila | statik: just one word then :-) Are you just delayed or something wrong is going on ? | 20:56 |
| jam | we shouldn't be *passing* absolute paths to those functions | 20:56 |
| statik | vila: just delayed | 20:57 |
| vila | statik: 2 good words, thanks :) | 20:57 |
| lifeless | jam: only those in the various communications I've made about it | 20:57 |
| jam | well, are there *public* ones? | 20:58 |
| jam | I remember some comments about rookery, etc | 20:58 |
| jam | This is something that we would point interested users to | 20:58 |
| jam | lifeless: I honestly haven't seen any URLs given on bazaar@lists... | 20:59 |
| jam | Only on bazaar-canonical@ | 21:00 |
| jam | which means it isn't public | 21:00 |
| lifeless | uhm | 21:00 |
| jam | I just went back and searched my folders | 21:00 |
| lifeless | I'm sure I've posted the loom location, status updates etc all to bazaar@ | 21:01 |
| jam | I found "Stacking Policy" from aaron | 21:01 |
| jam | Your status updates haven't had a url in them | 21:01 |
| jam | just "Things to be done" | 21:01 |
| lifeless | all the bundles have source_branch: http://people.ubuntu.com/~robertc/baz2.0/shallow-branch in their headers | 21:02 |
| jam | lifeless: with the one caveat that all of your submissions have been under the heading "VersionedFiles" not "Stack*" | 21:03 |
| jam | and while I realize one is a precursor to the other | 21:03 |
| lifeless | or shallow | 21:03 |
| lifeless | in fact, 'shallow' predates versionedfiles | 21:03 |
| lifeless | in the bazaar@ mail list | 21:04 |
| michalski | hey, I've got a problem: when typing: bzr push lp:~michalski/+junk/<XYZ> | 21:14 |
| michalski | it comes back with error: | 21:15 |
| michalski | Unable to obtain lock lp--1221433044:///~michalski/+junk/vector-core/.bzr/branch/lock | 21:15 |
| michalski | held by michalski@bazaar.launchpad.net on host vostok [process #22773] | 21:15 |
| michalski | locked 79 minutes, 10 seconds ago | 21:15 |
| beuno | michalski, bzr break-lock lp:~michalski/+junk/vector-core | 21:15 |
| michalski | ah ok :) thanks | 21:16 |
| beuno | (a better message for that will be available in the next bzr release) | 21:16 |
| michalski | worked, thanks beuno | 21:17 |
| === mw|food is now known as mw | ||
| james_w | statik, jam: nice work, it's a good explanation | 22:00 |
| james_w | is there any plan for server-side forking in launchpad with stacked branches? | 22:01 |
| statik | james_w: thanks! lp will support stacked branches, but I think server-side forking is a ways off. | 22:03 |
| lifeless | abentley: ping | 22:03 |
| abentley | lifeless: pong | 22:04 |
| lifeless | I've got something wrong with mpdiffs in my new code | 22:04 |
| james_w | fair enough, I think it may make it clearer to a user what is going on, but I understand that it makes very little difference to the data. | 22:04 |
| lifeless | I'm hoping you can spend a few minutes with me to walk me through/clarify some stuff | 22:04 |
| abentley | Sure. | 22:05 |
| lifeless | so in an annotated knit the 'noeoldup' test text fails | 22:05 |
| lifeless | it ends up serialising wrongly - the serialised text is missing a \n and the knit record is corrupted | 22:06 |
| lifeless | I've tracked this down I think to the output of get_mpdiffs differing | 22:06 |
| lifeless | in the original knit code, we get: | 22:06 |
| lifeless | MultiParent([NewText(['line\n'])]) | 22:07 |
| mwhudson_ | beuno: hello! | 22:07 |
| lifeless | (which is conceptually strange to me, because both texts are == ['line'] ) | 22:07 |
| lifeless | in the new code, we get: | 22:07 |
| beuno | mwhudson_, morning! I was just closing all my work-related windows to get started on loggerhead :) | 22:07 |
| lifeless | MultiParent([ParentText(0, 0, 0, 1)]) | 22:08 |
| lifeless | which is what I would expect | 22:08 |
| mwhudson_ | :) | 22:08 |
| lifeless | (the new code runs same test scenario tweaked for api etc) | 22:09 |
| abentley | So you are doing a diff and the MultiParent([NewText(['line\n'])]) is the result? | 22:09 |
| lifeless | with the original knit code yes ('test_make_mpdiffs' from test_versionedfile.py) | 22:09 |
| lifeless | I checked that by adding: | 22:09 |
| lifeless | if version == 'noeoldup': | 22:09 |
| lifeless | print "Y", mpdiff, version | 22:09 |
| lifeless | to that tests inner loop | 22:10 |
| lifeless | now what I *think* might be happening is that the get_mpdiffs with knits is broken for the specific case of the last line with noeol | 22:10 |
| lifeless | but that something else is compensating on insertion | 22:11 |
| abentley | Another possible problem would be trusting the KnitDelta's concept of 'line'. | 22:11 |
| abentley | It might be split on | 22:11 |
| abentley | \r or something. | 22:11 |
| lifeless | not in the test case :) | 22:12 |
| lifeless | ok, well I'll keep poking at this | 22:14 |
| lifeless | I am concerned that when I find the root cause and fix it for the original code there will be some underlying issue exposed | 22:15 |
| abentley | lifeless: A NewText always has a trailing newline. | 22:15 |
| abentley | At least in the serialization. Quite possibly in the repr | 22:15 |
| lifeless | ok | 22:16 |
| lifeless | how do you signal to a reciever that they should not have a trailing eol ? | 22:16 |
| abentley | I signal that they *should* have a trailing eol by doubling it. | 22:16 |
| abentley | Having a single \n means it should be stripped. | 22:17 |
| lifeless | ok, so ['line\n', '\n'] -> 'line' as bytes ? | 22:17 |
| abentley | No, ['line\n'] -> 'line'. ['line\n', '\n'] -> 'line\n' | 22:18 |
| lifeless | right, | 22:18 |
| * lifeless wipes sleep from eyes | 22:18 | |
| lifeless | alright, the generated patch is ok, but its not matching where it can | 22:18 |
| beuno | mwhudson_, I'm going through all the comments on the theme, so I can address all of them and move on to the HTML/CSS fun-part | 22:18 |
| abentley | lifeless: Odd, but I guess better. | 22:19 |
| lifeless | ahha! | 22:21 |
| lifeless | _extract_blocks is buggy | 22:21 |
| lifeless | abentley: can you do an experiment for me, just want to know its not me :) | 22:21 |
| abentley | I can do a quick one. | 22:21 |
| lifeless | change _extract_blocks in knit.py to return None | 22:21 |
| lifeless | and run | 22:21 |
| lifeless | ./bzr --no-plugins selftest versionedfile.*make_mpd | 22:22 |
| abentley | I get a KnitCorrupt. | 22:22 |
| lifeless | yup | 22:22 |
| lifeless | excellent | 22:22 |
| abentley | Knit <bzrlib.knit._KnitAccess object at 0x9ad5eac> corrupt: incorrect number of lines 1 != 2 for version {noeolsecond} | 22:23 |
| lifeless | we currently never match the last line of identical files if they both have no trailing eol | 22:23 |
| abentley | lifeless: We currently override that, actually. | 22:24 |
| abentley | see KnitContent.get_line_delta_blocks | 22:24 |
| lifeless | abentley: indeed - to never match | 22:24 |
| abentley | lifeless: The intention is to make them match. | 22:25 |
| lifeless | abentley: but if no optimised matcher is provided, we do a full diff, which the code I'm working on does | 22:25 |
| mwhudson__ | beuno: sounds great | 22:25 |
| lifeless | (because I haven't yet hooked in the optimiser) | 22:25 |
| lifeless | abentley: well, it doesn't seem to have the effect of making them match | 22:26 |
| abentley | Well, this is in the case when there's an optimizer present. | 22:26 |
| lifeless | the optimiser should say they match totally, but it doesn't | 22:27 |
| lifeless | anyhow | 22:27 |
| abentley | Why not? | 22:27 |
| lifeless | I don't know - I've been working through this as we speak, as I said I didn't know enough | 22:28 |
| lifeless | when I started digging I just had a knit corrupt and was pulling on the chain | 22:28 |
| abentley | knit.py: 332 is supposed to do specifically that. | 22:28 |
| lifeless | all I can say right now is that when there is no optimiser the diff correctly reuses the parent text entirely | 22:29 |
| lifeless | and that we have a separate more severe bug | 22:29 |
| lifeless | inserting into annotated knits with an identical noeol text that is a snapshot corrupts the text | 22:30 |
| lifeless | (which is the error you see) | 22:30 |
| lifeless | so we can't actually fix this generation bug for current bundles, or something | 22:30 |
| abentley | Ah. Bogus. | 22:30 |
| lifeless | (it copies the annotated representation from the basis including the *lack* of trailing \n, so the record can't be parsed) | 22:31 |
| lifeless | I'll finish analysing this on bzr.dev and write it up for consideration by the list | 22:31 |
| lifeless | It's orthogonal to what I'm doing, and now I know it exists in potentia in bzr.dev I'm not blocked | 22:32 |
| lifeless | thanks for the hand, very useful and saved me time | 22:32 |
| === mwhudson__ is now known as mwhudson | ||
| abentley | lifeless: I don't recall precisely how it worked with annotation, but it's a bit surprising, because mpdiffs aren't annotated. | 22:56 |
| jelmer | lifeless: I've almost finished merging bzr.dev into your shallow branch branch, btw | 22:57 |
| mkanat | jam: If you have any questions about https://bugs.launchpad.net/bzr-cvsps-import/+bug/235884 I'll be around for a bit (if you're around). | 23:03 |
| ubottu | Launchpad bug 235884 in bzr-cvsps-import "cvsps_import can think that trunk checkins happened on a new branch" [Undecided,New] | 23:03 |
| jam | mkanat: If i was to bet, I would say it is confusion on the part of cvsps, and I'm just copying what it is telling me to | 23:05 |
| mkanat | jam: It's possible. I can attach the cvsps log, I'll do that. | 23:05 |
| mkanat | jam: I was thinking it was also possible that cvsps_import creates branches by branching against HEAD w/o a revision number. | 23:08 |
| jam | mkanat: that is possible as well, though the graph itself should tell me where to branch | 23:08 |
| mkanat | jam: Yeah. There's some weirdness in Patchset 8195, where it says that one file is INITIAL->1.95, on HEAD. | 23:09 |
| mkanat | How do you fix the content-type of an attachment in Launchpad? | 23:10 |
| jam | mkanat: AFAIK it is auto detected, I don't know a way to change it | 23:11 |
| mkanat | That's kind of lame. I can't imagine why it would have autodetected that file as text/html. "file" says it's ASCII text. | 23:12 |
| mkanat | Looks like I can't fix it by manually branching from HEAD at the right point, I get a traceback from bzr when doing an import after that. | 23:17 |
| jam | mkanat: are you getting this warning: | 23:19 |
| jam | trace.warning('%s claims an ancestor branch %s which does | 23:19 |
| jam | ' not exist yet. Falling back to HEAD', | 23:19 |
| jam | patchset, patchset.ancestor_branch) | 23:19 |
| mkanat | jam: I'll check. | 23:19 |
| mkanat | jam: Not unless --quiet turns that off. | 23:20 |
| jam | mkanat: so... looking at the code, I think you are approximately correct | 23:20 |
| jam | specifically, I see this patch: | 23:20 |
| jam | PatchSet 8199 | 23:20 |
| jam | Date: 2008/05/21 23:03:24 | 23:20 |
| jam | Author: lpsolit%gmail.com | 23:20 |
| jam | Branch: BUGZILLA-3_2-BRANCH | 23:20 |
| jam | Ancestor branch: HEAD | 23:20 |
| jam | Tag: (none) | 23:20 |
| jam | Log: | 23:20 |
| jam | mkanat: the problem is that cvsps import doesn't actually give me a base revision to branch from | 23:20 |
| jam | so I just branch from whatever is the current tip | 23:20 |
| mkanat | Ah, yeah. | 23:20 |
| mkanat | You could figure it out, theoretically, from the version numbers. | 23:21 |
| mkanat | Provided that they haven't done anything wonky with their cvs binary. | 23:21 |
| jam | mkanat: and part of *that* is because CVS logs aren't very good at telling you what was going on | 23:21 |
| jam | mkanat: what version numbers? | 23:21 |
| mkanat | Yeah, I ran into a lot of that with VCI. | 23:21 |
| jam | the one for the file? | 23:21 |
| mkanat | jam: The file version numbers. | 23:21 |
| jam | 1.7->1.7.2.1 | 23:21 |
| jam | But did *that* file change on HEAD | 23:21 |
| mkanat | jam: Yeah. 1.7 will have existed in some patchset. | 23:21 |
| jam | or just the *other* files | 23:21 |
| mkanat | Oh, right. | 23:21 |
| mkanat | Because you can't know what the actual last HEAD revision was. | 23:22 |
| jam | yeah | 23:22 |
| mkanat | Man, CVS is so lame. | 23:22 |
| jam | mkanat: you might find that using "cvs2svn --fast-export | bzr fast-import" works better for you | 23:22 |
| jam | I don't really know | 23:22 |
| mkanat | jam: If you had actual access to the repository files, would there be any way to figure that out, do you know? | 23:22 |
| mkanat | jam: The problem is that I have about 30 branches based on my current imports, right now. | 23:23 |
| jam | mkanat: unforunately, I don't know much detail about how cvsps works | 23:23 |
| jam | I built on it, since it seemed tobe the recommended tool | 23:23 |
| jam | (everyone else was doing it, and such) | 23:23 |
| jam | only to find out later that it isn't really very good | 23:23 |
| mkanat | Yeah. I did the same when I needed to abstract away CVS. | 23:23 |
| mkanat | Yeah, but it's still the only tool. | 23:23 |
| mkanat | jam: I'd be fine with switching to cvs2svn, but I need to keep my current branches updated... | 23:24 |
| lifeless | abentley: the corruption is not mpdiffs fault AFAICT | 23:24 |
| lifeless | jam: this is why cscvs doesn't use it :P of course cscvs then has its own problems | 23:25 |
| mkanat | jam: I also have no idea how it's constructing the history now, pulling patches with an unrelated history... | 23:25 |
| jam | mkanat: I'm not sure what you mean by unrelated history | 23:26 |
| abentley | lifeless: Ah, cool. | 23:26 |
| mkanat | jam: Well, theoretically a file is a collection of changes, and we have some HEAD changes followed by some 3.2 changes that may or may not have been to files with the same content. | 23:26 |
| lifeless | abentley: its just triggerable *by* mpdiffs, and only triggers when mpdiffs creation is fixed for this corner case | 23:27 |
| lifeless | abentley: a classic example of cascade failure/masked bugs | 23:27 |
| jam | mkanat: I believe it goes to 'snapshots' each time | 23:27 |
| abentley | Heh. | 23:27 |
| mkanat | jam: Ahh... | 23:27 |
| jml | lifeless: hi | 23:27 |
| jml | lifeless: may I draw your attention to my bzr-loom patch. | 23:27 |
| lifeless | jml: the one I reviewed? | 23:28 |
| jml | orly? | 23:28 |
| mkanat | jam: Any suggestions on how to fix the situation I'm in now? Reverse the additional checkins? | 23:28 |
| lifeless | couple of days ago? | 23:28 |
| jml | lifeless: where did you review it? | 23:28 |
| * jml frowns | 23:28 | |
| jam | mkanat: well, depending on what is going on you *might* be able to rebase your changes onto a new converision | 23:28 |
| * jml sees now | 23:28 | |
| jam | I don't know how well rebase handles that case yet, but it is a use case for it to handle | 23:28 |
| mkanat | jam: Oh, we have rebase now? | 23:29 |
| lifeless | we do, in a plugin | 23:29 |
| lifeless | where it shall remain ;P | 23:29 |
| mkanat | Hahaha. | 23:29 |
| jam | mkanat: there is a plugin, worked on by jelmer, lp:bzr-rebase | 23:29 |
| lifeless | there is a bug open on it for integration with treemapper | 23:29 |
| lifeless | which would be needed to do what jam is suggesting | 23:29 |
| * elmo is still waiting for bzr rerere | 23:29 | |
| * lifeless tickles elmo | 23:29 | |
| lifeless | I love how that is spelt: '/me tickles elmo' | 23:30 |
| jml | lifeless: anyway, thanks for the review. | 23:30 |
| lifeless | its *almost* right | 23:30 |
| mkanat | Yeah, I'd think that this would be a good use case for rebase. | 23:30 |
| mkanat | lifeless: So you're saying that rebase won't do what I need right now, then? | 23:30 |
| lifeless | mkanat: AIUI there is a missing feature - the file id mapping logic. I may be wrong. | 23:30 |
| lifeless | mkanat: but given you are converting between two mirrors of cvs, no renames are involved so a simple-implementation would likely suffice | 23:31 |
| mkanat | lifeless: Okay. I guess I'll try and see if it goes. | 23:32 |
| jam | by the way elmo, thanks for whatever you did to pqm, it is much snappier now | 23:32 |
| jam | (that could just be updating to the latest kernel) | 23:32 |
| lifeless | jam: it's a bzr bug | 23:32 |
| lifeless | jam: elmo replaced the kernel to work around it | 23:32 |
| jam | lifeless: sort of | 23:32 |
| jam | The fact that one kernel is 10x slower than the other... | 23:32 |
| jam | I can agree that it going from 5 => 18s is bzr | 23:33 |
| jam | but going from 5 => 300ms seems like the kernel | 23:33 |
| lifeless | jam: there are two theories. one is the GIL & thread starvation, the other TCP autotuning | 23:33 |
| lifeless | jam: elmo thinks its tcp autotuning that the new kernel *adds* (e.g. kernel works around broken application requests) | 23:33 |
| lifeless | jam: I think its GIL starvation due to scheduler changes | 23:34 |
| jam | by the way, I wasn't able to reproduce it on tungsten | 23:34 |
| lifeless | jam: either way its around 99% certainty that bzr is faulty | 23:34 |
| elmo | jam: what? | 23:34 |
| jam | at least, when I ran the test it ran in 300ms | 23:34 |
| jam | rather than 5+s | 23:34 |
| lifeless | really must disappear for a bit | 23:34 |
| jam | elmo: I submitted 2 patches to PQM, and it was done in < 1 hr | 23:34 |
| jam | It used to take 2hrs to complete 1 | 23:34 |
| jam | So I appreciate your work in that area | 23:35 |
| elmo | jam: try the branch in ~james/haha/home/+trunk | 23:35 |
| elmo | it's entirely reproducable on tungsten there | 23:35 |
| elmo | if it's gone in current bzr.dev that jus tproves it was bzr and not the kernel ;-) | 23:35 |
| elmo | as spiv said he fixed the batching of stuff in the smart server | 23:35 |
| jam | right, but AFAIK that would explain 5=>18 not .3 | 23:35 |
| elmo | err, no? | 23:36 |
| elmo | it's 18 on tungsten right now, if I upgraded tungsten's kernel, it'd go to .3 | 23:36 |
| elmo | it goes to 5 iff I revert back from that branch -1000 revisions | 23:36 |
| elmo | + stay on the current kernel | 23:36 |
| mkanat | jam: Oh, cvs2svn won't do what I need, since it apparently doesn't support repeated syncs. | 23:37 |
| jam | elmo: well we seemed to have fixed it then, bzr.dev @3452 gives 394ms | 23:37 |
| jam | and I did reproduce your "haha" at 18.5s | 23:37 |
| elmo | ok, cool | 23:38 |
| elmo | spiv: ^-- whatever you did, don't ever undo it ;-) | 23:38 |
| jam | elmo: how did you get that directory? it would probably be good to know what revision, etc you are using there | 23:38 |
| elmo | jam: that was a copy of trunk at the time we were diagnosing the problem | 23:38 |
| jam | elmo: so you don't have an idea of a number, right? | 23:39 |
| jam | I think I just isolated it to Spiv's buffering patch | 23:39 |
| jam | rev 3451 == 18.9s | 23:40 |
| jam | rev 3452 == 349ms | 23:40 |
| jam | pretty good indication | 23:40 |
| jam | 3452 Canonical.com Patch Queue Manager 2008-05-24 [merge] | 23:40 |
| jam | Speed up HPSS v3 by buffering writes to the medium. (Andrew Bennetts) | 23:40 |
| jam | elmo: so I got "lucky" that andrew had just merged his patch when I went to test the bug | 23:40 |
| elmo | jam: right | 23:40 |
| lifeless | jam: see, bzr :) | 23:42 |
| elmo | oh, yay, that revision even had tests | 23:42 |
| lifeless | jam: generally, whenever bzr is slow, its bzr's fault until proved otherwise :) | 23:42 |
| lifeless | irrespective of the width of the change | 23:43 |
| johan | $ bzr push lp:~jdahlin/bzui/main | 23:57 |
| johan | bzr: ERROR: Transport operation not possible: http does not support mkdir() | 23:57 |
| johan | do you guys know why I get this? | 23:57 |
| johan | using bzr 1.3.1 | 23:57 |
| beuno | johan, you probably haven't set your lp-login | 23:57 |
| beuno | bzr launchpad-login username | 23:58 |
| johan | beuno: oh | 23:58 |
| beuno | should solve it | 23:58 |
| johan | not a very good error message ;) | 23:58 |
| beuno | not at all, and it's been fixed in 1.4 I believe | 23:58 |
| beuno | (you can get the latest and greatest from the PPA) | 23:59 |
| beuno | https://launchpad.net/~bzr/+archive | 23:59 |
| johan | cheers | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!