[00:05] <Verterok> g'morning igc
[00:06] <thumper> morning
[00:07] <thumper> can I branch into the current directory?
[00:07] <thumper> for example:
[00:07] <thumper> on a server I have a directory which I have rights to
[00:07] <thumper> but the directory above is root only
[00:07] <thumper> in that directory I want to get the contents of a bzr branch
[00:07] <thumper> which was created elsewhere
[00:07] <mwhudson> bzr init, bzr pull
[00:07] <mwhudson> will probably work
[00:08] <thumper> mwhudson: ok, will try
[00:08] <mwhudson> (means you have to get the format right though)
[00:08] <thumper> sweet
[00:08] <thumper> works
[00:08] <thumper> ta
[00:08] <mwhudson> which, given sikrit insider infomation, probably means bzr init --rich-root-pack
[00:08] <thumper> it isn't
[00:08] <mwhudson> ok :)
[00:08] <thumper> but thanks anyway
[00:27] <igc> morning Verterok, how are you?
[00:27] <beuno> thumper, hi!   kick-ass blog post, btw  :)
[00:32] <Verterok> igc:
[00:32] <Verterok> I'm fine, thank you. although a bit busy (hoping to have some free time)
[00:32] <igc> busy is better than bored I always say :-)
[00:33] <Verterok> igc: good point :)
[00:33] <beuno> igc, and how are you?
[00:34] <Verterok> beuno: hi
[00:34] <igc> beuno: hi. Quite sleepy these days. The pain killers I'm on have that effect.
[00:35] <igc> otherwise, just taking each day at a time right now
[00:37] <beuno> igc, you don't seem that sleepy if I look at your work   ;)
[00:39] <igc> beuno: it's nice to hear you say that. Quantity is certainly down at the moment.
[00:39] <igc> I'm in week 2 of a 6 week treatment so ...
[00:39] <igc> hopefully I'll feel better when it's over
[00:41] <beuno> igc, I'm sure you will
[00:45] <thumper> beuno: thanks, but to be honest, abentley wrote most of it
[01:03] <mwhudson> hm
[01:03] <mwhudson> is there some way i can create a branch with a ghost on mainline?
[01:03] <mwhudson> (programming is ok)
[01:28] <igc> jam: did you see my partial review? I was wondering about that change to Merge3Merger._entries3()
[01:50] <bob2> lifeless: should that be 'http://bazaar.launchpad.net/~jameinel/%2Bjunk/pybloom/' (i.e. no bzr-)?
[02:05] <poolie> mwhudson: um, it is possible but probably complicated
[02:05] <poolie> i would start by looking for an api that will copy just one revision and not its parents
[02:05] <mwhudson> poolie: ok
[02:05] <mwhudson> don't push one of these branches to launchpad :)
[03:00] <bob2> hm, my upgrade to --gc-plain seems to not be progressing
[03:53] <bob2> hm, I lie, it is churning through it
[03:57] <jam> mwhudson: I believe there is a 'allow_lefthand_ghost=True' member that you can look for
[03:58] <jam> I think it is on set_parent_ids/trees
[03:58] <jam> igc: I did see it, I haven't fully digested it.
[03:58] <jam> I believe that True => False is *correct* though it doesn't really apply for the weave code
[03:58] <jam> just something I was trying to get around to, not quite sure how it ended up here
[04:02] <igc> jam: ok. IIUIC, the rest of the patch is benign, i.e. it doesn't seem to impact anything outside (re)merge --weave?
[04:03] <igc> that's while I highlighted that change - it has a broader impact potentially?
[04:03] <igc> s/while/why/
[04:49]  * igc lunch
[05:05] <thumper> is there an ETA for bzr-svn in the bzr ppa?
[05:33] <bob2> 85664   backup.bzr
[05:33] <bob2> 40232   .bzr/
[05:33] <bob2> that is quite awesome
[05:34] <jam> igc: well, when you get back from lunch, the next layer up does a "if changed" check, and filters them all out again, but I'm fine skipping it for now.
[06:06] <thumper> bob2: from what to what did you upgrade?
[06:07] <bob2> pack-0.92 -> bt+gc
[06:07]  * mwhudson stabs non-canonical histories
[06:12] <thumper> bob2: bt+gc??? I'm lost
[06:13] <mwhudson> thumper: btree indexes and lifeless's groupcompression thingy
[06:13] <mwhudson> (i assume)
[06:14] <thumper> ah
[06:14] <bob2> the pair of new formats lifeless posted to the list this morning
[07:19] <lifeless> bob2: :)
[07:19] <lifeless> bob2: it will be better when the fetcher knows to do inverse-topological-order
[07:59] <awmcclain> Oh no. Is there any way to undo a bzr revert?
[08:04] <matkor> awmcclain: bzr revert of uncommited changes ?  I think they are lost ...
[08:04] <awmcclain> Boo. for that.
[08:04] <awmcclain> all for doing bzr revert instead of bzr revert .
[08:05] <awmcclain> not pleased with bzr right now.
[08:06] <bob2> doesn't help now, but maybe aliasing 'revert' to 'shelve --all' might save you in the future?
[08:08] <awmcclain> yeah... i just wanted to revert one file.
[08:08] <awmcclain> so i cd'ed into the child directory
[08:08] <awmcclain> but bzr revert crawled out and did the entire tree
[08:08] <awmcclain> bad bzr! naughty!
[08:10] <asabil> awmcclain: there are backup files
[08:10] <awmcclain> oh???
[08:11] <asabil> awmcclain: just check for hidden files in your folder
[08:11] <awmcclain> okee doke
[08:11] <asabil> (ones ending with ~)
[08:11] <asabil> I think there is maybe a way to ask bzr to revert the revert :p
[08:11] <asabil> but I don't know
[08:13] <awmcclain> Well, I got it for the one file that really mattered... thank you!
[09:13] <MvG> Hi! I'm trying to move repository data from a shared repository to a dedicated repository of a single branch. I had assumed that "reconfigure --standalone" would work for this, being the opposite of "--use-shared". However I got a IncompatibleRepositories error from current bzr.dev. Trying again informs me that the tree is already standalone. How can I tell whether the conversion worked? What is the reason for this error message?
[09:16] <MvG> Steps to reproduce: bzr init-repo --rich-root-pack repo; cd repo; bzr init branch; cd branch; bzr reconfigure --standalone
[09:16] <Odd_Bloke> lifeless: I'm aiming to get to Canonical's offices sometime between 1 and 2 this afternoon.  Is that OK?
[09:24] <igc> lifeless: fyi, I'm benchmarking the group-compress stuff tonight on some repos to see how well it compresses them
[09:24]  * igc dinner
[09:27] <bob2> MvG: "bzr info" should tell you if it worked
[09:27] <Stavros> hello
[09:27] <Stavros> this is a bit offtopic, but i'd like to ask how you guys wrote your distutils script
[09:28] <MvG> bob2: bzr info tells me it did. But I worry it might have been migrated only partially. Otherwise why the error message?
[09:30] <lifeless> ogthats cool
[09:30] <lifeless> igc: thanks
[09:30] <lifeless> igc: it really needs a custom InterRepository to compress well
[09:31] <lifeless> igc: it will get about 50% I expect from an existing repo with the current inter object
[09:31] <lifeless> Odd_Bloke: thats cool
[09:31] <lifeless> MvG: sounds like you've found a bug; could you please file it in launchpad ?
[09:33] <MvG> lifeless: Sure.
[09:43] <Odd_Bloke> lifeless: Excellent. :)  Has jelmer mentioned what time he's going to be arriving?  (SUBTLE PING :D)
[09:44] <MvG> lifeless: Submitted https://bugs.launchpad.net/bzr/+bug/248932
[09:45] <lifeless> Odd_Bloke: no :)
[09:46] <lifeless> mv	thanks!
[10:55] <jaro> hello
[10:55] <jaro> now trying migration from svn to bzr
[10:55] <jaro> what tools better to use?
[10:55] <jaro> bzr fast-import?
[10:59] <jaro> anyone is here?
[11:00] <Jc2k> hi jaro
[11:00] <Jc2k> there is normally someone round who can help
[11:00] <Jc2k> i only have experience with bzr-svn, which isn't really aimed at doing migration
[11:01] <jaro> :/
[11:01] <luks> well, bzr-svn works fine for migration
[11:02] <jaro> luks: can i with bzr-svn migrate my subversion repository to bzr and i will see all changes?
[11:03] <luks> jaro: yes
[11:03] <jaro> how?
[11:03] <jaro> May by some how to?
[11:03] <jaro> link
[11:03] <jaro> ?
[11:04] <luks> install bzr-svn, run `bzr svn-import <SVN_URL>`
[11:04] <luks> or just `bzr branch <SVN_URL_OF_TRUNK>` if you want to migrate only trunk
[11:05] <luks> then you can uninstall bzr-svn and just use plain bzr
[11:05] <ignas> what is the mystical "front-end" tool that is being mentioned in http://bazaar-vcs.org/BzrFastImport ?
[11:06] <luks> ignas: http://bazaar-vcs.org/BzrFastImport/FrontEnds
[11:07] <ignas> luks: thanks
[11:09] <jaro> luks: i try bzr svn-import <URL>
[11:10] <jaro> then cd <project>
[11:10] <jaro> and there are no files
[11:10] <jaro> :(
[11:10] <luks> try `bzr info`
[11:11] <jaro> Repository branch (format: rich-root-pack)
[11:11] <jaro> Location:
[11:11] <jaro>   shared repository: .
[11:11] <jaro>   repository branch: .
[11:11] <jaro> Related branches:
[11:11] <luks> or are there no files or directories at all?
[11:12] <jaro>   parent branch: <url>
[11:12] <luks> if not, what URL did you use?
[11:13] <jaro> file:///patch/to/svn/project
[11:14] <luks> jaro: does the project have only a single branch? no trunk/branches/tags structure?
[11:14] <jaro> yes
[11:14] <luks> well, then all you need is in the directory
[11:14] <lifeless> jaro: do 'bzr checkout .' and you'll get your files
[11:14] <luks> you can use `bzr checkout .` to recreate the working tree if you want
[11:14] <luks> :)
[11:15] <jaro> but bzr checkout only get files
[11:15] <jaro> But i need history
[11:15] <luks> bzr log
[11:15] <luks> in that directory
[11:15] <ignas> or bzr vis for a nice visual history if you have gtk plugin installed
[11:18] <jaro> bzr log show my history
[11:18] <LarstiQ> hey ignas
[11:18] <jaro> So can I delete /patch/to/svn/project ?
[11:18] <ignas> LarstiQ: hi
[11:18] <jaro> And how can I see my files in /patch/to/bzr/project ?
[11:18] <jaro> To change them ?
[11:19] <luks> jaro: it's always nice to keep backups, just in case, but yes you can
[11:19] <luks> jam: bzr checkout .
[11:19] <luks> jaro:
[11:19] <luks> evil tab completion
[11:20] <lifeless> poolie: around?
[11:21] <jaro> luks: big thanx
[11:23] <matkor> what is proper way of resolivng binary file confilct ? I end up with foo and foo.moved, how to choose that foo/foo.moved is correct conflcit colvation ?
[11:28] <lifeless> matkor: that generally means foo and foo.moved were added independently; you should take the one that is in the branch closer to trunk
[11:29] <poolie> lifeless: hi, a bit
[11:29] <lifeless> poolie: can we chat about get_record_stream a bit? perhaps a quick call ?
[11:32] <igc> lilfeless: so my first group-compress test is still running after 2h30minutes
[11:33] <igc> I'm wondering if I'm doing the right thing?
[11:33] <igc> I'm doing this ...
[11:33] <igc> bzr init --gc-plain .
[11:33] <LarstiQ> igc: is there a windows vm running the testsuite yet?
[11:33] <igc> bzr pull ../normal-repo
[11:33] <matkor> lifeless: yah, but how to say to bzr: use foo/foo.moved and forget about second one ? Deleting foo.moved and bzr resolve deos not make confilct resolved ...
[11:34] <igc> lifeless: the normal repo I'm trying first is python
[11:34] <igc> hi LarstiQ
[11:34] <lifeless> matkor: does bzr st list foo.moved as unknown? if so, you probably just had foo.moved on local disk before the merge
[11:34] <LarstiQ> igc: heya :)
[11:34] <igc> LarstiQ: not to my knowledge
[11:34] <LarstiQ> igc: hmmm
[11:34] <lifeless> igc: yes, the fetch logic is O(n^2) at the moment
[11:34] <igc> I'm pretty sure jam is running on Windows these days
[11:35] <lifeless> igc: the raw compressor is better, but *shrug*
[11:35] <igc> lifeless: when n = # of revisions?
[11:35] <igc> s/when/where/
[11:36] <igc> LarstiQ: and vila was for a while as well IIRC
[11:36] <LarstiQ> igc: ok. I watched a run on markh's laptop, and it didn't look too good.
[11:37] <lifeless> igc: yeah; it caps at 20MB of raw output and resets, but it will be doing 1000's of extractions
[11:37] <lifeless> igc: I should have a better InterObject done today
[11:38] <igc> LarstiQ: as in the test suite didn't look good? or some particular bzr operations?
[11:39] <igc> lifeless: ok. VM memory use for the pull is up to 780MB fwiw
[11:39] <matkor> lifeless: Is hard to say what happend becouse other person asks me to help with that ...
[11:40] <lifeless> igc: mysql? ooo?
[11:40] <LarstiQ> igc: test failures, including not entirely deterministic ones related to test cleanup
[11:40] <igc> lilfeless: I'm planning to do those tonight but I was waiting for the python one to finish first
[11:40] <lifeless> matkor: ok. well, if bzr st shows one as unknown, just use regular 'mv' etc
[11:41] <lifeless> igc: it may well be faster to do a upgrade to --btree-plain first (or btree-rich-root etc9
[11:43] <igc> lilfeless: interesting. I did try the same thing with --btree-plain. That took 195 secs
[11:43] <igc> which is slowly than a branch (170s) but not by a lot
[11:43] <lifeless> igc: so the btree index layer won't bloat anywhere near as much as teh graphindex one
[11:43] <lifeless> igc: 'bzr upgrade --btree-plain' will be _much_ faster than a pull :)
[11:43] <igc> s/slowly/slower/
[11:55] <lifeless> igc: (upgrade --btree-plain will rewrite just the indices)
[12:45] <ignas> how do I cancel a merge?
[12:45] <awilkins> ignas: Revert
[12:45] <ignas> bzr revert seems to only revert the changes
[12:45] <ignas> i still can see the merged revisions in the pending merges list
[12:45] <lifeless> ignas: are y ou running 'bzr revert'
[12:45] <lifeless> ignas: or something more complex ?
[12:45] <ignas> "bzr revert ." ;)
[12:46] <ignas> got the hint
[12:46] <lifeless> ignas: the . tells revert not to touch pending merges :)
[12:47] <menesis> ignas: bzr revert --forget-merges
[12:47] <ignas> menesis: thanks, just plain "revert" worked too though
[12:48] <ignas> by the way - what is the correct way to resolve a tricky situation:
[12:48] <ignas> i have a release branch 2008.04
[12:48] <ignas> and trunk
[12:48] <ignas> I had a bugfix branch for small bugfixes
[12:48] <ignas> it worked fine
[12:48] <ignas> but I have managed to do bzr pull from trunk to it
[12:48] <ignas> and now if I want to merge a couple more of the bugfixes to 2008.04
[12:49] <ignas> i am getting all the new stuff from trunk that got pulled ...
[12:49] <ignas> i could -r rev1..rev2 the merge to my release branch
[12:49] <ignas> but then I will lose the history for separate commits (I think)
[12:50] <ignas> any ideas? except for picking all the separate commits from the bugfix branch (that is based on trunk now) and moving them to some other branch
[12:50] <ignas> that is based on some common ancestor of trunk and release
[12:57] <ignas> and a related question - where should I be branching my "feature that will probably go into the release and trunk" from to have nice merges later?
[12:58] <ignas> I am adding python2.5 support at the moment, and if i am branching from 2008.04 directly - I am getting release specific changes in the merge from 2.5 branch to trunk...
[12:58] <ignas> must I always branch specifically from the "branching" point of the release and trunk branches?
[13:02] <lifeless> ignas: I generally branch features from trunk, and do a cherrypick merge if needed
[13:02] <lifeless> ignas: but if you know a-priori that it will go into a release branch as well as trunk I would tend to start with the release branch
[13:04] <ignas> well - release branch has at least some release specific changes (like setting of the version for a 2008.04.02 release for example)
[13:05] <ignas> so as menesis just explained to me - bugfix branch should be branched out as early as feasible (like when the bug was first encountered/appeared in the code)
[13:05] <ignas> and features should not be merged into release branches that have been in use in general
[13:06] <lifeless> well, different folk find different things work
[13:06] <lifeless> I generally ignore history and just code to head; backporting is usually dead easy bzr-wise
[13:07] <ignas> and how do you do backporting?
[13:07] <ignas> cherry picking?
[13:13] <ignas> oh, apparently I can bzr revert some changes that were release specific, and it seems that it is "legal" to do so, so I can just skip the changes made to version.txt and to setup.py when merging from "a branch that was branched from release" to "trunk"
[13:57] <lifeless> ignas: yes, I cherry pick when needed
[14:05] <jelmer> re
[14:28] <uws> So, when is a new .pack file created?
[14:29] <uws> the sizes are really different in my repository
[14:29] <uws> I'm using a --rich-root-pack repos (that's best, right?)
[14:29] <jelmer> uws, hi
[14:29] <uws> hey jelmer
[14:30] <jelmer> uws, rich-root-pack would probably be the best choice if you don't have to worry about pre-1.0 clients
[14:30] <uws> i'm hip and up-to-date, so no worries there :)
[14:31] <jelmer> (-:
[14:31] <uws> jelmer: also, i'm cloning a svn repos using svn+http://  and it seems to open a new connection for each revision
[14:31] <uws> is that right?
[14:31]  * jelmer catches up on three days of bzr-svn highlights
[14:31] <jelmer> uws: No, that'd be a bug
[14:32] <uws> svn+http://  is ok right?
[14:32] <jelmer> though a known one if you're using particular older versions of bzr-svn
[14:32] <jelmer> yeah, svn+http:// and http:// should both work
[14:32] <uws> ii  bzr-svn                  0.4.10-2                 Bazaar plugin providing Subversion integration
[14:32] <spiv> jelmer: I'd love a fix for the find_tags stage being very slow.
[14:32]  * spiv is about to sleep
[14:32] <uws> jelmer: If i pull from the http:// one later after branching from svn+http://, will that download all revisions again?
[14:33] <jelmer> uws: No, the identity of the repository does not depend on the location
[14:33] <uws> so what does it depend on?
[14:33] <jelmer> spiv: I may have a look at that in the next two days
[14:33] <jelmer> uws: the subversion repository uuid
[14:33] <spiv> jelmer: wonderful!
[14:33]  * spiv -> sleep
[14:33] <jelmer> uws, and the path in the repository
[14:33] <uws> ah ok
[14:34] <jelmer> spiv: goodnight
[14:34] <uws> I'm cloning webkit svn ;)
[14:34] <uws> takes a LONG time
[14:34] <jelmer> ah, ok
[14:34] <jelmer> I need to do more memory use profiling
[14:34] <uws> jelmer: yeah, it leaks so I pull like 1000 revs at once
[14:35] <jelmer> siretart: do you happen to be in .uk as well?
[14:36] <uws> jelmer: it seems bzr-svn 0.4.10-2 (debian package) calls connect() to the http server quite often\
[14:36] <uws> my guess is each revision
[14:37] <jelmer> uws: That should not be the case with the 0.4 branch of bzr-svn
[14:38] <lamalex_2> Is there a howto for setting up an external branch? I'm starting a new project for work, want to use bzr, but don't want to use launchpad.
[14:38] <uws> bzr-svn is also quite cpu bound it seems
[14:38] <uws> lamalex_2: just type "bzr init" and you're done
[14:38] <jelmer> uws, some of that has changed as well
[14:38] <uws> connect(5, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("17.254.17.56")}, 16) = -1 EINPROGRESS (Operation now in progress)
[14:38] <uws> connect(11, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("17.254.17.56")}, 16) = -1 EINPROGRESS (Operation now in progress)
[14:38] <lamalex_2> uws: ... that's too easy
[14:38] <uws> jelmer: ^^ i see that every few seconds
[14:39] <lamalex_2> how do I control write access?
[14:39] <uws> lamalex_2: to a shared repository? just file system access rights, or share a shell accoutn
[14:39] <lamalex_2> ah ok
[14:39] <jelmer> uws: Yeah, so that's a known issue which is fixed in the 0.4 branch
[14:39] <lamalex_2> great thanks
[14:40] <uws> jelmer: does it affect speed seriously?
[14:40] <jelmer> uws: The reconnects probably don't matter much
[14:41] <uws> jelmer: so I shouldn't have to upgrade manually (and remove the debian package)
[14:41] <jelmer> uws: I can run a webkit import here as well with the 0.4 branch and see how fast that is
[14:41] <uws> jelmer: it's really slow :)
[14:41] <jelmer> uws, what's the URL?
[14:41] <uws> jelmer: svn+http://svn.webkit.org/repository/webkit/trunk
[14:41] <pickscrape> I can't for the life of me get authentication.conf to work :(
[14:41] <pickscrape> I want it to change the username I connect to a server using, but it always ends up connecting as me.
[14:41] <siretart> jelmer: sorry, no
[14:41] <uws> does running "bzr pack" once in a while help for speed?
[14:42] <siretart> jelmer: I'm .de
[14:42] <pickscrape> Anyone have any experience on this happening and knows what I'm doing wrong?
[14:42] <uws> pickscrape: you can use  sftp://username@host instead
[14:42] <pickscrape> uws: thanks, but I don't want to have to tell my colleagues that they have to specify the username every time they want to access the server :)
[14:42] <uws> pickscrape: is it ssh?
[14:42] <pickscrape> yes
[14:43] <uws> pickscrape: if so, you can also force it in ~/.ssh/config for that particular host
[14:43] <lamalex_2> uws: why would I use init vs init-repository?
[14:43] <uws> furthermore, urls for push/pull are remembered so it's really a one time thing
[14:43] <pickscrape> uws: Oh, thanks for that I'll look into it.
[14:43] <uws> lamalex_2: depends on whether you will have multiple branches, which will share the same "backing storage"
[14:44] <lamalex_2> what do you mean by backing storage, and is this wiki'd somewhere? I hate to waste your time if there's already an article on this
[14:45] <uws> lamalex_2: "bzr help init-repository" versus "bzr help init"
[14:46] <lamalex_2> that doesn't give me why I should use one or the other, advantages,  disadvantages, etc
[14:46] <uws> lamalex_2: branches created with "init" contain ALL history in .bzr
[14:46] <uws> so if you have two branches for the same project, most history will be there twice, resulting in unnecessary disk usage
[14:47] <uws> a repository holds all the revision data, and your branches (doesn't matter how many) just point to a specific revision,
[14:47] <lamalex_2> ah
[14:47] <uws> this results in the repository .bzr dir to be large, and the branch .bzr dirs to be really smalls (a few KB)
[14:47] <lamalex_2> so it sounds like repository is the safer choice, are there any large disadvantages?
[14:48] <uws> lamalex_2: you can't copy the branch directory using conventional means (cp, drag/drop in file browser) to other media
[14:48] <uws> lamalex_2: but you can of course still create branches outside the repo as well
[14:49] <pygi> greetings asabil
[14:49] <jam> Odd_Bloke: want some help with bug 160530?
[14:49] <asabil> hello pygi :)
[14:53] <Odd_Bloke> jam: Yeah, I haven't really looked into it a great deal, but copy-pasting the strings in the bug into PQM's queue didn't cause a problem.  So I don't know if this has been magically fixed, or...? :)
[14:55] <jam> Odd_Bloke: I couldn't tell you for sure, are you seeing stuff that uses the email library to parse the requests, rather than reading the raw string?
[15:07] <colbrac> jelmer: Working on bzr-gtk?
[15:11] <Odd_Bloke> jam: I haven't really looked into it enough, I'll look into it further later.
[15:11] <jam> Odd_Bloke: np
[15:11] <jam> Someone certainly could have cleaned up PQM's message parsing and not mentioned it
[15:12] <uws> jelmer: is it right that bzr-svn looks like it's cpu-bound?
[15:13] <uws>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
[15:13] <uws>  7210 uws       20   0  469m 442m 6700 R 43.7 44.1   7:44.93 /usr/bin/python /usr/bin/bzr pull -v -r 18500
[15:13] <uws> like that, all the time
[15:13] <uws> (also 100% btw)
[15:14] <jelmer> uws: Yeah, some bits may be CPU bound, especially in < 0.4.11
[15:14] <jelmer> colbrac: somewhat
[15:15] <colbrac> jelmer: Is that account coming through?
[15:23] <jelmer> colbrac, yep, just give me a few minutes
[15:24] <jelmer> uws, it's pretty slow here as well, but not using a lot of cpu
[15:24] <jelmer>  2497 jelmer    20   0  209m 178m 7992 S   14 11.8   8:11.88 python
[15:25] <uws> jelmer: Hmm, your 0.4 branch installs ra.so and client.so (and some other files) directly into site-packages/
[15:25] <uws> is that right?
[15:27] <uws> jelmer: Unable to load bzr-svn extensions - did you build it?
[15:27] <uws> strange, I did
[15:29] <lifeless> jelmer: http://news.launchpad.net/ppa/introducing-autoppa
[15:29] <jelmer> lifeless, blegh, ubuntu only :-( Hopefully it works on Sid :-)
[15:37] <james_w> rockstar: hi, are you still looking for me?
[15:38] <rockstar> james_w, kinda.  I've got some questions about using bzr-builddeb
[15:38] <james_w> rockstar: ah, sure, ask away
[15:40] <lifeless> jam: hi
[15:41] <rockstar> Well, I'm having an awkward time trying to find a good workflow.  I just wondered, since you probably use it on a normal basis, I wonder if you could recommend a workflow
[15:41] <rockstar> james_w, ^^
[15:41] <james_w> I don't use it that much :-)
[15:41] <james_w> what are you struggling with?
[15:42] <lamalex_2> uws: is there any apache setup or anything I need to do to make this repo accessible?
[15:44] <lamalex_2> wow no! this rules. bzr+ssh://host/path
[15:44] <jam> lifeless: hi, probably afk for a bit, my son is waking up from the morning nap, and I'll be taking him to day care in a bit
[15:44] <jam> LarstiQ: I *do* use win32 probably 75% of the time, but I *don't* run the full test suite (on either platform). I know that BzrDir.clone() is broken (BzrDir.sprout() works, which is a bit weird), but that is something that probably makes a lot of tests fail
[15:45] <jelmer> uws, hmm, it is slow
[15:45] <jelmer> uws, I'm at 800 revisions now
[15:45] <jelmer> 28k to go :-)
[15:45] <uws> jelmer: yeah, just stop it. you can branch from me later if you wish
[15:46] <uws> I'm at ~18000 already
[15:46] <jelmer> ah, ok - over how much time?
[15:46] <jam> lifeless: I would be curious to know how you did remote testing of your btree code
[15:46] <uws> ~1.5 days
[15:46] <jelmer> wow, ok
[15:46] <jam> As I'd like to put the new bloom stuff through its paces over a remote connection
[15:46] <jelmer> uws: I guess the 0.4 branch is a bit faster then
[15:46] <uws> jelmer: I couldn't get it to work
[15:46] <jam> So far, I've just finally managed to do better than no blooms on a local filesystem
[15:46] <uws> jelmer: complained about needing bzr 1.6, and it doesn't work with the 1.6b2
[15:47] <uws> complaining about make_knit_factory or something
[15:47] <jam> Not a *lot* better yet, but *better* which means they are viable :)
[15:47] <jelmer> uws: yeah, it needs bzr.dev
[15:48] <uws> jelmer: will the speed improvements be an order of magnitude?
[15:49] <jam> lifeless: oh, and until I get the 'paged bloom' code written, they won't scale to 1M+ pack files, because they will always read the full array
[15:49] <jelmer> uws, it's doing about one revision per three seconds here
[15:49] <jelmer> what sort of speed are you seeing?
[15:49] <jam> Though we could still *create* them, even if we didn't always use them yet.
[15:49] <uws> jelmer: roughly that yes
[15:49] <uws> jelmer: however I don't see that anywhere
[15:49] <uws> jelmer: only from the "strace -econnect)
[15:50] <uws> It just says "Pull phase 0/2" for a VERY long time
[15:50] <rockstar> james_w, for instance, I'm trying to package a tarball from upstream to put in my PPA.  It doesn't make sense for me to version the contents of the tarball, so I figure I version debian/
[15:50] <LarstiQ> rockstar: why, that almost sounds like a larstiq workflow ;)
[15:51] <uws> jelmer: will speed be constant when the revision number gets higher for my bzr-svn branching?
[15:51] <rockstar> At this point, what does bzr-builddeb provide over the standard debian tools?
[15:51] <jelmer> uws, yeah, that's the idea
[15:51] <uws> jelmer: Ok, I'll just let it run for the next few days then :S
[15:52] <uws> launchpad doesn't have a mirror either
[15:52] <uws> would they be interested in mine?
[15:52] <james_w> rockstar: if you only want to version debian/ then bzr-builddeb will construct the source package for you by assembling the bits in the right way. You can do this yourself, but you may find it more convenient.
[15:53] <rockstar> Where is the convenience?  That's really what I'm looking for.
[15:53] <jelmer> uws, installation of the 0.4 branch should be fixed now
[15:53]  * jelmer wonders who he has to bribe to get his gssapi patch reviewed
[15:54] <james_w> rockstar: to build the source package you need the upstream tarball unpacked, with debian/ in place. You can obviously do this by hand, but I found doing that tedious.
[15:54]  * LarstiQ takes euros and litas.
[15:55] <jelmer> LarstiQ: I can give you 200 litas I think
[15:55] <jelmer> :-P
[15:55] <jelmer> I still have some from last year, not likely to need them in the near future
[15:56] <LarstiQ> jelmer: you sir, have a deal!
[15:56] <LarstiQ> but first I'm going to bbq in the park.
[15:56] <rockstar> james_w, Ah, so you can say "download the tarball from here, build everything" ?
[15:58] <james_w> rockstar: yeah, one thing it can do is to try and get a tarball for you if you don't have one already (using apt or uscan).
[15:59] <rockstar> james_w, Ah, that's what I was looking for.
[15:59] <jelmer> LarstiQ: heh, bon appetit
[16:13] <lamalex_2> This transport does not update the working tree of: bzr+ssh://combatshadow/var/www/acetechgroup.com/systems/htdocs/systems/. See 'bzr help working-trees' for more information. -- What does that mean? Why can't I push to my repo?
[16:14] <radix> you can, it just doesn't update the working tree
[16:14] <lamalex_2> what does that mean?
[16:16] <james_w> lamalex_2: did you have a look at "bzr help working-trees"?
[16:17] <lamalex_2> so I have to run bzr update in my repo whenever I push
[16:17] <lamalex_2> that's annoying
[16:18] <james_w> lamalex_2: there are two plugins that might interest you, the first is "push-and-update", which automates "ssh wherever 'bzr update'" when you push
[16:18] <james_w> then second is "bzr-upload" that allows you to upload the working tree to a remote location, this is what web developers usually want.
[16:19] <lamalex_2> that's what I want too
[16:21] <lamalex_2> where can I get the push-and-update plugin?
[16:26] <lifeless> https://launchpad.net/bzr-push-and-update
[18:14] <Odd_Bloke> lifeless: So I've looked at your cleanup of thumper's queue-abstraction branch and it _mostly_ looks OK.  There are a couple of things that I think could be better, but it's hard to know whether it makes sense in this branch...
[18:29] <bud3030> Hi bzr  I have changed email address should i change it in bzr.conf, auth,conf, location,conf
[18:30] <Odd_Bloke> bud3030: Use 'bzr whoami <new string>' and 'bzr whoami' again to check it's correct.
[18:30] <bud3030> Odd_bloke thanks Ill give a try
[18:52] <pickscrape> Would the correct way to reverse a changeset on a branch be: bzr merge -r 8..7 . (where the revision to reverse if r8)?
[18:52] <pickscrape> s/if/is/
[18:53] <pickscrape> Actually... yes, that works. I'd accidentally done the merge the other way round, and the result makes bzr stat crash
[18:53] <pickscrape> bzr diff --stat
[18:53] <pickscrape> oops
[19:02]  * thumper wonders what bzr diff --stat does
[19:03] <pickscrape> Nothing unless you install the diffstat plugin :)
[19:03] <rockstar> Dangit, someone took my bzr-stats idea...
[19:03]  * rockstar snoozed and lost
[19:04] <pickscrape> rockstar: It's been around for ages
[19:04] <pickscrape> https://launchpad.net/bzr-diffstat
[19:04] <asabil> pickscrape: you can also simply uncommit
[19:04] <pickscrape> I recently picked it up and got it working with 1.5.
[19:04] <asabil> if you didn't publish the branch yet
[19:05] <pickscrape> asabil: no, this is a changs from a couple of revs back from HEAD that has been published. I figure it out though.
[19:05] <rockstar> pickscrape, that doesn't make me any less of a sad panda  :)
[19:05] <pickscrape> rockstar: :( One of the reasons why I've not started any projects of my own too
[19:51] <bud3030> jam how can one correct the error 13 : hook route to ubuntu machine
[19:52] <bud3030> am i log in to go privite
[20:06] <newz2000> hi, maybe this is esoteric, but it never hurts to ask...
[20:07] <newz2000> is there a plugin that will export a project as a zip file?
[20:07] <newz2000> (or some other archive)
[20:07] <beuno> newz2000, bzr export
[20:07] <beuno> it's not a plugin, it's a default command
[20:08] <newz2000> :-D
[20:08] <newz2000> that explains why it wasn't on the plugins page
[20:08] <newz2000> so I guess I'm not the only one who's wanted this feature then
[20:08] <beuno> probably not  :)
[20:09] <newz2000> ok, one more thing then...
[20:10] <newz2000> I have a workflow for some projects that includes a few steps. Is there a way to bundle these steps into one process? I like the plugin that does ssh -c bzr co .
[20:10] <newz2000> I can script it of course, just wondering if there was a hook for bzr push that would do it automatically
[20:11] <beuno> you can hook to post-tip-change, and make that run a script
[20:14] <newz2000> ok, I see this in the docs... out of curiosity, is it possible to define different actions on a per project basis?
[20:16] <beuno> hm, that's a good question
[20:16] <beuno> I don't think there's a straight forward way of doing that from bzr
[20:16] <beuno> you can probably do that on your script
[20:16] <beuno> pass on the branch nick or path
[20:17] <newz2000> At a diff job we did this with ant, so maybe I'm crossing the point of what my vcs should be doing for me
[20:19] <newz2000> beuno: thanks for the export tip... that's a big help.
[20:19] <beuno> newz2000, welcome'
[20:23] <uws> So, my bzr-svn for webkit will take a few days methinks
[20:23] <uws> there's no launchpad mirror. would they me interested in mine?
[22:00] <bkor> jelmer: could you please advise on https://bugs.launchpad.net/bugs/248119 ?
[22:54] <chadmiller> Hi all.  One of my cow-orkers is using bzr.dev of an hour ago, and gets a AttributeError exception. ...
[22:55] <Peng> chadmiller: Pastebin the traceback?
[22:55] <Peng> chadmiller: Does he have any plugins installed?
[22:56] <Peng> chadmiller: FWIW, it works for me, but I haven't tried to commit or anything.
[22:56] <chadmiller> Five lines pasted here:
[22:57] <chadmiller>   File "/usr/local/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 1092, in sprout
[22:57] <chadmiller>     hardlink=hardlink)
[22:57] <chadmiller>   File "/usr/local/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 1386, in create_workingtree
[22:57] <chadmiller>     return self._format.workingtree_format.initialize(
[22:57] <chadmiller> AttributeError: 'property' object has no attribute 'initialize'
[22:57] <chadmiller> That's from "bzr branch".
[22:57] <chadmiller> I have him checking that ssh is working correctly.  I've seen some weird problems caused by transport failure.
[23:35] <chadmiller> Ideas anyone?  It wasn't ssh.
[23:36] <bob2> anything in lp with that error?
[23:36] <mwhudson> whuut
[23:36] <mwhudson> chadmiller: is your co-worker proficient in python?
[23:37] <mwhudson> if you run the command with "BZR_PDB=1" you'll get a pdb at the point of the exception
[23:37] <mwhudson> and then poke around
[23:37] <chadmiller> mwhudson: I don't suppose so, no.  He knows gdb, though, and Python ain't hard.
[23:37] <mwhudson> also
[23:38] <mwhudson> what exactly command is he running?
[23:38]  * mwhudson finds that his irc grammar is getting worse and worse
[23:39] <chadmiller> mwhudson: "bzr branch bzr+ssh://ourserver/branchname bn"
[23:39] <mwhudson> chadmiller: ok, can you get him to run it again with BZR_PDB=1
[23:39] <mwhudson> and then type
[23:39] <mwhudson> p self
[23:39] <mwhudson> p self._format
[23:39] <mwhudson> p self._format.workingtree_format
[23:39] <mwhudson> ?
[23:40] <chadmiller> I'll do so.  he's offline now, for sleep or something.
[23:40] <chadmiller> (Lazy Swedes!)
[23:40] <mwhudson> ok
[23:40]  * mwhudson looks to see if the problem can be seen in the code
[23:40] <mwhudson> chadmiller: oh, one more, what format is the branch hes getting in?
[23:41] <chadmiller> mwhudson: "Repository branch (format: pack-0.92)"
[23:41] <mwhudson> chadmiller: ok, ta
[23:45] <mwhudson> hm hm
[23:46] <mwhudson> i wonder if _format is the class object, when it should be an instance
[23:46] <mwhudson> hey wee, i can reproduce
[23:47] <mwhudson> which means... a rather bad miss in bzr's tests
[23:50] <thumper> mwhudson: file a critical bug
[23:50] <thumper> mwhudson: to make sure it is fixed for 1.6 release
[23:50] <mwhudson> wth
[23:50] <mwhudson> it only happened once :(
[23:51] <thumper> weird
[23:57] <mwhudson> chadmiller: fwiw, my experience suggests that if your work mate simply tries again, it will work for him :/
[23:57] <chadmiller> mwhudson: Consider this a counterexample, then.
[23:58] <mwhudson> oh good
[23:58] <mwhudson> ah hurrah, i hit it in pdb
[23:58] <Peng> Lazy import issue?