[00:00] <rick_h_> is htat a differnet plugin?
[00:00] <LarstiQ> rick_h_: no, that's in bzr-dbus
[00:01] <igc> morning
[00:02] <lifeless> LarstiQ: sydney
[00:02] <lifeless> LarstiQ: http://www.slug.org.au/node/102
[00:02] <lifeless> LarstiQ: not my graphs. ask Pilky
[00:03] <lifeless> awmcclain_: uhm, jam: ^ awmcclain_ wants g+w branches ? I don't remember the voodoo
[00:03] <lifeless> Pieter: hi, interesting
[00:03] <Pilky> lifeless: did you see what I said earlier to jam, turns out that the 1.3-1.5 results must've been done on my iMac not my MacBook (which really confuses me)
[00:03] <lifeless> Pilky: no, I didn't
[00:03] <lifeless> my adsl went offline overnight
[00:03] <Pilky> ah
[00:04] <rick_h_> LarstiQ: where are you getting a bzr-dbus README?
[00:04] <rick_h_> the only files I have are here:http://bazaar.launchpad.net/~jamesh/bzr-avahi/devel/files
[00:05] <lifeless> rick_h_: thats bzr-avahi :)
[00:05] <Pilky> I thought I'd done all the benchmarks on my MacBook as I remember taking it back to 1.3 to test the speed, but the results I did from 1.3 today don't match up
[00:05] <lifeless> Pieter: can you ls . and .. and also do bzr info?
[00:05] <rick_h_> right, what I'm saying. The error seems dbus related which is why I asked if that was a seperate plugin
[00:06] <Pieter> lifeless: http://pastie.org/223007
[00:06] <LarstiQ> lifeless: cool
[00:07] <rick_h_> ok, checked out the bzr dbus plugin, but now I have two plugins that don't load
[00:07] <lifeless> rick_h_: :X
[00:07] <lifeless> rick_h_: can you pastebin the error from ~/.bzr.log please
[00:08] <LarstiQ> rick_h_: ah sorry, I read 'python-dbus' as 'bzr-dbus', sorry :/
[00:08] <rick_h_> lifeless: http://paste2.org/p/42752
[00:09] <rick_h_> I'm tring to use this to get bzr avahi http://blogs.gnome.org/jamesh/2008/02/19/bzr-avahi/
[00:10] <rick_h_> it looks like it's saying no module named dbus, but "python-dbus is already the newest version."
[00:11] <lifeless> Pieter: ah
[00:11] <lifeless> Pieter: what is pwd?
[00:11] <LarstiQ> rick_h_: ok, now that you have bzr-dbus, did you follow the instructions in the bzr-dbus README?
[00:11] <Pieter> lifeless: /Users/pieter/m/bzr/working
[00:11] <lifeless> LarstiQ: this:
[00:12] <lifeless> File "/home/rharding/.bazaar/plugins/bzr_dbus/activity.py", line 31, in <module>
[00:12] <lifeless> LarstiQ: should give you an answer
[00:12] <rick_h_> ah, ok...working on it. This seems like a pita
[00:15] <lifeless> rick_h_: you should name the bzr_dbus dirctory 'dbus' in ~/.bazaar/plugins
[00:15] <LarstiQ> lifeless: doh
[00:15]  * LarstiQ hangs his head in shame.
[00:15] <lifeless> LarstiQ: ah you see it now?
[00:16] <LarstiQ> lifeless: the non python symbol naming of the plugin? yeah
[00:17]  * LarstiQ was too focused on the org.thingy
[00:19] <rick_h_> crap, that broke everything now
[00:20] <rick_h_> ok, now I'm getting AttributeError: 'BranchHooks' object has no attribute 'install_named_hook'
[00:21] <LarstiQ> I think, some code may have bitrotted a bit.
[00:23] <beuno> mwhudson, got a minute?   I'm can't decide on how to approach something in the new theme
[00:23] <mwhudson> beuno: not really, but let's hear it
[00:24] <lifeless> Pieter: some lag here sorry; on the phone
[00:24] <lifeless> rick_h_: thats a version issue; what bzr version do you have ?
[00:25] <rick_h_> 1.3.1-1ubuntu0.1
[00:25] <beuno> mwhudson, heh, well, here goes.  For the diffs, now, as opposed to the current theme, it fits the screen and wraps lines. So we don't have a horizontal scrollbar pushing everything away. This is a problem when long lines of codes don't have spaces to wrap over, because the texts gets hidden under the next div.
[00:26] <beuno> that leaves me two roads
[00:26] <beuno> a) add an html tag that will allow me to wrap on some characters like /
[00:26] <mwhudson> oh, because the diffs have spaces replaced with &nbsp; right?
[00:26] <beuno> b) don't do this anymore, and push everythign off-screen
[00:26] <mwhudson> is there a concept of "space that doesn't collapse but still wraps" ?
[00:27] <beuno> mwhudson, no, no &nbsp; anymore. They make files too big. I'm using <pre>
[00:27] <mwhudson> i think in the spirit of "not trying to fix everything at once", i favour (b)
[00:27] <mwhudson> beuno: oh
[00:28] <beuno> the problem is with lines like: &lt;p class="expand"&gt;&lt;a href="#"&gt;&lt;img tal:attributes="src python:branch.static_url('/static/images/treeCollapsed.png')"
[00:28] <beuno> no spaces
[00:28] <mwhudson> mm
[00:28] <beuno> I can force wraping by adding a tag after each /
[00:28] <beuno> which would solve it
[00:28] <mwhudson> <wbr/> or whatever?
[00:28] <beuno> less work, should look better then off-screen pusing
[00:28] <beuno> exactly
[00:28] <mwhudson> well, but that's a total hack though
[00:29] <mwhudson> what if the long text was long_package_name.long_module_name.long_function_name?
[00:29] <beuno> right. CSS3 has a fix for this, but we can't use that for few years  :)
[00:29] <lifeless> mwhudson: so, whats needed to merge bzr-search-integration to lh trunk?
[00:29] <mwhudson> lifeless: me not having two critical issues to fix today
[00:29] <beuno> mwhudson, well, we can pick a few characters,  / \ _ .
[00:29] <lifeless> mwhudson: what issues?
[00:30] <beuno> lifeless, and, I need to make it less invasive if search isn't installed  (ie, not show the div if no results)
[00:30] <mwhudson> lifeless: codebrowse using too many file descriptors and the ssh server performance problem
[00:30] <lifeless> beuno: I don't think the div is such a big issue :P but you're the dev
[00:30] <lifeless> mwhudson: ooh, fd leakage?
[00:31] <mwhudson> lifeless: well, not strictly leakage
[00:31] <beuno> mwhudson, b) takes longer because I have to re-structure everything
[00:31] <beuno> a) makes the file a bit bigger, which is a but sucky
[00:31] <mwhudson> lifeless: loggerhead currently keeps a branch object around for every branch it has ever seen
[00:31] <beuno> but I did remove all those &nbsp;, so we still win
[00:32] <mwhudson> lifeless: when you're accessing branches over http, this keeps a connection open
[00:32] <mwhudson> lifeless: so, once enough branches have been browsed, you bump into limits
[00:33] <mwhudson> beuno: it sounds like you're arguing for (a)
[00:33] <beuno> mwhudson, I can also add <wbr/> after X characters, which would probably take up less space. On the other hand, it may wrap in less-then-optimal places
[00:33] <beuno> mwhudson, yes, I like a) right now
[00:33] <mwhudson> beuno: the general assumption is that it's source code
[00:34] <mwhudson> beuno: so the whole idea of wrapping it is a bit goofy anyway
[00:34] <mwhudson> beuno: so i really wouldn't worry about trying to be too perfect here
[00:35] <beuno> right, I agree from that point of view. On the other hand, a side-by-side view that goes off-screen isn't useful at all
[00:35] <beuno> ok, so after X characters it is  :)
[00:35] <Verterok> lifeless: is there any chance that you can install eclipse-3.3?
[00:35] <awilkins> Verterok: Darn, SaveableCompareEditorInput is 3.3 specific
[00:36] <lifeless> Verterok: are there packages?
[00:36] <lifeless> Verterok: hardy is the most recent release...
[00:36] <Verterok> lifeless: I don't think so :(
[00:36] <beuno> mwhudson, that's the last big item on my list, so it should be reviewable on monday. Along with search branch, once lifeless makes it work with bzr.dev
[00:36] <awilkins> There's no hardy package newer than 3.2 (not in official package repos anyway)
[00:37] <Verterok> awilkins: yes, do you depends on 3.2?
[00:37] <awilkins> Verterok: Is there an older choice for SaveableCompareEditorInput?
[00:37] <Verterok> awilkins: write it by hand :(
[00:37] <awilkins> Verterok: Alas, yes, the release of the UML modeller we use is 3.2 specific.
[00:37]  * mwhudson has to go away for a bit
[00:37] <beuno> mwhudson, thanks for the input
[00:38] <awilkins> Verterok: I may just clip it out, I've been using Beyond Compare for merge editing
[00:38] <Verterok> awilkins: I can make a ugly but temporal solution of copy/paste the implementation
[00:38] <lifeless> beuno: search with bzr.dev is orthogonal to merging to loggerhead
[00:38] <lifeless> beuno: because most folk will have 1.5 or 1.6b2 of bzr
[00:38] <beuno> lifeless, not if I'm trying to find ways to buy time
[00:38] <lifeless> beuno: pfft
[00:39] <beuno> :)
[00:39] <beuno> and it breaks everything I have indexed
[00:39]  * awilkins opens Eurpoa
[00:39] <awilkins> *Europa
[00:39] <Verterok> awilkins: Ok, if you need the compare feature, I can try to make it a separate plugin
[00:39] <beuno> but I suppose I can revert...
[00:40] <Verterok> awilkins: s/need/not need/
=== edcrypt_ is now known as edcrypt
[00:41] <Verterok> lifeless: "installing" eclipse-3.3 it's just unzip it in some place
[00:41] <awilkins> Verterok: Our comparing is nasty because all the documentation is smunged onto a single line by the tool ; I have an external converter than unpacks it to an HtmlTidy-ed CDATA span and then repacks it after editing
[00:42] <awilkins> Verterok: Plus the modeller drops dead on files with conflict markers because they aren't valid XML ; so I'm making my users edit conflicts outside the IDE at the moment
[00:43] <lifeless> Verterok: really? ok I'll look for it then
[00:44] <lifeless> Verterok: why doesn't http://bazaar-vcs.org/BzrEclipse say 3.3 and where to get it ?
[00:44] <Verterok> lifeless: the current published plugin is 3.2 compatibly
[00:44] <Verterok> compatible
[00:44] <Verterok> but the trunk isn't any more
[00:45] <Verterok> as awilkins said, it's caused by the compare editor
[00:46] <Verterok> lifeless: so if you download the "official" plugin, it still works with 3.2
[00:46] <Verterok> lifeless: http://mirror.calvin.edu/eclipse/downloads/drops/R-3.3.1.1-200710231652/index.php
[00:47] <Verterok> it's a mirror of the 3.3 download page
[00:47] <Verterok> yesterday, the eclipse folks released 3.4
[00:47] <Verterok> so, 3.3 download page is gone :P
[00:50] <awilkins> Verterok: Ouch, if you start dropping it it cascades at least as far as the commit dialog... which I obviously can't do without.
[00:51] <Verterok> awilkins: the commit dialog too? mmm...that's odd. what is the dependency?
[00:51] <awilkins> It sets up a diff action
[00:52] <awilkins> Line 400 : DiffOperation.openDialog
[00:53] <awilkins> DiffOperation uses SaveableBazaarCompareEditorInput
[00:54] <Verterok> awilkins: I think we can put that in an interface, and create a extension point for it, toughts?.
[00:55] <awilkins> That seems fair ; what does it use for 3.2?
[00:55] <awilkins> I don't think it's a saveable one, but I remember a diff view
[00:55] <Verterok> awilkins: SyncInfoCompareEditor
[00:57] <Verterok> awilkins: it's hack and a bit ugly compare editor, but it works :P
[00:58] <lifeless> argh
[00:58] <lifeless> http://mirror.calvin.edu/eclipse/downloads/drops/R-3.3.1.1-200710231652/download.php?dropFile=eclipse-SDK-3.3.1.1-linux-gtk-x86_64.tar.gz is not the download
[00:58] <lifeless> its actually a page about the download. garh garh
[00:59] <lifeless> Verterok: how do I find out if I have a 64 bit vm ?
[00:59] <Verterok> lifeless: give me a min. I'll come back with the direct link :)
[00:59] <lifeless> Verterok: I've found it
[00:59] <lifeless> Verterok: but I need to know if I have a 32bit for 64 bit vm
[00:59] <Verterok> ok
[01:00] <Verterok> lifeless: output of 'java -version' ?
[01:02] <lifeless> rick_h_: sorry for going silent
[01:02] <lifeless> rick_h_: bzr 1.4 has that function
[01:02] <lifeless> Verterok: thanks
[01:02] <rick_h_> lifeless: ah, ok. So is there some method I should use to pull plugins for the hardy versoin?
[01:03] <rick_h_> or am I fubar'd unless I update bzr to 1.4?
[01:03] <lifeless> rick_h_: 'apt-get install' is the usual one :)
[01:03] <lifeless> rick_h_: some plugins have version specific branches; I don't know if bzr-avahi does
[01:03] <lifeless> jamesh: ^
[01:03] <rick_h_> ok, is there a ppa for bzr I can pull 1.4 with?
[01:03] <lifeless> markh: did you end up chatting to zou_ about installer builds?
[01:03] <lifeless> rick_h_: http://bazaar-vcs.org/Download
[01:04] <markh> hi lifeless - not sure who zou_ is :)  I've chatted with Alexander who made the last oens
[01:04] <markh> I've got a nice new binary build here too, that include the little of tortoise that works
[01:04] <lifeless> markh: zou_ is a gnash developer, they just switched to bzr
[01:04] <lifeless> markh: release it!
[01:05] <markh> yeah, I'm literally finishing it now :)
[01:06] <markh> so - dumb user question: I've a branch of dvr.dev with a few changes that I'd like to public (ie, not quite ready to propose for merging).  What is the best way to do that?  What would happen if I tried to publish the branch to Launchpad - would it try and upload the *entire* branch?
[01:06] <markh> bzr.dev obviously :)
[01:06] <lifeless> markh: well, stacking hasn't landed yet, so yes, yes it will
[01:06] <markh> so just put a bundle up on some server for people to grab?
[01:07] <lifeless> normally we'd just upload the branch
[01:07] <markh> oh - fair enough then - I'll do that!
[01:16] <awilkins> Verterok: Should the diff use the merge viewer attached to the org.eclipse.compare.contentMergeViewers extension point?
[01:16] <Verterok> lifeless: another thing, you need the xmlrpc branch of xmloutput plugin
[01:18] <Verterok> awilkins: I don't fully understand the question, as I remember bzr-eclipse don't  use rg.eclipse.compare.contentMergeViewers extension point
[01:18]  * Verterok checks
[01:18] <lifeless> Verterok: eclipse is nearly downloaded
[01:18] <lifeless> Verterok: what next
[01:19] <Verterok> lifeless: install xmloutput plugin, but not the trunk, the xmlrpc branch
[01:19] <awilkins> It doesn't use it, but my question is, should it be just getting the merge viewer from the platform which knows which viewer goes with which kind of file, rather than using the same one all the time.
[01:19] <Verterok> lifeless: https://code.launchpad.net/~guillo.gonzo/bzr-xmloutput/xmlrpc
[01:20] <awilkins> Since there is an extension point for defining which viewer is used (and it's in 3.2 --- 3.4 at least), this may resolve the version-compatibility issue and also make it more flexible (since it should use the best available viewer for a given filetype)
[01:21] <Verterok> awilkins: ahh, now I get it, thanks :). yes the comapre editor don't do the content comaprsion/merge, they delegate to the platform
[01:21] <lifeless> Verterok: should it be called xmloutput or xmlrpc in ~/.bazar/plugins?
[01:21] <Verterok> lifeless: gooood question :D xmloutput
[01:23] <Verterok> lifeless: once eclipse is up and running, follow the steps in http://bazaar-vcs.org/BzrEclipse/Installation until step 6
[01:24] <Verterok> lifeless: the url of the update-site should be replaced with: http://guille.beuno.com.ar/bzr-eclipse/bzr-search-site/
[01:25] <Verterok> awilkins: do you have a link to that extension point?
[01:25] <awilkins> http://help.eclipse.org/stable/topic/org.eclipse.platform.doc.isv/reference/extension-points/org_eclipse_compare_contentMergeViewers.html
[01:25] <Verterok> thanks
[01:26] <lifeless> wow, the plugin has lots of history/content :P
[01:28] <Verterok> lifeless: xmloutput or bzr-eclipse?
[01:28] <lifeless> xmloutput
[01:28] <lifeless> took ages to branch
[01:29] <lifeless> 380K
[01:29] <lifeless> something freaky going on here
[01:30] <Verterok> that's a lot
[01:30] <lifeless> Verterok: oh
[01:30] <lifeless> Verterok: upgrade your branch dammit
[01:30]  * Verterok check his xmloutput branch
[01:32] <lifeless> bzr info https://code.launchpad.net/~guillo.gonzo/bzr-xmloutput/xmlrpc
[01:32] <lifeless> Standalone branch (format: dirstate or knit)
[01:33] <lifeless> you want 'bzr upgrade sftp://bazaar.launchpad.net/~guillo.gonzo/bzr-xmloutput/xmlrpc'
[01:33] <Verterok> indeed, doing it ATM. thanks!
[01:35] <lifeless> Verterok: so, the tarball I downloaded
[01:35] <lifeless> has an eclipse dir
[01:35] <lifeless> oh, it fails, its good now
[01:36] <Verterok> lifeless: it should have a eclipse executable inside
[01:36] <lifeless> europa
[01:38] <StyXman> hi all
[01:38] <Verterok> lifeless: hardy comes with the java vm from sun or the gcj?
[01:38] <Verterok> StyXman: hi
[01:38] <StyXman> how can I do a bzr diff while editing the message for bzr ci? it tells me it can't lock...
[01:39] <lifeless> Verterok: typo: 'Remainin portions'
[01:39] <beuno> StyXman, bzr ci --show-diff?
[01:39] <lifeless> StyXman: currently you can't, but as beuno says
[01:39] <StyXman> beuno: wonderful
[01:39]  * beuno curses simpletal
[01:39] <Verterok> lifeless: in the install guide?
[01:40] <lifeless> in the licence
[01:41] <Verterok> thanks, fixed
[01:41] <lifeless> unterminated entity ref ...StringReader@6c618821)
[01:41] <lifeless> ^ what does that mean
[01:42] <Verterok> ups, xmloutput not working?
[01:42] <lifeless> when I click ok after setting the bzr executale to use
[01:43] <Verterok> when you choose ok, it tries to execute 'bzr xmlplugins'
[01:43] <Verterok> I missed to check if the output is actually xml
[01:44] <lifeless>  just ran that in concole
[01:44] <lifeless> it did not error
[01:44] <lifeless> however
[01:44] <lifeless> I have plugins that include " in their strings
[01:45] <Verterok> I'm using the same version here, let me check
[01:45] <lifeless> and it doesn't seem to be using CDATA
[01:45] <lifeless> bzr xmlplugins | xmllint -
[01:45] <lifeless> -:127: parser error : xmlParseEntityRef: no name
[01:45] <lifeless>    lan-notify &``. ``lan-notify`` is very useful in local LAN collaboration to
[01:45] <lifeless>                ^
[01:46] <lifeless> back in a little, moar caffeine needed
[01:46] <Verterok> mm...so I should use CDATA for the description
[01:47] <lifeless> Pieter: ping, when you can, I'm interested in 'pwd' from the checkout please
[01:47] <lifeless> Verterok: well
[01:47] <StyXman> moar coffee indeed :)
[01:47] <Pieter> lifeless: I already pasted that :)
[01:47] <Pieter> lifeless: /Users/pieter/m/bzr/working
[01:47] <lifeless> Verterok: its not escaping everything properly; either escape or CDATA
[01:47] <lifeless> Pieter: sorry, ETHREADLIMIT :)
[01:47] <lifeless> Pieter: oh! I know
[01:48] <lifeless> Pieter: 'merge URL' and 'switch BRANCH' dont, unfortunately, share a lookup function
[01:48] <lifeless> Pieter: I did the switch logic too see how people would like it; they seem to :)
[01:48] <Pieter> ah.. this is a bit unexpected behaviour though ;)
[01:48] <StyXman> ktxbye
[01:48] <lifeless> Pieter: so 'merge 5.1' found '.' as the branch to merge from
[01:48] <lifeless> Pieter: Totally, I'm filing a bug
[01:48] <Verterok> lifeless: y'r absolutely right...
[01:49] <Verterok> applying bzrlib.xml_serializer._escape_cdata
[01:50] <lifeless> Verterok: I know I am :)
[01:50] <Verterok> :)
[01:52] <Verterok> lifeless: pushed to lp (and the branch is upgraded)
[01:53] <lifeless> I'll repull for kicks
[01:54] <lifeless> igc: something you might find fun to do; write a 'bitch about knits' patch, like the current 'bitch about weaves' one.
[01:54] <lifeless> Verterok: 25 seconds
[01:54] <lifeless> Verterok: vs minutes
[01:54] <Verterok> lifeless: nice! :D
[01:54] <lifeless> Verterok: now I get
[01:54] <lifeless> XMLRPC based client is not available
[01:54] <awilkins> moar caffeine : Mother Of All Roasts
[01:55] <lifeless> Verterok: its lint clean now though which is better :)
[01:55] <lifeless> oh caffeine. be right back
[01:55] <lifeless> Pieter: and please, get a callgrind file on _anything_ that is slow (after checking here that its not just a case of asking bzr to do lots)
[01:55] <igc> lifeless: as in grumble if people aren't running with packs?
[01:55] <Verterok> lifeless: let me think but in the meantime just for the sake of try, restart eclipse :P
[01:56] <lifeless> Pieter: your slow switch or merge _should_ be faster, its definitely worth gathering data on
[01:56] <lifeless> igc: yes, packs or something better
[01:56] <lifeless> igc: which is why just grumble on knits:)
[01:56] <igc> :-)
[01:57]  * fullermd looks at all his knit branches...
[01:57] <lifeless> Verterok: I restarted
[01:57] <lifeless> XMLRPC based client is not available
[01:57] <lifeless> back soon
[02:06] <lifeless> back
[02:06]  * Verterok just found a bug...in the xmlrpc java client
[02:06] <Verterok> lifeless: a new build in tic
[02:06] <lifeless> :P
[02:06] <lifeless> cool
[02:06] <lifeless> don't you love new users
[02:07]  * Verterok have a headless build...so sit and relax
[02:07] <lifeless> Pieter: bug 243386
[02:07] <ubottu> Launchpad bug 243386 in bzr "url lookups should be able to use the same heuristic switch does" [Undecided,New] https://launchpad.net/bugs/243386
[02:07] <Verterok> lifeless: absolutely :D
[02:14] <thumper> hey guys
[02:14] <thumper> how many windows users do we have here?
[02:14] <thumper> just raise hands
[02:14]  * markh ducks
[02:16] <thumper> feel free to point at windows users
[02:17] <lifeless> jam
[02:17] <lifeless> markh
[02:17] <lifeless> zou_ who is in #gnash
[02:20]  * Verterok thinks that bzr-eclipse need more users....and bug reports
[02:21] <Verterok> lifeless: new build uploaded to the update site
[02:21] <Verterok> lifeless: Help --> software updates --> find and install --> search for new features to install
[02:22] <Verterok> similar to the install, and avoid the check for updates of all plugins
[02:23] <lifeless> still says
[02:23] <lifeless> "Remainin portions "
[02:23] <Verterok> lifeless: yes, I fixed that in trunk :P
[02:25] <lifeless> Verterok: ok
[02:25] <lifeless> now its been 5 years since I used eclipse in anger :)
[02:25] <lifeless> I want to point it at bzr.dev, which I have indexed
[02:25] <lifeless> and try it out
[02:26] <Verterok> lifeless: works?
[02:26] <lifeless> doesn't complain in the setup box now
[02:26] <Verterok> great
[02:26] <lifeless> search window has 'file, java, plug-in' tabs
[02:27] <Verterok> lower left --> customize
[02:27] <lifeless> how do I tell it which breanch to search
[02:27] <Verterok> you must have it in eclipse, as a project
=== cprov is now known as cprov-out
[02:28] <Verterok> if you don't want to branch,  it can be imported
[02:28] <Verterok> create a new empty project
[02:28] <lifeless> bzr is python :)
[02:28] <lifeless> does that matter?
[02:29] <Verterok> nope :)
[02:29] <Verterok> eclipse treat .py as text files (in case PyDev isn't installed)
[02:29] <lifeless> so branch as new project
[02:29] <lifeless> use existing
[02:29] <lifeless> empty list
[02:30] <Verterok> there is no previous branch location used from eclipse (no integration with locations.conf yet )
[02:31] <Verterok> lifeless: you can branch or you can take a shorcut :)
[02:32] <lifeless> Verterok: k, well - take the things I try as user feedback to consier :P
[02:32] <lifeless> (it doesn't say 'used from eclipse' :)
[02:32] <lifeless> Verterok: what should I do?, I can't seem to edit the list ..
[02:32]  * Verterok fires up a text editor...and start taking notes
[02:33] <Verterok> lifeless: there should be two options
[02:33] <beuno> mwhudson, so...  it turns simpletal converts < and > to html, no matter how much I yell at it
[02:33] <mwhudson> beuno: even CDATA ?
[02:33] <mwhudson> beuno: that sucks :/
[02:33] <lifeless> beuno: monkeypatch?
[02:33] <Verterok> check "initialize a new branch location"
[02:34] <Verterok> lifeless: wait, you want to use the already indexed bzr.dev?
[02:34] <beuno> lifeless, I'm trying to avoid that. Though mwhudson would know a magic way around it, that neither me or google did
[02:35] <beuno> s/Though/Thought
[02:36] <zou_> bzr commit file1.h file2.cpp
[02:37] <Verterok> lifeless: to avoid re-indexing the branch, you can go to: File --> new --> Project --> General --> Project and specify a location
[02:37] <zou_> got message: "bzr: ERROR: Selected-file commit of merges is not supported yet: file1.h file2.cpp"
[02:37] <zou_> what should I do then?
=== mw is now known as mw|out
[02:41] <lifeless> Verterok: sweet thanks
[02:41] <lifeless> zou_: you've done a merge from somewhere
[02:41] <lifeless> zou_: you should just 'commit'
=== edcrypt__ is now known as edcrypt
[02:42] <zou_> lifeless: you mean just "bzr commit"?
[02:42] <lifeless> yes
[02:42] <zou_> hmm, but I want to control what I am going to commit.
[02:43] <lifeless> you've done a merge though
[02:43] <lifeless> so you already have some other work going in
[02:43] <lifeless> bzr will link to say that that work was merged
[02:43] <zou_> yes. here is what I did:
[02:44] <lifeless> but we don't [yet] allow you to merge just some files from that merge, because the graph of merges is done at the revision level, not per-file.
[02:44] <zou_> (1)I made some local changes on Gnash yestoday (2)I did a "bzr update" today.
[02:44] <zou_> Now I want to commit my local changes with "bzr commit file1.h file2.cpp"
[02:45] <lifeless> had you committed those changes locally?
[02:45] <zou_> yes. I'v done "bzr commit --local"
[02:45] <lifeless> so, can I ask why you don't want to commit some of your changes?
[02:46] <lifeless> oh, markh meet zou_
[02:46] <zou_> some changes are important. others are just trivial work, eg. indent the sources and add some debugging lines.
[02:47] <lifeless> zou_: ok. why does that matter though ?
[02:47] <zou_> I just want to commit the "important changes".
[02:47] <lifeless> zou_: is it for review? or because some aren't ready? or ... ?
[02:47] <markh> zou_: hi!  Please don't get your expectations up too far for a first tortoise release ;)
[02:48] <lifeless> zou_: because all your work is /already/ committed locally
[02:48] <markh> but its looking quite nice and I hope to have a binary up in a day or so...
[02:48] <zou_> I don't want to make a new revision for a file without any meaningful change.
[02:49] <lifeless> zou_: ok. so I would merge all the things in because you have committed them
[02:49] <lifeless> zou_: but I can help you untangle things if its real important
[02:50] <zou_> markh:  file marks + update + diff + commit should be enough at the moment.
[02:50] <lifeless> zou_: and I think you probably want to start using a separate branch to do your own work, because 'commit --local' on trunk is for *things you want on trunk*
[02:50] <lifeless> zou_: but what you are saying to me is 'I have committed things I didn't want on trunk yet' - and thats an ideal situation to be using a branch
[02:51] <zou_> markh: and make the installation easier for me, hopefull a single TortoiseBzr.exe would work:)
[02:52] <zou_> lifeless: I just thought "commit --local" was safe, eg. doesn't interrupt the work of the others.
[02:53] <zou_> So I "commit --local" a lot without carefull consideration.
[02:53] <lifeless> zou_: its for offline work on a shared branch, the intent is that what you did becomes part of trunk at the earliest possible opportunity - which is now
[02:53] <markh> zou_: first cut will have icon overlays but no functinging context menus - so checkins etc are still from the cmdline
[02:53] <lifeless> zou_: for doing stuff without care, use a branch. Branches are easy to make and work with
[02:53] <zou_> But before a real commit(commit to remote branch), I have to think for the others.
[02:53] <markh> it shouldn't take too long to wire that up,m be we decided an earlier release without out it was better
[02:54] <lifeless> zou_: exactly. you want a branch for this, not commit --local
[02:54] <markh> One task will be to wrap up the pygtk "worker" applications in a py2exe environment
[02:55] <zou_> lifeless: OK, step1: bzr branch bzr+ssh://myname@bzr.savannah.gnu.org/gnash
[02:55] <zou_> step2: local changes.
[02:56] <lifeless> zou_: or even bzr branch . ../localwork
[02:56] <zou_> then what should do after that? what are the commands?
[02:56] <lifeless> zou_: in the new branch, commit to do a commit
[02:57] <lifeless> merge $TRUNKURL + commit, to get updates from trunk
[02:57] <lifeless> cd $TRUNK; bzr update; bzr merge $LOCALBRANCH; bzr commit
[02:57] <lifeless> to take something you did locally and put it in the trunk
[02:58] <lifeless> you probably want to have your localbranch be the one that your build trees point at
[02:58] <lifeless> zou_: we can get more sophisticated, but $learning curve
[02:58] <zou_> what is the URL of my local branch?
[02:59] <lifeless> zou_: well, if you ran 'bzr branch bzr+ssh://myname@bzr.savannah.gnu.org/gnash' then it would have made a new branch at ./gnash
[02:59] <lifeless> if you ran 'bzr branch . ../localwork' it would have made it at ../localwork
[03:01] <zou_> This is what I did:  bzr co bzr+ssh://myname@bzr.savannah.gnu.org/gnash/trunk.  so it's not a branch?
[03:01] <lifeless> zou_: that does a checkout
[03:01] <lifeless> zou_: checkouts operate like cvs - when you commit it goes to the thing you checked out
[03:02] <lifeless> zou_: for clarity - are you talking about the *existing place you were doing commit --local*, or a new one made during this conversation ?
[03:02] <zou_> yes, but for a cvs rep., I can always use "cvs commit file1.h file2.h" and leave "modifiedy file3" alone.
[03:03] <lifeless> zou_: yes, and you can in bzr too; but you *already committed* this stuff with --local
[03:03] <lifeless> zou_: so lets make you a new branch and get you hacking again
[03:04] <lifeless> zou_: cd to the checkout
[03:04] <zou_> lifeless: I am taking about the "existing place"
[03:04] <lifeless> cd to the existing place
[03:04] <zou_> done
[03:04] <zou_> and then?
[03:04] <lifeless> run this command:
[03:04] <lifeless> bzr branch . ../local-branch
[03:05] <lifeless> that should be very fast; if its not we can make it faster in future but don't worry about that right now
[03:05] <zou_> doing now, wait it to be fininshed.
[03:06] <zou_> finished.
[03:06] <lifeless> (when I say we can make it faster, I mean that its local configuration, not code-writing, to make it faster)
[03:06] <lifeless> ok
[03:06] <lifeless> this new place - local-branch - is where you should do changes and write code
[03:07] <zou_> cd local-branch
[03:07] <zou_> so I can do "bzr commit file1 file2" and leave modifidy file3 alone now?
[03:07] <lifeless> yes, we need to recover the work you don't want to commit first
[03:08] <lifeless> this needs  alittle python, because I just found a bug in the command that would normally make it real easy
[03:08] <lifeless> you're on windows aren't you ?
[03:08] <zou_> yes. Cygwin + windows.
[03:09] <lifeless> well, lets see if we can use python, otherwise we'll peek at a file quickly on disk
[03:09] <lifeless> python
[03:09] <lifeless> >>> import bzrlib.workingtree
[03:09] <lifeless> if that errors, we'll need to peek on disk
[03:09] <lifeless> let me know if it worked or errored
[03:09] <lifeless> (no output is worked)
[03:10] <zou_> lifeless: I'v typed import bzrlib.workingtree
[03:10] <lifeless> ok
[03:10] <lifeless> now
[03:11] <lifeless> tree = bzrlib.workingtree.WorkingTree.open('../trunk')
[03:11] <zou_> still after ">>>" ?
[03:11] <lifeless> (replace ../trunk with the path to your checkout - I am guessing at the relative path)
[03:11] <lifeless> zou_: yes, the >>> is the python prompt
[03:12] <zou_> done
[03:12] <lifeless> tree.lock_read()
[03:13] <lifeless> print tree.get_parent_ids()[1]
[03:13] <lifeless> tree.unlock()
[03:13] <zou_> done
[03:13] <lifeless> the print statement will have printed out a GUID
[03:13] <lifeless> exit python now
[03:13] <lifeless> you should be in local-branch still
[03:13] <lifeless> run bzr pull -r revid:$GUID ../trunk
[03:14] <lifeless> this will restore your local work so we can pick and choose bits of it for trunk
[03:14] <zou_> it prints "zoulunkai@gmail.com-2008xxxxxxxxxxxxx"
[03:15] <zou_> should I write down the GUID before exit python?
[03:15] <lifeless> zou_: yah, put that in the bzr pull commit - so 'bzr pull -r revid:zoulunkai@gmail.com-2008xxxxxxxxxxxxx ../trunk' (or whatever it printed)
[03:15] <lifeless> zou_: if your window will go away yes - or just copy and paste
[03:18] <zou_> bzr pull -r  revid:zoulunkai@gmail.com-2008xxxxx   ../trunk
[03:18] <zou_> got message:
[03:18] <zou_> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
[03:19] <lifeless> zou_: are directory are you in ?
[03:19] <zou_> I am under the local-branch dir.
[03:19] <lifeless> cool
[03:19] <lifeless> add --overwrite to the command line
[03:20] <zou_> ok, finished. got message: " ....  All changes applied successfully, Now on revision 9425"
[03:20] <lifeless> cool
[03:20] <lifeless> now, local-branch has what you were working on before you updated
[03:21] <lifeless> one last thing to do -
[03:21] <lifeless> cd to trunk
[03:21] <lifeless> and run bzr revert
[03:21] <zou_> I am still under "local-branch" dir. you mean "cd ../trunk"?
[03:22] <lifeless> yes
[03:22] <zou_> done "bzr revert"
[03:23] <lifeless> right
[03:23] <lifeless> now, to get some changes from local-branch into trunk
[03:23] <lifeless> you can get them all by doing a merge
[03:23] <lifeless> but you only want some
[03:23] <lifeless> so I'm going to teach you how to do a 'cherrypick'
[03:23] <lifeless> (this is all in the manual btw)
[03:24] <zou_>  <lifeless> now, to get some changes from local-branch into trunk
[03:24] <zou_> how to do that?
[03:25] <lifeless> cd to the trunk
[03:25] <lifeless> and do 'bzr missing ../local-branch'
[03:25] <lifeless> this command tells you about commits that can be merged
[03:26] <lifeless> (it tells you in both directions)
[03:28] <zou_> got message:  "you have 13 extra revision(s): ....   you are missing 1 revision(s)"
[03:29] <zou_> I want to commit some of my local changes. Can I use the local-branch dir to do that?
[03:29] <zou_> commit to the remote branch.
[03:30] <lifeless> yes
[03:30] <lifeless> so, from the look of it you've only done one local commit, but you commited several things
[03:31] <lifeless> so the we have to merge the files you want across:
[03:31] <lifeless> 'bzr merge ../local-branch/file1.h'
[03:31] <lifeless> 'bzr merge ../local-branch/file2.cpp --force'
[03:31] <lifeless> 'bzr merge ../local-branch/file3.cpp --force'
[03:31] <lifeless> etc
[03:31] <lifeless> when you are happy, bzr commit
[03:33] <zou_> bzr update
[03:33] <zou_> then haven't the changes from remote branch already be merged to my local branch?
[03:34] <zou_> the merge command is confusing.
[03:34] <lifeless> zou_: could you rephrase the question, I'm not sure what you mean
[03:35] <zou_> by using cvs, "cvs update" merges changes from remote rep. to my local rep. automatically.
[03:35] <zou_> I am not sure when I need a "bzr merge" command.
[03:36] <zou_> after "bzr update remote_branch"?
[03:37] <lifeless> zou_: you need merge to move changes between your local 'trunk' directory and your 'local-branch' directory
[03:38] <lifeless> zou_: the way merge works, is it moves some changes, and then you use 'commit' to record them permanently
[03:39] <zou_> ok.
[03:39] <lifeless> zou_: so you need merge in 2 places: after you do 'bzr update' in the trunk directory, you should cd to the local-branch directory and run 'bzr merge ../trunk ; bzr commit -m "merge trunk"' to move changes to the local branch
[03:39] <lifeless> zou_: and when you have finished some work in local branch and want to put it in the trunk you should do:
[03:40] <lifeless> cd trunk; bzr update ; bzr merge ../local-branch; bzr commit -m 'details of what you are committing to trunk'
[03:40] <zou_> very clean, thanks:)
[03:40] <zou_> clear
[03:41] <lifeless> happy to help
[03:41] <lifeless> you guys are taking a big step from CVS to distributed in one step
[03:41] <lifeless> features like offline commits involve most of the complexity of full distribution, which is why you ran into the wall today
[03:42] <zou_> another question:
[03:42] <zou_>  'bzr merge ../local-branch/file1.h'  'bzr merge ../local-branch/file2.cpp --force'
[03:43] <zou_> why I need the '--force' option?
[03:43] <lifeless> so the first merge merges one file
[03:43] <lifeless> and leaves you with pending changes
[03:43] <lifeless> merge will stop and refuse to operate by default when you have pending changes, because its easy to get conflicts-on-conflicts and other such confusion
[03:43] <lifeless> so the --force says 'allow me to merge the other file please'
[03:44] <zou_> I have a 'trunk' dir and a 'local-branch' dir. what is the pending change?
[03:44] <lifeless> well you are in trunk
[03:45] <lifeless> and you merge one file - file1.h - from local-branch
[03:45] <lifeless> that becomes a pending change in trunk
[03:45] <zou_> yes
[03:45] <lifeless> because you haven't yet run 'commit' to record it permanently
[03:45] <lifeless> file1.h is the pending change :)
[03:46] <lifeless> why don't you try it and see what happenes
[03:46] <zou_> so, I select the files I want to commit at the "merge" stage instead of "commit" stage, right?
[03:46] <lifeless> zou_: yes, when you are picking individual changes
[03:47] <lifeless> zou_: _normally_ most people merge the entire directory - e.g. 'bzr merge ../local-branch', because thats what you usually want
[03:48] <zou_> No, for Gnash, I do selective "cvs commit" everyday. (cvs commit all_files is dangerous)
[03:49] <zou_> I touched lots of files during debugging, but many of them are not worthy for committing at all.
[03:50] <zou_> It's difficult to track back if there are too much revision numbers.
[03:50] <beuno> mwhudson, ignore my previous comment, you can print html, although it complicates everything for me. It's going to be a few python lines just to print out <wbr/>...
[03:51] <zou_> lifeless: thanks a lot for you time!
[03:51] <lifeless> zou_: ah, there are plenty of tools we have to help you here though
[03:51] <lifeless> zou_: firstly, I didn't say that people _commit_ everything all the time - but that they _merge_ everything
[03:52] <lifeless> zou_: another thing that you may like is the 'shelve' plugin
[03:52] <lifeless> this lets you put some changes aside that are not ready to commit (or imappropriate, like debugging stuff)
[03:55] <zou_> I think windows users need a TortoiseBzr which behaves like the TortoiseCVS, GUI helps me think better:)
[03:56] <lifeless> zou_: to some degree we will have that soon
[03:57] <lifeless> zou_: but there are _substantial_ differences in a full-tree system, which is what git/bzr/hg/monotone all are
[04:00] <lifeless> ok, I'm heading lunch and poolies I think
[04:00] <lifeless> poolie: see you 3ish ok ?
[04:01] <zou_> I think I could expect that "selective merge", "selective update", "selective diff" would be very intuitive within the windows file explorer
[04:02] <lifeless> zou_: well, selective update doesn't exist as a concept in the system; selective merge does but with some caveats; selective diff does
[04:02] <lifeless> gotta run
[04:02] <zou_> select the file with your mouse and right click it to choose a context menu to do your action:)
[04:04]  * igc lunch
[04:11] <zou_> are all files share the same revision number of a bzr branch?
[04:12] <poolie> lifeless: 3ish is fine
[04:13] <zou_> eg. for a cvs-head branch, we can have revsion 1000 for file1, 800 for file2, 2000 for file3.
[04:14] <zou_> do we have a similar concept for a bzr-head branch? Or all files for a bzr-head branch share the same revision number?
[04:16] <mwhudson> zou_: a revision in bazaar is a snapshot of the entire tree
[04:17] <zou_> got it. so we don't have "revision for a single file"
[04:17] <mwhudson> so, more the second of your two options, but the answer is more "neither"
[04:17] <mwhudson> zou_: right
[04:18] <zou_> thanks. Then I understand why I cann't do "selective commit" better.
[04:30] <Peng> Eek, LH's traceback didn't go in the log.
[04:32] <mwhudson> Peng: hmm
[04:32] <mwhudson> sounds like a bug
[04:33] <Peng> Huh.
[04:38] <Peng> Want me to file a bug against LH?
[04:41] <mwhudson> Peng: well, probably
[04:41] <mwhudson> Peng: what was the traceback?
[04:42] <Peng> mwhudson: That's another matter. Googlebot has been having lots of fun going through my LH instance today, and certain annotation pages traceback with a NoSuchId in tree None.
[04:42] <mwhudson> man wtf, _that_ sort of traceback should be in the log i'd have thought
[04:43] <mwhudson> Peng: interesting
[04:43]  * Peng shrugs.
[04:43] <Peng> I'll file a bug.
[04:44] <mwhudson> Peng: are they reproducible, in that when you visit the urls do they traceback?
[04:44] <Peng> mwhudson: Yes.
[04:44] <mwhudson> ok, good (probably)
[04:44] <mwhudson> Peng: is this public code?
[04:45] <Peng> mwhudson: URL where it happens: http://snurl.com/2p8ye Traceback: http://paste.pocoo.org/show/77818/
[04:45] <beuno> ah, that reminds me, I have Peng's patch for broken atom links.  Off to trunk...
[04:45] <Peng> There are at least 2 pages that cause it to happen.
[04:45] <Peng> beuno: :)
[04:46] <mwhudson> i wish googlebot sent referer headers :/
[04:46] <Peng> Heh.
[04:47] <beuno> mwhudson, I've been meaning to run a custom spider script I have on LH with a bigg-ish branch, just haven't found the time
[04:47] <mwhudson> Peng: so i guess the question is: is this a url that should render and explodes, or a link we shouldn't have generated?
[04:48] <Peng> And I don't have an answer.
[04:49] <beuno> from the traceback, it seems it blows up in bzrlib, LH seems to pass on an incorrect fileid
[04:50] <beuno> Peng, how many branches are you serving from LH?
[04:50] <mwhudson> index.txt-20071121073725-0corxykv5irjal00-1
[04:50] <beuno> it would be good if we could know which one had index.txt
[04:50] <Peng> beuno: Um. Maybe a little over 30.
[04:50] <beuno> and what it's real fileif is
[04:50] <beuno> *fileid
[04:50] <Peng> It's in the URL.
[04:51] <Peng> Hm.
[04:51] <beuno> Peng, can you run bzr ls --show-ids in that branch?
[04:52] <beuno> ah, wait a minute...
[04:52] <beuno> is not present in the tree None
[04:52] <beuno> the tree should probably no be None...
[04:53] <mwhudson> there's no file with that file id in bzr.dev it seems
[04:53] <mwhudson> i don't know how you can tell if there ever was such a file id
[04:53] <mwhudson> convert the branch back to knits? :)
[04:53] <Peng> That revid is r3231 of my branch, and probably bzr.dev.
[04:53]  * mwhudson types the fileid into google
[04:54] <Peng> yeah
[04:54] <Peng> There wasn't such a fileid in that revision.
[04:55] <mwhudson> the file id was fora  file called index.txt in the root afaict
[04:55] <beuno> maybe bzr-search can help in that area?
[04:55] <Peng> Heh.
[04:55] <Peng> Want me to file a bug about the logging thing?
[04:56] <beuno> please  :)
[04:56] <mwhudson> and it was removed in r3067 it seems
[04:56] <mwhudson> ah hah
[04:57] <mwhudson> ok, this is quite a good one
[04:57] <mwhudson> in the changelog view
[04:57] <mwhudson> when a file is removed
[04:57] <mwhudson> we link the filename to ...
[04:57] <beuno> aaaaaaah
[04:57] <beuno> lol
[04:57] <beuno> interesting  :)\
[04:57] <poolie> hello beuno
[04:58] <beuno> hey poolie
[04:58] <pickscrape> I'm trying to debug bug 56680 (diffstat), but I'm struggling to get bzr to even add the file given in the zip attached to the bug
[04:58] <ubottu> Launchpad bug 56680 in bzr-diffstat "uncaught exception: bzr: ERROR: exceptions.UnicodeDecodeError:" [Low,New] https://launchpad.net/bugs/56680
[04:58] <pickscrape> It is complaining thus: BzrError: Parameter ''Lekt\xfcre'' is unsupported by the current encoding.
[04:59] <pickscrape> Any idea how I get my encoding right to allow bzr to add it? I'm not too familiar with locales etc.
[04:59] <Verterok> pickscrape: your terminal encoding don't support ¿utf-8 maybe?
[04:59] <mwhudson> beuno: should be easy to fix i hope
[04:59] <beuno> mwhudson, so we should either remove the link, or point to the previous revision
[04:59] <Verterok> pickscrape: linux + bash?
[04:59] <pickscrape> LANG is en_US.UTF-8
[04:59] <pickscrape> Verterok: Yes, Ubuntu Hardy.
[05:00] <Verterok> pickscrape: try this: python -c "import sys; print sys.getdefaultencoding()"
[05:01] <pickscrape> Verterok: ascii
[05:02] <Verterok> pickscrape: and sys.getfilesystemencoding()?
[05:02] <pickscrape> UTF-8
[05:02] <Verterok> I get ascii and utf-8 for each one
[05:02] <Verterok> it "should" work (I recently fixed a similar bug in xmloutput)
[05:03] <pickscrape> I'm not even at the point of fixing diffstat yet :)
[05:03] <pickscrape> It's getting it added by bzr that is currently falling over.
[05:03] <Peng> mwhudson: So..you figured out where the tracebacks were coming from?
[05:03] <mwhudson> Peng: yes
[05:04] <mwhudson> Peng: look at http://bzr.mattnordhoff.com/loggerhead/bzr/configobj-4.5.2/changes/3067
[05:04] <Verterok> pickscrape: the diffstat command class should have a encoding_type attribute
[05:04] <mwhudson> Peng: expand the first revision, click the link to index.txt
[05:05] <beuno> mwhudson, linking to the previous revision is probably what the user expects (actually being able to see the file)
[05:05] <Peng> mwhudson: Okay. That was quick. :)
[05:05] <pickscrape> Verterok: I don't want to start trying to fix diffstat until I can reproduce the problem, and I can't do that without having a file with unicode characters in its filename already recognised by bzr
[05:05] <mwhudson> beuno: or just have it not be a link
[05:06] <beuno> mwhudson, well, that's easier, just would be interesting to know what the user expects
[05:06] <beuno> Peng?  :)
[05:06] <Verterok> pickscrape: I understand, but I think you are hitting a new bug :)
[05:06] <pickscrape> Yay :)
[05:07] <Peng> beuno: ?
[05:07] <pickscrape> Verterok: Bug in bzr itself?
[05:07] <beuno> Peng, what would you want/expect LH to do when a file is removed?
[05:07] <Peng> beuno: I think linking to the previous revision would be most useful.
[05:08] <Peng> But having no link at all would be easiest code-wise, obviously.
[05:08] <Verterok> pickscrape: I hit a similar problem with the 'annotate --xml' command in xmloutput plugin and it was related to the encoding_type attribute
[05:09] <beuno> of course, moving the user to a previous revision will be very confusing if they want to navigate from that page...
[05:09] <beuno> how about both?  no link, link beside it, "See index.txt in revision X"
[05:10] <pickscrape> encoding_type in diffstat is currently
[05:10] <pickscrape> 'replace', but I'm having this problem with bzr add
[05:11] <Peng> beuno: That sounds good to me.
[05:12] <beuno> I'll file a bug for it
[05:13] <Verterok> pickscrape: do you have a traceback?
[05:14] <pickscrape> !paste
[05:14] <ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
[05:15] <Peng> beuno / mwhudson: Thanks for you help. :)
[05:15]  * Peng points out that tracebacking on bad input is also bad.
[05:15] <pickscrape> Verterok: http://paste.ubuntu.com/23238/
[05:15] <mwhudson> Peng: oh yes, there should be a bug for that too
[05:16] <mwhudson> loggerhead is very bad at validating its input
[05:16]  * beuno files a bug for that too
[05:18] <Verterok> pickscrape: indeed it looks like a bzr or env. problem
[05:18] <pickscrape> Verterok: thanks, I'll raise a bug. Either way it will be either fixed or the solution documented :)
[05:19] <beuno> I wonder how this removed bug hasn't surfaced through LP
[05:20] <beuno> anyway, Peng, thanks for all the bugs, and, especially, patches  :)
[05:20] <Peng> LP has a very restrictive robots.txt, so it won't get triggered by them.
[05:20] <Peng> beuno: :)
[05:24] <mwhudson> hm, so i'm little surprised that paste doesn't send uncaught exceptions to _some_ logger
[05:24] <pickscrape> Verterok: thanks for your help. I need to go to bed now. :)
[05:24] <Verterok> pickscrape: np, sorry I can't give you more pointer on where to look
[05:25] <mwhudson> should be easy enough to write some middleware for that though
[05:35] <beuno> Peng, commit 179 removes the link  :)
[05:36] <Peng> beuno: Cool. :)
[05:36] <beuno> but of course, mwhudson deserves the credit for being so smart
[05:37] <Peng> I'm sure this will make Googlebot happy.
[05:37]  * beuno goes off to tweak loggerhead-serach a bit better before lifeless's presentation
[05:39] <mwhudson> Peng: it will keep on requesting those urls for a few years i guess
[05:39] <mwhudson> :)
[05:39] <Peng> Heh, true.
[05:42] <Peng> Well, then, I'm gonna go to bed. Good night, and thanks again. :)
[05:43] <beuno> g'night Peng
[06:01] <beuno> lifeless, pushed my loggerhead search changes, UI is a bit better, so I may even try and put it for review tomorrow
[06:03] <beuno> anyway, that's it for me today. Good night folks
[06:04] <lifeless> night beuno
[06:04] <lifeless> beuno: coolness
[06:05] <beuno> lifeless, good luck with your presentation, and blog about it so we know how it went  :)
[06:05] <mwhudson> bye beuno
[06:06] <beuno> mwhudson, good luck with those file descriptors. I'm interested to see what you come up with
[06:07] <mwhudson> i'm not going to get to it today :(
[06:19] <lifeless> mwhudson: how have you gone with the ssh server?
[06:19] <mwhudson> lifeless: we think we have it beat
[06:20] <lifeless> excellent
[06:41] <ToyKeeper> Maybe this is crazy, but is there any way to branch a remote repo to a local one, without the complete history?  (perhaps only the past 50 revisions or somesuch)
[06:42] <ToyKeeper> I keep seeing people complain that they don't want to download a project's entire history before making changes.
[06:42] <spiv> Not crazy at all.
[06:42] <spiv> lifeless is working on smoothing off the rough edges of a feature to do exactly that.
[06:42]  * mwhudson gets ready to stop for the week
[06:43] <lifeless> mwhudson.suspend()
[06:44] <AfC> Are we still calling that "shallow branches", or has that become a feature of "stacked branches", or ... ?
[06:45]  * ToyKeeper tells the users to be patient, since the feature is in progress  :)
[06:45] <lifeless> AfC: its being touted as stacked
[06:45] <lifeless> which makes me think entirely non appropriate thoughts.
[06:52] <AfC> lifeless: that seems ... a less than ideal choice, given that "shallow" creates the impression of minimalism, whereas "stacked" means, well, nothing to do with thin. I can imagine you are thinking inappropriate thoughts :)
[06:54] <lifeless> AfC: :)
[06:54] <lifeless> Jc2k: is it git-svn that makes http://bzr-mirror.gnome.org:8080/gtk+/trunk/changes show just a list of names and dates?
[06:57] <AfC> lifeless: replying on Jc2k's behalf: I don't think so. Contrast revno 16032
[06:58] <AfC> lifeless: most of the people who hack on GTK whack their ChangeLog entry into the commit message, and so the first line thereof is, well, the usual. The translators seem to not do that, but then there are also GTK hackers who don't either.
[06:58] <AfC> (whether any one group is or isn't using git-svn to facilitate this behaviour I can't tell you)
=== zou_ is now known as zou_away
[07:10] <markh> should the bzr binaries for windows set the PyOptimize (sp?) flag, or should I stick with __debug__ mode?
[07:11] <markh> iirc, most assert statements are gone
[07:12] <markh> I should see if the test suite completes any faster with binaries built with that flag...
[07:12] <vila> markh: *all* assert statements should be gone by now, there is even a test for that to ensure they don't come back
[07:12] <lifeless> AfC: ok
[07:12] <markh> so there's no good reason to not set that flag?
[07:13] <lifeless> markh: indeed
[07:14] <markh> lifeless: thanks
[07:15] <ToyKeeper> Hmm, I wonder how best to handle svn->bzr conversion.  The tags/ dir has 90% of the files.
[07:16] <ToyKeeper> I suppose I could just convert trunk/, and manually tag based on when people copied trunk to tags/.
=== prateeksaxena is now known as prtk
[07:27] <AfC> ToyKeeper: that would probably work
[07:28] <ToyKeeper> Yeah, except there's some stuff in branches/ too, and I'd lose that if I only did trunk/.
[07:29] <ToyKeeper> It's probably better than pulling in tags/ and then having to delete it all though.  :)
=== gour is now known as gour|afk
[08:29] <markh> so, finally worked out my ssh problem!  I'm guessing support for plink is new, as that is the problem.  If I disable plink and let it fall back to paramiko, it all works.
[08:45] <mark1> so it seems we do prefer plink over paramiko even when paramiko exists.
[08:45] <mark1> (did my last message about my ssh problem make it before I was disconnected?)
=== markh is now known as Guest66607
=== zou_away is now known as zou_
=== mark1 is now known as markh
[09:18] <sabdfl> no revisions to pull!
[09:49] <RAOF> Is there a tarball of a bzr.dev repository somewhere?  My connection just refuses to branch bzr, either from launchpad or bazaar-vcs.org.
[09:50] <Kinnison> IIRC you can rsync it from bazaar-vcs.org
[09:50] <Kinnison> Otherwise, get a tarball of a recent bzr and then branch bzr.dev with that
[09:53] <Jc2k> lifeless: thats just one of the braindead ChangeLog things we have to deal with
[09:54] <Jc2k> some people put a copy of the changelog entry in the commit
[09:54] <Jc2k> translators don't, hence the rev AfC pointed out
[09:58] <james_w> RAOF: is there a bug in bzr you are hitting, or is it just your connection?
[10:00] <RAOF> james_w: I'm not entirely sure.
[10:02] <RAOF> When I try to branch bzr I end up getting unknown host errors, so it's probably my connection.  On the other hand, these errors always appear to occur at abount the same point in the branch process.
[10:03] <RAOF> Kinnison: You'd rsync http://bazaar-vcs.org/bzr/bzr.dev, right?
[10:04] <RAOF> Of course you wouldn't.  That's not how rsync works :/
[10:04] <bob2> no, that's http :)
[10:05] <bob2> rsync -r bazaar-vcs.org::bazaar-ng/bzr/bzr.dev .
[10:05] <RAOF> Thanks.
[10:06]  * RAOF was stocastically converging on that.
[10:08] <Kinnison> :-)
=== cprov-out is now known as cprov
=== gour|afk is now known as gour
[13:06] <whs> https://bugs.edge.launchpad.net/bzr.webdav/+bug/243491
[13:06] <ubottu> Launchpad bug 243491 in bzr.webdav "bzr push ask my password multiple times" [Undecided,New]
=== kiko__ is now known as kiko
[13:15] <aa_> hi, any doc for using the revision of a branch in a python application as the "version" ?
[13:16] <james_w> aa_: there is the "version-info" command
[13:17] <james_w> "bzr version-info --python > _version.py"
[13:17] <james_w> from _version import version_info
[13:17] <james_w> version = version_info['revno']
[13:18] <james_w> or some variation on that.
[13:18] <aa_> yeah, looks great, thanks
[13:18] <gour> aa_: hello. how is pida doing?
[13:18] <jelmer> luks: you rock
[13:18] <aa_> gour: ! hello, pida is doing fine, thanks
[13:19] <gour> aa_: cool. i moved to emacs...
[13:23] <aa_> gour: pida does emacs too :)
[13:24] <gour> aa_: are the patches applied upstream?
[13:24] <gour> aa_: i use cvs version
[13:25] <gour> aa_: ..and moved to bzr
[13:26] <luks> jelmer: umm, I do? :)
[13:27] <jelmer> luks, automv
[13:27] <luks> oh
[13:27] <james_w> oh yeah, I agree with jelmer, you do.
[13:34] <awilkins> How do you merge two folders that have been added independantly in different branches under tha same name
[13:34] <jelmer> I don't think you can since they would have different file ids
[13:34] <awilkins> When you merge, one gets moved, you want to move files from the usurper into the .moved folder and ditch the usurpoer
[13:34] <awilkins> I'm finding it a little tricksy
[13:38] <awilkins> Ok, sorted
[13:39] <awilkins> Moved the files from the usurper, trashed it, move dhte old one back, resolved
[13:47] <fdv> Hi. "bzr: ERROR: exceptions.KeyError: 'pop(): dictionary is empty'" on a 'bzr st' is a known error, right?
[13:47] <james_w> fdv: sounds familiar
[13:47] <james_w> in tsort.py?
[13:47] <fdv> yep
[13:47] <james_w> yeah, would you like me to find the bug?
[13:48] <fdv> james_w: that's ok, I think I've seen it
[13:48] <fdv> then I'll just scrap that repo and create a new one
[13:48] <fdv> but thanks :)
=== mw|out is now known as mw
=== prateeksaxena is now known as prtk
[14:22] <jelmer> jam: ping
[14:22] <jelmer> lifeless: ping
[14:29] <jam> jelmer: ??
[14:29] <jelmer> jam: Hi!
[14:29] <jam> does everyone know the moment I log in ?
[14:30] <jelmer> Lucky guess (-:
[14:32] <jelmer> jam: I was going to ask you about something but already forgot what it was
[14:32] <jam> jelmer: well, I'm merging your setup.py change if that was it
[14:33] <jelmer> I should've asked you about that as well, but that wasn't it
[14:33] <jam> though you are missing the Copyright and other headers
[14:33]  * jelmer tries to revive his short-term memory with some coffee
[14:33] <jam> also, do we want to force "python2.4" what if they have 2.5 installed?
[14:33] <jam> I realize it is avoiding 2.3...
[14:34] <jelmer> In my defense it was copied from bzr-email so it's all Roberts fault :-P
[14:34] <jelmer> Yeah, just using python makes sense now
[14:34] <jelmer> There's very few systems around anymore with python2.3 as default python
[14:38] <jam> jelmer: though honestly, I always run with "python setup.py" rather than "./setup.py"
[14:38] <jam> but I suppose some people do it the other way
[14:38] <jelmer> Yeah, most people seem to do that
[14:38] <jelmer> I always get annoyed by setup.py's that aren't executable
[14:39] <Kinnison> If you're worried about 2.3, do the sys.version hack at the top?
[14:49] <jam> *I'm* not worried
[14:49] <jam> some people might be
[14:50] <jam> but they can just do "python2.4 setup.py"
[14:51] <Kinnison> kay
[14:52] <jam> of course, I didn't even have a setup.py script
[14:52] <jam> I don't believe in needing more than "bzr branch" :)
[15:14] <asabil> a small question some git fanboys have been asking, and I don't really have an answer
[15:14] <asabil> why does bzr not use the same repository format as git ?
[15:14] <james_w> because it doesn't used hash based naming for stuff
[15:14] <jam> "it" being bzr
[15:15] <jam> We could use it as a layer, but we would still need a layer on top of it
[15:15] <jam> It also doesn't store anything like "per-file graphs" etc.
[15:15] <jam> It just stores "content blobs"
[15:15] <james_w> the indexes for git packs are better than what we have, mainly because they have fixed length names.
[15:16] <asabil> hmm oki, thanks :)
[15:18] <awilkins> How does git reassemble hunks into files, anyone know?
[15:18] <awilkins> Does it just have "make me a file" hunks?
[15:19] <james_w> awilkins: it doesn't split files
[15:19] <awilkins> james_w: Yes, but it has to be able to write files to disk
[15:19] <james_w> it's "blobs" are full texts.
[15:19] <james_w> I'm not sure I understand the question then, sorry.
[15:20] <awilkins> I think it's good that it can do things like track content that was split out of one file into multiple, but what I was wondering is how it knows which file to write the content into
[15:20] <james_w> oh, it doesn't track that
[15:20] <james_w> it just guesses after the fact.
[15:20] <awilkins> If you view the content as one great big stream, are there hunks in the stream that correspond to "swtich context to this file" for exapmple
[15:21] <awilkins> It can't just guess, or the kernal source would come out as a big blob when you checked out.
[15:21] <james_w> so if you annotate a file it will also search in other files for the hunks when they disappear (moving backwards through history) and then link them up.
[15:22] <awilkins> Hmpph, I shall just have to look at the docs if I ever get the time
[15:22] <awilkins> Or start using it
[15:27] <jam> awilkins: everything maps sha1sum => content object
[15:27] <jam> some of these will be xdelta
[15:27] <jam> with a marker that "I'm based on *this* sha1sum"
[15:28] <jam> at the top level you have "inventory" blobs
[15:28] <jam> (I think the git term is "tree")
[15:28] <jam> And then you have "commit" blobs which reference tree blobs, which reference raw file content blobs
[15:28] <awilkins> Knew it had to be in there somewhere
[15:28] <awilkins> So it's hierarchical and not stream based
[15:28] <jam> awilkins: that is my understanding
[15:29] <jam> and the reason git repack --as-hard-as-you-can actually works pretty well
[15:29] <awilkins> I'll trust that more than the back of a cereal packet :-)
[15:29] <jam> because it just does an xdelta against 50-or-so likely-to-be-close sha1sums
[15:29] <jam> and grabs the smallest.
[15:29] <jam> smallest delta
[15:29] <jam> I don't specifically know how that effects performance on *extracting*
[15:30] <jam> as it could lead to arbitrarily long chains (unless that is also capped somehow)
[15:30] <lifeless> jearl: pong
[15:30] <lifeless> jearl: sorry
[15:30] <awilkins> jam: It's the kind of realm where speculation is useless and test implementations are everything
[15:32] <lifeless> jearl: I wanted jelmer how has loged out
[15:54] <wingo-tp> greetings.
[15:54] <wingo-tp> i have more traceback nasties.
[15:54] <wingo-tp> https://bugs.launchpad.net/bzr/+bug/243536
[15:54] <ubottu> Launchpad bug 243536 in bzr "bzr log fails" [Undecided,New]
[15:55] <mw> are any bzr developers planning to attend http://guadec.expectnation.com/guadec08/public/schedule/detail/81?
[15:56] <wingo-tp> i will be there but i am not a bzr dev.
[15:56] <mw> the feeling i get is that git will be railroaded through, which would be unfortunate
[15:58] <wingo-tp> the topic seems a bit out of date: there already are git and bzr mirrors.
[15:58] <Jc2k> mw: there will be 4 at least bzr/canonical guys there, and mark afaik
[15:59] <mw> jc2k: ah, excellent
[15:59] <wingo-tp> either one would be fine imo...
[16:00] <Jc2k> im just amazed at the kinds of arguments the pro-Git people are making
[16:00] <Jc2k> and they even admit they havent tried anything else
[16:00] <capiscuas1982> 1 question, one member of my team is trying to push in my bzr branch, is that possible? or it must be a team branch
[16:01] <capiscuas1982> $  bzr push lp:subdownloader
[16:01] <capiscuas1982> Enter passphrase for key '/home/leggewie/.ssh/id_dsa':
[16:01] <capiscuas1982> bzr: ERROR: Cannot lock LockDir(lp-146781388:///~capiscuas/subdownloader/trunk/.bzr/branchlock): Transport operation not possible: readonly transport
[16:01] <capiscuas1982> i don't know how to give him write access to ~capiscuas branch
[16:01] <Jc2k> wingo-tp: i would be happy to keep subversion, as bzr-svn does a wonderful job
[16:02] <radix> capiscuas1982: yeah, you'll need to create a team
[16:02] <radix> capiscuas1982: if you want multiple people to be able to push to the same exact branch
[16:03] <radix> capiscuas1982: alternatively he can push to his own branch location and you can merge it into your branch
[16:03] <james_w> Jc2k: it may be that svn would be better that git, as I doubt bzr-git could do as good a job as bzr-svn.
[16:03] <capiscuas1982> team is already created at ~subdownloader-developers
[16:03] <capiscuas1982> how can I copy from my branch ~capiscuas into a new branch ~subdownloader-developers ??
[16:04] <radix> capiscuas1982: bzr push lp:~subdownloader-developers/subdownloader/trunk
[16:05] <capiscuas1982> radix: i got this bzr: ERROR: Transport operation not possible: http does not support mkdir()
[16:05] <Jc2k> james_w: my day job is (sadly) to make "libgitcore", (http://git.codethink.co.uk/?p=git;a=shortlog;h=libgitcore). im hoping that might help bzr-git, but im not going to take that route until after GNOME has picked a DVCS
[16:05] <radix> capiscuas1982: run "bzr lp-login <your username>"
[16:05] <radix> first
[16:06] <radix> you should only need to run that once
[16:06] <capiscuas1982> radix: thks
[16:07] <james_w> Jc2k: yep, it probably would help, but the friction between the two models might make it difficult anyway. Or perhaps it just needs someone smarter than me to work on it.
[16:08] <capiscuas1982> radix: it worked, but i'm surprised it didn't ask for my password in launchpad
[16:08] <radix> capiscuas1982: authentication works with your ssh key
[16:08] <capiscuas1982> oh yeah
[16:08] <capiscuas1982> right
[16:11] <wingo-tp> so
[16:11] <wingo-tp> anyone have an idea about #243536?
[16:11] <mw> Jc2k: yeah, they mostly started using git because somebody famous wrote it, suffered hugely for months, finally came to grips with it, and now claim to have no time for anything else
[16:12] <mw> and now say "oh, but it makes perfect sense once you read 'Git for Computer Scientists'
[16:12] <wingo-tp> could it be the same as 239499 ?
[16:12] <wingo-tp> different repos, but both arch-imported...
[16:13] <wingo-tp> in this case i can't even do a bzr log, which sucks.
[16:14] <wingo-tp> (jam? :)
[16:15] <wingo-tp> this is becoming urgent
[16:16] <jam> wingo-tp: I think it is fixed in 1.6b2 if not there in b3, abentley had the fix
[16:16] <wingo-tp> jam: it's not
[16:17] <jam> wingo-tp: I'm checking quickly about it
[16:17] <jam> hopefully it isn't a huge repo
[16:18] <wingo-tp> not huge, no; a few hundred revisions
[16:18] <wingo-tp> thanks for taking a look
[16:30] <walkeraj> Some clarification.  If I don't use init-repo --no-trees, then each time a branch is created it gets its own copy of the entire working tree, correct?
[16:37] <jam> wingo-tp: sorry about the delay... "bzr log --short -r -10..-1" works fine :)
[16:38] <wingo-tp> heh ;)
[16:38] <wingo-tp> tx jam :)
[16:38] <wingo-tp> but... hm. we still have a problem :)
[16:38] <jam> wingo-tp: actually, 'bzr log --short -r 1..-1' also works fine
[16:38] <jam> Yeah, I see the problebm
[16:39] <jam> just slowing working out the "outer boundary" of it
[16:39] <wingo-tp> interesting
[16:39] <wingo-tp> cool
[16:39] <jam> the problem is pretty much *just* that the first revision claims to have a parent, but it is a ghost
[16:39] <jam> so "revision_history" tries to walk off and hits that
[16:39] <wingo-tp> ah.
[16:40] <jam> so... oddly enough, we have this "trap" for it:
[16:40] <jam> self._extend_partial_history(stop_index=last_revno-1)
[16:40] <jam> which is what abentley did
[16:41] <jam> ah, ok, so it is now breaking in a different location
[16:42] <jam> weird, I could have sworn it was breaking there
[16:42] <jam> anyway, now it is breaking in "tsort" for log --long
[16:42] <jam> so "bzr log --long -r 2..-1" works, because it doesn't try to include that problematic 1st revision
[16:42] <guilhembi> jam: hi! I posted on the support issue. Need to run
[16:42] <guilhembi> bbl
[16:44] <walkeraj> Hmm, did my last message come through?  This is my first attempt using pidgin for IRC, and I am leery.
[16:59] <bpeterson> does anybody offer free Bazaar hosting (ie github.com or freehg.org) aside from Launchpad?
[17:00] <Peng> I'm not sure.
[17:01] <Peng> On the upside, bzr can work with dump HTTP and SFTP, so you can host it basically anywhere, but that doesn't get you a slick interface.
[17:01] <awilkins> bpeterson: Cheap hosting by anyone who provides a web host with sftp or ftp uploads :-)   ?
[17:01] <bpeterson> true. So I could I setup it up easily using the SF webspace?
[17:02] <Peng> yes
[17:02] <Peng> The only setup required is "mkdir bzr", then just push over sftp.
[17:02] <bpeterson> nice although I might just bite the bullet and use launchpad
[17:02] <Peng> Launchpad is pretty nice.
[17:03] <bpeterson> It's a pity it doesn't have a wiki, though.
[17:07] <jam> wingo-tp: well, the quick fix is to edit your ".bzr/branch/last-revision" file and tell it that you only have 138 revisions instead of 139, but I don't know how that will work long term.
[17:07] <jam> testing
[17:09] <wingo-tp> interesting
[17:09] <wingo-tp> i guess i should fix the history at some point, no?
[17:09] <jam> well, we should support this sort of thing as well
[17:10] <jam> for example "bzr reconcile" has some code to fix incorrect last revision info, but it fails because of the ghost in your history.
[17:10] <jam> also, after my "fix" doing "bzr log -r 1" seems to return the first revision as revno 2
[17:10] <jam> which is just weird
[17:48]  * vila cries
[17:48] <vila> ftp... I hate you
[17:49] <vila> the protocol is messy, the servers interpret it with a crystal ball, trying to run then without being root is a dream, TDD nightmare :-(
[17:49] <vila> s/then/them/ even
[17:55] <jam> vila: then don't use ftp :)
[17:56] <Kinnison> vila: ftp sucks
[17:56] <vila> jam: Ooooh, *I* don't use it :-) I wanted to add chmod support in bzrlib so that bzr-upload users can enjoy it...
[17:56] <vila> Kinnison: I know why now :)
[17:57] <jam> as you wish vila, as you wish.... I've jumped ship a while ago :)
[17:57] <jam> I honestly appreciate that you are willing to work on it
[17:58] <vila> jam: I can see that :-/ But well, I have a patch nearly correct, a single test is still failing because it's damn hard to recognize errors....
[17:58] <jam> vila: both ftp and sftp have *awful* error handling
[17:58] <jam> you basically can't trust that you'll get anything better than "Failed"
[17:59] <vila> yeah, that's a shame, I'm now to the point where I wonder if the best solution will not be to issue *more* commands to get better diagnostics which is kind of weird when trying to avoid LBYL...
[17:59] <jam> well, you could LAYL
[17:59] <jam> (look after you lept)
[17:59] <vila> yeah, my point
[18:00] <jam> though failed is generally failed, even if users want more
[18:00] <jam> tell them to use something that doesn't suck if they want that
[18:00] <vila> that could help raising NoSuchFile or DirNotEmpty instead of PathError
[18:00] <Peng> Nice, Googlebot has used 360 MB of bandwidth spidering Loggerhead, and LP has used 78 MB.
[18:00] <jam> next you'll be telling me that you will be supporting servers that don't have APPE
[18:01] <vila> the other problem I have is that the test suite covers more than is strictly needed... so it's a bit hard to decide when a failed test is really relevant :-/
[18:01] <vila> jam: not worth the effort
[18:02] <vila> I was hoping that adding ftp servers to the local_test_server plugin will be as easy as http, but... root access required sucks
[18:03] <vila> I think I will leave that percolate a bit, I'm too much in anger against that mess right now :-)
[18:04] <vila> I sepdn the whole week on it (part time of course, but yet, several couples of hours) and the conclusion is that, anyway, there are so much requests sent that the performances will always suck
[18:05] <vila> and all of that to finally implementing chmod in our own test server in a couple of minutes...
[18:06] <vila> jam: do we really have users for ftp ?
[18:06] <jam> vila: yeah, we do
[18:06] <jam> :(
[18:07] <vila> Well, at least that means our implementation is correct...
[18:07] <vila> ...correct for our needs :)
[18:08] <vila> jam: anyway, sorry for the rant, I needed to tell it to someone :-)
[18:08] <jam> the only bit I've been seeing is the APPE stuff
[18:08] <jam> rant away
[18:09] <jam> I didn't like *my* time in the ftp code either
[18:09] <jam> I'm happier being an ear to rant towards than being the one doing the work :)
[18:09] <vila> jam: hehe
[18:09] <vila> I'll get back to preparing my submission :)
=== kiko is now known as kiko-fud
=== thekorn_ is now known as thekorn
=== prateeksaxena is now known as prtk
=== mw is now known as mw|food
[19:26] <mkanat> What branch format should I be using for new branches that only I am going to be using?
[19:27] <jelmer> mkanat: rich-root-pack may be a good choice, that's going to be the default in the near future
[19:27] <mkanat> jelmer: Okay.
[19:27] <jelmer> otherwise, the default (pack-0.92) should work fine as well
=== mw|food is now known as mw
[20:06] <Peng> If you use pack-0.92, you can upgrade to rich-root-pack later..
[20:07] <Peng> How does upgrading to a rich-root format work? Does it pick a random file ID for the root? If two people upgrade the same branch, will they use the same ID?
[20:15] <jam> Peng:  I think it standardizes on "TREE_ROOT" as the file id for the root
[20:15] <jam> so all trees share the same root at that point.
[20:16] <Peng> Oh.
[20:16] <Peng> Okay.
[20:19] <abentley> jam: it uses whatever root id was already the root id, but 99.9% of the time, that's TREE_ROOT
[20:23] <Peng> There's a root ID when you're not using a rich root format?
[20:30] <jelmer> Peng: only that implicit one
[20:31] <Peng> Ah.
[22:12] <vila> jam: regarding _can_roundtrip_unix_modebits, did your review implies that we will use it only for our tests and never as part of bzrlib ?
[22:13] <vila> jam: the underlying question being: can I put it into the test classes instead so that I can query the server too ?
[22:13] <vila> to be able to test against server with and server without chmod support ?
[22:14] <vila> hmm, not there anymore, no urgency, since you voted tweak, I can do that in a later patch
[22:42] <jam> vila: I only "_can_roundtrip" be used in the test suite
[22:43] <jam> I only *see* ...
[22:43] <jam> And for example in chroot we do:
[22:43] <jam> def _can_roundtrip_unix_modebits(self):
[22:43] <jam>     return self.server.backing_transport._can_roundtrip_unix_modeb
[22:43] <jam> so you could conceptually do 2 returns based on whether the server can/can't support it
[22:43] <jam> But logically, it just enables the tests for that action
[22:43] <jam> if you say "False" then we skip all the related tests
[22:43] <vila> yeah, I can't imagine using it in bzr anyway, what if it returns False ? :)
[22:44] <jam> So I don't think there is an advantage to testing across that
[22:44] <jam> vila: it is just for the test suite, so we can assert that it really does what we want when we pass a mode bit
[22:44] <jam> If the transport can't support it, it just gets ignored.
[22:45] <vila> hmmm, I see. So the tests are structured to test the mode bits last so that all other features are already tested.
[22:46] <jam> vila: right
[22:46] <jam> if they were *good* tests they would have separated them out
[22:46] <vila> But, if the server doesn't implement it the tests will fail anyway if we say can_roundtrip
[22:46] <jam> I wrote them, though, so you are stuck with what you get :)
[22:47] <vila> jam: good point, now that you said it, I thought about separating them at one point :)
[22:47] <jam> vila: be my guest
[22:47] <jam> I think I wrote that code 2-3 *years* ago
[22:47] <vila> ok, so no problem in putting can_roundtrip into the tests classes instead of the transport classes ?
[22:48] <vila> so that the server can be queried too if needed
[22:49] <jam>        john@arbash-meinel.com-20060116213637-2f4cc1c55769f464 |     def test_unicode_paths(self):
[22:50] <jam> So it seems I wrote it in Jan, 2006
[22:50] <jam> about 2.5 years ago
[22:50] <jam> my TDD was not as good then :)
[22:50] <vila> Ha ! Of course I'll have to write a true ftp.stat() first :-/
[22:51] <vila> Which demonstrate that you're better TDD hacker now :)
[22:51] <vila> s/better/a better/
[22:54] <vila> jam: Do you think that patch can still find its way into bzr-1.6 or is it too late ?
[22:54] <jam> vila: At this point, I have very little idea of when 1.6 will land
[22:54] <jam> so if you merge it *today* I think it will get in :)
[22:54] <vila> hmm, same here :-/
[22:54] <jam> I can't say much outside of that
[22:55] <jam> VersionedFiles and stacking is almost done
[22:55] <jam> the bulk of it has landed.
[22:55] <vila> Ok, last thing before I go to sleep then...
[23:32] <jelmer> lifeless, ping
[23:42] <krow> Hi!  So I just pushed a new tree to Launchpad. I then go and do a bzr branch lp:name from it.
[23:42] <krow> Then I do a bzr merge /tmp/patch
[23:42] <krow> That merge pukes on this:
[23:43] <krow> [brian@piggy drizzle]$ bzr merge /tmp/\[MERGE\]\ bzero\ to\ memset.txt
[23:43] <krow> bzr: ERROR: Revision {('brian@localhost.localdomain-20080625052913-\xc2\xa06upwo0jsrl4lnapl',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x7f89830956d0>".
[23:43] <krow> So...
[23:43] <krow> I know the patch was generated from the recently created tree.
[23:43] <krow> What am I, and I suspect it is me, screwing up?
=== kiko__ is now known as kiko-afk
[23:52] <lifeless> jelmer: pong
[23:53] <lifeless> krow: hi
[23:53] <jelmer> lifeless: So, I've got --stacked working with your shallow-branch branch
[23:53] <jelmer> except...
[23:53] <jelmer> it fetches all revisions
[23:53] <jelmer> s/working/passing tests/
[23:54] <lifeless> krow: you created a cherry pick patch, but the reference branch, the one that is expected to be common to anyone applying the patch, has more history than the one you are applying the patch too
[23:54] <lifeless> jelmer: ok
[23:54] <lifeless> jelmer: uhm, merge in aarons stuff too
[23:54] <jelmer> lifeless, where's that?
[23:55]  * jelmer looks on bb
[23:55] <jelmer> Re: [MERGE] Stacking policy   ?
[23:55] <lifeless> krow: so, what (exact) command did you use to make the patch?
[23:55] <lifeless> jelmer: yes
[23:56] <jelmer> ah, that includes two of the fixes I had already made locally
[23:59] <jelmer> lifeless, nope, that doesn't appear to help (though it doesn't break the tests either)
[23:59] <jelmer> I suspect a bug in one of my FakeVersionedFiles implementations..