[00:04] <jelmer> jam, where does subvertpy live on Windows?
[00:06] <jelmer> igc: btw, it would still be nice to see your RevisionImporter class land
[00:07] <ronny> jelmer: basically i'd have to store blobs, then generate the tress - and finish with the commit
[00:08] <jelmer> ronny, yeah, that's very well possible
[00:08] <dirkD> james_w: i don't understand why it still keeps looking for "/usr/lib/libpython2.4.so", even if i set 'PYTHON_LIBS = -L/usr/lib64 -lpython2.4' and 'PYTHON_LIB_LOC = /usr/lib'
[00:09] <ronny> jelmer: bascially i want to write up a client/server that can start a content-addressed repo for backups, and then send added/removed files
[00:09] <james_w> dirkD: no idea
[00:09] <ronny> i think git is an almost ideal store for incremental backup
[00:12] <lifeless> igc: cool
[00:13] <jelmer> ronny, yeah, I agree it seems quite well suited for something like that
[00:13] <lifeless> ronny: seen duplicity?
[00:15] <ronny> lifeless: yes, dont like it
[00:15] <lifeless> k
[00:17] <dirkD> jelmer, james_w: i had to change PYTHON_LIB_LOC and PYTHON_LIBS not only in ./Makefile, but also in ./src/Makefile . But it doesn't work yet: http://pastebin.com/m9691f84
[00:17] <igc> jelmer: I haven't forgotten about that, though its now a bit more than just revision loading because I needed a thin veneer over a repository and that become it
[00:19] <jelmer> igc: I might also have a look at preparing it for bzr.dev after finishing InterBranch, if that's ok with you?
[00:20] <james_w> dirkD: maybe because you are using nautilus-python that is meant for the new API
[00:20] <dirkD> ok, but isn't it related to libnautilus-extension?
[00:21] <dirkD> http://library.gnome.org/devel/libnautilus-extension/stable/libnautilus-extension-nautilus-file-info.html#NautilusFileInfo
[00:22] <poolie> igc, thanks <https://wiki.canonical.com/Bazaar/Sprints/Brisbane09?action=diff&rev1=13&rev2=14>
[00:25] <dirkD> james_w: i think i have the right version
[00:25] <dirkD> james_w: http://pastebin.com/m16eae94d
[00:27] <spiv> jml: btw, the probable fix for https://bugs.edge.launchpad.net/bzr/+bug/331823 has landed, please let us know how it works out for you
[00:27] <james_w> dirkD: I'm not really sure what's going on, and it's far too late for me
[00:27] <dirkD> for me too :P (1:27)
[00:27] <dirkD> for jelmer too
[00:28] <jml> spiv: thanks. I'm running the nightly build, so it'll be easiest to tell when that updates.
[00:28] <igc> jelmer: sure. Make sure you grab the latest fastimport - revision_store.py is the latest code
[00:29] <jml> Or I guess I can just pull dev and push up an LP branch
[00:31] <lifeless> jml: bug 331823 fix hath landed
[00:32] <spiv> lifeless: you're four minutes behind the times!
[00:32] <lifeless> spiv: heh
[00:34] <jml> what revno?
[00:34] <lifeless> 4043
[00:34] <spiv> jml: 4043<EMAIL_ADDRESS>[00:35] <jml> thanks.
[00:36] <lifeless> igc: great work vis-a-vis emacs
[00:36] <jml> http://paste.ubuntu.com/122611/ that's r4041 on initial push -- that hasn't happened before
[00:36] <lifeless> spiv: my sink fix is merging now
[00:36] <jml> as in, this bit hasn't happened: "Source format does not support stacking, using format: '1.6'
[00:36] <jml>   Packs 5 (adds stacking support, requires bzr 1.6)"
[00:37] <igc> thanks lifeless
[00:37] <jam> jelmer: subvertpy the python files lives inside 'library.zip' with all the other python files. The '.dlls' are in lib/*, IIRC
[00:37] <lifeless> jml: what is your source branch format?
[00:37] <jml> lifeless: source branch == the branch I'm pushing?
[00:37] <lifeless> jml: I hope
[00:38] <jml>         branch: Branch format 7
[00:40] <lifeless> jml: please file a bug
[00:43] <jml> lifeless, spiv: the critical bug is fixed. pushing up a single revision change took only "HPSS calls: 274" and "136.763  return code 0"
[00:43] <lifeless> jml: 'ugh'
[00:44] <lifeless> jml: you might like to try a copy of bzr.dev on the server too
[00:44] <jml> lifeless: haha
[00:44] <jml> lifeless: the server in this case is Launchpad.
[00:44] <lifeless> jml: I know
[00:44] <jelmer> jam: Thanks
[00:45] <jelmer> igc: thanks, will do
[00:45] <jml> lifeless: anyway, two minutes for a single revision sucks, but it was what 1.12 was doing, so the regression is gone.
[00:45] <lifeless> jml: Im serious though, I posted details on using a bzr.dev on e.g. people yourself
[00:47] <lifeless> jml: be great to know if you get the sort of improvements we're seeing in our testing
[00:48] <jml> lifeless: yeah, well I'm not going to install bzr.dev onto Launchpad this week
[00:49] <jml> lifeless: I can try setting up a toy server to experiment with later.
[00:49] <lifeless> jml: some checkout bzr into your homedir on people :P, if you havetime
[00:51] <ronny> can someone point me to docs for conviently using the apis to do things like pull/push/branch
[00:53] <lifeless> ronny: I don't think we've got great docs for that. To reproduce exactly the UI I'd go to builtins.py cmd_pull|push|branch
[00:53] <lifeless> ronny: but generally you can just do branch.push(other_branch), branch.pull(other_branch), and branch.sprout(new_url)
[00:56] <ronny> lifeless: the ui thing seems to do a toon of things more (like handling stacking)
[00:57] <lifeless> ronny: yeah; so big picture I want to put a layer of ui-but-not-cli into bzr, but its not there yet; things like push.py are heading in that direction
[00:57] <dirkD> james_w, jelmer: thanks a lot, it works!
[00:58] <dirkD> and goodnight
[00:59] <ronny> hmk
[01:00] <lifeless> ronny: the push UI specifically handles 'need a new branch' 'target dir is missing' 'explicitly stack' and a couple more
[01:01] <ronny> i think i want to avoid replicating that in anyvc
[01:01] <lifeless> you could use show_push_branch
[01:02] <ronny> yeah, less to replicate
[01:16] <lifeless> yay, sink refactoring landed
[01:18] <poolie> lifeless: dude, put your stuff on the wiki so that maria can book our hotel plesae
[01:19] <lifeless> poolie: sure think
[01:22] <lifeless> poolie: didn't realise it was blocked, I've put the core details on
[01:22] <lifeless> poolie: I'll dig up the itinery thing and get exact flights soon
[01:22] <poolie> ok
[01:23] <poolie> flights wbn, but dates are of course necessary to make the booking
[01:23] <lifeless> I had no idea it was blocked, I've known dates for ages (since I told you I'd booked)
[01:24] <poolie> thanks
[01:27] <jelmer> When I add tests for InterBranch.update_revisions(), should I remove the old tests (except for a trivial one) for Branch.update_revisions(source, ...)
[01:27] <jelmer> ?
[01:28] <poolie> jelmer: probably yes
[01:28] <poolie> maybe just a test that it's finding the interoject that you expect
[01:29] <jelmer> ok
[01:29]  * igc lunch
[01:30] <igc> (probably a long one - back later)
[01:44] <grettke> Hi folks. Question for you. I've got a bzr repo and I would like to keep a svn repo in sync with the bzr repo. How would you go about doing that? Is there a standard approach?
[01:45] <lifeless> install bzr-svn
[01:45] <grettke> lifeless: done
[01:45] <lifeless> if you want to go svn->bzr use bzr svn-import or even just bzr branch svn://path/to/branch (and then bzr pull to incrementally update)
[01:45] <lifeless> for the other way, its bzr push
[01:46] <grettke> lifeless: When I push, it complains that: bzr: ERROR: These branches have diverged.  Try using "merge" and then "push".
[01:47] <grettke> I do just want to branch as I am primarily sharing out to svn in this case, bzr is the master.
[01:47] <lifeless> grettke: try push --overwrite
[01:47] <lifeless> jelmer: ^
[01:48] <grettke> lifeless: Entered. It is working.
[01:48] <grettke> lifeless: I mean "running".
[01:50] <Peng_> Um, I'd do "bzr missing" to help figure out why it thinks they're diverged.
[01:50] <jelmer> grettke, are you pushing a new branch?
[01:51] <grettke> jelmer, It is "new" in that I just created it and there is nothing in it. I created it via svn mkdir before pushing.
[01:51] <Peng_> With a new enough bzr-svn, you don't need to do that.
[01:51] <grettke> I've got 1.12.1
[01:52] <grettke> Peng_: Understood. I shouldn't have had to.
[01:53] <lifeless> grettke: the svn mkdir is what made the branch history different
[01:54] <mwhudson> does anyone here have access to IE?
[01:54] <grettke> lifeless: I see. From here forward, I can just push right to it?
[01:54] <lifeless> grettke: yes
[01:54] <grettke> mwhudson: Internet Explorer?
[01:55] <mwhudson> yes
[01:55] <grettke> mwhudson: yes
[01:55] <mwhudson> grettke: have you used loggerhead before?
[01:55] <grettke> jelmer: I can't find a subvertpy directory in the Windows installation
[01:55] <grettke> mwhudson: no
[01:55] <jelmer> grettke, I've just replied to the bugreport after asking jam
[01:55] <mwhudson> in any case, if you could look at http://bazaar.staging.launchpad.net/%7Eabentley/bzrtools/bzrtools.dev/changes and see if it looks ok and the js behaves that would be awesome :)
[01:56] <jelmer> grettke, it's in a zip file in the lib directory
[01:56] <grettke> jelmer, oh I see you posted, agreed!
[01:57] <grettke> mwhudson: is a change in the UI supposed to occur after clicking on the downward facing arrow icons?
[01:58] <mwhudson> grettke: yes
[02:00] <mwhudson> grettke: i take it from your question that it doesn't?
[02:00] <grettke> grettke: The arrows facedownards, but nothing else.
[02:00] <mwhudson> grettke: it works ok in safari and ff if you can try those to compare
[02:00] <grettke> mwhudson: I Can screenshoot if you like.
[02:00]  * mwhudson swears
[02:00] <grettke> mwhudson: How about opera?
[02:01] <mwhudson> grettke: haven't tried that either
[02:11] <grettke> mwhudson: It does the same thing in Opera.
[02:11] <mwhudson> :(
[03:42] <poolie> igc, we're now getting a decent graph in http://benchmark.bazaar-vcs.org/rrd/runtime-common-suite-all.png
[03:42] <poolie> i haven't reenabled all the branches yet
[03:42] <poolie> however we're getting an error in generating the summary.html so i'm going to look at that
[03:43] <Stanlin> how to use bazaar with eclipse?
[03:49] <lifeless> Stanlin: http://bazaar-vcs.org/BzrEclipse
[03:50] <Stanlin> it doesnt work in windows
[03:50] <lifeless> verterok: ^ you have a fan
[03:51] <Stanlin> it simple cant pull
[03:51] <Stanlin> commits, but doesnt pull
[03:52] <lifeless> what happens
[03:52] <Stanlin> no traffic, just fails
[03:52] <Stanlin> in debian works fine
[03:54] <lifeless> Stanlin: well for starters please report a bug
[03:54] <lifeless> on bzr-eclipse
[03:54] <Stanlin> is bazar cvs or vsc?
[03:55] <lifeless> Bazaar is Bazaar.
[03:57] <Stanlin> i mean
[03:57] <Stanlin> is this a control system?
[03:57] <Stanlin> or versioning system?
[04:00] <spiv> Stanlin: I don't know what you mean by those terms
[04:11] <thumper> Stanlin: some people refer to it as one of the "distributed version control systems" (DVCS)
[04:11] <poolie> spiv/lifeless: in http://bazaar-vcs.org/SmartPushAnalysis1.13 in case 2/3 (push one revision), there are lots of get_parent_map calls after we've inserted the stream
[04:11] <poolie> apparently caused by bug 331823
[04:11] <spiv> poolie: not since this morning
[04:11] <spiv> poolie: :)
[04:11] <poolie> way to go robot you found kitten
[04:11] <thumper> spm: on bzr.dev?
[04:11] <spiv> poolie: new numbers are 28.7s, 19 HPSS calls
[04:12] <poolie> thanks
[04:12] <spiv> poolie: I'm just digging into why case 4 is still apparently suffering from that bug, though.
[04:12] <spiv> poolie: also, the only VFS calls in that 19 are read-only ones
[04:13] <spiv> (gets and stats)
[04:14] <spiv> (Actually, it looks like case 4 is suffering from a different bug that happens to be superficially similar, but it's still worth figuring out exactly what it is)
[04:15] <spiv> It looks like the fix to 331823 also fixed a previously unnoticed bug with update_revisions of a stacked remote branch, which has in turn revealed this issue.
[04:16] <poolie> http://bazaar-vcs.org/SmartPushAnalysis1.4?action=AttachFile&do=get&target=HPSS-push-bzr-logs.tar.gz
[04:16] <poolie> thumper: ^^
[04:17] <poolie> spiv, we should add some tests about stacked branches...
[04:17] <thumper> spiv: a smart push analysis I think poolie means
[04:17] <thumper> spiv: case 8 (or 9), push a new stacked branch
[04:17] <lifeless> poolie: already planned
[04:17] <spiv> Yes, definitely.
[04:17] <thumper> thanks guys
[04:17] <poolie> cool
[04:18] <poolie> those tables are good
[04:18] <poolie> i changed one of them to have three row headings: version, wall time, rpcs
[04:18] <spiv> thumper: push a new stacked branch, also push onto an existing stacked.
[04:18] <thumper> spiv: right
[04:18] <spiv> poolie: thanks, I was intending to do that :)
[04:18] <poolie> thanks
[04:19] <jkakar> How can I create an empty Bazaar branch in a temporary directory, for use in a unit test?  It seems to be missing from http://bazaar-vcs.org/Integrating_with_Bazaar.
[04:19] <spiv> thumper: possibly also with different combinations of modifying new files vs. modifying files whose bases are already present in the stacked branch.
[04:19] <thumper> spiv: I defer to your knowledge on the tests needed
[04:20] <lifeless> jkakar: self.make_branch('foo')
[04:20] <lifeless> jkakar: in TestCaseWithMemoryTransport or any subclass thereof
[04:20] <spiv> jkakar: use TestCaseWithMemoryTransport (or a subclass) -- what lifeless said
[04:20] <jkakar> lifeless: Cool, thanks.
[04:20] <lifeless> jkakar: you _want_ to use that to get full isolation of bzr
[04:21] <spiv> jkakar: http://doc.bazaar-vcs.org/latest/developers/testing.html#test-support
[04:21] <Stanlin> how to make Zend work with bazaar?
[04:21] <Stanlin> zend studio
[04:21] <jkakar> spiv: Awesome, thanks.
[04:24] <lifeless> Stanlin: no idea sorry
[04:24] <Stanlin> i meant
[04:25] <Stanlin> is bazaar a CVS or a SVN?
[04:25] <igc> polie: that graph looks good; let me know if I can help with the summary.html issue
[04:25] <thumper> Stanlin: what?
[04:25] <igc> poolie: ^^^
[04:25] <thumper> Stanlin: its a VCS
[04:25] <poolie> :?
[04:25] <thumper> Stanlin: a DVCS even
[04:25] <poolie> igc i'll get back to it when thumper lets go of my ear :)
[04:26] <poolie> Stanlin: it's like both but much better
[04:26] <spm> thumper: ? i gather you were after andrew not me?
[04:26] <Stanlin> well im asking that, because Zend has the option for CVS and SVN, dunno what to use
[04:27] <thumper> spm: yes
[04:27] <thumper> spm: tab completion sometimes gets you fist
[04:27] <thumper> s/fist/first
[04:27] <spm> and here was me thinking 'fist' was you being excessively NZerish for 'first'... ;-)
[04:27] <thumper> Stanlin: what is Zend?
[04:27] <spiv> Stanlin: Bazaar is not a drop-in replacement for CVS or SVN
[04:28] <spiv> Stanlin: it works in a different (and better) way, but tools that expect to invoke CVS or SVN won't automatically work with Bazaar.
[04:29] <lifeless> thumper: zend is a proprietary php ide
[04:29] <Stanlin> oh i see, thats why bazaar doesnt work in windows
[04:29] <spiv> Stanlin: Bazaar works in windows.
[04:30] <lifeless> Stanlin: bazaar works fine in windows; did you file the bug on bzr-eclipse I asked you to? (The primary developer of bzr-eclipse is in argentina and won't be awake at the moment, so if you want the problem fixed he needs a bug report)
[04:31] <Stanlin> ok ill prepare it
[04:40] <poolie> thumper: End getting all value/timestamp matches to Function End took 0.0423979759216 seconds
[04:42] <Stanlin> what connection type uses bazaar?
[04:42] <poolie> http, ssh, sftp, https, etc
[04:42] <Stanlin> pserver? ext? extssh? pserverss?
[04:43] <poolie> it has equivalents to those but it's not the same protocol as cvs or svn
[04:44] <poolie> thumper: http://bazaar-vcs.org/Roadmap, http://bazaar-vcs.org/Roadmap/BrisbaneCore, http://bazaar-vcs.org/Roadmap/SmartServer
[04:45] <poolie> ... https://wiki.canonical.com/Bazaar/Migration, Bazaar/Projects <https://wiki.canonical.com/Bazaar/Projects>
[04:47] <poolie> Draft Specs/Easy Workspace Setup <http://bazaar-vcs.org/DraftSpecs/EasyWorkspaceSetup>
[05:05] <Stanlin> how to specify the protocol for bazaar? aint working with https
[05:05] <Stanlin> do i need to point to the trunk?
[05:06] <thumper> Stanlin: what are you trying to do?
[05:10] <spiv> Stanlin: you may find http://doc.bazaar-vcs.org/latest/ helpful, in case you haven't already seen it.
[05:12] <Stanlin> im trying to connect from zend
[05:12] <Stanlin> usin svn
[05:13] <lifeless> Stanlin: bzr is not svn, if you're using svn you should seek help in a svn channel - e.g. #svn
[05:13] <Stanlin> but i want to use bzr
[05:13] <lifeless> Stanlin: if the code you want to get access to is in a bzr branch you need to use bzr.
[05:14] <Stanlin> yeah i want to force bzr to become svn
[05:14] <spiv> bzr isn't svn.
[05:15] <spiv> It's a bit like asking for WordPerfect to be MS Word ;)
[05:17] <spiv> Perhaps try asking the Zend community if anyone has integrated bzr?
[05:19] <Stanlin> whats the channel for zend?
[05:20] <Stanlin> i mean, i like eclipse but we use zend framework which zend studio is perfect
[05:20] <Stanlin> ok brb
[05:21] <Stanlin> i need to sleep
[05:26] <berto-> hi, if i want to submit a merge directive is the email address<EMAIL_ADDRESS>?
[06:05] <bialix> vila: ping
[06:07] <bialix> hmmm. I don't think he's sleeping. fullermd said real hackers never sleep
[06:16] <bialix> vila: please look at my comment for https://bugs.launchpad.net/qbzr/+bug/333892
[06:17] <bialix> ubottu say vila about my fix
[06:17] <bialix> pff
[06:18] <bialix> ubottu: next time try harder and say this to vila
[06:18] <bialix> ubottu -- you're empty can
[06:19] <bialix> yeah, yeah. train yourself
[06:23] <lifeless> poolie: I'm done for the day, but perhaps you'd like a small chat ?
[06:24] <poolie> lifeless: sure, call me?
[06:25] <lifeless> sure
[07:01] <vila> hi all
[07:26] <creek23> hi, how do i output a diff on a patch file? it only displays it on command prompt -- im on windows.
[07:39] <ignas> hi
[07:42]  * igc dinner
[08:03] <lifeless> creek23: I'm not sure
[08:03] <lifeless> creek23: is this in the gui or the console?
[08:06] <creek23> console
[08:07] <vila> lifeless: Are you still there long enough to talk about some _commit_write_group problem I encounter in bbc ?
[08:09] <lifeless> creek23: I thought windows supported '> filename ' syntax
[08:09] <creek23> ...? how do i do that?
[08:09] <ignas> why logger head has revisions "inverted", i mean - when looking at a revision through the web - let's say 2534 "next" button points to 2533, while previous to 2535... shouldn't it be the other way
[08:09] <lifeless> bzr diff > foo.patch
[08:18] <creek23> thanks lifeless... its working now.
[08:26] <lifeless> vila: always, but there will be latency
[08:26] <lifeless> I'm in the middle of other things
[08:27] <vila> lifeless: high latency is better than infinite latency :-)
[08:28] <vila> So, the problem I encounter is that during a commit on a MemoryTree the _write_group is None when  self.work_tree.update_basis_by_delta(self.rev_id,  self.builder.get_basis_delta()) is called in Commit.commit()
[08:28] <lifeless> vila: seems appropriate to me
[08:28] <lifeless> vila: it should be None
[08:28] <vila> ok
[08:30] <vila> The problem is we can't build an CHKInventory then. This is where I want some input: should we even try to build one and if not why do we end up trying ?
[08:30] <lifeless> vila: you shouldn't be building on in the working tree object :)
[08:31] <lifeless> vila: you can _construct_ a CHKInventory, for an existing CHKInventory in the repository, outside of a write group
[08:31] <lifeless> but update_basis applies a delta to a inventory
[08:31] <lifeless> ...
[08:31] <lifeless> so this is MemoryTree
[08:31] <lifeless> which has no persistent basis
[08:32] <lifeless> probably it just needs an overridden update_basis_by_delta - see the one in MutableTree and think about what MemoryTree needs :P
[08:33] <vila> but how comes commit can work for chk without that ?
[08:34] <vila> First test ever trying to run with a MemoryTree ?
[08:34] <ronny> when is on-disk stability for brisbane-core planned?
[08:37] <lifeless> ronny: soon, a few weeks
[08:38] <lifeless> vila: WorkingTree4/5 have a real apply_delta thing in there
[08:38] <lifeless> vila: MutableTree is for WorkingTree3 and MemoryTree
[08:42] <vila> lifeless: right, so that's because it's the first test using a memory tree for chk repo, right ?
[08:45] <lifeless> I imagine so
[08:45] <lifeless> at least the first doing a commit
[08:46] <vila> lifeless: ok, thanks, that gives me the right context :)
[08:48] <lifeless> np
[09:00] <mwhudson> ignas: i guess the idea is that you start at the tip
[09:00] <mwhudson> ignas: i agree it's a bit ass-backwards
[09:01] <ignas> mwhudson: i think being backwards is a binary choice - it either is or is not ;)
[09:01] <Coke> Hi guys. I'm confused about the distinction of repository and branch. I have my repository under DIR A, I check it out under DIR B. The strange thing is, DIR A is completely empty aside from .bzr.  The repos still only has .bzr files
[09:04] <ignas> i did not even know you could do that
[09:05] <lifeless> Coke: so you did something like "bzr init-repo A" "bzr init A" "bzr checkout A B" ?
[09:05] <Coke> lifeless: not init-repo, just init
[09:05] <lifeless> Coke: ok
[09:05] <lifeless> Coke: so A is a *branch*
[09:05] <lifeless> pure and simple
[09:06] <Coke> uh.
[09:06] <Coke> ok.
[09:06] <Coke> I have to make them into repositories then?
[09:06] <lifeless> 'bzr init' makes branches
[09:06] <lifeless> no you don't need to do anything else
[09:06] <lifeless> what does 'bzr log' report in A
[09:06] <ignas> Coke: you should bzr update the A branch
[09:06] <ignas> Coke: then the files you have commited in B will appear
[09:07] <Coke> ignas: yes
[09:07] <Coke> so, how can I make it a real repos from this branch?
[09:07] <ignas> Coke: it's a "real" repo
[09:07] <lifeless> Coke: its already real.
[09:07] <ignas> Coke: but the working tree is only updated explicitly i think
[09:07] <lifeless> Coke: I'm gonig to guess, that A is on a remote server
[09:07] <lifeless> Coke: would that be right ?
[09:08] <Coke> lifeless: yeh, but it's mounted locally
[09:08] <lifeless> Coke: as far as bzr is concerned, is it seeing the local mount for A, or are you using a network protocol
[09:08] <Coke> local mount
[09:09] <Coke> told you
[09:09] <ignas> lifeless: i just tried it locally, bzr ci in a checkout of a branch, does not update the working tree of the original branch
[09:09] <lifeless> I'm not doubting you, I'm just making sure we're communicating clearly
[09:10] <lifeless> ignas: right, its not == push
[09:10] <lifeless> Coke: ok so here is whats going on; the checkout command is designed for folk wanting to emulate svn/cvs where there is a centralised spot that all commits go to
[09:10] <Coke> I don't need to emulate it .
[09:10] <ignas> lifeless: oh, so bzr ci is not just "commit locally + push", it's just something simmilar to it
[09:10] <Coke> I've done init-repo on my source repos now
[09:11] <Coke> So, what do I do to make my working copy in my home dir? not co?
[09:11] <lifeless> ignas: bzr ci with a bound branch is a two-phase commit direct to the branch object thats checked out
[09:11] <Coke> I think they should have ditched the SVN terminology, if you're switching from svn it's confusing
[09:12] <lifeless> Coke: well, given that svn repositories are also just a .svn directory on the server, I don't agree. But lets get you up and running ?
[09:12] <lifeless> Coke: you can use checkout if you want.
[09:12] <Coke> what is the bzr way
[09:12] <lifeless> Coke: alternatively you can use branch and then use push to push commits back to the other branch
[09:13] <lifeless> Coke: bzr supports a few different ways, for different use cases
[09:13] <Coke> it says I cannot check out, my repos is not a branch
[09:13] <Coke> what the hell?
[09:13] <Coke> the repository has to be a branch?
[09:13] <lifeless> right, repos are not branches. As I said above you *do not need to do anything*
[09:14] <Coke> lifeless: I want to see the files in the actual repos
[09:14] <lifeless> Coke: repositories are not branches, you don't need to care about repositories at all.
[09:14] <lifeless> Coke: Ok. We can do that. Can I ask, why you have both A and B?
[09:14] <Coke> What I did before 1) bzr init /sourcedir  2) bzr co /sourcedir /projectdir
[09:15] <Coke> lifeless: because I want versioning
[09:15] <Coke> all the files on the server are backed up
[09:15] <lifeless> ok
[09:15] <Coke> if you're going to question/make me change our entire network setup to accomodate bzr I'll just switch source tools
[09:15] <lifeless> I'll be slightly delayed for a bit here, real life things happening
[09:15] <lifeless> Coke: I am not trying to do that, I'm trying to make sure I actually give you what you want.
[09:16] <Coke> I don't know what I want.
[09:16] <Coke> How is it done with BZR?
[09:16] <Coke> Right now I'm not even sure my commits are working properly
[09:16] <Coke> no files in the "repository"????
[09:16] <ignas> Coke: why do you want to see the source code in /sourcedir?
[09:16] <ignas> Coke: you don't expect that from svn do you?
[09:16] <Coke> ignas: comfort?
[09:16] <Coke> ignas: yes
[09:17] <ignas> Coke: nope, svn repository is an opaque object, that you can't see inside of
[09:17] <ignas> Coke: so if you want to use bzr co and bzr ci - just trust it ;)
[09:17] <Coke> What should I use?
[09:17] <ignas> and when you don't trust it - go over to /sourcedir and bzr up
[09:17] <Coke> Like I said, I don't WANT to use anything
[09:17] <Coke> ignas: bzr up does not work on one of the ...  So branch has left it's original english and programming meaning to become what used to be "repository"?
[09:21] <lifeless> we're reiterating because you're not answering the questions I'm asking which are designed to let ignas and I know what you have configured so we can tell you what it will do
[09:21] <Coke> lifeless: like I've said, nevermind what I want or what I have, I want to know how to do it bzr style
[09:21] <lifeless> Coke: no, a branch is a branch - its a line of development, the tip of a DAG
[09:21] <Coke> lifeless: but the main source repository isn't a branch
[09:21] <Coke> it may contain branches
[09:21] <ignas> Coke: no
[09:21] <Coke> (in the SVN sense)
[09:22] <Coke> ignas: ok
[09:22] <ignas> Coke: no, the main source is not a branch container
[09:22] <Coke> if not, let me ask you this: what did my branch actually branch off from?
[09:22] <ignas> Coke: the main source is a branch, branches are all over the place
[09:22] <Coke> a branch needs something branch off from, this is the one and only source I have
[09:22] <lifeless> Coke: your branch B branched off the branch A that you inited.
[09:22] <Coke> no wonder I didn't get it, branch is misused
[09:23] <lifeless> Coke: in fact, because you made B using 'bzr checkout' you have one branch - A, and a checkout of A called B
[09:23] <Coke> it's a bzr branch even though by english and svn meaning it's not
[09:23] <lifeless> its a branch in svn meaning
[09:23] <Coke> lifeless: branches are grown from the main repos in svn
[09:24] <lifeless> though svn is vague on that; its a branch in CVS and git and hg meaning
[09:24] <Coke> well, svn is shite, that's why I'm switching
[09:24] <ignas> Coke: you are confusing branches, repositories, branch containers and working trees
[09:24] <Coke> tried both hg and git, didn't like the way they handled stuff
[09:24] <Coke> "branch CONTAINERS"?
[09:24] <Coke> working tree?
[09:24] <Coke> Is there a bzr primer?
[09:24] <lifeless> ignas: I think you're adding confusion :)
[09:24] <Coke> I just want 1, 2, 3, 4
[09:24] <Coke> done
[09:25] <lifeless> ignas: cause I don't know what a branch container is
[09:25] <lifeless> Coke: there sure are docs
[09:25] <lifeless> http://doc.bazaar-vcs.org/latest/
[09:25] <Coke> 1) bzr command of some sort -> your main source is setup correctly, 2) bzr command of some sort -> your main source is copied to my local project dir ready for commits
[09:25] <Coke> that's just two steps
[09:25] <lifeless> you've done that
[09:25] <Coke> Indeed.
[09:26] <lifeless> and if you would run 'bzr log A' you'd see that your commits are there safe and sound
[09:26] <Coke> so no worries that the files are missing?
[09:26] <lifeless> no worries at all
[09:26] <lifeless> I really regret that you've had some confusion here
[09:28] <Coke> cvs -> svn -> bzr   I basically got through that by using svn and bzr as I would cvs
[09:28] <lifeless> Coke: 'bzr log A' will show the commits A has
[09:28] <lifeless> 'bzr log -v A' will show you more details
[09:28] <Coke> I think compatibility with the older, lesser versioning systems is the mistake
[09:28] <ignas> lifeless: http://info.wsisiz.edu.pl/~blizinsk/git-bzr.html "Differences between Git and Bazaar" (the document I got the branch container term from)
[09:29] <Coke> one just just empty the cup completely and start anew
[09:29] <lifeless> the big difference betwen bzr and cvs is that branches in CVS are just labels, but in bzr they are separate directories (which is close to svn, but not as free-form)
[09:29] <ignas> Coke: yeah, i think so too, which is why I use Darcs for my small hobby projects ;) (wouldn't suggest it to you though)
[09:29] <Coke> lifeless: yeh
[09:29] <Coke> here's waht my impression is though, bzr has no main repository
[09:29] <lifeless> the big difference between bzr and svn is that bzr doesn't need a server or main repo at all
[09:30] <lifeless> it can start in a single location and scale up from there
[09:30] <ignas> the Distributed part ;)
[09:30] <Coke> it's just a collection of branches, you just decide on a per-branch basis where you wan to put your changes?
[09:30] <lifeless> yup
[09:30] <Coke> ok
[09:30] <Coke> that's quite different from svn
[09:30] <Coke> well, glad that's cleared, was worrying that all my commits had gone missing
[09:30] <Coke> it does make sense now
[09:31] <Coke> I could init my project direcotry and check the files in from the same dir
[09:31] <lifeless> we _do_ have a hidden repository object, but its *solely* for disk-space optimisation, so in common use you don't need it. And as its just a database its not very useful on its own, so we try to avoid talking about it.
[09:32] <ignas> lifeless: sometimes I think that you should have named it "shared something" instead of "shared repository" to reduce the confusion
[09:33] <bialix> monsieur vila?
[09:34] <vila> bialix: yup
[09:34] <bialix> vila: my fix is just better version of your yesterday patch
[09:34] <bialix> I've tried to use Unavailable Feature but failed
[09:34] <bialix> because it seems I can;t use lazy import in test modules
[09:35] <bialix> it failed with traceback then
[09:35] <Coke> Ok, so here's the deal.
[09:35] <vila> bialix: May be I can help ? Where is your fix ?
[09:35] <vila> bialix: lazt_import is not for tests, that's for sure
[09:35] <Coke> bzr init /myreposmount/someproject; bzr co /myreposmount/someproject mylocaldir
[09:36] <Coke> then I just use ci -m, update, log and status inside mylocaldir as I please
[09:36] <Coke> am I still within the comfort zone of bzr there?
[09:36] <lifeless> Coke: totally
[09:36] <bialix> vila: I'm not sure this problem require too much efforts
[09:36] <Coke> Sweet. Thanks boys!
[09:36] <lifeless> my pleasure
[09:37] <bialix> vila: my branch https://code.launchpad.net/~qbzr-dev/qbzr/bug-333892
[09:37] <vila> bialix: sure, but easing selftest use is worth it IMHO :)
[09:37] <bialix> vila: actually I'm just wrap addTestFromModuleName into tre-except ImportError
[09:38] <bialix> vila: this way I'm skipping not all qbzr tests, but only those that required PyQt4 libs
[09:38] <vila> bialix: that's indeed better than my fix
[09:38] <bialix> vila: with qt libs we have 30 tests to run; without - 13 test
[09:39] <bialix> vila: I'm just want to ask you about my warnings
[09:40] <Coke> I switched to launchpad just for their bzr support
[09:40] <bialix> vila: here is my diff: http://bazaar.launchpad.net/~qbzr-dev/qbzr/bug-333892/revision/630
[09:40] <vila> bialix: pulling your branch, just a sec
[09:40] <Coke> Then it turns out that it doens't provide any way to upload files or screenshots.
[09:40] <Coke> Which is complete suckage.
[09:40] <lifeless> Coke: it can upload files
[09:41] <lifeless> Coke: you just need to have a release
[09:41] <lifeless> Coke: not sure about screenshots, have you asked on #launchpad ?
[09:41] <bialix> vila: I hope you excuse moi for my harmless game with ubottu :-)
[09:42] <vila> bialix: hehe, bots are our friends, we should take care of friends, always ;)
[09:42] <bialix> you think I offend it?
[09:43] <bialix> poor ubottu :'-)
[09:43] <Coke> lifeless: yeh, screenshots on their website faq is "not yet"
[09:43] <Coke> lifeless: I'll try that release thingie
[09:43] <mwhudson> ignas: https://bugs.edge.launchpad.net/loggerhead/+bug/297930 fwiw
[09:44] <Coke> I'm currently making a barcode library, so far all EAN encodings work nicely. Going for code-128 today.
[09:45] <Coke> I was planning on making it available on launchpad just because it's easy for me to switch the, uhmm... "branch root" (?) to launchpad.net
[09:45] <ignas> mwhudson: that makes me sad...
[09:46] <mwhudson> maybe i should change the links to "older" and "newer"
[09:47] <Coke> What do I call the "original" branch? the one you want people working against
[09:50] <bialix> vila: so you qbb:approve my fix? ;-)
[09:51] <vila> bialix: ok, I think what you've done is best than what existed, the way you did it doesn't allow using UnavailableFeature, which is a bit unfortunate, but certainly the best you can do
[09:52] <bialix> vila: UnavailableFeature cannot be used because to load modules we need to import PyQt4
[09:53] <lifeless> Coke: 'trunk'
[09:53] <bialix> vila: I've tried and failed
[09:53] <lifeless> Coke: or 'mainline' sometimes, but most folk call it 'trunk'. Oh, another possible term is 'project.dev'
[09:53] <Coke> Oki doki
[09:56] <vila> bialix: the idea is that you should wrap the import pyqt4 or define some TestFeature that tests can then use, but that would certainly be far more invasive than your actual fix
[09:57] <bialix> wrapping import pyqt4 does not help, because the tests will try to import qbzr modules, and these modules in turn also will try to import pyqt4
[09:57] <vila> bialix: in the end, that's your code, for me, as a user or even occasional contributor, the most important point is being to run selftest without the need to enable/disable the plugin 40 times a day :-)
[09:57] <vila> bialix: yes, you should wrap everywhere... that's why I say invasive :-)
[09:57] <bialix> vila: I've asked you about those warnings
[09:57] <bialix> is it ok?
[09:57] <vila> bialix: warnings are fine, I can visual-grep-v them :-)
[09:58] <bialix> I've used trace.note, so IIRC they could be suppressed with bzr selftest -q
[09:58] <bialix> ok.
[09:58] <bialix> thanks
[09:58] <bialix> will push to trunk shortly
[10:03] <awilkins> Coke: What's your barcode library written in?
[10:03] <bialix> vila: why you say all the time "qbzr is my code"? it's not fair and actually incorrect.
[10:04] <bialix> qbzr is written by luks, me, garyvdm and markh
[10:04] <bialix> 4 men, most of them much better hackers than me alone
[10:07] <vila> bialix: saying that it's not your code isn't true either, I don't forget the orthers, but it's not like I was talking to someone who didn't *en *know* the code
[10:07] <vila> s/*en/even/
[10:08] <vila> bialix: yet, it's more your code than mine because you know it far better than me
[10:08] <bialix> ok, I forgot that in English you and you written by the same word.
[10:09] <bialix> in Francais is not IIRC
[10:10] <vila> bialix: you (singular) and you (plural) are indeed different in French tu (singular), vous (plural)
[10:11] <Coke> awilkins: Pythohn
[10:11] <bialix> yep, I'm sorry. OK
[10:11] <vila> bialix: I had a fight with my gf long ago because one day I said *my* house instead of *our* house :-)
[10:11] <bialix> :-D
[10:11] <vila> bialix: in the end qbzr is GPL right ? So it's really *our* code, whoever we are :)
[10:11] <bialix> yep
[10:11] <Coke> lifeless: where's the release stuff in launchpad?
[10:13] <Coke> I see no way to upload files to launchpad. "Downloads" is empty and no way of adding any files there.
[10:15] <bialix> branch format 7 != 1.9?
[10:17] <bialix> Coke: you have to create release first
[10:17] <Coke> There's no option to create a release
[10:17] <Coke> I can register a series
[10:17] <Coke> I can make announcements.
[10:18] <Coke> ctrl+f doesn't find "release" anywhere on the page
[10:18] <bialix> go to your series
[10:18] <bialix> you'll see "make release" link
[10:19] <Coke> i have a series named "1.0"
[10:19] <Coke> Holy crap.
[10:20] <Coke> I'm 100% sure that programmers have built the interface for launchpad
[10:20] <Coke> When you have to use the search function to find menu options in an UI you know programmers have designed it
[10:20] <lifeless> lol
[10:20] <Coke> The option to make a release is via "series" (doesn't even mention "release" on the details)
[10:20] <lifeless> yes
[10:20] <Coke> There are FOUR option menus that switch around depending on where you are.
[10:21] <Coke> Either you use top tabs, and then there's the middle tabs, you have links in the middle of the page and now it seems releases are handled via a special menu to the right.
[10:21] <Coke> I might consider buying the Appple bible of UI design and send it to the launchpad crew.
[10:24] <Coke> How can BZR know about launchpad-login??
[10:24] <bialix> you told it
[10:26] <Coke> so bzr can run any arbitrary command name?
[10:27] <bialix> almost. but I won't do the sandwitch for you
[10:27] <bialix> even if you say "sudo"
[10:29] <Coke> Oh, it supports plugins
[10:29] <Coke> neet
[10:29] <bialix> heh. s/I won't/bzr won't/
[10:30] <Coke> Here's what I don't understand, it took the svn guys years to complete svn and it was a total failure. When did Bazaar start as a project?
[10:30] <bialix> between 2004 and 2005
[10:31] <Coke> How does bzr obtain my email address when I commit to trunk?
[10:32] <bialix> run `bzr whoami`
[10:32] <Coke> how do I change it?
[10:33] <gnomefreak> is it known that bzr is saying you dont have permission to push branch (its a brand new branch
[10:33] <bialix> `bzr whoami "My Name<EMAIL_ADDRESS>[10:33] <bialix> bzr whoami -h ftw
[10:34] <gnomefreak> to be exact http://pastebin.mozilla.org/628162
[10:34] <bialix> gnomefreak: perhaps you're trying to push with http:// URL
[10:35] <Coke> what would be the "bzr way" to do tags
[10:35] <gnomefreak> nope im using the lp:~gnomefreak/....
[10:35] <gnomefreak> bialix: ^^
[10:35] <bialix> gnomefreak: try again with -Derror option
[10:36] <bialix> you should have your SSH key registered at LP
[10:36] <bialix> Coke: bzr way?
[10:36] <bialix> `bzr tag` is not good enough for you?
[10:36] <gnomefreak> bialix: i do
[10:37] <bialix> -Derror will print more info about problem
[10:37] <bialix> ah
[10:37] <bialix> yep
[10:37] <bialix> gnomefreak: you can't use this URL
[10:38] <bialix> lp URLs has 3 parts: username/projectname/branchname
[10:38] <bialix> you have 4
[10:38] <gnomefreak> i think i see that. i changed it and ill let you know
[10:38] <gnomefreak> yep i used extra it has created it. thanks
[10:38] <bialix> you need to choose another branchname instead of "greasemonkey/greasemonkey.upstream"
[10:39] <Coke> oooufffffff.
[10:39] <Coke> It's just tooooo complicated to make proper releases in launchpad.
[10:39] <Coke> I don't get it, I made a series, it's a competely new branch now
[10:39] <Coke> How do I tag 1.0 ?
[10:40] <bialix> first time everything is hard, is not?
[10:40] <Coke> no
[10:40] <Coke> sourceforge was quite pleasant
[10:40] <Coke> albeit slow
[10:40] <Coke> ok, so each version is it's own branch
[10:41] <bialix> Coke, look at http://bialix.com/qbzr/docs/make_release.html
[10:41] <bialix> this is my instruction how to do QBzr release
[10:41] <bialix> I wrote it for myself and other QBzr guys
[10:42] <bialix> Coke: you can tag the trunk with "1.0" label or use separate branch and tag it. does not matter
[10:44] <Coke> I tagged it now
[10:44] <Coke> and I have a separate branch
[10:46] <Coke> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
[10:46] <Coke> HPSS calls: 1 <bzrlib.smart.medium.SmartSSHClientMedium object at 0x138fa90>
[10:46] <Coke> permission denied, public-key
[10:46] <Coke> ah.
[10:46] <Coke> ofcourse.
[10:48] <Coke> bialix: is it possible to add a release on a trunk tag?
[10:50] <Coke> I'm quite possitive this could not have been made any more complex.
[10:54] <Coke> It appears that you have to link a branch in launchpad to get it into a release
[10:54] <Coke> That means tags can't be used.
[11:03] <Coke> Bleh, sorry for pestering you with these bullshit noob questions...
[11:03] <Coke> http://launchpad.net/crosswordpuzzle
[11:03] <Coke> I think I've managed to make my first release.
[11:05] <Coke> I did tag the revision, so 1.0rc1 should be "frozen" in time, but I'm using the same branch (trunk) for the 1.0 series. Don't see the point of forking unless there are simultaneous changes in trunk and 1.0, but im the only developer so...
[11:05] <Coke> Time for lunch.
[11:05]  * bialix back
[11:06] <bialix> this will work
[13:20] <igc> night
[13:50] <jam> night igc, morning vila
[13:52] <jam> jelmer: why did you mark bug #334326 as invalid after reporting it?
[13:52] <jelmer> jam: It was a cold cache issue
[13:53] <jelmer> jam: running bzr st on the wrong disk
[13:53] <jelmer> jam: it takes less than 2 seconds on a disk with a warm cache
[13:53] <vila> jam: hi !
[13:53] <jelmer> jam: Which I think is reasonable for 2Gb and 75k files :-)
[13:53] <jam> jelmer: can you just mention that on the bug?
[13:53] <jam> I think we could be doing better in cold-cache situations, though that isn't the current focuse
[13:53] <jelmer> jam: I did, but it looks like it hasn't come through yet on lp
[13:53] <jam> hi vila
[13:53] <jam> jelmer: ah, ok, np then
[13:54] <jam> I just saw the "invalid" change
[13:54] <jelmer> jam: The checkout one is valid though, and quite annoying
[13:55] <jam> jelmer: what version are you running?
[13:56] <jam> I just submitted a couple patches for review which might address this specifically
[13:56] <jelmer> jam: my own strange mix of brisbane-core and my own patches that haven't been merged yet
[13:56] <jelmer> jam: Ah, cool
[13:57] <jam> jelmer: so phase one of the patch was this: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C49A45A9D.5040303%40arbash-meinel.com%3E
[13:57] <jam> You might want to try *just* that fix, and see what it does for you
[13:57] <jam> (When extracting fulltexts, we weren't reading in forward-sorted order, which is a bit naughty)
[13:57] <jelmer> jam: checkout is a pity, since most other things seem to work well (status, commit, log)
[13:57] <jelmer> jam: Thanks, I'll give that a try
[13:58] <jam> I have another patch on top of that, which may help more
[13:58] <jam> though the fact you are hitting such high memory consumption is a bit strange
[13:58] <jam> certainly if you are swapping
[13:58] <jam> things get uber-slow
[13:58] <jelmer> I'm not swapping
[13:59] <nicolaide> i have some problems try download from launchpad using bzr... the error is that
[13:59] <nicolaide> bzr: ERROR: Invalid http response for http://bazaar.launchpad.net/%7Enotify-osd-developers/notify-osd/main/.bzr/repository/packs/f8097ae6b0b6a1353502801617edd7cf.pack: Expected a boundary (Wb_/GvfIMKppD)jWz:C-) line, got ''
[13:59] <nicolaide> someone can help me?
[13:59] <jam> nicolaide: sounds like you have a broken squid proxy
[14:00] <jam> (known issue that has been fixed in squid for a year or 2)
[14:00] <jam> I think we have a workaround
[14:00] <nicolaide> mmm....and how can i fix that problem?
[14:01] <jam> nicolaide: so the bug is #198646
[14:01] <jam> bug #198646
[14:02] <jam> nicolaide: I assume you can't do anything about your squid proxy, right?
[14:03] <nicolaide> i dont have any idea of that
[14:03] <jam> nicolaide: the easy fix is to use "bzr launchpad-login" with your launchpad username
[14:03] <jam> after which we'll connect via ssh rather than http
[14:03] <nicolaide> mmm... i try...
[14:03] <nicolaide> stay tunned
[14:03] <nicolaide> jeje
[14:03] <nicolaide> No Launchpad user ID configured.
[14:47] <jelmer> abentley: hi
[14:49] <abentley> jelmer: Hi
[14:49] <jelmer> abentley: I put up a patch a couple of days ago that merges clean-tree into bzr core
[14:49] <jelmer> abentley: Are you still ok with moving it?
[14:51] <abentley> jelmer: I have mixed feelings.
[14:53] <jelmer> abentley: What about in particular?
[14:54] <abentley> I don't like the core command set getting bigger, and I don't like everything good getting ripped out of bzrtools.
[15:02] <jam> jelmer: do we still get the performance benefits in 0.5+ if you use the old mapping?
[15:03] <jelmer> abentley: I agree we shouldn't end up merging all of bzrtools into bzr core, but clean-tree is common enough to be in core imo
[15:04] <awilkins> jelmer: Yes, when you push revisions to a 1.4 repository using 1.5 libraries, the bzr: properties are revprops and not fileprops.
[15:04] <awilkins> jelmer: Sorry, latency on that was a bit long
[15:04] <jelmer> awilkins, ah, cool
[15:04] <jelmer> awilkins, :-)
[15:04] <jelmer> jam, some of the benefits, yes
[15:04] <jam> jelmer: so specificaly, I'm thinking of the python.org conversion. What would they gain by switching mappings?
[15:05] <jam> As blowing away an existing conversion has a lot of knock-on effects
[15:05] <jelmer> jam: pushing back into subversion wouldn't need svn file properties
[15:06] <jam> jelmer: isn't that only with svn >= 1.5 ?
[15:06] <jam> I guess they are using 1.5.1 according to: http://svn.python.org/projects/python/trunk/
[15:06] <jelmer> jam: Also with newer 1.4's, as awilkins just reported
[15:09] <jam> jelmer: so the big win there is just that they aren't *visible* ? Or does it scale better, or ?
[15:14] <jelmer> jam, it also scales better
[15:14] <jelmer> jam, file properties require one roundtrip per revision
[15:15] <jelmer> jam, revision properties come in with the log data
[15:15] <jam> jelmer: though if someone else is doing the conversions for you... it doesn't change much, does it?
[15:16] <jelmer> jam: Well, you also need to fetch that data when you push
[15:17] <awilkins> jelmer: Not with 1.4 ; with a 1.4 repository as long as you are using 1.5 libraries (the specific scenario I was using was the 1.5 file:/// provider)
[15:17] <jelmer> jam: "bzr co" on OOo trunk is now down to 43 minutes
[15:18] <jelmer> with your sort knit fetch patch
[15:18] <jam> jelmer: down from?
[15:19] <jam> jelmer: the next step is to check out: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C49A47EDF.2050001%40arbash-meinel.com%3E
[15:19] <jam> Which may or may not improve things
[15:20] <jelmer> jam: Down from somewhere between 45 to 55 minutes.
[15:21] <jam> aka, a little, but not very significant
[15:21] <jam> we should really teach pack about grouping texts together...
[15:23] <jelmer> jam: Yeah, a significant amount of time is spent in seek()
[15:23] <jelmer> during the actual import itself it was close to 20%
[15:25] <jam> jelmer: that is converting from bzr-svn, right?
[15:25] <jam> Do you know if you cache parent texts?
[15:25] <jelmer> jam: yes, I cache parent texts (in bzr-svn)
[15:27] <jelmer> actually, that code wasn't there yet when I was doing the import
[15:27] <jelmer> so it may actually be better now
[15:28] <jam> jelmer: when converting texts from subversion, you just use "get_record_stream()" which passes FulltextContetFactory, is that right?
[15:29] <jam> (btw, it would probably be better to use ChunkedContentFactory, so you don't have to ''.join(lines))
[15:29] <jam> which causes the target repo to switch over to "foo.add_lines()"
[15:29] <jam> but that doesn't use any caching.
[15:29] <jelmer> jam: well, svn deltas are on the fulltext
[15:30] <jelmer> not on lines
[15:30] <jam> jelmer: I'm talking about "versionedfiles.py line 78"
[15:30] <jam> line 70: lines = stream.readlines()
[15:30] <jam> line 78
[15:31] <jam> FulltextContentFactory(..., bytes=''.join(lines))
[15:31] <jelmer> jam: ah
[15:31] <jelmer> jam, That's only used during stacking, but worth optimizing anyway - thanks
[15:31] <jam> jelmer: ah, so what is the code path for "bzr branch $SVN" ?
[15:32] <jelmer> jam, all in fetch.py
[15:32] <jelmer> RevisionBuildEditor is the object that Subversion reports changes to
[15:37] <jam> jelmer: line 561
[15:37] <jam> self.editor.texts.insert_record_stream([
[15:37] <jam>     FulltextContentFactory((self.file_id, text_revision),
[15:37] <jam>         [(self.file_id, revid) for revid in text_parents],
[15:37] <jam>         text_sha1,
[15:37] <jam>         fulltext)])
[15:37] <jam> So my earlier comment is still correct
[15:37] <jam> you insert the texts 1 at a time
[15:37] <jam> as a Fulltext
[15:37] <jam> which then is translated in '.insert_record_stream()' into an add_lines() call
[15:37] <jam> which doesn't cache the parent_texts
[15:38] <jelmer> jam, That's a corner case situation though
[15:39] <jam> jelmer: I haven't been able to track down the bulk-insert yet, then
[15:39] <jelmer> jam: FileRevisionBuildEditor._close()
[15:39] <jam> That is line ~561 isn't it?
[15:39] <jelmer> yeah
[15:40] <jam> self.editor.texts.insert_record_stream([]), and inserting a stream which is 1 entry long, and uses a FulltextContentFactory
[15:41] <jelmer> jam: It used to be add_lines() but IIRC lifeless recommended using insert_record_stream() here to avoid splitlines()
[15:41] <jam> jelmer: I'll write up a patch.
[15:41] <jam> the big win is being able to cache recently inserted texts
[15:41] <jam> I'll ping you with a patch in a second
[15:41] <jelmer> jam: thanks
[15:42] <Peng_> You mind if I mark someone's bug as a duplicate?
[15:42] <jam> unfortunately, there is some munging you have to do to get between fulltexts and a Content object
[15:42] <jam> :(
[15:42] <jam> but I'll still see what I can do
[15:42] <jam> it could be pretty big
[15:48] <jam> jelmer: is _text_cache used for anything else? Or could I put 'lines' in there, instead of 'fulltext' ?
[15:49] <jelmer> jam: you could put lines there
[15:49] <jam> k
[15:50] <jam> and self.file_stream
[15:50] <jam> I can do "readlines()" instead of '.read()' ?
[15:50] <jelmer> jam, It's a LRUSizeCache though, so the max size of it would have to be reduced
[15:50] <Peng_> (Bug 328148 and bug 321750.)
[15:50] <jelmer> jam, yeah
[15:50] <jam> jelmer: I can change the "measure length" function
[15:50] <jam> so as to remain accurate
[15:50] <jam> sum(map(len, lines)) :)
[15:51] <jam> (I've done this before :)
[15:51] <jelmer> jam, :-)
[15:51] <jelmer> peng_: go for it
[15:54] <barry> jam: so, i want to get the c.p.o mirrors updated, packed, and mirroring the svn masters again.  do you have some time to help me set that up the right way?
[15:55] <jam> barry: first, you need to install bzr-svn on the appropriate machine
[15:55] <jam> Then we will need to look at this: http://paste.ubuntu.com/122880/
[15:55] <barry> jam: @dinsdale[~/python:1006]% bzr plugins
[15:55] <barry> bzrtools 1.12
[15:55] <barry>     Various useful commands for working with bzr.
[15:55] <barry> launchpad
[15:55] <barry>     Launchpad.net integration plugin for Bazaar.
[15:55] <barry> netrc_credential_store
[15:55] <barry>     Use ~/.netrc as a credential store for authentication.conf.
[15:55] <barry> svn 0.5
[15:55] <barry>     Support for Subversion branches
[15:56] <jam> barry: any chance to get svn 0.5.2 ?
[15:56] <jam> jelmer just mentioned he has done perf improvements and bugfixes
[15:56] <jam> 0.5 is good enough if it is hard to do others
[15:56] <barry> jam: is that in a ppa?
[15:57] <barry> jam: this is a debian lenny box but i've hacked in the ppa for bzr from hardy
[15:57] <barry> jam: and it seems to work okay :)
[15:57] <jam> barry: it isn't yet. jelmer?
[15:57] <barry> jam: we have svn 1.5.1 on the machine
[15:58] <jam> barry: so for now, we'll go with what you have
[15:58] <barry> jam: cool
[15:58] <jelmer> barry: 0.5.2 is in experimental
[15:58] <sevenseeker> I have code that is neither in svn or bzr, if I init the bzr environment, and I need to eventually import this into svn, can I then update the svn repos?  If so, where do I supply the svn info?
[15:59] <barry> jelmer: i don't want to do too much admin tweaking on this box, but adding a ppa would be okay
[15:59] <Peng_> jelmer: :)
[15:59] <jam> barry: we just need to get jelmer to update the ppa :)
[15:59] <jam> but for now 0.5.0 is probably good enough
[15:59] <barry> jam: cool
[16:00] <jam> barry: so it seems the next step is to log in as the user that will be doing the conversions
[16:00] <jam> (whoever runs the cron script)
[16:00] <jam> and set "default-mapping =v3" in ~/.bazaar/bazaar.conf
[16:00] <barry> jam: can we trigger the update from an svn hook?
[16:01] <jam> barry: I know there are ways to do something like that. *I* don't know them
[16:01] <sevenseeker> should I first import to svn, then checkout a fresh copy via bzr and go from there?
[16:01] <jam> I think the ones I've seen trigger on the email generated by the svn hook
[16:01] <jelmer> sevenseeker, either would work
[16:01] <jam> I don't know svn well enough
[16:01] <barry> jam: okay, no worries.  for now i'll do the updates as a cron
[16:01] <jam> I would guess it would be something simple
[16:01] <jelmer> barry, doing it inside of the post commit hook means svn commit won't finish until the bzr mirror has updated
[16:01] <sevenseeker> jelmer: thank you, just looking for best practices is all :)
[16:02] <jelmer> sevenseeker, committing to svn first would probably be easiest
[16:02] <jam> jelmer: would you expect that to take long for simple updates?
[16:02] <barry> jelmer: i hadn't thought about that
[16:02] <jelmer> jam: In 0.5.0, it could be noticable
[16:03] <jelmer> jam, barry: is there any particular reason for going with the v3 mappings? Lots of existing branches that depend on it?
[16:03] <barry> jelmer: ok, for now i think i'll just run it from a cron every minute...?
[16:03] <jam> jelmer: "lots"? not sure, but we had trouble getting them to upgrade to 1.9
[16:03] <jelmer> barry: yeah, that should work
[16:04] <barry> jelmer: yeah.  i really don't want to ask the py-devs to have to update their branches after i've just asked them to update their clients ;/
[16:04] <barry> jelmer: these are experimental mirrors so when the experiment is over, we can make real ones using the better format
[16:05] <jam> jelmer: when is "apply_textdelta" used?
[16:05] <barry> jelmer: iow, i hate to require that people blow away their branches right now
[16:05] <jelmer> jam: apply_textdelta is called to report delta's for a particular file
[16:06] <jelmer> jam: it's called for any text change
[16:06] <jam> jelmer: k, but is/isn't it used during conversion?
[16:06] <jelmer> jam: it's used heavily during conversion
[16:06] <jam> don't worry, I think I have it sorted out
[16:06] <jam> you hide its actually calls behind the VF api
[16:06] <barry> jam, jelmer we have a bzrdev user that owns the branches currently, and holds the ssh authentication tokens.  should we make that user also do the mirroring?
[16:06] <jam> texts.get_record_stream()
[16:07] <jam> barry: makes the most sense to me
[16:07] <barry> jam: no security issues that you can think of?  (i can't)
[16:07] <jam> barry: it seems like it is a trusted user already
[16:08] <jam> and it only needs *read* access to the svn repo
[16:08] <barry> cool
[16:08] <barry> jam: so, add a ~/.bazaar/subversion.conf for that user?
[16:09] <jam> It looks like you can put it in ~/.bazaar/bazaar.conf, but having subversion.conf is probably still a good thing
[16:09] <barry> jam:  we have no bazaar.conf right now
[16:10] <jam> jelmer: so when converting, you insert a text of "link XXX" for symlinks?
[16:10] <jelmer> jam: yes, and set a magic file property
[16:10] <jam> jelmer: but why do that for bzr?
[16:10] <jam> since bzr never pays attention to the texts of symlinks
[16:11] <jelmer> jam: where do I set that?
[16:11] <jam> I just see you doing "if fulltext.startswith('link' )"
[16:11] <jam> and I'm trying to figure out how to handle it
[16:12] <jam> You insert the fulltext *before* you check for whether it is a symlink or a file
[16:12] <jam> and I was trying to understand why
[16:12] <jam> (I would insert empty lines for a symlink, though I don't think it specifically hurts anything)
[16:12] <jelmer> jam: A symlink can be magically changed into a regular file
[16:13] <jelmer> jam: and in that case we need to know the base against which we'll receive delta's
[16:13] <jam> barry: sorry we didn't tell you about the "don't disconnect my internet" flag
[16:13] <barry> jam: not sure if this made it through:
[16:13] <jam> :)
[16:13] <barry> % cat subversion.conf
[16:13] <barry> default-mapping = v3
[16:14] <barry> jam: man, my router is so royally f'd ;)
[16:14] <jam> barry: looks right to me. what about you jelmer?
[16:15] <jelmer> barry, it should be in the relevant [UUID] section
[16:15] <jam> jelmer: can it just be the default?
[16:15] <jam> for what they are doing at least
[16:15] <jelmer> in that case it should be in bazaar.conf
[16:15] <barry> jelmer: yeah, i don't know what that means ;)
[16:16] <jam> barry: put it in ~/.bazaar/bazaar.conf :)
[16:17] <barry> % cat bazaar.conf
[16:17] <barry> [DEFAULT]
[16:17] <barry> # Use the old bzr-svn mappings for now so that users don't have to re-get
[16:17] <barry> # any of their existing branches.  This should be removed and the new
[16:17] <barry> # mappings used when the experiment is over.
[16:17] <barry> # barry 25-Feb-2009
[16:17] <barry> default-mapping = v3
[16:18] <barry> jam, jelmer ^^
[16:18] <jam> +1 (AFAIK)
[16:20] <barry> jam: cool, thanks.  now we have to set up the cronjob, right?  what's the command for updating the existing branches?
[16:20] <barry> jam: is it a (cd wherever; bzr pull http://svn.python.org/blah) ?
[16:20] <jam> jelmer: does "svn-import" update? Or is it just "for branch in branches: bzr pull" ?
[16:20] <jam> barry: that should be fine, I'm just not sure if there is a svn-import command that would bring in all branches at once
[16:20] <jelmer> jam: It will craete new branches when they appear in svn
[16:21] <jelmer> barry, you probably want to use "bzr svn-import --incremental"
[16:21] <jelmer> that will only fetch new svn revisions
[16:21] <barry> oh, i should note that we don't want to import all svn branches, becuase we have a bazillion of them
[16:21] <jam> barry: branches are cheap in bzr, are you sure?
[16:21] <jam> I suppose the total history may get bigger
[16:22] <barry> jam: right now we have just 2.5, 2.6, 3.0, py3k and trunk
[16:23] <barry> jam: hmm.  we have 77 branches in svn.python.org/python/branches
[16:23] <barry> i guess it wouldn't be too bad.  let's do what's easiest
[16:23] <barry> we've got 188GB free, so that shouldn't be a problem
[16:23] <jam> I would think "svn-import --incremental" would be easiest
[16:24] <jam> since it runs across the whole repo in one pass
[16:25] <barry> jam: okay cool.  since this is running on the svn machine, should i use the svn repo file path as the FROM_LOCATION?
[16:25] <jam> presumably
[16:25] <jam> you probably want to run it manually once
[16:25] <jam> to make sure
[16:26] <barry> and TO_LOCATION would be the shared repo dir containing the .bzr directory, right?
[16:27] <jam> right
[16:28] <barry> jam, jelmer okay cool, thanks.  so --incremental is the only svn-import switch i'll need?
[16:28] <jelmer> barry, yep
[16:29] <barry> jelmer: great, thanks.
[16:29] <barry> jam, jelmer now i know you wanted me to do a pack. can i just do that after the svn-import runs?  note that we haven't been updating the mirrors in many days
[16:30] <jelmer> barry, bzr should be autopacking
[16:31] <jam> jelmer: I want an explicit pack, because it changes the indexes
[16:31] <jam> barry: should be fine
[16:34] <barry> jam: so just to make sure: bzr svn-import --incremental followed by bzr pack, right?
[16:36] <jam> barry: right. You don't need to "bzr pack" during cron
[16:36] <jam> just this one time
[16:36] <barry> jam: gotcha
[16:36] <barry> jam: thanks
[16:36] <barry> let me run these commands and see how they go!
[16:44] <sevenseeker> running 'svn checkout http://foo.com/bar/trunk bar-trunk' works for me, but with bzr 1.12 switching 'svn' with 'bzr' like 'bzr checkout http://foo.com/bar/trunk bar-trunk' does not work and says...
[16:45] <sevenseeker> bzr: ERROR: Not a branch: "http://foo.com/bar/trunk"
[16:45] <jelmer> sevenseeker, do you have bzr-svn installed?
[16:45] <sevenseeker> got this from http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#bzr-svn
[16:46] <sevenseeker> jelmer: I did... its possible it is messed up I guess, so let me reinstall
[16:46] <jelmer> sevenseeker, you can check by running "bzr plugins"
[16:46] <sevenseeker> argh! not there
[16:46] <jam> jelmer: I'm seeing test failures with svn "trunk"
[16:47] <jam> replay_snapshot() takes at least 5 arguments (4 given)
[16:47] <sevenseeker> its been awhile since I installed it... maybe I didn't reinstall when I upgraded bzr to 1.12
[16:47] <jelmer> jam, your bzr-rebase is outdated
[16:47] <jam> k
[16:50] <sevenseeker> ok, I reinstalled 0.5.2 via easy_install from source, but it is not showing up in the plugins
[16:51] <jam> jelmer: now I'm getting a failure in: test_fetch_signature
[16:51] <jam> has no revision svn-v4:137f067b-b28 ...
[16:51] <jam> (this is with trunk, to make sure the test suite is clean before I apply my changes)
[16:52] <jelmer> sevenseeker, I don't think easy_install works for bzr plugins
[16:53] <sevenseeker> jelmer: oic
[16:53] <jelmer> jam: trying here
[17:01] <jelmer> jam: all tests pass here
[17:01] <jelmer> jam: lp:bzr-svn ?
[17:02] <jam> jelmer: yep, and bzr.dev
[17:02] <jam> $ bzr revision-info
[17:02] <jam> 2675<EMAIL_ADDRESS>[17:07] <jam> jelmer: does it matter that I'm using subvertpy 0.6.1?
[17:08] <jam> I'm also getting failing "dpush" tests
[17:08] <jelmer> jam: What's the error message for the dpush failures?
[17:08] <jam> AssertionError: not equal:
[17:08] <jam> a = 'unknown:\n  foofile.BASE\n  foofile.THIS\nconflicts:\n  Contents conflict in foofile\n'
[17:08] <jam> b = 'modified:\n  foofile\n'
[17:09] <jam> and another with "Unexpected return code"
[17:09] <jelmer> jam: Perhaps you have bzr-git installed as well?
[17:09] <jam> probably
[17:09] <jam> I also see: ValueError: Only svn:log can be set with Subversion 1.4
[17:09] <jam> So maybe my local SVN is old?
[17:09] <jelmer> jam: Ah, yeah, that would explain the failures
[17:10] <jam> jelmer: nope, no bzr-git
[17:10] <jelmer> svn 1.4 would explain it though
[17:10] <jelmer> the dpush thing is a bug though; it seems to accidently be setting revprops there while it shouldn't
[17:11] <jam> k
[17:11] <jam> I just need a baseline so I know my code isn't breaking *more* stuff :)
[17:16] <jam> I think I have a reasonable patch, which I can let you test in a second
[17:16] <jam> finishing the test suite run now
[17:24] <rodolfo> hi all
[17:25] <rodolfo> yesterday i installed bzr-gtk and still didnt figure out how to use: 1) nautilus integration, 2) what's that notification icon on my tray all about?!
[17:26] <jam> jelmer: do you create a new RevisionBuildEditor for each revision?
[17:27] <jelmer> jam: Yes
[17:27] <jelmer> uhm
[17:27] <jelmer> no
[17:27] <jam> jelmer: so the text_cache is regenerated each rev
[17:27] <jam> I'm inserting something into self.editor._XXX
[17:27] <jam> but then I never find it again
[17:28] <jelmer> jam: yeah, you're right
[17:28] <jelmer> pointless cache :-)
[17:28] <jam> jelmer: so we might want to rethink  the text_cache
[17:32] <jelmer> jam: Pushed a fix
[17:39] <Peng_> jelmer: Did you mean to make a change to commit.py in your "Fix import." commit?
[17:39] <Goundy> Hi.
[17:40] <Goundy> How to commit and push a branch by keeping the commits messages got from a merge ?
[17:40] <jelmer> peng_: Yes
[17:40] <jelmer> peng_: The commit message is incomplete :-)
[17:41] <Peng_> jelmer: Ok, just making sure. :)
[17:41] <Peng_> Goundy: If you run "bzr merge" and "bzr commit", the merged revisions will be listed in the log. (Unless you did a cherrypick.)
[17:42] <Goundy> Peng aborting commit write group: BzrCommandError(empty commit message specified)
[17:43] <Goundy> Peng and if I specify a message I'm screwed cuz I loose my messages got from merge
[17:43] <Goundy> what's a cherrypick ? ôO
[17:44] <jam> jelmer:  care to try out: http://bzr.arbash-meinel.com/plugins/svn/add_lines_cache/
[17:44] <jam> With my trivial testing, it makes a modest improvement
[17:45] <jelmer> jam: checking
[17:46] <jelmer> jam: Are chunks random blocks of data?
[17:46] <jelmer> jam: or is there more to it?
[17:46] <Goundy> Peng any hint ? :-)
[17:50] <jam> "chunked" means that it is a list of strings
[17:50] <jam> so "lines" is a chunked
[17:50] <jam> as is [fulltext]
[17:51] <Goundy> well guys are you sure nobody have a little idea about my issue ?
[17:51] <Goundy> It's making me stuck...
[17:51] <Goundy> And I already screwed my history tree I don't want to put more rubbish inside it :/
[17:52] <jam> Goundy: I doubt you are "screwed"
[17:52] <jam> try committing with a message
[17:52] <jam> and then doing "bzr log"
[17:52] <jam> it should show the commit messages for the merged revs
[17:52] <jam> (just indented)
[17:53] <pickscrape> Is anyone aware of any integration between bzr and cruisecontrol?
[17:53] <Goundy> jam well I know that it works but I'm just trying to keep my meaningful messages for each file that comes from the merge destination....
[17:54] <jam> I'm pretty sure "bzr log file" will also give you what you want
[17:54] <jam> as would "bzr gannotate file"
[17:54] <KhaZ> pickscrape: No, I'm not sure.  That said, check out TeamCity - it rocks Cruise Control.
[17:54] <KhaZ> pickscrape: (Not sure if it works with bzr either, however.  We use it at work tho, and prefer it over CC).
[17:54] <pickscrape> KhaZ: does it handle PHP projects well?
[17:55] <jelmer> jam: so ideally, bzr-svn should be working with chunks?
[17:55] <jam> jelmer: for some values of "ideally".
[17:55] <jam> I think they are generally better
[17:55] <jam> as they are more trivial to convert to lines or fulltexts
[17:56] <jam> and you can have *part* of your content shared
[17:56] <pickscrape> KhaZ: ah, it's not free is it...
[17:56] <jam> (so 2 texts for the same file can share 90% of the content, just the lines that have changed are diff)
[17:57] <jelmer> jam: Any reason you call chunks_to_lines() ? Is that really necessary?
[17:57] <jam> jelmer: chunks aren't guaranteed to be lines
[17:57] <jam> so if you want to work in *lines* (like for .add_lines()) you have to call it
[17:57] <jam> that said, chunks_to_lines() was written with that in mind
[17:57] <jam> chunks_to_lines(lines) is very fast
[17:57] <jam> and returns the original object
[17:58] <Goundy> jam ah indeed bzr log gives all what I want but not loggerhead so it's a launchpad problem and not a bzr one
[17:58] <Goundy> Thank you
[18:01] <jam> barry: how's it going?
[18:01] <jam> (I don't see any updates to code.python.org yet)
[18:02] <barry> jam: nope, i got nervous so i'm doing a fresh import into a test directory, which is still running.  i wanted to see what branches it ends up with because i forgot that that svn repo has the sandbox an dlots of other crud
[18:02] <jelmer> jam, We don't seem to actually require chunks to be lines anywhere
[18:02] <jam> jelmer: does 'bzr svn-import' use a 1.9-r-r format by default?
[18:02] <jelmer> jam: Except when self.file_data wasn't changed
[18:03] <jelmer> jam: No, it uses rich-root-pack
[18:03] <jam> jelmer: we do during the "add_lines()" call
[18:03] <jam> but yes, that is the only time
[18:03] <jelmer> jam: But we call read_lines() to obtain the data we feed to add_lines()
[18:03] <jam> It was more to leave "file_data" as always lines
[18:03] <jam> but we can make it always chunks
[18:04] <jelmer> jam: http://pastebin.ubuntu.com/122932/
[18:04] <jam> jelmer: fine with me
[18:05] <barry> jam, jelmer opps, i'll need to import to a 1.9-r-r format i guess.  when i do the real incremental import will that work automatically if the target branches are 1.9-r-r?
[18:06] <jelmer> barry, it won't change the format of existing items
[18:06] <barry> jelmer: but all the new branches?
[18:06] <jelmer> barry, so if you create a 1.9-r-r repo before you start, it should work fine
[18:06] <barry> gotcha
[18:15] <Peng_> When will bzr stack without me explicitly requesting it? When branching from LP? When pushing to LP? What?
[18:16] <beuno> Peng_, pushing
[18:16] <Peng_> beuno: Do I ever have to worry about it on "bzr branch"?
[18:17] <beuno> Peng_, why would you worry?
[18:17] <beuno> if you want it stacked, you add --stacked to the branch command
[18:17] <beuno> but it doesn't stack at all by default
[18:17] <beuno> Launchpad can't force you to  ;)
[18:18] <Peng_> beuno: Alright. That's what I wanted to make sure of. Thanks.
[18:25] <jelmer> jam: Merged, thanks!
[18:55] <thumper> beuno: actually stacking by default on LP does work
[18:55] <thumper> beuno: the branch will be stacked on the development focus branch
[18:55] <thumper> beuno: if and only if your local repository format supports it
[18:56] <thumper> beuno: unless there were more bug fixes I haven't checked
[18:56] <thumper> beuno: and you're running with a bzr later than 1.7
[18:57] <thumper> Peng_: if you have a local branch in format 1.6 and push to LP for a project that has a dev focus branch set, LP will try to stack it for you
[18:57] <thumper> Peng_: actually LP tells the bzr client to stack it
[19:11] <LarstiQ> thumper: I suppose lp doens't have shared repositories for multiple branches in the same (owner, project) combo yet?
[19:11] <LarstiQ> (if ever)
[19:20] <jam> jelmer: so did you see a performance difference?
[19:21] <KhaZ> pickscrape: There's a free version of it, but it is limited somewhat.
[19:26] <jam> LarstiQ: I think with stacked, they are working around the issue
[19:26] <LarstiQ> jam: that is indeed why I asked :)
[19:29] <bialix> yo LarstiQ, how your vacations?
[19:31] <LarstiQ> bialix: too short, but good! Thanks for asking :)
[19:31] <LarstiQ> had good weather (snow out, -8, clear sky and sun)
[19:31]  * bialix wanna get vacation too, but can't
[19:31] <bialix> that's nice
[19:32] <bialix> I'm reworking UI of the scmproj
[19:32] <fullermd> Vacations are so exhausting.  You always have to deal with people saying things like "Oh, where are you going?"
[19:32] <bialix> now it's much more usable
[19:33] <fullermd> ...   what do you mean, going?  I'm locking the door, taking the phone off the hook, and sleeping for 2 weeks straight...
[19:33] <LarstiQ> :)
[19:33] <LarstiQ> fullermd: in my case it's usually "Finland, visiting my girlfriend"
[19:33] <bialix> fullermd: ya, I know what you talking about
[19:34] <fullermd> Going somewhere is something you then have to lock the door, take the phone off the hook, and sleep for 2 weeks straight to _recover_ from.  Defeats the purpose.
[19:37] <LarstiQ> bialix: so how is scmproj coming along?
[19:38] <bialix> I've starting actively uising it at work.
[19:38] <bialix> I think nested trees should rocks
[19:39] <bialix> but even with my emulation I've got measurable boost
[19:39] <bialix> I can finally implement very complex build configuartion for my project
[19:39] <bialix> and this is fantastic.
[19:40] <bialix> Too bad nested trees was in coma so long
[19:40] <bialix> I'm working on tutorial now.
[19:41] <LarstiQ> bialix: that's good to hear
[19:42] <bialix> I've forced to rework model a bit, but in the end it's just improve usability (based on my dogfooding experience)
[19:43] <bialix> I hope it's no more so clunky as before
[19:43] <bialix> it was really is
[19:45] <bialix> I found many interesting ideas in git submodules
[19:45] <bialix> but in the same time their submodules are so "spartan"! you have to do many boring operations manually
[19:46] <bialix> it seems just like a half-hour hack
[19:47] <bialix> but bzr still don't have anything, so git won by scores 1:0
[19:52] <bialix> ok. thanks for listening. have to go. bye.
[20:24] <barry> jam: bzr: ERROR: parent_id {18549@6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Fbranches%2Frelease20-maint:Lib%2Fidlelib} not in inventory
[20:26] <jam> barry: can't say I've seen that specific issue. But it is claiming that "Release20-maint:Lib" isn't present, when  its child "idlelib" is being addedd
[20:26] <jrydberg__> anyone here installed bzr using fink?
[20:26] <jam> this certainly wasn't one of the branches you used to be converting
[20:27] <jam> I don't know if jelmer knows what would cause that sort of traceback (but he may be sleeping by now)
[20:27] <barry> jam: right.  i think it's a byproduct of running 'bzr svn-import' over the whole svn repo
[20:27] <jam> barry: sort of. I don't see how bzr-svn wouldn't be able to convert something that could be represented in svn, without giving a different error.
[20:28] <barry> jam: might be interesting to check out that branch over svn and see i end up with?
[20:28] <jam> barry: probably a good starting point
[20:29] <jam> (I could understand if it was a path that svn supports that bzr doesn't, like with a '\', but I don't see that happening here)
[20:29] <barry> jam: that's probably a pre-svn branch iirc.  i don't remember when we upgraded from cvs to svn
[20:29] <jam> If it helps, it looks like revno 18549 is when this file was originally introduced
[20:29] <jam> barry: considering you are at 44k or so, I would guess it is also a cvs time
[20:30] <jam> but still, if it is valid in svn, I don't see why we couldn't represent it at this poin
[20:30] <jam> point
[20:30] <jam> oh, and it idlelib is the directory which is missing
[20:30] <jam> I misread the original error
[20:30] <jam> the *parent_id == ...idlelib* is missing
[20:31] <barry> jam: yep.  i just checked out the branch, which went fine, but there is no Lib/idlelib
[20:31] <jam> barry: can you try an older rev?
[20:31] <jam> to see if there used to be one
[20:33] <barry> jam: let's see if i can remember how to do that :)
[20:33] <jam> svn co -r 20000 should work, IIRC
[20:33] <jam> either that or
[20:33] <jam> svn co $URL@20000
[20:33] <barry> jam: thanks
[20:36] <barry> jam: cvs2svn was run at r18549 and nothing before that appears to be 'svn up'able
[20:36] <barry> svn: Target path does not exist
[20:37] <jam> does that mean you already had a svn repo, and then you pulled in things from cvs?
[20:37] <jam> or that the existing svn was pure conversion up to r18549?
[20:37] <barry> jam: svn log says...
[20:37] <barry> r18549 | (no author) | 2001-01-02 12:07:49 -0500 (Tue, 02 Jan 2001) | 2 lines
[20:37] <barry> This commit was manufactured by cvs2svn to create branch
[20:37] <barry> 'release20-maint'.
[20:40] <jam> barry: so can you do "svn co -r 18549 $SVN/python/branches/release20-maint"
[20:40] <jam> ?
[20:40] <barry> yep
[20:40] <lifeless> moin
[20:40] <jam> barry: and is there a Lib/idlelib in there?
[20:40] <jam> morning lifeless
[20:40] <jelmer> barry, hi
[20:40] <barry> jam: nope
[20:40] <jelmer> barry, that's caused by a bug in 0.4 that's now fixed :-/
[20:40] <jam> jelmer: so is it the old mappings causing the problem?
[20:41] <jam> he's using 0.5.0
[20:41] <barry> jam: yeah
[20:41] <jelmer> jam: Well, sortof
[20:42] <jelmer> jam: An import using the new mappings would of course never cause problems since there's no older interpretation you could conflict with
[20:45] <barry> jam: otp w/thumper
[20:45] <jelmer> barry, This is importing into an empty bzr repository ?
[20:46] <jam> jelmer: that is what he said earlier
[20:46] <jam> on a machine that didn't do the earlier import
[20:46] <jam> so it wouldn't have anything cached
[20:46] <jelmer> oh, hmm
[20:46] <jelmer> couldn't be the different interpretation then
[20:46] <jelmer> barry, and this is the python repo?
[20:47] <jam> jelmer: yes
[20:47] <jam> svn.python.org/python/ IIRC
[20:48] <lifeless> bug 334326
[20:48] <lifeless> jelmer: ^ why invalid?
[20:48] <jelmer> jam: I'll give that a try
[20:48] <jelmer> lifeless, crap I closed the wrong one
[20:49] <jelmer> lifeless, the "bzr st" one is invalid
[20:50] <jelmer> lifeless, fixed
[20:56] <jelmer> jam: btw, do the tests for InterBranch look ok ?
[20:57] <barry> jelmer: it is importing into an empty bzr repository
[20:57] <jelmer> barry, I'm trying to reproduce it
[20:57] <jam> jelmer: http://svn.python.org/projects/python/trunk is the trunk branch
[20:57] <jam> I had the wrong url
[20:57] <jelmer> barry, whereabouts does it fail?
[20:58] <barry> jelmer: time bzr svn-import --incremental /data/repos/projects/ experiment
[20:58] <barry> jelmer: bzr: ERROR: parent_id {18549@6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Fbranches%2Frelease20-maint:Lib%2Fidlelib} not in inventory
[20:59] <calc> is there any way to have a partial repo checkout like what is normal with cvs and svn?
[20:59] <calc> eg i want to have dirs a/b a/c a/d and be able to just checkout a/b
[20:59] <jam> calc: in general, checkout granularity is at the *branch* level, so you can checkout less than a whole repository, but not less than a whole branch
[21:00] <lifeless> calc: its intended but not implemented
[21:02] <barry> jelmer, jam would it make sense to switch to updating only the handful of branches i really care about (for now)?
[21:03] <jam> barry: it may save *you* some time :)
[21:03] <jam> jelmer: I just sent in a review
[21:03] <jam> I'll also comment that some of this may conflict with stuff like RemoteBranch and streaming code.
[21:04] <jam> otherwise it seems ok
[21:04] <calc> lifeless: ok
[21:04] <calc> hmm well this will create a bit of a mess in my lp repo
[21:04] <calc> i'll have something like 15 branches per release now :-\
[21:05] <barry> jam: ;)  what's the best way to do that. not svn-import i'm guessing.
[21:05]  * calc wonders if he can add more to the lp bzr path eg sub repo's
[21:06] <jam> barry: for the *first* time 'bzr branch svn...' for later times 'cd XXX; bzr pull'
[21:06] <jam> afaik
[21:06] <jam> another alternative is to use a 'custom' layout
[21:06] <jam> which defines just the branches you want to convert
[21:07] <jam> let me see if I can come up with that quickly
[21:07] <barry> jam: ah yes!  duh.  i can just bzr pull in the directories we already have
[21:08] <jelmer> jam: Thanks
[21:08] <jelmer> barry: Hopefully I'll have a fix more the main issue in a few minutes
[21:08] <barry> jelmer: ok, cool.  any chance of a ppa? :)
[21:09] <jam> barry: something like: http://paste.ubuntu.com/123015/
[21:09] <jelmer> barry: For which Ubuntu release?
[21:10] <barry> jelmer: debian lenny :)  but so far hardy has been working for bzr/bzrtools
[21:10] <jam> Hardy, I believe
[21:10] <barry> jam: is that hex string an example, or specifically what i should use?  i have no idea what that means
[21:10] <jelmer> I'm trying hard to stay away from being the maintainer of various things in PPA, as there's plenty packages I have to worry about as is
[21:10] <barry> jam: and that goes in subversion.conf, right?
[21:10] <jam> barry: the hex string is specifically what you should use
[21:10] <jam> barry: it is the UUID for your svn repository
[21:10] <jam> (I took it from the error message you gave)
[21:11] <barry> jam: gotcha
[21:11] <barry> jam: thanks
[21:11]  * barry tries
[21:11] <jam> I don't know if "projects" is in there or not, as I don't know where your svn root is
[21:11] <jam> but it *looks* like that may be correct
[21:12] <barry> jam: projects is the root of the filesystem repo, but i don't believe it's in the urls
[21:12] <jam> jelmer: do you have debian lenny packages then? I know you do the "debian/experimental" stuff
[21:13] <jelmer> jam: I've been looking at providing backports for lenny
[21:13] <jelmer> jam, Also so they can be used on alioth
[21:13] <jelmer> since the bzr 1.5 smart server (which is in lenny) is kinda slow
[21:14] <lifeless> jelmer: have you tried push with .dev to .dev this week ?
[21:14] <jelmer> lifeless: "No revisions to pull." :-P
[21:14] <lifeless> 'push'
[21:14] <jelmer> oh, right (-:
[21:15] <jelmer> lifeless, what do you mean exactly?
[21:15] <barry> jam: the paths in branches: are those svn paths or bzr paths?
[21:15] <jam> barry: svn paths
[21:15] <barry> jam: cool, thanks
[21:15] <jam> jelmer: he wants you to test the latest streaming code in bzr.dev
[21:15] <jelmer> jam: ah
[21:15] <jam> which has a couple new smart verbs, etc
[21:15] <jelmer> lifeless, no, I haven't tried that yet
[21:16] <lifeless> jelmer: I sent a mail to the list
[21:16] <jelmer> problem is I don't control most of the bzr smart servers I connect to
[21:16] <igc> jam: fyi, lifeless had tweaked his groupcompress branch: http://bazaar.launchpad.net/~lifeless/+junk/bzr-groupcompress/revision/29
[21:16] <lifeless> jelmer: andrew and I have landed streaming push etc
[21:16] <jelmer> lifeless, Yeah, I saw some interesting things fly by
[21:16] <igc> jam: the second part of that is missing from your branch - don't know how much it matters
[21:17] <lifeless> jelmer: and you can use a homedir checkout on the server
[21:17] <igc> morning all
[21:17] <lifeless> jelmer: its all in my mail :)
[21:17] <lifeless> h igc
[21:17] <igc> morning jelmer, lifeless
[21:18] <jelmer> lifeless: ah, neat
[21:18] <jelmer> lifeless, is there a plugin yet for installing a new bzr on a remote server ? :-P
[21:19] <lifeless> bzr-copy-server?
[21:19] <jam> lifeless: I don't know if you noticed, but I created a bzr-groupcompress project, so there should be a shared location we can work on it.
[21:19] <lifeless> jam: cool, I hadn't
[21:19] <jam> igc: I think my 'experimental' branch did
[21:20] <jam> lp:///~jameinel/bzr-groupcompress/experimental
[21:20] <jam> I need to put that back in 'trunk'
[21:20] <jam> since we have --development5 now
[21:21] <Peng_> Is there any reason to use "lp:///foo" instead of "lp:foo"?
[21:21] <domas> more slashes
[21:21] <jam> Peng_: technically you can use lp://dev/foo
[21:21] <domas> looks like URI, too
[21:21] <jam> and some other lp special names
[21:21] <Peng_> Cool, "lp://///foo" works. :P
[21:22] <jam> lp:/foo doesn't :)
[21:22] <Peng_> Aww.
[21:22] <igc> jam: ah, ok. I guess I should stick with testing/using the main branch though, shouldn't I?
[21:22] <jam> lp:foo == lp:///foo == lp://edge/
[21:23] <jam> igc: I would stick to using "lp:bzr-groupcompress"
[21:23] <jam> I'll probably land my stuff there now
[21:23] <jam> since you need it for d5 anyway
[21:23] <Peng_> Why does it still use edge? Just because of the redirect for testers?
[21:24] <jam> Peng_: not sure, something to do with how the xmlrpc code is set up
[21:24] <Peng_> Yeah, I think it's that xmlrpc doesn't like the redirect.
[21:25] <jam> I know that *used* to be the case
[21:25] <jam> not sure if it is still true
[21:26] <jam> igc: I just pushed up my latest
[21:26] <igc> jam: thanks
[21:27] <jam> igc: I'll mention that the only "hack" I need to make conversions fast is the xml8.py change
[21:27] <jam> And I can convert mysql 525 in 1m45s
[21:27] <jam> (bzr branch mysql-5.1 -r 525, which is 1063 revs)
[21:27] <igc> jam: so which gc format should I be testing? gc-plain-chk?
[21:28] <jam> If I was picking one, 'gc-plain-chk255'
[21:28] <jam> not sure if that is the pure winner
[21:28] <jam> but it is my best choice right now
[21:28] <igc> jam: sure. I guess my goal is to tell you the answer :-)
[21:28] <igc> but I want one to work firstly :-)
[21:28] <jam> igc: oh, and I should mention that I think GC+CHK repositories don't autopack right now
[21:29] <jam> They may not even "bzr pack"
[21:29] <jam> I need to work on that
[21:29] <igc> jam: please
[21:29] <igc> lack of autopack will certainly distort benchmarks
[21:30] <jelmer> dev5-subtree is not GC, right?
[21:30] <jam> igc,lifeless: so I'm thinking that for a first-cut, to go ahead and have 'autopack' fully rebuild the groups
[21:30] <jam> jelmer: correct
[21:30] <lifeless> jam: sure
[21:30] <jam> basically, just stream the expected revs in "gc-optimal" order
[21:30] <jam> and shove them into the target
[21:30] <lifeless> jam: well, calculate pack count, and for the ones to redo, do tht
[21:31] <jam> lifeless: right
[21:31] <jam> not the whole repo
[21:34] <thumper> why is bzr lying to me?
[21:34] <thumper> Source format does not support stacking, using format: '1.6'
[21:34] <thumper> bzr info -v tells me it is branch format 7 and packs 5
[21:34] <thumper> which AFAIK --1.6
[21:35] <jam> thumper: I bet you upgraded the repo and not the branch. Also, are you checking the *target* or the *source* ?
[21:35] <thumper> the branch is branch format 7
[21:35] <thumper> and it is the source
[21:35] <thumper> the target is lp
[21:35] <thumper> a new branch
[21:35] <thumper> the command appeared to work
[21:36] <thumper> but it is telling me it is in the wrong format when it isn't
[21:36]  * thumper wishes there was a `bzr info --format` that just showed the formats
[21:36] <lifeless> bug 334114
[21:36] <thumper> lifeless: thanks
[21:37]  * thumper me tooed
[21:42] <Peng_> bzr info -v is reasonably fast now, so it can work.
[21:43] <jelmer> thumper: is there an easy way in lp to sort by how many people have me tooed?
[21:44] <jelmer> maybe an "AOL" button ? :-P
[21:47] <thumper> jelmer: no idea
[21:48] <jelmer> thumper, found it: https://bugs.edge.launchpad.net/bzr/+bugs?field.searchtext=&orderby=-users_affected_count&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
[21:53] <barry> jam: i'm catching up on the bzr thread now.  that "12 minute" branch time; was that using bzr 1.5, 1.6 or something else, and was that from c.p.o, lp.net or someplace else?
[21:54] <jam> barry: so testing from people.ubuntu.org/~jameinel/python/trunk
[21:54] <barry> jam: also, when do you think the --stacked fix will hit bzr.dev?
[21:54] <jam> a full "bzr branch" took 16m40s
[21:54] <barry> jam: bzr version?
[21:54] <jam> a 'best case' 'bzr branch --stacked' took 3m30s
[21:54] <jam> barry: bzr.dev
[21:54] <jam> (with patches)
[21:54] <jam> barry: pqm is finishing up running the tests now
[21:54] <jam> so... 5 min ?
[21:55] <barry> jam: wow!  that's impressive.  do i get all my wishes fulfilled so easily? :)
[21:55] <jam> I think 3m40s with the patch over bzr+ssh. versus 6m50s over http
[21:55] <jam> plain http
[21:56] <jam> I think you could get 3m40s there if you had a smart server running
[21:56] <jam> because it seems to be the http Range request issues
[22:01] <lifeless> does anyone know why we intercept failing hooks?
[22:01] <lifeless> it make it really hard to see whats going on
[22:02] <barry> jam: can you sanity check: https://pastebin.canonical.com/14265
[22:05] <jam> barry: the patch has landed.
[22:05] <barry> jam: excellent!
[22:05] <jam> any chance you could try' bzr branch --stacked' and see how it compares with your 8min ?
[22:05] <barry> jam: yep.  'course my router sucks :)
[22:06] <jam> barry: well do whatever you did to get around the router earlier
[22:06] <barry> jam: basically, it's yank my internet connection.  my wife's about to go out for a bit, so i'll do it then.  i like being married :)
[22:06] <poolie> hello barry
[22:06] <barry> poolie: hi!
[22:07] <barry> jam: that pastebin is my response to brett.  i wanna make sure i'm not telling fibs
[22:07] <jam> barry: yeah, I haven't seen any fibs yet, but having your timing would be a real asset there
[22:08] <barry> jam: cool.  i'll do that in a bit
[22:13] <jam> barry: you may want to do timings against http://people.ubuntu.com/~jameinel/python/trunk and bzr+ssh://rookery.canonical.com/home/jameinel/public_html/python/trunk
[22:13] <jam> just to see what adding a smart server would get you
[22:16] <barry> jam: anything special i need to do on the client?
[22:17] <barry> jam: other than --stacked
[22:17] <jam> barry: I don't think so
[22:17] <barry> jam: cool.
[22:19] <lifeless> jam: if you wanted to finish tuesdays chat, I can do that
[22:22] <jam> igc, lifeless: I just landed a few patches that make 'groupcompress' compatible with the new network streaming changes
[22:22] <jam> igc: in the meantime, to get around autopack, you can branch to a new standalone branch
[22:24] <jam> lifeless: I think for tonight, I'm just going to try to get gc autopack working
[22:24] <jam> I think I'm close
[22:25] <lifeless> ok cool
[22:25] <igc> jam: I'm out of here for several hours real soon (so I'll wait till the autopack stuff is going)
[22:26] <lifeless> spiv: that hook race condition fix is up for review
[22:27] <lifeless> spiv: it also leads into setting the stacked branch during init so that will be a less round trip or so
[22:33] <spiv> lifeless: just reviewed
[22:39] <poolie> kfogel: thanks for the thoughtful comments on our release docs
[22:40] <kfogel> poolie: you're welcome
[22:46] <lifeless> spiv: so, I'm going to work on _real_repository in push
[22:57] <maxb> Is there any documentation which explains "ghosts" ?
[23:00] <kfogel> maxb: "ghosts"?
[23:00] <fullermd> Well, usually they're just pockets of swamp gas...
[23:01] <kfogel> "Rodents of Unusual Size?  I don't believe they exist."
[23:03] <garyvdm> maxb has asked a good question.
[23:03] <garyvdm> qbzr has code in it to deal with "ghosts: - which I don't understand, and don't know how to test.
[23:04] <garyvdm> How do you end up with a ghost?
[23:04] <fullermd> Ghosts are revisions that are referenced but not available.
[23:04] <lifeless> jam: ping
[23:04] <fullermd> The usual way AIUI is conversions, especially from arch.
[23:04] <jam> lifeless: pong, though I'm going out the door now
[23:04] <jam> autopack is now working
[23:04] <lifeless> you added a bug, I need to ask you about it
[23:04] <jam> and does a pretty good job
[23:04] <fullermd> Stacked branches are sorta a special case of ghosts, but I'm not sure if they actually "look like" ghosts...
[23:04] <lifeless> :!bzr diff -c 3871.4.4
[23:04] <lifeless> jam: cool
[23:05] <lifeless> bug 304841
[23:05] <garyvdm> fullermd: how can you create a branch that has a ghost to test that your code is ghost friendly?
[23:05] <jam> sorry I can't talk more now
[23:06] <lifeless> jam: ok, I'll just delete the offending line :)
[23:06] <lifeless> jam: I think its bogus
[23:15] <fullermd> garyvdm: No idea.  I think there's something in the bzr test suite that does it...
[23:15]  * fullermd refers all questions that require actual knowledge to lifeless   :p
[23:15] <lifeless> garyvdm: do a commit with a parent that is a ghost
[23:16] <lifeless> garyvdm: one easy way is tree.set_parent_ids([tree.last_revision, 'blah blah blah']); tree.commit()
[23:16] <lifeless> garyvdm: testing a ghost on mainline is a little more compelx
[23:16] <garyvdm> lifeless - thanks
[23:17] <garyvdm> fullermd, lifeless: I really need to work on qbzr testsuit.
[23:18]  * igc out for a few hours - back later
[23:30] <lifeless> pop quiz, moving _fetch_order and _fetch_uses_delta to RepositoryFormat ?
[23:36] <james_w> erm, the ides of March?
[23:37] <james_w> oh, wrong sort of quiz