[00:01] <poolie> hello jam
[00:01] <jam> hi poolie, a little late for "before the standup call" :)
[00:01] <poolie> yeah :)
[00:15] <strk> I have two branches in a repository. One I use for dev, standalone. Another I use for trackign trunk, bound upstream.
[00:15] <strk> a working tree switches between the two
[00:15] <strk> bzr diff ../bzr-local-repository/trunk # shows nothing
[00:16] <strk> bzr diff ../bzr-local-repository/mybranch # shows nothing
[00:16] <strk> from the working tree
[00:16] <strk> is that enough to tell 'trunk' and 'mybranch' don't differ ?
[00:17] <strk> bzr diff ../bzr-local-repository/trunk ../bzr-local-repository/mybranch # gives me:
[00:17] <strk> bzr: ERROR: sorry, u'..' not allowed in path
[00:17] <strk> what does the << u'..' >> part mean ?
[00:17] <strk> typo in bzr code ?
[00:18] <emgent> heya
[00:21] <spiv> strk: the u'' is Python's way of indicating a unicode string.
[00:23] <strk> thx, any idea about previous question ?
[00:23] <strk> i'm having troubles figuring out a good workflow, as it seems every merge puts my working tree in a non-up-to-date status
[00:24] <strk> even if there's nothing to merge (apparently, since diff gives no diffs)
[00:24] <spiv> Well, there are different types of differences :)
[00:24] <spiv> There's difference in content, that's what "bzr diff" does.
[00:24] <strk> it seems I basically got an 'empty' commit in mybranch
[00:25] <spiv> There's also difference in history.  "bzr missing" can report on that.
[00:25] <strk> which I guess is the commit that a merge to trunk is showing as a "pending merge" again
[00:26] <strk> the two branches obviously have a different history
[00:26] <strk> if, from a trunk-bound tree I call 'bzr missing mybranch'
[00:26] <strk> I get that annoying missed revision
[00:27] <strk> message:   trunk merge ?
[00:27] <strk> that's a commit after a merge of trunk to mybrach
[00:28] <strk> seems silly to merge back to trunk, as it came from trunk initially!
[00:28] <spiv> You might prefer "bzr merge --pull"
[00:28] <strk> kind of an egg & chicken
[00:37] <igc> morning
[00:41] <lifeless> strk: this is a bug actually;
[00:41] <lifeless> strk: the graph fails to converge correctly
[00:42] <strk> is there something I can do to help tracking it ?
[00:42] <lifeless> uhm
[00:42] <lifeless> for now
[00:42] <lifeless> if when you merge
[00:42] <lifeless> bzr st shows nothing other than pending merges
[00:42] <lifeless> just revert
[00:43] <strk> I'm afraid I failed in that when merged trunk into mybranch
[00:43] <strk> how can I check that ?
[00:43] <strk> like, how can I get bzr log tell me exactly which files were changed, if any ?
[00:43] <spiv> bzr log -v
[00:44] <strk> ouch
[00:44] <strk> looks terribly wrong
[00:45] <strk> http://rafb.net/p/yWqEyF12.html <-- bzr log -v -l 10 (from mybranch-bound working tree)
[00:45] <lifeless> spiv: this is gnash btw
[00:45] <lifeless> spiv: who have just migrated
[00:45] <strk> shouldn't the indented entries under revno: 9430 show "composition" of that commit ?
[00:45] <strk> (first rev)
[00:46] <spiv> lifeless: ah, nice
[00:46] <lifeless> back soon; bacon and eggs are calling
[00:46] <strk> it seems that was my first backward merge
[00:47] <strk> so far I've always merged mybranch *into* trunk
[00:47] <strk> but for the first time, to commit something to trunk w/out reverting or committing my changes ... I did the commit from another working tree
[00:47] <mwhudson> beuno: are you around?
[00:48] <strk> then I tought I had to merge trunk to mybranch, and the log above shows what happened
[00:48] <spiv> strk: I'm not sure what you mean by "composition"
[00:49] <strk> spiv: I'm still trying to understand 'bzr log' output
[00:49] <strk> my current interpretation is based on 'bzr log' output from trunk, which seems clearer
[00:50] <strk> by "composition" I mean a kind of commit trackback history
[00:50] <strk> for example
[00:50] <strk> http://rafb.net/p/oatno492.html <-- thise is bzr log for trunk
[00:50] <spiv> Right, so r9430 merged in trunk (which had 4 revisions you didn't have, which are shown indented).  The only text changed by the merge was .bzrignore
[00:51] <strk> hold on
[00:51] <strk> r9430 merged in mybranch
[00:51] <strk> *from* trunk
[00:51] <spiv> strk: you might find a graphical layout helpful, e.g. "bzr viz" if you have the bzr-gtk plugin installed.
[00:52] <strk> I'll get it immediately
[00:52] <spiv> In http://rafb.net/p/yWqEyF12.html it shows r9430 in mybranch is a merge from trunk
[00:52] <spiv> Note that the revnos in different branches can and do point to different revisions.
[00:52] <strk> right, r9430 is a merge from trunk to mybranch
[00:53] <strk> r9430 in mybranch, that is
[00:53]  * strk looking at 'viz' now
[00:54] <strk> mm... timestamps are all bogus (ok, let's forget about that now)
[00:54] <strk> ok, the graph from 9425 on is pretty spaghetti :)
[00:55] <spiv> Yeah, I thought it would be :)
[00:55] <strk> lemme see if the viz for trunk makes more sense
[00:56] <strk> :'(
[00:56] <strk> less spaghetti, but still unclear
[00:56] <spiv> So the first paste shows r9430 (of mybranch) merged in trunk, and at that time trunk had four revisions mybranch didn't.  Most of *those* revisions were merges from mybranch.
[00:56] <spiv> So, I'm not sure what specifically isn't clear to you atm.
[00:57] <strk> ok
[00:57] <strk> the point is, the four revisions mybranch had all
[00:57] <strk> see 9429
[00:57] <strk> r9429 of mybranch
[00:57] <spiv> mybranch's r9430 merged in the changes in trunk which were a) some merges from mybranch (and thus no changes vs. mybranch), and b) a change to .bzrignore
[00:58] <strk> "Fix missing libgnashplugin.so glib link...."
[00:58] <spiv> So I see it.
[00:58] <strk> ok, my point is that (a) is confusing
[00:58] <strk> what does it mean to merge changes that were merges from here ?
[00:59] <spiv> Ah.
[00:59] <strk> the missing libgnashplugin.so thing
[00:59] <strk> was committed in mybranch
[00:59] <spiv> Look at the bzr viz for mybranch again.
[00:59] <strk> yes, I'm looking at it now
[00:59] <spiv> And/Oo try "bzr log --show-ids"
[00:59] <spiv> "And/or", rather
[00:59] <strk> there I see that mybranch r9429 was...
[00:59] <strk> ok, restarting with --show-ids
[00:59] <spiv> The history of a branch is a DAG
[01:00] <strk> bzr: ERROR: no such option: --show-ids
[01:00] <spiv> strk: bzr log --show-ids?
[01:01] <strk> http://rafb.net/p/3IJBae18.html (--limit 120
[01:01] <spiv> (you can already see the ids in bzr viz by clicking on a revision and looking at the information below the graph)
[01:02] <spiv> A regular commit makes a branch with just one parent.
[01:02] <spiv> (so just one "parent:" line in the log --show-ids output, and just one downwards line in the bzr viz diagram)
[01:02] <spiv> A merge adds another parent.
[01:04] <spiv> So when you commit a merge, you're not just recording what files were changed by the merge, but exactly which revision was merged onto another.
[01:05] <strk> mm
[01:05] <spiv> This is what lets bzr automatically figure out which revisions to process when you do "bzr merge".
[01:05] <strk> do you have viz window in front of you too ?
[01:05] <strk> ops, I guess you ca'nt wout access to mybranch ?
[01:05] <spiv> e.g. if you get conflicts, and resolve them, then that resolution is recorded.
[01:05] <spiv> strk: right
[01:06] <strk> I have a r9425.1.1 (branch nick:trunk)
[01:06] <spiv> I see that in your first paste, yep.
[01:06] <strk> which was supposedly (I tought it was) the merge of a sum of 3 commits I made in mybranch
[01:06] <strk> specifically, r9426,r9427 and r9428
[01:07] <spiv> It was.
[01:07] <strk> the 'giz' graph shows r9425.1.1 in trunk having 2 parents
[01:07] <strk> or, two lines ...
[01:07] <spiv> Right 2 parents.
[01:07] <strk> one is r9428 and the other is r9425
[01:07] <spiv> Hmm, make sure you turn off View->Show Compact Graph in bzr viz.
[01:07] <spiv> (not sure if that's on by default)
[01:08] <strk> is off
[01:08] <spiv> If you compare the graph of those two parent revisions, you'll see that there are three revisions in mybranch that aren't in trunk.
[01:09] <strk> uh ?
[01:10] <spiv> In fact, try this: "bzr viz -r 9426" in trunk.  the top revision will be that merge.
[01:12] <spiv> And what you should see will look like this: http://rafb.net/p/1KTfVR17.html
[01:12] <strk> yes
[01:13] <spiv> i.e. two lines going down out of that revision, that's two parents.
[01:13] <strk> trilling
[01:13] <spiv> But three revisions along the right-hand line that aren't on the trunk (which is always on the left-most side in bzr viz, just like log)
[01:14] <strk> is the graph info all trunk has about those 3 revisions ?
[01:15] <spiv> It has the full contents of those revisions in its repo.
[01:15] <strk> k
[01:15] <spiv> e.g. in bzr viz you can double click on any one of them and get the full diff.
[01:16] <strk> great!
[01:16] <strk> so, back to mybranch viz
[01:16] <strk> r9430 in mybranch brought in .bzrignore changes only
[01:17] <strk> which was r9425.1.4 in trunk
[01:17] <strk> what I don't understand is the graph I guess
[01:17] <spiv> Well, the only changes in trunk that weren't already in your branch were the .bzrignore changes.
[01:17] <strk> in that it *seems* to have brought in also r9425.1.3,1.2,1.1
[01:18] <spiv> Right, those are new revisions, but those revisions don't have any text changes that mybranch didn't already have -- because those revisions were merges from mybranch.
[01:18] <strk> oh, maybe r9425.1.2 AND r9425.1.4 did actually get in
[01:19] <strk> the other two didn't because they had revisions in branch as parents
[01:19] <strk> namely, r9425.1.3 (trunk) came from r9429 (branch)
[01:19] <spiv> Right, .1.1 and 1.3 were merges from mybranch.
[01:19] <strk> and r9425.1.1 (trunk) came from r9428 (mybranch)
[01:21] <spiv> All good now? :)
[01:21] <strk> not yet :)
[01:21] <strk> if I now merge mybranch into trunk
[01:21] <strk> there's somehting unclear
[01:22] <strk> status gives pending merges:   Sandro Santilli 2008-06-25 trunk merge ?
[01:22] <strk> but no changes
[01:22] <spiv> Right.
[01:22] <lifeless> this is a case we should actually detect and cancel a merge on
[01:22] <spiv> That's because there's a new revision, but for this branch that revision has no new changes to merge.
[01:22] <spiv> lifeless: +1
[01:22] <lifeless> with --force allowing it to be done anyhow
[01:23] <spiv> lifeless: (probably allow --force to override)
[01:23] <strk> alright, I'll take that as a bug
[01:23] <spiv> lifeless: snap!
[01:24] <strk> another thing. 'viz' shows me info about things I tought I reverted
[01:24] <strk> r9422.1.2 in mybranch
[01:24] <strk> shown in 'viz' for trunk
[01:26] <strk> shown in cyan color
[01:28] <strk> never mind, too late to think ... 2:30 am
[01:28] <strk> thanks a lot for your time
[01:35] <mdmkolbe|work> I have a repository in my home directory at the departmental machines, how do I check out from my home machine?  (e.g. like svn's svn+ssh://host/path)
[01:41] <mdmkolbe> I have a repository in my home directory at the departmental machines, how do I check out from my home machine?  (e.g. like svn's svn+ssh://host/path)
[01:41] <lifeless> mdmkolbe: bzr co bzr+ssh://host/path
[01:42] <mdmkolbe> cool, thx
[02:03]  * mwhudson adds 'logging' to the pile of things loggerhead does appallingly
[02:04] <lifeless> :P
[02:05] <mwhudson> lifeless: did you see https://bugs.edge.launchpad.net/loggerhead/+bug/242806 ?
[02:05] <Peng> Heh.
[02:06] <lifeless> mwhudson: rotfl
[02:08] <mwhudson> in better news, i can run 'ab -n 10 -c 5 'http://localhost:8080/revision/158' on ubuntu-desktop-course-beta (which is a laaarge revision page) and have the loggerhead process use 300 megs at the end
[02:09] <jml> lifeless: is there a way to view a log of all commits made to a thread?
[02:09] <mwhudson> whereas with kid, just rendering that page once got the oom killer into action
[02:10] <lifeless> jml: 'bzr log'
[02:10] <lifeless> mwhudson: excellent
[02:10] <jml> lifeless: that shows messages from before the thread was created
[02:10] <mwhudson> that page is still a DoS on the user's browser of course
[02:11] <lifeless> jml: bzr log -r thread:..
[02:11] <jml> lifeless: that shows messages from the last merge from the lower thread.
[02:12] <lifeless> jml: how about this; rather than me guessing what exactly you mean, you pastebin something, and say 'I want X Y and Z from there, and nothing else'
[02:14] <jml> lifeless: ok. probably later though.
[02:18] <lifeless> k
[02:27] <Peng> Quick!
[03:07] <lifeless> jam: still around ?
[03:07] <jam> lifeless: current waiting for leo to die (WW), but somewhat around :)
[03:08] <lifeless> jam: I'm onto annotate
[03:08] <lifeless> and I'm at a complete loss as to what to do
[03:10] <jam> oops.. :)
[03:10] <jam> the code you care about is in knit.py
[03:11] <jam> if you want to do the simple thing
[03:11] <jam> just feed the fulltexts into annotate.reannotate()
[03:13] <lifeless> I'm hesitant to touch it because I know its been performance tuned
[03:14] <lifeless> and I have no benchmarks or other things to check I don't break it entirely
[03:45]  * igc lunch
[04:12]  * lifeless goes looking for jml's test for stacking on remote repos
[04:16] <jam> lifeless: I was planning on letting you make it slow, in exchange for having it *work* :)
[04:27] <lifeless> jam: :). Its on my list; I'm getting the stacking repo stuff polished first
[04:27] <lifeless> as annotate is not as strict a blocker
[04:28] <jam> sure, I would have thought some tests would fail, but there may not be a lot of per-xxx annotate tests
[04:30] <lifeless> well
[04:30] <lifeless> none that know to setup a basis repository, do a shallow branch precisely cross history lines and then annotate
[04:30] <lifeless> there is one XFAIL, that I wrote :P
[05:00] <lifeless> Jc2k: is loggerhead up on bzr-mirror yet ?
[05:03] <mwhudson> seems to still be on 9876
[05:20] <lifeless> yay:
[05:20] <lifeless> :!bzr commit -m "Implement generic stacking rather than pack-internals based stacking."
[05:22] <lifeless> jml: ping
[05:23] <jml> lifeless: pong.
[05:23] <lifeless> do you remember where you put the patch that tests stacking on bzr+ssh ?
[05:24] <lifeless> like was it mail, a bug, or ?
[05:24] <jml> lifeless: I grepped around in my sent mail and couldn't find it.
[05:25] <jml> lifeless: I might have it on disk in a branch.
[05:26] <jml> lifeless: once I finish this review I'll look again.
[05:31] <poolie> lifeless: yay, way to go
[05:32] <poolie> beuno, if you're still up, that demo site is *amazing*
[05:32] <lifeless> and on the 7th day
[05:32] <poolie> well done
[05:32] <lifeless> poolie: the bzr-search one ?
[05:34] <lifeless> beuno: also, the download link, for a dir, could output a tarball :)
[05:35] <lifeless> jml: march 5 I found an email that describes the problem
[05:35] <jml> lifeless: yes, I found that.
[05:39] <lifeless> thumper: there are branches being created in the web ui for the bzr project that appear to be pure noise
[05:40] <thumper> lifeless: unfortunately that happens, a question on launchpad-bazaar is one way if you get no response form the owner, editing the whiteboard to tell the branch owner that it isn't appreciated is another
[05:41] <lifeless> thumper: putting aside my preference for not having that feature; I would be happy if branches that 'have never been pushed too' didn't show up on https://code.edge.launchpad.net/bzr
[05:41] <jml> lifeless: so, I think the tests are uncommitted changes in a working tree :\
[05:41] <lifeless> jml: ><
[05:42] <lifeless> pastebinned ?
[05:42] <jml> lifeless: I'll do so now.
[05:42] <jml> http://paste.ubuntu.com/22781/
[05:43] <jml> lifeless: I seem to remember you narrowing the test down on your laptop.
[05:44] <jml> lifeless: but the memory is not trustworthy.
[05:44] <lifeless> I loath the ui of paste.ubuntu.com
[05:45] <lifeless> argh
[05:46] <lifeless> :!bzr patch http://paste.ubuntu.com/22781/plain/
[05:46] <lifeless> bzr: ERROR: http://paste.ubuntu.com/22781/plain is permanently redirected to http://paste.ubuntu.com/22781/plain/
[05:46] <lifeless> abentley: where do you want bzrtools bugs?
[05:47] <abentley> lifeless: bugs.launchpad.net/bzrtools
[05:48] <lifeless> abentley: thanks
[05:53] <lifeless> jml: bingo:
[05:53] <lifeless> jml:  02: bzr: support (but failing, RemoteRepository is not a PackRepository)
[05:54] <jml> lifeless: is this in a local branch of yours?
[05:54] <spiv> lifeless: pqm seems to be confused; it processes a request, the log in the web ui shows it succeeded, but no change happens to bzr.dev and I get no email.
[05:54] <lifeless> its shelved
[05:54] <lifeless> spiv: gpg key expired
[05:54] <lifeless> hangon
[05:55] <spiv> lifeless: ah.  Thanks.
[05:57] <lifeless> spiv: resubmit
[05:57]  * spiv presses the magic button
[06:03] <lifeless> jml: and it passes!
[06:03] <jml> gsap
[06:04] <lifeless> which means, we're gtg
[06:04] <jml> sweet.
[06:04] <jml> that makes the stuff I'm working on now all that more pressing.
[06:05] <lifeless> poolie: you gotta relax a bit more :P
[06:05]  * jml makes another coffee and dives to hacking level
[06:05] <lifeless> jml: pushing an updated loom
[06:05] <poolie> lifeless: uh?
[06:05] <lifeless> poolie: you were stressing about stacking this morning
[06:06] <jml> lifeless: cool. I won't be looking at your branch today unless I am suddenly endowed with the nine rods of eternity.
[06:07] <lifeless> nein rohds huh
[06:08] <poolie> lifeless: oh ok
[06:09] <poolie> that's an interesting comment but remind me of it over that beer sometime
[06:09] <lifeless> ok
[06:09] <lifeless> I was intending to tease was all
[06:09] <lifeless> anyhow, I'm about to send in a final review request for Development1
[06:09] <jml> lifeless: yeah
[06:10] <lifeless> I'm now, finally, completely happy to land it
[06:10] <jml> lifeless: of course, if that happens I may have more pressing concerns than fast distributed version control.
[06:10] <lifeless> then I'm going to drink some caffiene, and look at making annotate stack correctly
[06:24] <mwhudson> if you want to stream out a file's contents is some version of iter_file_bytes() your best bet?
[06:25] <mwhudson> or is get_file_lines() likely to work well too?
[06:25] <beuno> poolie, thanks  :)
[06:26] <mwhudson> hi beuno
[06:26] <beuno> hey mwhudson
[06:26] <mwhudson> beuno: did you see https://code.edge.launchpad.net/~mwhudson/loggerhead/streaming ?
[06:27] <beuno> lifeless, downloading tarballs is on the bug list :)
[06:27] <beuno> mwhudson, I haven't. Let's take a peak
[06:29] <beuno> mwhudson, oh, cool!  That will make big diffs and annotates seem more responsive  :)
[06:30] <mwhudson> yeah, and it keeps memory usage under control a bit more too
[06:30] <mwhudson> e.g. it can render my 24 meg horror test case revision page with ~70 megs resident
[06:30] <mwhudson> it's a bit slower on that page though
[06:32] <beuno> mwhudson, looks very good. We should do some benchmarking before release to compare the improvements, but it sounds like it's going to be a pretty big leap
[06:33] <beuno> also, our dependencies are down to python-paste and python-simpletal. How cool is that?
[06:35] <mwhudson> yeah, i'm pretty happy about that
[06:35] <mwhudson> though really, the streaming is a hack in some ways, we simply shouldn't be generating 24 meg pages
[06:36] <mwhudson> ah, cool
[06:36] <mwhudson> so it turns out a little bit of buffering is a good thing :)
[06:37] <beuno> no, we shouldn't. I'd like to experiment a bit on not using templates to generate the diff text and annotate content when we're past 1.6
[06:37] <beuno> should be a lot faster and a lot smaller
[06:37] <mwhudson> beuno: <blink>+1</blink>
[06:38] <poolie> :)
[06:38] <beuno> but that can only be done with the new HTML. I'm scared of the current one
[06:38] <mwhudson> sure
[06:38] <mwhudson> and we should really be focusing on getting to a releasable state i think now
[06:38] <mwhudson> there's so many improvements in trunk...
[06:39] <beuno> yeah, next on my list is do something sensible with setup.py
[06:39] <beuno> and, well, get the new theme landed  :)
[06:39] <ferringb> beuno: refering to loggherhead from above, or...
[06:39] <mwhudson> beuno: so with a little bit of buffering to send ~1k at a time to the browser (rather than ~10 bytes) my torture test completes in 28 seconds
[06:40] <mwhudson> vs. ~40 on trunk
[06:40] <beuno> mwhudson, 12 seconds is a *really* big improvement
[06:41] <mwhudson> yeah, i'm amazed, tbh
[06:41] <beuno> ferringb, I'm sorry?
[06:41] <beuno> mwhudson, does it pass the tests?  :p
[06:41] <ferringb> beuno: "mwhudson, looks very good. We should do some benchmarking before release to compare the improvements, but it sounds like it's going to be a pretty big" ...
[06:42] <mwhudson> beuno: yes :)
[06:42] <ferringb> asking if that's in reference to loggerhead (presume it) or something else
[06:42] <beuno> ferringb, yes, Loggerhead
[06:42] <mwhudson> at one point it was only transmitting ~1% of the data to the client but that was a simple typo :)
[06:42] <beuno> hahaha
[06:43] <beuno> are we still removing whitespaces?
[06:43] <mwhudson> i feel a bit sad at having to write this though: http://pastebin.ubuntu.com/22785/
[06:43] <mwhudson> beuno: er
[06:43] <mwhudson> beuno: probably not
[06:44] <beuno> mwhudson, well, that gave us big savings on large files, but I'm not sure what the memory/cpu tradeoff was for that
[06:45] <mwhudson> hm, i can probably do it on the 1k chunks reasonably
[06:45] <krow> Quick question... what is the command with bzr to remove all files from a directory which are not in source control?
[06:46] <ferringb> bzr clean-tree
[06:46] <spiv> bzr clean-tree
[06:46] <spiv> ferringb: beat me :)
[06:47] <krow> [brian@piggy drizzle-1.0]$ bzr clean-tree
[06:47] <krow> bzr: ERROR: unknown command "clean-tree"
[06:47] <krow> No wonder I did not find it in the help drop down :)
[06:48] <ferringb> part of bzrtools then
[06:48] <poolie> is it in bzrtools?
[06:48] <poolie> you should be able to apt-get install that, or follow the instructions on the plugin page
[06:48] <poolie> depending on your system
[06:49] <krow> Fedora, so no apt-get.
[06:50] <poolie> i think it is packaged
[06:50] <krow> There is a python tool for grabbing the latest bzr right? I can never remember what it is.
[06:50] <mwhudson> beuno: seems to still be worth it
[06:51] <poolie> i think that's ezsetup?
[06:51] <lifeless> yum on fedora
[06:51] <lifeless> or apt-get if you install it
[06:51] <beuno> mwhudson, does it shave off a few more seconds?
[06:52] <krow> Nah... there is some python tool... I always forget its name... anyways. Thank for the help :)
[06:52] <mwhudson> no, it takes a little longer
[06:52] <mwhudson> but makes the page 30% or so smaller for my torture test
[06:53] <mwhudson> more like 40%
[06:53] <beuno> yeah, worth it on 24mb pages  :)
[06:53] <mwhudson> right
[06:58] <lifeless> hi beuno
[06:59] <beuno> evening lifeless
[06:59] <poolie> krow: probably the easiest thing is
[07:00] <poolie> mkdir -p ~/.bazaar/plugins && bzr branch lp:bzrtools ~/.bazaar/plugins/bzrtools
[07:01] <beuno> mwhudson, I get 53sec vs 41sec for my big diff in trunk vs streaming. And, more importantly, browsing seems much further
[07:01] <mwhudson> i haven't dared load up my big one in firefox :)
[07:01] <mwhudson> but cool
[07:02] <mwhudson> i mean, still ridiculously, insanely long to wait for a web page
[07:02] <mwhudson> but progress is progress
[07:03] <beuno> yeah, it comes up fairly quickly with streaming now, so, if we compare against 1.2, this is light years better
[07:04] <mwhudson> oh man
[07:04] <mwhudson> with 1.2 your machine would have fallen over :)
[07:05] <jamesh> 41 seconds for a web page wasn't so bad 10 years ago
[07:05] <beuno> ahahah, that can be our tagline for 1.6  :p
[07:06] <mwhudson> :)
[07:08] <mwhudson> beuno: ok, https://code.edge.launchpad.net/~mwhudson/loggerhead/streaming is at revno 182 now
[07:09] <mwhudson> beuno: can you read through the diff and let me know what you think?
[07:09] <beuno> mwhudson, yeap, pulling now
[07:10] <mwhudson> i guess things will be messy if an error occurs mid-page render
[07:10] <mwhudson> not much we can do about that though
[07:11] <beuno> not really. And that is probably better than nothing at all
[07:15] <beuno> mwhudson, diff looks good. Stripping whitespace on flush seems like a much better thing to do
[07:16] <mwhudson> ok to merge?
[07:17] <beuno> absolutely
[07:17] <mwhudson> beuno: i see you found the logging bug -- that's a real laugh/cry dilemma
[07:17] <beuno> mwhudson, hehe, yeah. Poor guy really thought it rotated
[07:18] <marianom> sorry to bother everyone, just gonna say hi to beuno :)
[07:18] <beuno> hey marianom!  What are you doing up?
[07:18] <marianom> I bet you know! :)
[07:19] <beuno> marianom, :)  let me know if I can help
[07:19] <marianom> on my way to sleep now. see you tomorrow, beuno (everything's ok btw) good night everyone and keep the good bzr rocking!
[07:21]  * mwhudson merges & pushes
[07:21] <mwhudson> ... and stops
[07:22] <beuno> mwhudson, sounds good
[07:22] <beuno> btw, did you roll out on LP today?
[07:22] <beuno> LH on LP is getting worse by the minute. I'm not sure what's been going on
[07:22] <mwhudson> beuno: erm, tricky question to answer :)
[07:23] <beuno> ah, is it better at least?
[07:24] <mwhudson> we should rollout a new loggerhead tomorrow with good luck and a following wind
[07:25] <beuno> that would be with tg + simpletal I assume?
[07:25] <mwhudson> there will probably be a general launchpad rollout early next week
[07:25] <mwhudson> edge has been back and forth repeatedly :)
[07:25] <mwhudson> beuno: nope, paste
[07:25] <beuno> yeah, storm issues I hear
[07:26] <beuno> mwhudson, oh, very cool. Se that will be a good way to iron out any remaining peformance issues  :)   (good for us, don't know about users)
[07:27] <mwhudson> yeah, i wonder about trying to wedge this latest branch in
[07:27] <mwhudson> anyway, emma is back from work so really stoppoing now
[07:27] <beuno> cya tomorrow mwhudson
[07:29] <Jc2k> lo
[07:30] <lifeless> i
[07:30] <lifeless> hi
[07:30] <beuno> mornin' Jc2k
[07:30]  * Jc2k yawns
[07:48] <Jc2k> beuno: i have a feature request :)
[07:49] <Jc2k> beuno: show the author in loggerhead somehow
[07:49] <beuno> Jc2k, where specifically?
[07:50] <Jc2k> this i'm not sure of :)
[07:50] <Jc2k> i just want to blog about bzr-svn storing the author property, and loggerhead seems like the right thing to show it off
[07:51] <beuno> Jc2k, LH already shows whatever you specify in --author
[07:51] <Jc2k> where abouts :O
[07:55]  * Jc2k to work
[07:55] <beuno> Jc2k, it shows that instead of the committer
[07:55] <Peng> Is LH supposed to use any old-style classes?
[07:55] <beuno> in changelog/revisioview/annotate
[07:56] <Jc2k> beuno: then bzr-svn must have failed..
[07:56] <beuno> Peng, not any new ones, no  :)
[07:56] <beuno> Jc2k, it's fairly new in trunk, do you have the lastest and greatest?
[07:57] <Peng> beuno: Well, it has 4, and loggerhead/controllers/__init__.py's BufferingWriter is new.
[07:57] <beuno> Jc2k, http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/changes
[07:57] <beuno> revno 170
[07:58] <Peng> Hmm, thanks to the whitespace stripping, /changes went from 82 KB to 63, and gzipped it went from like 4.65 to 4.3.
[08:00] <beuno> Peng, can you file a bug and/or provide a patch for that?  :)
[08:00] <beuno> (old-style classes)
[08:00] <Peng> beuno: All of them or just the most recent one?
[08:02] <beuno> Peng, all of them. We do want to start cleaning up our code base
[08:04] <lifeless> ok, annotate across stacking boundaries working
[08:05] <Peng> Crapcrapcrapcrap
[08:06] <Peng> (Entirely OT, but I just accidentally ran a blanket "commit" instead of one file")
[08:06] <jml> bzr uncommit?
[08:06] <Peng> It was with hg, actually.
[08:07] <Peng> And I pounded ctrl+c and I think I broke my repo a little.
[08:07] <lifeless> heh
[08:07] <lifeless> ctrl-c isn't safe?
[08:09] <Peng> beuno: http://bzr.mattnordhoff.com/bzr/loggerhead/trivial/new-style-classes
[08:09] <Peng> lifeless: I think it was.
[08:10] <beuno> Peng, you rock!  thanks  :)
[08:11] <lifeless> Peng: it was safe, or it was not safe?
[08:12] <Peng> lifeless: If you don't know, when you hg commit, it commits to the live repo. When you hit Ctrl+C, it aborts the transaction and truncates the file changes. But I hit Ctrl+C a bunch of times, and got some "failed to truncate file" messages. But it exited successfully, so hopefully it tried again.
[08:14] <Peng> BTW, ack rocks. "ack-grep --python 'class [^(]+:'" :)
[08:15] <lifeless> ack?
[08:16] <Peng> lifeless: It's like grep, only in Perl, and with colors. http://petdance.com/ack/
[08:16] <lifeless> ah
[08:17] <lifeless> apt-cache show ack-grep helped me :)
[08:17] <Peng> (Eh, seems grep has colors too.)
[08:17] <Peng> lifeless: Heh, right.
[08:18] <Peng> I tried it out just for fun. The "--python" thing is fun. (There are arguments for other languages too.) It's a lot shorter than "find . -name '*.py'".
[08:19] <lifeless> Peng: bzr search class :P
[08:19] <Peng> Heh.
[08:20] <Peng> Another nice thing is that it ignores things like *~ files and .bzr and .svn by default.
[08:25] <spiv> Peng: "grep -Irn foo *" is pretty close :P
[08:25]  * spiv -> yoga
[08:26] <poolie> lifeless: ready, call me?
[08:29] <lifeless> poolie: it rang out
[08:30] <poolie> huh
[08:30] <lifeless> twice now
[08:39] <visik7> I've some problem with the new bzr-svn
[08:40] <Peng> go on
[08:40] <visik7> I got this error: http://dpaste.com/58999/
[08:41] <visik7> with an active bzr-svn branch (branched with an older version of bzr-svn)
[08:51] <lifeless> Jc2k: ping
[08:52] <lifeless> Peng: I feel your pain re: data corruption
[08:52] <lifeless> Peng: is it your mozilla config branch?
[08:55] <Peng> lifeless: Homedir.
[08:55] <Peng> lifeless: The branch has already probably had some sort of corruption for months. I think this really may have made it worse though.
[08:55] <lifeless> Peng: time to try bzr again ? :P
[08:56] <Peng> Perhaps.
[08:56] <Peng> I've been liking "hg commit -X" though.
[08:56] <lifeless> -X?
[08:56] <lifeless> oh, auto-everything ?
[08:57] <Peng> exclude
[08:57]  * igc dinner
[08:57] <Peng> There's one file I do version, but it changes frequently and I don't need to record each one.
[08:57] <Peng> Anyway, like I said in #mercurial, I was gonna go to sleep too. Bad things always happen when I'm about to go to sleep. :(
[08:58] <lifeless> Peng: we should have exclude for diff and commit et al
[09:02]  * Peng goes to bed.
[09:02] <Peng> Good night, lifeless.
[09:03] <lifeless> night Peng :)
[09:07] <visik7> I got that issue on all my svn-bzr branches
[09:12] <visik7> ok it's officially dead even with a clean branch
[09:12] <visik7> svn-bzr doesn't work here anymore
[09:13] <visik7> for example:  bzr checkout http://google-gadgets-for-linux.googlecode.com/svn/trunk/ gg4l
[09:13] <lifeless> jelmer: ^
[09:17] <visik7> it doesn't recognize anymore svn branches
[09:40] <lifeless> mwhudson: why do you use sqlite2 rather than 3?
[09:49] <garyvdm> Hi. I'm having a problem pushing to a ftp site.
[09:50] <garyvdm> I'm getting this error:
[09:50] <garyvdm> bzr: ERROR: File exists: '/.bzr': 550 /.bzr: Access is denied.
[09:50] <jelmer> visik7: that works fine here
[09:51] <jelmer> visik7: when did it break?
[09:51] <garyvdm> I've checked the .bzr does not exist. So it seems that bzr is interperating the ftp incorrectly
[09:52] <lifeless> garyvdm: what path are you giving bzr? that leading / suggests its trying to mkdir at the root
[09:52] <garyvdm> What is the best way to try and fix this?
[09:52] <gour> eMBee: hi, any luck with bzr-gtk ?
[09:53] <garyvdm> lifeless: yes - Command used:
[09:53] <garyvdm> C:\Inetpub\wwwroot>bzr push ftp://usr:pass@www.squarepegs.co.za/ --use-existing-dir
[09:53] <lifeless> garyvdm: so, I suspect you actually want something like ftp://usr:pass@www.squarepegs.co.za/home/garyvdm/public_html/xxx
[09:54] <garyvdm> I want to put the branch in the root, but I guess I can put it in a sub folder.
[09:54] <garyvdm> Let me try that.
[09:55] <lifeless> garyvdm: the root may not be what you think it is
[09:56] <lifeless> if you ftp to www.squarepegs.co.za, and do ls / - does it show you your files, or something like 'usr', 'bin', 'lib' etc
[09:56] <garyvdm> I did check that. The root is the root of the website.
[09:57] <lifeless> garyvdm: ok, then its likely that the ftpserver has a policy stopping you making .bzr
[09:57] <visik7> jelmer: today
[09:57] <jelmer> visik7: still there?
[09:57] <lifeless> garyvdm: try pushing to /test
[09:57] <visik7> yes, today
[09:57] <garyvdm> Ok
[09:57] <lifeless> garyvdm: if that works, ftp in and mv test/.bzr .bzr
[09:57] <visik7> jelmer: on revno: 1345
[09:57] <jelmer> visik7: bzr-svn shows up in "bzr plugins" ?
[09:58] <visik7> yes
[09:58] <jelmer> visik7: have you built it?
[09:58] <visik7> yes
[09:58] <jelmer> what happens if you prefix the http url with "svn+" ?
[09:58] <jelmer> e.g svn+http://google-gadgets-for-linux.googlecode.com/svn/trunk/
[09:59] <visik7> same problem
[09:59] <visik7>  ERROR: Not a branch: "svn+http://google-gadgets-for-linux.googlecode.com/svn/trunk
[09:59] <jelmer> anything in ~/.bzr.lo g?
[09:59] <jelmer> anything in ~/.bzr.log ?
[10:00] <visik7> yes I'll dpaste it
[10:01] <visik7> http://dpaste.com/59005/
[10:03] <mwhudson> lifeless: it's what was installed on vostok at the time i think
[10:03] <jelmer> visik7: hmm, it should be impossible to get into that situation
[10:04] <jelmer> train leaves
[10:04] <jelmer> bye
[10:04] <visik7> jelmer: I'm a lucky  man :)
[10:06] <lifeless> mwhudson: I've already given you a patch to upgrade :)
[10:06] <lifeless> 3 is faster
[10:07] <visik7> jelmer: so am I tfu ?
[10:08] <garyvdm> lifeless: I tried that. Unfortunatly it did not work.
[10:09] <garyvdm> http://pastebin.com/m7f8c0cf9
[10:09] <garyvdm> From the pastebin you can see, I did a ls to check that /test does not work
[10:09] <garyvdm> Then I tried to push to /test, and it say /test exists
[10:10] <garyvdm> Then I tried to put to /test --use-existing-dir - and it says /test does not exits.
[10:10] <garyvdm> Huh?
[10:11] <garyvdm> Ok  - time to download wireshark.
[10:11] <lifeless> oh, microsoft ftp server again
[10:11] <lifeless> garh
[10:12] <lifeless> garyvdm: can you try:
[10:12] <lifeless> "ls /"
[10:12] <lifeless> just for my peace of mind
[10:12] <garyvdm> ok
[10:13] <garyvdm> Ah - ls / gives me a compleatly different list...
[10:14] <lifeless> I thought it might
[10:14] <lifeless> do 'pwd'
[10:14] <garyvdm> "/ftptrudi" is current directory.
[10:14] <garyvdm> ok push to /ftptrudi
[10:14] <lifeless> yes
[10:16] <garyvdm> It's working now. Thanks lifeless.
[10:17] <lifeless> np
[10:34] <beuno> lifeless, bug #242035 fixed. Half a bug to go  :)
[10:34] <ubott2> Launchpad bug 242035 in loggerhead "[search] Javascript for searching isn't included in every page" [Medium,Fix released] https://launchpad.net/bugs/242035
[10:35] <beuno> (that would be half of #242034)
[10:36] <beuno> Jc2k, I didn't quite understand where we stand on the --author bit.  Are you using past revision 170?
[10:37] <lifeless> beuno: cool
[10:40] <poolie> vila, are you here by any chance?
[10:41] <Jc2k> beuno: i have r 262 of the branch for loggerhead + bzr search
[10:41] <lifeless> Jc2k: 'bzr search author'
[10:42] <Jc2k> eh
[10:42] <lifeless> Jc2k: it will give you an answer quickly :P
[10:42] <beuno> Jc2k, ah, so you're using search. Let me integrate the latest changes into it, and I'll push that
[10:44] <beuno> Jc2k, pushed revno 267
[10:44] <beuno> has many improvements
[10:44] <Jc2k> cool
[10:44] <beuno> speed amongst one of them  (from mwhudson's streaming work)
[10:44] <Jc2k> whats the URL again? parent isnt set
[10:44] <beuno> should show authors and such
[10:45] <lifeless> lp:~bueno/loggerhead/bzr-search_integration
[10:45] <beuno> Jc2k, not that I'm hurt or anything, but you haven't added the gnome theme on it...  :p
[10:45] <beuno> I can provide a branch with trunk + search + gnome theme, if that's what you've been waiting for
[10:46] <Jc2k> that would make be a very happy GNOME beuno
[10:46] <poolie> lifeless: vf bounced due to conflicts, i'm updating them
[10:46] <lifeless> poolie: trivial stuff?
[10:46] <lifeless> Jc2k: so, bugs for gnome
[10:46] <lifeless> Jc2k: I'll file them I guess as you are busy with new job :)
[10:47] <Jc2k> eh, awesome. cheers.
[10:47] <lifeless> Jc2k: but the list - rebase -i; an in-place-branches mode; anything else ?
[10:47] <poolie> basically just conflicts on the get_data_stream stuff
[10:47] <Jc2k> crap, i thought of one in bed
[10:47] <beuno> Jc2k, I'll push that in a minute for ya'
[10:47] <lifeless> Jc2k: thats the idea, to capture them
[10:48] <lifeless> bug 242661
[10:48] <ubott2> Launchpad bug 242661 in bzr "Cherrypick without merge needed" [Undecided,New] https://launchpad.net/bugs/242661
[10:48] <lifeless> that guy is having a conversation with himself
[10:48] <Jc2k> lifeless: the stuff that bkor filed, and cleaern urls
[10:48] <Jc2k> cleaner
[10:48] <lifeless> needs some response / love :)
[10:48] <lifeless> bkor: loggerhead changes are all in progress I think; I'm worried about CLI stuff not getting sufficient attention
[10:49] <james_w> lifeless: hi. I've read it a couple of times, but haven't understood it yet. I thought of asking them to have another stab on the mailing list.
[10:49] <lifeless> though loom on its own is a pretty good answer to branch lists
[10:49] <pygi> hi hi
[10:49] <lifeless> if you ignore 'record, up-thread and down-thread', then you get N branches at one spot with switch between them
[10:49] <beuno> Jc2k, lp:~beuno/loggerhead/gnome_theme  should make you happier
[10:51] <Jc2k> that confused me - its changed ports!
[10:51] <Jc2k> beuno: http://bzr-mirror.gnome.org:8080/vcs-mirror/trunk/changes
[10:52] <lifeless> james_w: I want: a bunch of bugs, in lp, tagged gnome, that if we solve will help address the various things gnome would like
[10:52] <lifeless> james_w: both the misguided ones, and the good ones like bkor filed on lh
[10:52] <james_w> lifeless: was that one from a GNOME person?
[10:53] <beuno> Jc2k, right, I think mwhudson set it back to 8080
[10:53] <beuno> javascript/css not being added correctly, that's odd...
[10:53] <Jc2k> yeah..
[10:54] <beuno> Jc2k, you're running this through apache, right?
[10:55] <beuno> /static/* dir isn't being exposed
[10:55] <Jc2k> beuno: nope, mwhudson always told me to just run the serve-branches
[10:55] <beuno> ah, right, 8080, missed that
[10:56] <Jc2k> so i should run it with mod_rewrite [P] foo?
[10:56] <beuno> no, should work out of the box
[10:57] <AfC> I believe the correct term when it comes to mod_rewrite is "voodoo"
[10:57] <beuno> Jc2k, branch works fine here:  http://200.127.6.219:8080/changes
[10:58] <lifeless> Jc2k: was which one ?
[10:58] <Jc2k> lifeless: ?
[10:58] <lifeless> Jc2k: sorry, mt
[10:58] <lifeless> james_w: was which one ?
[10:59] <james_w> lifeless: I was responding to your comment that 242661 needs some love
[10:59] <Jc2k> beuno: i just branched the url you gave and ran the serve branches script
[10:59] <lifeless> james_w: no, I don't think its a gnomer
[10:59] <beuno> ah, it's doing something weird, by serving the static dir from each branch: http://bzr-mirror.gnome.org:8080/epiphany/trunk/static/javascript/collapse.js
[10:59] <beuno> Jc2k, right, it's probably our fault. Let me debug this for a bit...
[11:00] <Jc2k> cheers
[11:00] <poolie> lifeless: i realize you've finished, so rst this question if you wish
[11:00] <poolie> but, you've deleted the get_data_stream_for_search and the Fetcher that calls it
[11:00] <poolie> i'm guessing that should just be carried across in the merge?
[11:01] <poolie> and then eventually a new form of something similar needs to be written?
[11:01] <lifeless> poolie: that was my intent yes
[11:01] <lifeless> poolie: its what I've been saying spiv should be looking into as a priority :P
[11:01] <beuno> Jc2k, can you try branching trunk and see if the same thing happens?  lp:loggerhead
[11:04] <beuno> I can't reproduce the problem locally
[11:04] <poolie> lifeless: yeah i thought so :)
[11:04] <poolie> easy to resolve
[11:04] <Jc2k> beuno: http://bzr-mirror.gnome.org:8080/vcs-mirror/trunk/changes
[11:05] <beuno> Jc2k, ok, so it's something from trunk
[11:05] <Jc2k> are you using the serve-branches.py script? (looks like your using start-logerhead?_
[11:06] <beuno> Jc2k, I'm not: http://200.127.6.219:8080/
[11:06] <beuno> or am  :)  (using serve-branches.py)
[11:06] <Jc2k> lucky git
[11:07] <beuno> I don't understand why it misplaces the /static/ dir...
[11:08] <lifeless> poolie: spiv may be unhappy at the recent optimisations being disabled :P
[11:08] <beuno> Jc2k, this is a linux box it's running??
[11:10] <beuno> python 2.4 or 2.5?
[11:11] <poolie> i'll try to help him get them back
[11:11] <lifeless> beuno: you know you don't need to call load_plugins to load a plugin :)
[11:11] <lifeless> beuno: you can just 'import bzrlib.plugins.search'
[11:11] <lifeless> beuno: load_plugins loads /all/ plugins
[11:11] <beuno> lifeless, I didn't  :)
[11:11] <Jc2k> beuno: debian etch, python 2.4
[11:12] <beuno> Jc2k, it works with 2.4 here too...  :/
[11:12] <beuno> mwhudson, you're not still around and bored, are you/
[11:12] <poolie> ok i'm going to sign off
[11:15] <beuno> lifeless, thanks. Pushed revno 268
[11:15] <beuno> Jc2k, I'm heading to the office, but I'll try and get to it in a while. It shouldn't be placing /static/ dir on each branch's dir
[11:16] <beuno> it has something to do with mwhudson's voodoo to generate that with serve-branches  :)
[11:28] <lifeless> beuno: http://bazaar.launchpad.net/~lifeless/loggerhead/search
[11:47] <thekorn> hi, I'm using the editor feature of bzr commit (running bzr commit opens my editor for me and let me write down my message)
[11:47] <poolie> lifeless: it landed
[11:48] <thekorn> is it possible to predefine a a text for the part above the ---bar---
[11:49] <thekorn> so I have like a default message-body for all my commit-messages
[11:51] <james_w> hi thekorn
[11:52] <thekorn> hi james_w!
[11:52] <james_w> it's possible in bzrlib, but I'm not sure that there is any way to do it.
[11:55] <lifeless> poolie: woo, the eagle is in!
[11:55] <lifeless> thekorn: as in a template ?
[11:56] <thekorn> james_w, ok, I just found the related functions, they are having a lots "TODO"s in __doc__, too bad
[11:56] <thekorn> lifeless, best thing would be if it could list all my changed files there
[11:56] <lifeless> thekorn: well, TODO's just reflect bug plans :)
[11:57] <thekorn> because I'm always starting my messages with the files I changed
[11:57] <lifeless> interesting
[11:57] <lifeless> uhm, there might be a plugin already
[11:57] <lifeless> what I do is use --show-diff
[11:57] <thekorn> and right now I'm copieing the part under the ---bar---
[11:57] <lifeless> because I copy various bits of details
[11:57] <thekorn> and comment on each item
[11:58] <lifeless> thekorn: could you file a bug? It seems to me doing this would be a nice thing
[11:58] <thekorn> ok, will do
[11:58] <thekorn> thanks lifeless, james_w
[12:00] <lifeless> thekorn: after the bug is filed, if you want to work up a plugin or patch, I'd be happy to make suggestions
[12:01] <thekorn> lifeless, are there some docs on howto write a plugin somewhere
[12:01] <vila> poolie: just arrived, but launch break in a few minutes
[12:01] <lifeless> thekorn: there are some; but not enough :)
[12:01] <lifeless> thekorn: docs/en/developers/plugins.txt I think is one spot
[12:02] <lifeless> thekorn: there are using bzrlib thigns on the wiki too
[12:02] <lifeless> thekorn: but for this, I think a patch to the core is entirely suitable
[12:02] <vila> poolie: I just read you were about to sign-off though, so maybe in 10/12 hours ;-)
[12:06] <thekorn> lifeless, ok, cool, I will have a look at the general structure of bzr and bzrlib and try to understand how such a patch could look like
[12:07] <lifeless> thekorn: In my head is something like a 'template' setting in the config for commits
[12:07] <james_w> thekorn: I added start_message to get_commit_message for doing exactly this
[12:07] <lifeless> e.g. %s would mean 'include status', %d would mean 'include diff' etc
[12:09] <lifeless> thekorn: but we can start with just what you need
[12:11] <thekorn> ok, cool, I will file a bugreport, think about it a bit, and come here again to discuss this further,
[12:11] <thekorn> or directly on the bugreport, of course
[12:13] <lifeless> sure
[12:13] <lifeless> I'll see it if you discuss there too
[12:17] <beuno> lifeless, cool, thanks. Mergeing now.
[12:18] <lifeless> beuno: in my testing it makes a branch with no index work (but get no hits)
[12:19] <beuno> lifeless, that's exactly the behaviour I want, so it's perfect. I have been puttin it off, so it's great
[12:19] <lifeless> beuno: it should also do the same if the plugin is missing, but I didn't actually test that
[12:20] <pypas> bonjour a tous, Il y a t il des francophone sur le channel? (cause my english is too bad :(
[12:20] <lifeless> beuno: *I* would like it to say what is wrong if there is no index/no bzr-search, but thats not something I know the best way to do offhand
[12:20] <lifeless> vila: ^ pypas
[12:20] <beuno> lifeless, I'll test that before pushin. It should return no results because it can search other things (revnos, dates)
[12:21] <pypas> petite question : puis-je supprimer un repertoire, commiter et au besoin faire un revert pour recreer les fichiers supprimes?
[12:22] <vila> pypas: oui
[12:23] <pypas> j'ai essayer la suppression via bzr delete : pas fonctionne puis en supprimant via mon explorateur et pareil, marche pas
[12:23] <lifeless> beuno: hmm, bzr-search will be growing such searches too; in future perhaps I can change your mind :)
[12:23] <vila> plus precisemment ?
[12:23] <pypas> la supression fonctionne mais c'est le revert qui ne recreer pas mes fichiers
[12:25] <beuno> lifeless, sure, my mind is very changeable
[12:25] <vila> la suppression par 'bzr rm' ?
[12:26] <vila> pypas: que dit 'bzr st' avant et apres la suppression ?
[12:27] <vila> pypas: juste pour etre sur, on parle bien de supprimer des fichiers et/ou des repertoires qui sont deja connus de bzr (i.e. ajoutes et commites)
[12:27] <pypas> ils sont deja connu et j'ai fait un bzr remove path/vers/mon/rep
[12:27] <pypas> bzr delete
[12:28] <beuno> lifeless, works fine without bzr-search installed. Pushed.
[12:28] <vila> 'bzr delete' c'est quoi ? Quelle version de bzr utilises-tu (bzr version) ?
[12:29] <pypas> 1.5
[12:30] <vila> bzr delete
[12:30] <vila> bzr: ERROR: unknown command "delete"
[12:30] <pypas> tu es sous ng?
[12:30] <pypas> moi pas
[12:30] <pypas> au temps pour moi, c'ets un remove que j'ai fait
[12:30] <vila> pypas: ouch, tu parles de 'baz' donc, pas de 'bzr'
[12:31] <vila> pypas: ghaa, 'bzr version' dis quoi ?
[12:31] <pypas> 1.5
[12:31] <pypas> merci de ton aide vila mais je dois quitter, ma progeniture se reclame. je repasserais tantot
[12:32] <pypas> merci encore
[12:32] <vila> pypas: pareil, a plus
[12:35] <Sub_Zero> Hey all. I had a (hopefully) easy question about bazaar. Essentially, I want to alias 'bzr reset' to 'bzr revert' and 'bzr clean-tree', but I don't believe bzr aliases support multiple commands. I'm hoping there is an easy way to do this.
[12:36] <beuno> Sub_Zero, I suppose you could do a bash alias instead
[12:36] <Kinnison> Are bzr aliases core?
[12:36] <lifeless> beuno: what else needs going to make the search branch mergable?
[12:36] <Kinnison> Sub_Zero: I'd be tempted to write a plugin to do it
[12:36] <Kinnison> Sub_Zero: given the two commands you want to combine take differing arguments
[12:37] <Sub_Zero> beuno: Yeah, that does work. But I was hoping there would be a little more "integrated" way to do it.
[12:37] <beuno> lifeless, off the top of my head, just the remaining javascript bit, and looking into what I can/should use of the new streaming feature
[12:37] <beuno> I suppose we're almost there  :)
[12:37] <Sub_Zero> Kinnison: I think the plugin is the way to go, but I don't know any phython :(
[12:37] <beuno> I do want to add some context to the search results, but I don't think it's worth waiting for that
[12:38] <Kinnison> Sub_Zero: aah
[12:38] <Kinnison> Sub_Zero: always a bit of an issue, given my other suggestion was going to be to modify the alias plugin :-)
[12:38] <lifeless> beuno: sounds like 'merge it now' to me :)
[12:39] <Kinnison> Do it!
[12:39] <lifeless> beuno: because the streaming thing can be done later; and the remaining javascript bit is not worse that the old search facility
[12:40] <beuno> lifeless, well, one thing we do need to add, is for the <div> not to show if no results are returned, or search is not enabled
[12:41] <Sub_Zero> Kinnison: I've been meaning to sit down and get my feet wet in Python, but being mostly ignorant how hard would it be to write a plugin to execute those two commands?
[12:41] <spiv> lifeless, poolie: well done!
[12:41] <Kinnison> Sub_Zero: Not *certain* but I wrote commands for bzr reasonably easily, so I'd guess not too hard
[12:41] <beuno> lifeless, that's the part that's worst then now. If my day isn't too hectic, I can probably get that done before mwhudson wakes up and can review it
[12:43] <lifeless> beuno: I try to split 'need to' from 'want to'
[12:44] <lifeless> beuno: if its not worse than the old code in any regard, I look for reasons not to merge, rather than reasons to merge :)
[12:44] <lifeless> spiv: thanks
[12:44] <lifeless> spiv: no excuses on looking at the new api now :)
[12:44] <spiv> lifeless: :)
[12:44] <spiv> I've *looked* at it...
[12:44] <spiv> I just need to use it :)
[12:45] <beuno> lifeless, agreed. I'll make the div behave sanely if bzr-search isn't present or no results are returned, and put up a merge request
[12:46] <lifeless> spiv: I will be in hornsby at 7am tomorrow for a physio visit
[12:46] <beuno> ah, thought of one more thing. It doesn't search revnos now. That should be fixed too.
[12:47] <lifeless> spiv: that will probably finish around 8am; If you wanted to hack together I'm happy to stay around in hornsby for a few hours
[12:47] <lifeless> beuno: as in '52' ?
[12:47] <beuno> lifeless, yeap. Which is the only thing that currently works properly  :)
[12:47] <spiv> lifeless: I'm tempted, but my flat looks embarrasingly like a bomb site at the moment.
[12:47] <spiv> (Even more than usual)
[12:47] <lifeless> spiv: so you've cloned my house?
[12:48] <spiv> Worse :)
[12:48] <lifeless> spiv: we could sit at $pie_shop, drink caffeine and eat pie
[12:48] <lifeless> spiv: or I can just head home during rush hours
[12:48] <spiv> There's no decent pie shop anymore, but I'm sure we can manage something.
[12:49] <lifeless> spiv: how about - I give you a ring around 8:30, that should be close enough to civilised given the 9am stand-up; and I'll be esconced somewhere westfieldy
[12:49] <lifeless> spiv: and we can discuss go/nogo/details then ?
[12:51] <spiv> lifeless: works for me
[12:51] <lifeless> kk will do then
[12:59] <poolie> vila, i am signing off now, will mail you or try to catch you tomorrow
[12:59] <AfC> spiv, lifeless: it's too bad you're talking about Hornsby. I've been meaning to have you two over for lunch but with Robert fleeing the country I guess we're out of time. Andrew, the invitation is open.
[13:05] <spiv> AfC: we should definitely arrange something on your side of the harbour one day
[13:08] <vila> poolie: ok, no problem (just coming back from launch :)
[13:08] <vila> beuno: ping
[13:09] <beuno> vila, pong
[13:09] <beuno> I owe you a reply
[13:09] <beuno> I'm way behind on replies  :(
[13:10] <vila> beuno: did you give a try to bzr-upload with the chmod bit handling ? Are you happy with it or do we need more ?
[13:10] <vila> beuno: given that ftp doesn't work yet
[13:10] <beuno> vila, I haven't gotten around to testing it yet. I'll stick it into my main server today and see if anyone complains  :p
[13:11] <beuno> (and, well, eventually do real testing)
[13:11] <beuno> past few days have been very crazy
[13:11] <vila> beuno: ok, I have a patch for bzrlib to make ftp support chmod, I still need to test it against a real server
[13:12] <vila> beuno: ok, no problem, I was unsure about taking your last reply as valid for my mail bombing or if I should be waiting for mor replies ;)
[13:12] <beuno> vila, if you need an ftp/sftp server to test against, let me know, I'll set up an account for you on one of my webservers
[13:13] <vila> beuno: thanks for the offer, but I'm close to have one test server available using te local-test-server plugin so I will quickly be in position to test against any ftp server I can install on Ubuntu
[13:21] <lifeless> AfC: I have another week; and would like to do something
[13:22] <lifeless> AfC: I've been unwell recently; I'm starting to feel human again
[13:22] <AfC> lifeless: sooner rather than later would work well, actually
[13:22] <lifeless> AfC: are you GUADECing?
[13:22] <AfC> lifeless: no
[13:59] <Sigma> hi. I've got a little problem. "bzr push" says bzr: ERROR: These branches have diverged.  Try using "merge" and then "push".
[13:59] <Sigma> on the other and, "bzr merge" says "Nothing to do." :-)
[13:59] <Sigma> s/and/hand/
[14:00] <Sigma> any idea is welcome :-p
[14:02] <beuno> Sigma, maybe your push location is different than your merge location?
[14:04] <spiv> Sigma: I think bueno is right.  Check the "bzr info" output.
[14:05] <Sigma> hmm actually they are, but, the source of merge should be up-to-date with my push location. let me check :)
[14:06] <Sigma> I'm merging from launchpad/http and pushing to launchpad/sftp
[14:06] <beuno> Sigma, try "bzr missing"
[14:07] <beuno> and see what that says
[14:07] <Sigma> it says I have 1 extra revision
[14:08] <beuno> Sigma, maybe try pushing and specifying the URL. It may be pushing somewhere else
[14:14] <pypas> |/commands|
[14:17] <Sigma> I've got this error when merging : bzr: ERROR: Revision {yann.hodique@gmail.com-20080601233200-8sufw6rintulemn6} not present in "KnitVersionedFile(sftp://yann-hodique@bazaar.launchpad.net/%7Eyann-hodique/%2Bjunk/dotemacs/.bzr/repository/knits/f4/195%408a708873-67e9-0310-be3a-b2333ca284a8%253atrunk%253alib%25252%2546icomplete%25252%2542.el)".
[14:17] <beuno> ah, that doesn't look good
[14:18] <beuno> you're using knits for starters. What version of bzr are you using?
[14:18] <Sigma> 1.5, but this message relates to the storage in launchpad, no ?
[14:18] <beuno> yeah
[14:19] <beuno> it may be bug #205156
[14:19] <Sigma> hmm
[14:19] <beuno> https://code.edge.launchpad.net/~yann-hodique/+junk/dotemacs/
[14:20] <beuno> Sigma, you have the full repository locally?
[14:20] <beuno> you can probably to push --overwrite to fix that
[14:21] <beuno> and, I'd recommend upgrading the storage format with (but after we fix this)
[14:25] <Sigma> yes, I can overwrite, I'll try that
[14:25] <beuno> Sigma, that sould fix it, and, after that, I'd recommend doing:  bzr upgrade && bzr reconcile
[14:25] <beuno> both locally and remotely
[14:25] <beuno> (it may take a while to do it on LP)
[14:25] <Sigma> but locally I'm already at the latest format
[14:26] <Sigma> ah ok
[14:26] <beuno> and, it's *much* faster if you use bzr+ssh instead of sftp
[14:26] <beuno> Sigma, if you branched off LP, it probably brought in knits format
[14:26] <Sigma> Standalone tree (format: pack-0.92)
[14:27] <beuno> cool
[14:27] <beuno> then, push --overwrite
[14:27] <beuno> and upgrade afterwards
[14:27] <beuno> shouldn't happen every again with packs  :)
[14:28] <Sigma> ok thanks
[14:31] <Sigma> btw, when I re-branch from LP, I get Standalone tree (format: dirstate)
[14:32] <poolie> guilhem, https://answers.launchpad.net/bzr/+question/37308
[14:32] <poolie> guilhembi: ^^
[14:33] <beuno> Sigma, right. You must of upgraded at some point, or used a shared repository. Upgrade in LP and it should all go away
[14:33] <poolie> this is the person -> https://edge.launchpad.net/~xuekun-hu
[14:35] <Sigma> beuno: how am I supposed to upgrade on LP ? a simple "bzr upgrade bzr+ssh://yann-hodique@bazaar.launchpad.net/~yann-hodique/+junk/dotemacs/" doesn't seem to do the job
[14:35] <beuno> Sigma, ironically, for upgrades you need sftp
[14:35] <Sigma> I see :)
[14:35] <beuno> but, for the rest, bzr+ssh is much faster
[14:36] <beuno> morning jam
[14:36] <jam> 'morning beuno
[14:36] <LeoNerd> I find it's a tough call sometimes between sftp and bzr+ssh
[14:37] <LeoNerd> At home, I have a fast 100Mbit network to a slow server... sftp becomes faster, even though it has mmore network overhead, just because it's lighter on server CPU load.
[14:37] <Sigma> since it's taking ages, I suppose it's working :) thanks a lot
[14:38] <beuno> Sigma, you're welcome
[14:39] <poolie> Sigma: do you get an error over ssh?
[14:39] <guilhembi> jam: hi! Posted some test results of your latest bzr branch; and also: ha_ndbcluster.cc "false conflicts" is the most burning issue I believe
[14:39] <poolie> if you're going from knits to packs it will take a while
[14:40] <poolie> statik: can we talk briefly?
[14:41] <Sigma> poolie: bzr+ssh gives me "bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format." which is quite confusing :)
[14:41] <poolie> hm ok
[14:41] <poolie> could you file a bug please?
[14:41] <Sigma> yep, will do
[14:49] <GaryvdM> Hi. I'm having a problem branching a branch. I'm getting this error:
[14:49] <GaryvdM> C:\Inetpub\wwwroot\squarepegs>bzr pull http://www.squarepegs.co.za/
[14:49] <GaryvdM> bzr: ERROR: No such file: 'http://www.squarepegs.co.za/.bzr/repository/indices/e07e8982d90a74ddd63781f8e3fb20a7.rix'
[14:51] <GaryvdM> The branch was pushed with bzr 1.5 , and I'm an trying to branch it with a copy of bzr.dev
[14:51] <Sigma> hmm, the upgrade finally failed :/
[14:52] <Odd_Bloke> GaryvdM: Can you check if the file actually exists via non-HTTP means?
[14:53] <GaryvdM> Ok
[14:53] <beuno> Sigma, with what error?
[14:53] <Sigma> same as before : bzr: ERROR: Revision {yann.hodique@gmail.com-20080601233200-8sufw6rintulemn6} not present in "KnitVersionedFile(sftp://yann-hodique@bazaar.launchpad.net/%7Eyann-hodique/%2Bjunk/dotemacs/.bzr/repository.backup/knits/f4/195%408a708873-67e9-0310-be3a-b2333ca284a8%253atrunk%253alib%25252%2546icomplete%25252%2542.el)".
[14:54] <beuno> Sigma, and you already did push --overwrite?
[14:54] <Sigma> yes
[14:54] <beuno> hmr
[14:54] <beuno> jam, any idea on how to fix that  ^
[14:55] <beuno> it looks like bug #205156
[14:56] <GaryvdM> Odd_Bloke: hmmm - it's working via ftp. But not accessible through http. I think my host has changed something.
[14:56] <GaryvdM> Thanks
[14:57] <Odd_Bloke> GaryvdM: Yeah, that's probably a permissions issue.
[14:58] <jam> beuno, Sigma: Is this happening during a bzr upgrade? (Since otherwise I don't know why it would trigger in "repository.backup".
[14:58] <Sigma> beuno: btw, it looks like my LP repository is now broken : Branched 0 revision(s). :/
[14:58] <Sigma> jam: yep
[14:58] <jam> I *believe* the appropriate answer is that you need to upgrade with <= 1.5 (maybe 1.4) and then do "bzr reconcile" with that version
[14:58] <jam> and then it will work with bzr.dev
[14:58] <jam> The old fetch code could handle missing data
[14:59] <jam> the new stuff can't
[14:59] <jam> so if you have missing stuff, you need to upgrade with the old code first
[14:59] <jam> and reconcile to fill in appropriately.
[14:59] <jam> At least, that would be my 1-min recommendation.
[15:09] <Sigma> jam: sorry, I was not able to test it. the LP branch was not usable anymore after broken upgrade. I had to delete/recreate it. Thanks anyway :)
[15:09] <jam> Sigma: well, you probably just needed to mv .bzr/repository.backup .bzr/repository, but as long as you are back to functioning
[15:11] <Sigma> yep. it looks like there is room for a feature in LP to upgrade formats via the web interface
[15:13] <beuno> yes, and probably a warning when the repo is in an old format
[15:19] <LarstiQ> beuno: do consider older clients
[15:21] <beuno> LarstiQ, well, it's just a warning, not a death threat  :)
[15:21] <beuno> it seems the bug requesting it was already filed as #179035
[15:22] <beuno> most users don't even know they're using knits, so informing them may push more upgrades
[15:23] <beuno> (in fact, Loggerhead was using knits until recently)
[15:26] <Verterok> moin
[15:27] <beuno> howdy Verterok
[15:27] <Verterok> beuno: morinin'
[15:28]  * Verterok still sleepy
[15:28] <beuno> Verterok, I woke up at 3am, so I'm...  odd
[15:29] <beuno> went to sleep at 5pm, so I guess it's ok, but still, odd  :)
[15:30] <Verterok> beuno: good timing to work with the australian folks ;)
[15:31] <beuno> actually, british folks, but yes, that worked out good too
[15:33] <Verterok> beuno: right, (remember I'm still sleepy :-D)
[15:33] <beuno> hahaha
[15:33] <abentley> Verterok: I don't know if you saw, but I got the main BB instance onto Postgres this morning.
[15:34] <beuno> abentley, it seems much faster to me now. Especially when loading the merge requests
[15:34] <Verterok> abentley:  reading the mail ATM. yay!! :D
[15:35] <abentley> beuno: I'm not noticing a great improvement, but for me it's about thread-safety and easier schema migration.
[15:36] <beuno> right, having it not hang frequently will be good
[15:36] <abentley> Verterok: The gotcha I encountered was that the sequences for the primary keys weren't set properly.
[15:37] <abentley> So it would try to re-use ids that had already been used.
[15:37] <Verterok> abentley: I was about to asking if you find glitches with the scripts
[15:38] <abentley> Verterok: The main thing was just figuring out all the stuff outside the scripts-- creating the user, creating the db, creating the tables.
[15:38] <abentley> And some server configuration stuff too.
[15:39] <nandersson> Verterok: I'm just curious. Is your bzreclipse-plugin ready for Eclipse 3.4?
[15:39] <Verterok> abentley: I see, about the ids, I'll search if I can force the reuse using sqlalchemy
[15:40] <Verterok> abentley: regarding the configuration part, I can extend the README and add some guidelines about server configs, etc
[15:40] <matkor> was fix "division by zero" fix commited to bzr-gtk trunk ? I got such impression but still having problem with comiting / updating ...
[15:40] <abentley> Verterok: Also, you didn't do pkg_resources.require, so it didn't find the right versions of some packages.
[15:41] <abentley> Verterok: I've merged your changes into trunk, and included written a script that does most of it.
[15:42] <abentley> The other glitch was that I had one listing that displayed items in database-insertion-order.
[15:43] <abentley> And suddenly, that order changed.
[15:43] <Verterok> abentley: ups, I'll start fixing the first issues
[15:43] <Verterok> about the ordering, I don't quite fully understand
[15:44] <Verterok> nandersson: it should work
[15:44] <Verterok> nandersson: I didn't test it, but it *should* work :)
[15:46] <nandersson> Verterok: Thumbs up! I'm looking forward to try it out. Excellent job :)
[15:50] <abentley> Verterok: Instead of sorting by date, I sorted by database-insertion-order.
[15:51] <abentley> But in the migrated version, database insertion order doesn't match the original, and doesn't correlate with date.
[15:51] <abentley> So I changed it to sort by date.
[15:51] <Verterok> abentley: ah, ok
[15:53] <nelson> Does Bazaar really find lost socks?  Can it find lost gloves, too?
[15:56] <Verterok> abentley: I'll keep working on my branch to fix those issues, I'll send you a merge request when I'm done
[15:56] <abentley> Verterok: I suggest merging from trunk, since I did tweak a few things.
[15:56] <Verterok> abentley: ok, I'll :)
[15:57] <nelson> Do CVS ''tags'' become Bazaar ''branches''  in principle?
[16:08] <guilhembi> jam: hi! Don't know if this reached you: I posted some test results of your latest bzr branch; and also: ha_ndbcluster.cc "false conflicts" is the most burning issue I believe
[16:08] <jam> guilhembi: yeah, I saw that, are you done for the night?
[16:09] <guilhembi> jam: ahah yes, I woke up a while ago :)
[16:09] <jam> guilhembi: yeah, timezones can be a pain. Anyway, hopefully I'll have something you'll like when you wake up.
[16:10] <jam> I can't guarantee that the false conflicts are actually false
[16:14] <guilhembi> jam: if they are correct (which would be a pain), we'll need super-detailed explanations:
[16:14] <guilhembi> "this revision id changed this line from X to Y, and that revision id changed X to Z, and A was merged into B", etc.
[16:15] <guilhembi> Otherwise people will just do the gannotate analysis that I do and not understand why bzr conflicts.
[16:15] <guilhembi> and complain it's a bzr bug, and the sky will fall down or almost :)
[16:16] <guilhembi> That is, most people at MySQL are on the line of: "if it was already merged I should not see it again".
[16:20] <jam> guilhembi: well, we might need to add a "--ignore-the-fact-that-people-actually-disagreed-here" flag for you
[16:21] <guilhembi> :)))
[16:22] <guilhembi> jam: of course, if you can educate us, it's valuable. We're just users of RCS software, we can learn.
[16:22] <guilhembi> bbl.
[16:23] <mkanat> Is there any way to see the actual commits made against this branch that weren't against an ancestor?
[16:23] <mkanat> Or even bundle them (that would be ideal)?
[16:24] <mkanat> Hey, that's great about MySQL! :-)
[16:25] <jam> mkanat: "bzr send ../ancestor" should create a bundle against that ancestor
[16:25] <jam> "bzr diff -r ancestor:../branch"
[16:25] <jam> or
[16:25] <jam> bzr missing?
[16:26] <mkanat> jam: I'll try send.
[16:26] <mkanat> I'm porting a bunch of customizations from one branch to another, and I'd like to do them as their own commits.
[16:26] <jam> mkanat: you should be able to use "-o" if you want to put the output in a file "-o-" puts it to stndout
[16:27] <jam> mkanat: "bzr merge ../other/branch -r X..Y; bzr revert --forget-merges; bzr commit ?"
[16:28] <mkanat> jam: The customizations aren't a sequential series of commits.
[16:28] <mkanat> jam: Send seems to do it. :-)
[16:28] <jam> mkanat: hence the 'x..y'
[16:28] <jam> but whatever works for you
[16:30] <mkanat> jam: Are those a literal X and Y?
[16:31] <jam> mkanat: no, numbers
[16:31] <mkanat> That's what I figured.
[16:31] <mkanat> Yeah, send is easier.
[16:31] <jam> so you can select what patches you want included
[16:34] <asabil> anyone ever took a look at accurev UI for cherry picking and merging changesets from a branch to another ?
[16:34] <asabil> I think it would be really neat to have the same kind of tool in bzr-gtk
[16:34] <beuno> asabil, would you happen to have screenshots of that?  :)
[16:35] <asabil> 1 minute
[16:35] <asabil> let me find it again
[16:35] <mkanat> jam: Yeah, that makes sense.
[16:36] <asabil> beuno: http://www.accurev.com/images/screenshots/4.6/streambrowser.png
[16:36] <asabil> basically you can drag and drop stuff :)
[16:38] <beuno> asabil, ah, so you would drop revisions into another branch?
[16:39] <asabil> beuno: that's what I think can be done for bzr
[16:40] <beuno> asabil, could you file a detailed bug for it?  Sounds like a good idea, and I'd hate to loose it
[16:40] <asabil> beuno: if you don't mind flash: http://www.accurev.com/virtualbooth/2min-demo/2min-demo.html
[16:40] <asabil> beuno: I will try to do that later
[16:42] <beuno> asabil, thanks. That really looks very nice
[16:43] <asabil> :)
[16:58] <sabdfl> seems we've regressed on status performance
[17:04] <jam> guilhembi: if you are still around, could you check which bzr you used to  do 'gannotate'?
[17:04] <jam> If you used "bzr.dev" can you try my custom bzr? It annotates slightly differently and *might* provide a different insight
[17:17] <quicksilver> vila: ping?
[17:17] <quicksilver> anyone uses dvc/emacs with bzr?
[17:18] <vila> quicksilver: pong
[17:19] <quicksilver> vila: you ever use emerge to resolve conflicts?
[17:19] <quicksilver> I have before.
[17:19] <quicksilver> I'm sure there was a way to run it on a dvc-conflict
[17:19] <quicksilver> btu I can't find it now
[17:19] <vila> I use smerge, it's triggered by just opening a file which contains conflict markers
[17:20] <quicksilver> ah yes
[17:20] <quicksilver> smerge-ediff will launch emerge :)
[17:20] <vila> once the conflicts are resolved, don't forget M-x dvc-resolved
[17:20]  * quicksilver nods
[17:20] <vila> quicksilver: yup, but I find it less clear now that I'm used to read diffs... go figure
[17:21] <quicksilver> I'm happy reading diffs for simple stuff
[17:21] <quicksilver> for some complex conflicts a side-by-side view is nice
[17:22] <vila> Yup,  but I rarely encounter really complex ones... In the worst cases, I'm happy to hack the most close version at hand
[17:23] <vila> .. without using two/three buffers screen estate :)
[17:25] <gour> vila, quicksilver: so DVC is useful with bzr?
[17:25] <vila> gour: sure
[17:26]  * vila thinks I *really* should update the wiki about my usage :-/
[17:27] <vila> gour: the most useful command is: dvc-diff
[17:27] <gour> it would be nice
[17:27] <gour> DVC docs is *cough* a bit...
[17:27] <vila> it presents you a buffer containing, roughly, the output of 'bzr st' and 'bzr diff'
[17:28] <vila> from there, on any line, doing C-c C-c jumps to the modified line in the file itself
[17:28] <vila> so, hack, hack, hack, where am I: dvc-diff, Oh I see, let's go back to that part, hack hack
[17:29] <gour> :-)
[17:29] <vila> since my workflow includes reviewing before commit, it just flows naturally and allows me to fix details with just one keystroke
[17:30] <dato> hm, that's indeed nice
[17:30] <jam> vila: well, technically 2 keystrokes
[17:30] <jam> Unless your C-c C-c is different from mine :)
[17:31] <gour> cool, cool. i used to use darcsum when working with darcs 'cause DVC support for it is not the best. now, i believe DVC is tool-of-choice for emacs & bzr
[17:31] <vila> jam: :-) I tend to call any emacs command shortcut a keystroke, even if I should type 3 our 4 chrods :)
[17:31] <vila> chords ?
[17:32] <jam> most likely chords
[17:32] <jam> chrod sounds like a unix command
[17:32] <vila> Escape Meta Alternate Control Shift ftw :)
[17:32] <vila> you mean chroad which is a well know alias for bzr branch
[17:33] <vila> s/know/known/ damn typos ruining jokes !
[17:33] <dato> heh, chroad
[17:34] <quicksilver> yes, DVC is very useful
[17:34] <quicksilver> C-x V L and C-x V = and C-x V c ftw!
[17:35] <quicksilver> what does "M*" mean
[17:35] <quicksilver> in the output of update/pull ?
[17:35] <vila> modified and x bit modified ?
[17:37] <vila> quicksilver: wow, C-x V L .... never used that one :) I guess I've been bzr viz infected :)
[17:39] <quicksilver> C-x V L is annoying because it's the abbreviated log
[17:39] <quicksilver> I never want to see the abbreviated log
[17:39] <quicksilver> merge messages matter
[17:39] <quicksilver> but it's useful because you can hit "=" on any revision
[17:39] <quicksilver> and see the local diff
[17:40] <vila> can you limit it somehow ? I tried C-1 C-2 C-x  V L but it still display the whole log
[17:40] <quicksilver> if you can't I don't know how to :)
[17:40] <vila> quicksilver: yeah, '=' is double-click in bzr viz
[17:40] <vila> but I think there is a plan to display it in the same window with a single click
[17:59] <beuno> how do I specify a different port for bzr+ssh?
[17:59] <dato> bzr+ssh://host:port/path does not work?
[18:00] <beuno> dato, it does, thanks   :)
[18:00] <dato> .ssh/config is also handy for that
[18:00] <dato> np
[18:21] <bobesponja> hi
[18:21] <bobesponja> is there a ruby lib to interface with bzr?
[18:22] <jelmer> I think somebody was working on one
[18:22] <LeoNerd> bzrlib is in python, but maybe ruby can use a simimlar trick to perl, and embed a python 'terp?
[18:22] <LeoNerd> I've been playing with using bzrlib from perl using Inline::Python lately.. it's quite fun :)
[18:22] <beuno> bobesponja, or, you can use the xmloutput plugin to get data from bzr
[18:23] <bobesponja> ok, thanks for the info
[18:24] <bobesponja> LeoNerd: what's a python 'terp? :)
[18:24] <LeoNerd> "interpreter" for people like me who often mistype long words
[18:25] <bobesponja> ok
[18:26] <LeoNerd> Inline::Python is a perl module that pulls in libpython, and marshalls data between perl and python representations..
[18:26] <fullermd> Hm.  Does that actually work well?
[18:26] <LeoNerd> This makes it very easy to use python libraries from perl. Something similar may exist for ruby
[18:26] <LeoNerd> Ish...
[18:26] <LeoNerd> One thing it doesn't do ((yet)) is object attributes.
[18:26] <LeoNerd> Which is kinda essential to using bzrlib, since I notice various things use it
[18:27] <LeoNerd> So where python could just use   revision.repository   I have to   getattr(revision, 'repository')
[18:27] <james_w> someone's adopted bazaar in Debian, so it looks like it's not going to be removed from lenny.
[18:28] <LeoNerd> That being the 'baz' implementation of TLA, yes..?
[18:28] <beuno> james_w, and the FTBS?
[18:28] <james_w> fixed apparently
[18:28] <james_w> LeoNerd: yup
[18:28] <beuno> james_w, so now we have to pursuade that fellow to do the transition...
[18:29] <james_w> ah to "baz" package name?
[18:29] <beuno> yes
[18:29] <dato> james_w: who adopted it?
[18:29] <beuno> and make that trickle down to Intrepid
[18:30] <james_w> beuno: it's gone in Ubuntu.
[18:30] <beuno> james_w, I know, but lifeless wanted it so baz -> bzr repos could be migrated
[18:30] <beuno> AFAIK, removing it was a temporary thing
[18:30] <james_w> beuno: the failure we saw was apparently due to "dash". A lot easier than we thought, but there were apparently other problems.
[18:31] <beuno> james_w, really?  Argh, we spent quite a while on it...
[18:32] <beuno> it would be cool to be able to do the transition
[18:33] <james_w> I'm going to send a mail to the bug report now.
[18:33] <beuno> thanks  :)
[18:35] <bobesponja> http://rubyforge.org/projects/bzrwrapper/
[18:35] <bobesponja> 	0.1  	August 24, 2007
[19:11] <dpm> I've published a branch of an upstream project hosted at launchpad on my personal Launchpad page. The way I've been working is doing commits on my working copy and then pushing them to my LP branch. Now upstream has merged my changes and has made some new ones. What's the correct way to get the latest upstream changes now? 'bzr update' fetches the changes from my personal LP branch, not upstream. I've been using git in the past, which stores a refer
[19:11] <dpm> ence to the remote repo which was initially cloned. Is there something similar on bzr, or do I have to explicitly give the upstream branch as in 'bzr merge lp:upstream'?
[19:12] <james_w> dpm: yup, but then you will only have to give the  url to "merge" once
[19:13] <james_w> it only stores a single URL though, so if you regularly merge from two different places it's a bit annoying.
[19:13] <dpm> ok, I understand. Thanks
[20:01] <jam> abentley: a couple questions if you have time? I seem to be getting "foo.OTHER" rather than "conflict adding foo, moving existing foo => foo.moved". I'm probably doing something wrong, but if you have a hint as to what?
[20:01] <abentley> jam: Give me a few minutes.
[20:02] <jam> np
[20:02] <jjcroftiv> Hello - I am new to bazaar and have been using it for about a week.  So now I have a local repository with a number of revisions, and I a want to move this to a central server.  Can I simply tar up the whole repository, move it to the server, and continue to use it from there, or is there some other action required? TIA
[20:05] <beuno> jjcroftiv, tar and movinf is perfectly acceptable
[20:05] <beuno> you can push it to the remote location too
[20:07] <jjcroftiv> bueno, thanks for the response:)
[20:19] <abentley> jam: back.  I was implementing path_content_summary on TT, and it's not as simple as you might think.
[20:20] <abentley> We seem to have got switched around.  I work on the APIs you added to Tree, and you work on merge.
[20:20] <jam> :)
[20:21] <jam> So I *think* what is happening is that the same file/directory got added by two different branches
[20:21] <jam> so when you merge them together, you get a path conflict
[20:21] <jam> and one of them gets .moved out of the way
[20:22] <jam> abentley: I'm trying to figure out why I would be getting a bath of "foo.OTHER" instead of a conflict and "foo.moved".
[20:22] <jam> Would you get that if it looked like a rename instead of an add?
[20:23] <abentley> are both foo and foo.OTHER versioned?
[20:23] <jam> abentley: after the merge, yes
[20:23] <jam> +N  .bzr-mysql.OTHER/
[20:23] <jam> +N  .bzr-mysql.OTHER/default.conf.OTHER
[20:24] <jam> ^- my code
[20:24] <jam> v- bzr.dev
[20:24] <jam> +N  .bzr-mysql/
[20:24] <jam> +N  .bzr-mysql/default.conf
[20:24] <jam> R   .bzr-mysql/ => .bzr-mysql.moved/
[20:24] <abentley> Oh.  I thought you were talking about bzr.dev the whole time.
[20:26] <abentley> using OTHER suggests it's happening in the merge code, not the filesystem conflict resolution.
[20:27] <jam> abentley: oh, and I'm cheating a bit about the criss-cross merge stuff. http://paste.ubuntu.com/22937/
[20:27] <abentley> If you have two files with the same name in your transform, and you do the conflict resolution, you'll get the .merged.
[20:27] <jam> abentley: you mean .moved
[20:27] <jam> But why would I be getting .OTHER ?
[20:27] <abentley> Yes.
[20:28] <abentley> Not sure yet.
[20:28] <jam> I believe some part of my code is wrong (earlier I was running into "no final name for XXX" a bit)
[20:28] <jam> some of that turned out to be using something other than None to represent not there.
[20:28] <jam> some of it was getting the ordering of from => to wrong in iter changes
[20:31] <abentley> so I think foo.OTHER can be created if THIS deletes foo and OTHER creates it.
[20:31] <abentley> No, if OTHER keeps it.
[20:31] <jam> abentley: OTHER merges THIS and resolves it as a keep?
[20:31] <abentley> Is this being listed as a contents conflict?
[20:31] <jam> abentley: yes contents conflict
[20:32] <jam> Now, it may be because of base selection
[20:32] <jam> why I'm getting .moved rather than .OTHER
[20:32] <jam> um, vice versa
[20:32] <jam> I'm now getting .OTHER because of a closer base
[20:33] <jam> oh... it could also be because of what I posted about the "cheating" and how I'm handling None in the bases.
[20:33] <abentley> Yeah, if BASE has the file, THIS doesn't, and OTHER changed it, then you might get foo.OTHER.
[20:33] <abentley> Then if THIS added a new foo, you'd get foo and foo.OTHER.
[20:34] <abentley> jam: The logic is in merge_contents@778
[20:35] <jam> abentley: the "contents_conflict()" section?
[20:35] <jam> abentley: ahh, I think I'm also screwing with it in a different way
[20:35] <jam> You have:
[20:35] <abentley> jam well, that doesn't decide to emit the conflict.
[20:36] <abentley> It just implements it.
[20:36] <jam> if this_pair == base_pair: elif this_pair == 'file' and other_pair[0]' == 'file'. else contents_conflict()
[20:36] <abentley> jam, right.
[20:36] <jam> and I'm adding if not self._is_criss_cross  and this_pair == base_pair
[20:36] <jam> though I don't think that specifically would be the problem
[20:37] <abentley> It sounds like this may not be a bug.
[20:37] <jam> abentley: maybe, though it doesn't help the mysql guys...
[20:38] <jam> though guilhem may not realize that the alternative was to create a .moved
[20:38] <abentley> If you've got a non-None base.
[20:38] <guilhembi> jam: you want me to retry annotate or gannotate? I could do diff between  "bzr annotate sql/ha_ndbcluster.cc" with bzr.dev and your bzr?
[20:38] <jam> guilhembi: that would probably be interesting, (welcome back, btw)
[20:38] <jam> it can be on the same merge
[20:38] <jam> just do the annotate between the two
[20:38]  * guilhembi starts that; results in 2*5 minutes
[20:38] <jam> guilhembi: I'm surprised it is that slow for you
[20:38] <jam> it is about 2min here
[20:38] <guilhembi> uh
[20:38] <jam> guilhembi: oh, you might also do "bzr annotate --show-ids"
[20:39] <jam> that will help a bit
[20:39] <jam> it uses revision-ids rather than trying to work out "nice" values for it
[20:39] <jam> but they have about as much info
[20:39] <guilhembi> jam: Intel(R) Core(TM)2 CPU         T7400  @ 2.16GHz 2GB RAM opensuse 10.2
[20:39] <guilhembi> (laptop)
[20:39] <jam> guilhembi: laptop here as well
[20:39] <jam> T7500 @ 2.2GHz, 2GB
[20:40] <jam> It might be the number of pack files in your repo
[20:40] <jam> $ time bzr annotate --show-ids sql/ha_ndbcluster.cc >/dev/null
[20:40] <jam> real    0m19.441s
[20:41] <guilhembi> I use a shared repo, have several MySQL branches. But all of them are more or less included (as far as revision history) is concerned in 6.0-ndb, which is a recent branch.
[20:41] <jam> guilhembi: as you do commits, we create new pack files. Occasionally we autopack them together into larger ones
[20:41] <jam> having 1 large one is a lot faster than 20 small ones
[20:42] <jam> (at the moment our index code isn't scaling correctly with the number of packs, it should be log(N) at most, but it seems closer to N)
[20:42] <guilhembi> ahah, so one could write a plugin which forces a pack?
[20:42] <jam> guilhembi: just run 'bzr pack'
[20:42] <guilhembi> wah wah
[20:42] <jam> We expose it as a command
[20:43] <jam> we *want* to fix the problem, but it is a decent workaround for the moment
[20:44] <jam> guilhembi: however, I'm trying to work out if my tree is properly treating that file
[20:44] <jam> but 20s is vastly different than 5 min
[20:45] <guilhembi> ok, I do a pack...
[20:45] <jam> guilhembi: before you do, just do "ls .bzr/repository/packs | wc -l"
[20:45] <guilhembi> too late
[20:45] <jam> or you can do it while it is processing
[20:45] <jam> it won't change until it is done
[20:46] <guilhembi> jam: output is : 52
[20:46] <guilhembi> (ran this in shared repo)
[20:46] <jam> guilhembi: yeah.... that's pretty bad
[20:46] <guilhembi> jam: that's a lot you mean?
[20:46] <jam> I start noticing around 10+
[20:46] <guilhembi> ahah
[20:46] <jam> it is probably valid for the mysql tree and how many revisions you have
[20:46] <jam> but a pack should help quite a bit
[20:46] <guilhembi> maybe I should send this advice to my colleagues who have slow gannotate.
[20:47] <jam> guilhembi: well, try it first :)
[20:52] <jam> just to give a bit of info, as a trade off between number of packs and how often we have to autopack, the code uses the 'digits' to figure out the pack layout. So if you have 53,281 revisions , then it tries to create 5 10,000 entry packs, 3 1,000 entry packs, 2, 100 entry, 8 10, and 1, 1.
[20:53] <guilhembi> I ran "bzr pack" in a 6.0 branch, took 5 mins, and now I am down to 40 packs.
[20:53] <jam> In my mysql-repo, I see 61266 => 21
[20:53] <guilhembi> I should run this in shared repo directly, maybe
[20:53] <jam> guilhembi: can you do
[20:53] <jam> guilhembi: shouldn't matter, lets check something else
[20:53] <jam> grep -a "len" .bzr/repository/pack-names
[20:53] <jam> That is the "official" count
[20:53] <guilhembi> len=1
[20:53] <jam> there *can* be files present which aren't referenced
[20:54] <guilhembi> ok, so official count is 1, I start annotate
[20:54] <jam> guilhembi: so there are some "cruft" files that won't be used, if you want you could get rid of them
[20:54] <jam> I'm a bit surprised it is that high
[20:54] <guilhembi> bah, if they won't be used, they just take up space... no time...
[20:54] <jam> guilhembi: sure, it is just easier to remember the "ls" rather than the grep command :)
[20:55] <guilhembi> jam: to get rid of them, what shall I do (won't do it right now) ?
[20:55] <jam> cat .bzr/repository/pack-names
[20:55] <jam> At the end is the list of files that are being referenced
[20:56] <jam> rm the others
[20:56] <jam> you may also want to clean them out of .bzr/repository/indices
[20:56] <jam> Note that they are called "<name>.pack" on disk, and just <name> in that file.
[20:56] <guilhembi> mmm so somebody could write a plugin which does "bzr pack" + the procedure which you suggest...
[20:56] <jam> and there are NULLs in the file, but I don't expect that to cause you problems
[20:56] <jam> guilhembi: sure
[20:57] <jam> and if you did that, it would probably also want to delete the files in .bzr/repository/obsolete-packs so they are truly gone
[20:57] <jam> probably after doing "sync"
[20:57] <guilhembi> jam: Noted. Does it matter to "bzr pack" in one branch of the repo, or in the repo directly?
[20:57] <jam> to make sure you don't delete the last copy before the OS has a chance to write it out
[20:57] <jam> guilhembi: in a branch will pack the repo
[20:57] <jam> no difference
[20:58] <guilhembi> jam: not sure I get the relevance of "sync" here, but no big deal
[20:59] <jam> guilhembi: you want to tell the OS to write out the new .pack file to disk, before you delete the old pack files
[20:59] <jam> that is why we move them to 'obsolete-packs' rather than deleting them right away
[20:59] <jam> in case you lose power inbetween claiming the new .pack and getting rid of the old one
[20:59] <jam> OS don't always serialize actions the way we would prefer
[20:59] <jam> even sync isn't a 100% guarantee, but it is *better* than not doing it
[21:00] <guilhembi> jam: now I understand (interestingly, I have coded log recovery in a storage engine of MySQL, so this rings a bell now :)
[21:00] <jam> guilhembi: right, you write out the "next" stuff, write out  what you are going to , sync, and then start doing it.
[21:01] <guilhembi> So, first annotate finished, real 3m13
[21:02] <jam> guilhembi: I'm a bit surprised... is that with '--show-ids', with 'annotate' or 'gannotate' and bzr.dev or my bzr
[21:03] <guilhembi>  show-ids, annotate, your bzr; running with bzr.dev now
[21:03] <guilhembi> real    0m20.485s
[21:03] <guilhembi> wow
[21:03] <guilhembi> this 20s was show-ids, annotate, bzr.dev.
[21:04] <jam> guilhembi: try again with my bzr
[21:04] <jam> oh, you know what
[21:04] <jam> You didn't run "make" in my code, did you?
[21:04] <jam> You don't have the compiled "diff" extension
[21:04] <lifeless> moin
[21:04] <jam> moin lifeless, go back to sleep :)
[21:05] <guilhembi> jam: man, no; I branched your branch, and bent the symlink I use, and off I go
[21:05] <jam> guilhembi: right, so go into that dir and run "make"
[21:05] <jam> It should make annotate quite a bit faster
[21:06] <NfNitLoop> what's that compile to?  .pyc? or is it C/C++?
[21:06] <NfNitLoop> (sorry, eavesdropping)  : )
[21:06] <jam> NfNitLoop: there is some Pyrex code which compiles to C => .obj
[21:06] <NfNitLoop> Ah.
[21:06] <jam> Pyrex being an intermediate between Python and C, (such that it has types, and can be "compiled" to raw C code to be compiled)
[21:07] <NfNitLoop> Cool.
[21:07] <guilhembi> grmbl it's not mentioned in the INSTALL file, neither in "Run from source directory" in http://bazaar-vcs.org/InstallationFaq which is what I followed
[21:07] <NfNitLoop> See, I just hang out in here and learn through osmosis.  : )
[21:07] <jam> Though technically, the "diff" code is just plain C formatted to become a python extension. There are *other* things we do in pyrex extensions
[21:08] <jam> guilhembi: well, they aren't *needed* just recommended, but I'll update that page
[21:09] <guilhembi> jam: thanks; is "make" automatically done for people who use "python setup.py blah" ?
[21:09] <jam> guilhembi: The "Run from source directory" has a "% make" step
[21:09] <jam> guilhembi: yes
[21:09] <guilhembi> I'm trying to see how many colleagues would benefit from that...
[21:09] <guilhembi> jam: indeed, I'm really blind
[21:09] <guilhembi> jam: and now it's 20 secs for your bzr too.
[21:09] <guilhembi> So, the annotate outputs have 266 different lines...
[21:09] <jam> good to hear
[21:10] <jam> guilhembi: well, "bzr annotate foo" doesn't actually annotate the working copy either ... :(, unlike gannotate
[21:10] <mwhudson> morning
[21:10] <guilhembi> jam: you wanted me to annotate the working copy? I used the clean 6.0-ndb file.
[21:10] <jam> guilhembi: well, we are trying to figure out why we are seeing this conflict, right?
[21:11] <lifeless> jam: physio appointment
[21:11] <jam> if you want to take me through how *you* do it
[21:11] <lifeless> jam: though I'd love to go back to sleep, I can't
[21:11] <jam> that may be enlightening
[21:12] <jam> sorry to hear that lifeless, sleep afterwards then :)
[21:12] <jam> speaking of which, what are you doing up guilhem?
[21:13] <guilhembi> jam: it's only 22:14 here and I'm talking with a bzr dev to try to find out what's going on in a damn file merge
[21:13] <jam> silly man
[21:13] <guilhembi> yes
[21:14] <guilhembi> sure, I'll need to sleep, or waking up for kids' breakfast will be tough
[21:14] <guilhembi> jam: so, I have now gannotate ha_ndbcluster.cc, with your bzr, under the eyes.
[21:15] <guilhembi> let's look at a conflict which I prententiously claimed to be false...
[21:15] <guilhembi> line 9836
[21:17] <guilhembi> jam: I look and look again, but all lines in MERGE-SOURCE in conflict starting from line 9836,
[21:17] <guilhembi> are from revs <= sp1r-frazer@forth.ndb.mysql.com-20080320110539-62618
[21:18] <guilhembi> which is in 6.0-ndb already.
[21:19] <guilhembi> As MERGE-SOURCE is supposed to be what comes from 5.1-telco-6.2-merge and conflicts with 6.0-ndb text,
[21:19] <guilhembi> this is weird: all revs which form MERGE-SOURCE text have already been merged into 6.0-ndb.
[21:23] <jam> yeah, but if you are merging from different bases, it is still possible. I'll still try to look at it closer, I understand your confusion
[21:25] <guilhembi> jam: Ok. I verified again: I copy-pasted all revision ids from gannotate for this MERGE-SOURCE text, and ran "bzr log -r" for each of them in 6.0-ndb: they are all there.
[21:28] <jam> guilhembi: bzr log -r revid: will always display the revision
[21:28] <jam> whether it is merged or not
[21:28] <jam> It just has to exist in the repository, not in the branch
[21:29] <guilhembi> uh
[21:29] <jam> Though if it has a revno, then it would exist in the branch
[21:29] <guilhembi> jam: this behaviour of "bzr log -r" is probably confusing; "bzr help log" says
[21:30] <guilhembi> "  By default show the log of the branch containing the working directory."
[21:30] <jam> and in my check, the one you listed is in the ancestry
[21:30] <jam> the frazer@forth revision
[21:30] <guilhembi> I looked again, and it printed revnos for all revids.
[21:30] <jam> I'm a bit curious, though, why it would give that merge revision as the last modified, are you using my bzr or bzr.dev?
[21:31] <jam> my bzr shouldn't give the merge revision, unless it actually modified it
[21:32] <guilhembi> jam: actually (I just tested), asking for a revid which is in another branch than 6.0-ndb, when I am cd into 6.0-ndb, results in bzr: ERROR: exceptions.ValueError: list.index(x): x not in list
[21:32] <guilhembi> so it does not tell me about revs out of 6.0-ndb.
[21:32] <guilhembi> jam: I'm using your bzr
[21:32] <beuno> jam, specifying a revid that is not in the branch but is in the repo gived back a traceback. See bug #241998
[21:32] <guilhembi> and I'm using gannotate.
[21:32] <beuno> s/gived/gives
[21:32] <beuno> exactly  :)
[21:33] <beuno> I tested it on bzr.dev
[21:37] <jam> guilhembi: one other interesting thing to try, is to use "-Dmerge" with "bzr remerge"
[21:38] <jam> It should output a "filename.ext.plan" file
[21:38] <jam> Which should hint as to how it arrived at its decision
[21:39] <guilhembi> jam: bzr remerge -Dmerge?
[21:39] <jam> guilhembi: bzr remerge --weave -Dmerge sql/ha_ndbcluster.cc
[21:39] <jam> is what I would use
[21:40] <guilhembi> jam: that would be interesting... but what if I left it to you? You may read the plan more easily than me, maybe spot a weirdness?
[21:41] <jam> guilhembi: well, what I'm seeing is some lines in "killed base" and then them showing back up again as "new-b".
[21:41] <jam> Which means that in one of the common ancestors, the lines were changed
[21:41] <jam> and presumably in the others they are still there
[21:41] <jam> I'll try to draw a quick graph of what I think happened
[21:43] <guilhembi> jam: I think this may be a rabbit hole; I still have trouble understanding how the principle that: "if it has been merged already, it should not be a conflict", can fall short. You might be able to convince me that it's false, but for the entire Engineering group of MySQL, there would be work...
[21:44] <jam> guilhembi: I'm guessing it is a discrepancy between the merge algorithm's annotations and how 'annotate' might do it.
[21:46] <jam> As near as I can tell, the lines in question are considered "obsolete" by the time we get to the common ancestors
[21:46] <jam> but then 5.1-merge introduces them again anyway
[21:48] <jam> guilhembi: do you have these in BK that you could do the merge and compare, or is the current stuff only bzr?
[21:48] <guilhembi> jam: the chance that people messed lines around, committed, put them bacl, committed, is low.
[22:26] <pygi> folks, postgresql migrated to bzr, right?
[22:27] <pygi> or was it mysql?
[22:27] <Pieter> 'mysql
[22:27] <Pieter> postregsql is in git afaik
[22:28] <Pieter> or not
[22:29] <mwhudson> i think it might still be in cvs or something crazy...
[22:31] <jam> last I checked postgres was still in cvs, and it is mysql that moved to bzr
[22:33] <beuno> mornin' mwhudson
[22:33] <mwhudson> beuno: http://bazaar.launchpad.net/~bzr/bzr/trunk/files <- paste, zpt-templating, etc :)
[22:34] <mwhudson> (not streaming though)
[22:36] <beuno> mwhudson, very cool!  how's the server load?
[22:37] <mwhudson> ok so far i think
[22:37] <mwhudson> LH is also now running on a different machine from all the other codehosting stuff
[22:38] <beuno> ah, so it's harder to compare
[22:38] <beuno> yay!  nicer urls!
[22:38] <mwhudson> oh yeah!
[22:38] <mwhudson> that too
[22:38] <jam> mwhudson: well, right now it is taking a while to load :)
[22:39] <mwhudson> jam: which page?
[22:39] <jam> mwhudson: the one you linked
[22:39] <jam> once it came up, then it was reasonable the next access
[22:39] <mwhudson> hmm
[22:40] <jam> it could be dns on my end, I don't really know
[22:40] <jam> anyway /away for about an hour
[22:41] <pygi> jam, saw the mail from Packt about bzr book? :P
[22:41] <pygi> ups, you went away xD
[22:42] <beuno> mwhudson, you cerry-picked from trunk, right?  The order for dirs is still off
[22:42] <mwhudson> beuno: no, it's just trunk @ some rev
[22:43] <mwhudson> a few off tip
[22:43] <beuno> mwhudson, I get timeout at: http://bazaar.launchpad.net/~bzr/bzr/trunk/revision/3510
[22:43] <mwhudson> beuno: just after the wsgi merge
[22:44] <mwhudson> beuno: hmm
[22:44] <mwhudson> beuno: that's a big old diff i expect
[22:44] <beuno> I think it's like 20 big diffs  :p
[22:44]  * thumper pats lifeless on the back
[22:44] <thumper> I like looms
[22:45] <thumper> more and more
[22:45] <beuno> mwhudson, this revno makes a good case for my ajax branch  :)
[22:46] <beuno> it will load the page
[22:46] <beuno> and let you see each diff individually
[22:46] <mwhudson> it also makes the case for my streaming branch i expect :)
[22:47] <beuno> heh, yeah, that would be neat to see in production
[22:50] <LarstiQ> beuno: can I see that ajax branch in action somewhere?
[22:51] <beuno> LarstiQ, yeap, let me load it up on my machine
[22:51]  * LarstiQ wants to show it to someone
[22:54] <beuno> LarstiQ, http://intranet.pentacorp.net:8080/bazaar/bzr_garbage/revision/3469
[22:58] <bkor> elmo: was the ldif enough for now?
[22:59] <elmo> bkor: I think so, yeah, lamont should have set up/be setting up accounts
[22:59] <bkor> elmo: good, as I think the port opening will take a while
[22:59] <LarstiQ> beuno: thanks
[22:59] <elmo> bkor: ok
[23:00] <LarstiQ> beuno: I can't collapse the diffs?
[23:04] <beuno> LarstiQ, the UI needs some serious love, yes
[23:05] <beuno> I also need to merge that with trunk, since it's using old code
[23:05] <beuno> and, well, there's a shiny new theme on the way
[23:05] <beuno> so that will change everything. Again.
[23:06] <Pieter> it'd be nice if bzr diff had an option to ignore whitespace differences
[23:07] <beuno> Pieter, file a bug  :)
[23:08] <Pieter> yeah I guess, but I hate bugtrackers
[23:09] <mwhudson> diff --using 'diff -b'
[23:09] <mwhudson> ?
[23:09] <Pieter> yeah, but who's going to type that?
[23:10] <mwhudson> bzr alias diffws='diff --using "diff -b"'
[23:10] <mwhudson> ?
[23:10] <mwhudson> if that's too much, then there's no hope for you :)
[23:11] <Pieter> I don't like having to create aliases and installing plugins to get basic functionality :)
[23:12] <fullermd> Heck with whitespace, I just wish it said something sensible about binary files   :p
[23:13] <vila> Pieter: 'bzr help alias' no plugin needed
[23:14] <Pieter> that's not what I meant
[23:14] <LarstiQ> Pieter: but obviously it's not basic functionality ;P
[23:15] <LarstiQ> Pieter: I'm interested though, when do you find it useful?
[23:15] <LarstiQ> Pieter: and offtopic, are you going to Parkpop?
[23:15] <vila> You asked for an option, mwhudson gave you an option, you didn't want to type the option, he offered the alias, you said no plugin nor alias, I said no plugin. But, ok, bzr can't do what you want.
[23:16] <vila> g'night all
[23:16] <LarstiQ> vila: night!
[23:16] <Pieter> LarstiQ: if you have a python script that you changed to a class, so everything gets indented
[23:16] <beuno> mwhudson, btw, do you know why this would be happening: http://bzr-mirror.gnome.org:8080/alleyoop/trunk/changes ?
[23:16] <beuno> night vila
[23:16] <LarstiQ> Pieter: aaah, good point
[23:16] <Pieter> if you then want to diff it against eg the same file on another branch, you need something that ignores whitespace
[23:17] <LarstiQ> Pieter: wouldn't you want to ignore just uniform indent changes?
[23:17] <LarstiQ> for that specific case
[23:17] <mwhudson> beuno: looks like url generation is fuxored :(
[23:17] <Pieter> sure, anything that works :)
[23:17] <Pieter> LarstiQ: and I'm not going to parkpop :)
[23:17] <LarstiQ> Pieter: awww
[23:18] <LarstiQ> Pieter: ok, I agree that ignoring something there certainly has merit
[23:18] <beuno> mwhudson, yeah, I don't understand why. It's trunk + search, but he tried trunk alone, and same thing happened. I can't reproduce it locally
[23:18] <LarstiQ> Pieter: I'm not sure if python specific should be in core, but ignoring all whitespace could be
[23:19] <mwhudson> beuno: do you know if he's using a vanilla serve-branches.py ?
[23:19] <mwhudson> Jc2k: still awake?
[23:20] <beuno> mwhudson, yeap, untouched
[23:20] <Jc2k> hi guys
[23:20] <Jc2k> i considered patching serve-branches, but yeah, its a bit different to twisted.web2 :)
[23:21] <Jc2k> i'm around if you want me to do stuff, i just have to hit the pro Git guy on pgo over the head
[23:21] <mwhudson> Jc2k: hmm?
[23:22] <Jc2k> mwhudson: i was hoping i could add something to serve-branches to serve /static/ of the root to get things going until there was a proper fix, but its not twisted.web2 so i dont know where to poke so i left it :P
[23:23] <beuno> it should be serving /static/ from root
[23:23] <beuno> that's the default behaviour
[23:24] <mwhudson> the links to static things are all //staic
[23:25] <mwhudson> which i guess is the problem?
[23:26] <beuno> mwhudson, what's more interesting is that /static is served from: http://bzr-mirror.gnome.org:8080/epiphany/trunk/static/javascript/collapse.js
[23:27] <beuno> so it's not at the root
[23:27] <mwhudson> beuno: it's served from both places
[23:27] <mwhudson> or at least, it should be
[23:27] <beuno> mwhudson, doesn't seem to: http://bzr-mirror.gnome.org:8080/static/javascript/collapse.js
[23:28] <jam> beuno: there is that bzr_garbage again... you make me :'(
[23:28] <mwhudson> Jc2k: what versions of paste and paste-deploy do you have?
[23:28] <Jc2k> mwhudson: 1s
[23:28] <Jc2k> mwhudson: 1.0.1
[23:29] <mwhudson> Jc2k: oh er ah
[23:29] <mwhudson> Jc2k: that's paste-deploy, right?
[23:29] <Jc2k> oh
[23:29] <mwhudson> if it's paste, i'm amazed anything works at all :)
[23:29] <mwhudson> Jc2k: can you try commenting out the stuff to do with PrefixMiddleware in serve-branches.py ?
[23:30] <Jc2k> from dpkg -l
[23:30] <Jc2k> ii  python-paste               1.0.1-1                                  Tools for using a Web Server Gateway Interfa
[23:30] <Jc2k> ii  python-pastedeploy         1.0-1                                    Load, configure, and compose WSGI applicatio
[23:30] <mwhudson> holy crap
[23:30] <mwhudson> what os are you running?  etch?
[23:30] <Jc2k> etch :)
[23:31] <mwhudson> well, try commenting out the PrefixMiddleware stuff
[23:31] <beuno> jam, hahaha, it's an old branch  :p
[23:32] <beuno> there, killed the branch
[23:32] <Jc2k> mwhudson: http://bzr-mirror.gnome.org:8080/conduit/trunk/changes :)
[23:33] <jam> beuno: thanks :)
[23:33] <jam> beuno: you could call it "bzr_no_more_tears" if you prefer
[23:33] <beuno> Jc2k, cool. Search even works!
[23:33] <mwhudson> Jc2k: that looks better
[23:33] <mwhudson> dependencies suck donkey balls
[23:33] <beuno> jam, muahahaha, I'll grep my LH and do it!
[23:33] <cj> hurm...  '$ bzr branch lp:mysql-server' failed halfway through and now I can't 'bzr up' from the directory, and trying to re-run the branch command tells me:
[23:33] <cj> bzr: ERROR: Target directory "mysql-server" already exists.
[23:34] <jam> also, my fingers keep wanting to type bueno, what's up with your name? :)
[23:34] <cj> I'm new here... can someone LART me?
[23:34] <LarstiQ> jam: be-uno? :)
[23:34] <beuno> jam, why would you want to type a full nickname?
[23:34] <LarstiQ> not kinderbueno
[23:34] <beuno> lol
[23:34] <mwhudson> cj: can you cd into the branch and 'bzr pull' ?
[23:34] <jam> beuno: because I start typing "bu^T" and it never works
[23:35] <beuno> LarstiQ, I see you've been present in one of the conversations of me trying to explain my nickname
[23:35] <LarstiQ> beuno: I haven't actually
[23:35] <jam> but.. that is mixed languages :)
[23:35] <jam> At least if you just said it is a fixed typo of bueno, *that* I could understand
[23:35] <beuno> LarstiQ, then that's a pretty good observation
[23:36] <LarstiQ> beuno: I did ask you in London wether 'be-uno' was a correct way to pronounce it.
[23:36] <beuno> jam, the explanation is pretty stupid, so I'm going to defer that until the next time I see you and there is enough beer  :)
[23:36] <LarstiQ> so that helped in my confidence :)
[23:36] <jam> beuno: Well I'm as close to seeing you as I can now, and there is a reasonable amount of beers in the fridge, and the grocery store is 2 blocks away. I can't do much better than that :)
[23:36] <beuno> lifeless, http://bzr-mirror.gnome.org:8080/conduit/trunk/changes    LH + search + Gnome theme in action!
[23:37] <beuno> hmm, beer...
[23:37] <beuno> I should really have a fridge in the office
[23:37] <jam> beuno: well, following the "svn" link looks pretty bad: http://svn.gnome.org/
[23:37] <jam> And the font sizes keep changing
[23:37] <jam> but otherwise sexy
[23:38] <jam> beuno: of course, if you do something like search on conversion_exists, i would sort of expect the revisions to come back in more of a sorted order: http://bzr-mirror.gnome.org:8080/conduit/trunk/changes?q=conversion_exists
[23:38] <beuno> jam, yeah. New theme is 90% complete, so I should be able to wedge that in before Guadec
[23:38] <jam> 717, 87, 79, 111, 160, ...
[23:39] <beuno> jam, blame lifeless  :)
[23:39] <jam> I've blamed him for too much already
[23:39] <jam> he reached his quota for this week
[23:39] <beuno> well, I suppose we can blame Jc2k, since it's on his server
[23:40] <beuno> damn, font sizes do vary a lot
[23:42] <Jc2k> beuno: O: ) i think the list of repos/branches being unskinned is the only thing stopping me doing a "OMG Bazaar/Loggerhead FTW" post
[23:43] <beuno> Jc2k, that puts quite some pressure on me...  :p
[23:43] <Jc2k> :D
[23:43] <beuno> I'll get to that after I wrap up what I'm supposed to be doing now then
[23:44] <Jc2k> :D
[23:44] <Peng> jelmer: bzr-svn is currently tracebacking with bzr.dev because it can't import bzrlib.knit.make_file_knit.
[23:51] <mwhudson> prettier directory listings really shouldn't be hard
[23:53] <beuno> mwhudson, nah, I'll get that done today for sure
[23:53] <beuno> I also what to see if I can improve the font weirdness
[23:53] <beuno> seems both CSS files are clashing
[23:53] <mwhudson> beuno: cool
[23:57] <blueyed> I have a mainline dev branch.. a derived main.local branch with changes needed for local development and now a feature branch derived from main.local - how do I get only the feature into the main dev branch?