[00:05] g'morning igc [00:06] morning [00:07] can I branch into the current directory? [00:07] for example: [00:07] on a server I have a directory which I have rights to [00:07] but the directory above is root only [00:07] in that directory I want to get the contents of a bzr branch [00:07] which was created elsewhere [00:07] bzr init, bzr pull [00:07] will probably work [00:08] mwhudson: ok, will try [00:08] (means you have to get the format right though) [00:08] sweet [00:08] works [00:08] ta [00:08] which, given sikrit insider infomation, probably means bzr init --rich-root-pack [00:08] it isn't [00:08] ok :) [00:08] but thanks anyway [00:27] morning Verterok, how are you? [00:27] thumper, hi! kick-ass blog post, btw :) === mw is now known as mw|out [00:32] igc: [00:32] I'm fine, thank you. although a bit busy (hoping to have some free time) [00:32] busy is better than bored I always say :-) [00:33] igc: good point :) [00:33] igc, and how are you? [00:34] beuno: hi [00:34] beuno: hi. Quite sleepy these days. The pain killers I'm on have that effect. [00:35] otherwise, just taking each day at a time right now [00:37] igc, you don't seem that sleepy if I look at your work ;) [00:39] beuno: it's nice to hear you say that. Quantity is certainly down at the moment. [00:39] I'm in week 2 of a 6 week treatment so ... [00:39] hopefully I'll feel better when it's over [00:41] igc, I'm sure you will [00:45] beuno: thanks, but to be honest, abentley wrote most of it === sdboyer_ is now known as sdboyer [01:03] hm [01:03] is there some way i can create a branch with a ghost on mainline? [01:03] (programming is ok) [01:28] jam: did you see my partial review? I was wondering about that change to Merge3Merger._entries3() [01:50] lifeless: should that be 'http://bazaar.launchpad.net/~jameinel/%2Bjunk/pybloom/' (i.e. no bzr-)? [02:05] mwhudson: um, it is possible but probably complicated [02:05] i would start by looking for an api that will copy just one revision and not its parents [02:05] poolie: ok [02:05] don't push one of these branches to launchpad :) [03:00] hm, my upgrade to --gc-plain seems to not be progressing [03:53] hm, I lie, it is churning through it [03:57] mwhudson: I believe there is a 'allow_lefthand_ghost=True' member that you can look for [03:58] I think it is on set_parent_ids/trees [03:58] igc: I did see it, I haven't fully digested it. [03:58] I believe that True => False is *correct* though it doesn't really apply for the weave code [03:58] just something I was trying to get around to, not quite sure how it ended up here [04:02] 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] that's while I highlighted that change - it has a broader impact potentially? [04:03] s/while/why/ [04:49] * igc lunch [05:05] is there an ETA for bzr-svn in the bzr ppa? [05:33] 85664 backup.bzr [05:33] 40232 .bzr/ [05:33] that is quite awesome [05:34] 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] bob2: from what to what did you upgrade? [06:07] pack-0.92 -> bt+gc [06:07] * mwhudson stabs non-canonical histories [06:12] bob2: bt+gc??? I'm lost [06:13] thumper: btree indexes and lifeless's groupcompression thingy [06:13] (i assume) [06:14] ah [06:14] the pair of new formats lifeless posted to the list this morning [07:19] bob2: :) [07:19] bob2: it will be better when the fetcher knows to do inverse-topological-order [07:59] Oh no. Is there any way to undo a bzr revert? [08:04] awmcclain: bzr revert of uncommited changes ? I think they are lost ... [08:04] Boo. for that. [08:04] all for doing bzr revert instead of bzr revert . [08:05] not pleased with bzr right now. [08:06] doesn't help now, but maybe aliasing 'revert' to 'shelve --all' might save you in the future? [08:08] yeah... i just wanted to revert one file. [08:08] so i cd'ed into the child directory [08:08] but bzr revert crawled out and did the entire tree [08:08] bad bzr! naughty! [08:10] awmcclain: there are backup files [08:10] oh??? [08:11] awmcclain: just check for hidden files in your folder [08:11] okee doke [08:11] (ones ending with ~) [08:11] I think there is maybe a way to ask bzr to revert the revert :p [08:11] but I don't know [08:13] Well, I got it for the one file that really mattered... thank you! === elmo_ is now known as elmo [09:13] 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] Steps to reproduce: bzr init-repo --rich-root-pack repo; cd repo; bzr init branch; cd branch; bzr reconfigure --standalone [09:16] lifeless: I'm aiming to get to Canonical's offices sometime between 1 and 2 this afternoon. Is that OK? [09:24] 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] MvG: "bzr info" should tell you if it worked [09:27] hello [09:27] this is a bit offtopic, but i'd like to ask how you guys wrote your distutils script [09:28] bob2: bzr info tells me it did. But I worry it might have been migrated only partially. Otherwise why the error message? [09:30] ogthats cool [09:30] igc: thanks [09:30] igc: it really needs a custom InterRepository to compress well [09:31] igc: it will get about 50% I expect from an existing repo with the current inter object [09:31] Odd_Bloke: thats cool [09:31] MvG: sounds like you've found a bug; could you please file it in launchpad ? [09:33] lifeless: Sure. [09:43] lifeless: Excellent. :) Has jelmer mentioned what time he's going to be arriving? (SUBTLE PING :D) [09:44] lifeless: Submitted https://bugs.launchpad.net/bzr/+bug/248932 [09:44] Launchpad bug 248932 in bzr "reconfigure --standalone raises IncompatibleRepositories" [Undecided,New] [09:45] Odd_Bloke: no :) [09:46] mv thanks! [10:55] hello [10:55] now trying migration from svn to bzr [10:55] what tools better to use? [10:55] bzr fast-import? [10:59] anyone is here? [11:00] hi jaro [11:00] there is normally someone round who can help [11:00] i only have experience with bzr-svn, which isn't really aimed at doing migration [11:01] :/ [11:01] well, bzr-svn works fine for migration [11:02] luks: can i with bzr-svn migrate my subversion repository to bzr and i will see all changes? [11:03] jaro: yes [11:03] how? [11:03] May by some how to? [11:03] link [11:03] ? [11:04] install bzr-svn, run `bzr svn-import ` [11:04] or just `bzr branch ` if you want to migrate only trunk [11:05] then you can uninstall bzr-svn and just use plain bzr [11:05] what is the mystical "front-end" tool that is being mentioned in http://bazaar-vcs.org/BzrFastImport ? [11:06] ignas: http://bazaar-vcs.org/BzrFastImport/FrontEnds [11:07] luks: thanks [11:09] luks: i try bzr svn-import [11:10] then cd [11:10] and there are no files [11:10] :( [11:10] try `bzr info` [11:11] Repository branch (format: rich-root-pack) [11:11] Location: [11:11] shared repository: . [11:11] repository branch: . [11:11] Related branches: [11:11] or are there no files or directories at all? [11:12] parent branch: [11:12] if not, what URL did you use? [11:13] file:///patch/to/svn/project [11:14] jaro: does the project have only a single branch? no trunk/branches/tags structure? [11:14] yes [11:14] well, then all you need is in the directory [11:14] jaro: do 'bzr checkout .' and you'll get your files [11:14] you can use `bzr checkout .` to recreate the working tree if you want [11:14] :) [11:15] but bzr checkout only get files [11:15] But i need history [11:15] bzr log [11:15] in that directory [11:15] or bzr vis for a nice visual history if you have gtk plugin installed [11:18] bzr log show my history [11:18] hey ignas [11:18] So can I delete /patch/to/svn/project ? [11:18] LarstiQ: hi [11:18] And how can I see my files in /patch/to/bzr/project ? [11:18] To change them ? [11:19] jaro: it's always nice to keep backups, just in case, but yes you can [11:19] jam: bzr checkout . [11:19] jaro: [11:19] evil tab completion [11:20] poolie: around? [11:21] luks: big thanx [11:23] 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] 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] lifeless: hi, a bit [11:29] poolie: can we chat about get_record_stream a bit? perhaps a quick call ? [11:32] lilfeless: so my first group-compress test is still running after 2h30minutes [11:33] I'm wondering if I'm doing the right thing? [11:33] I'm doing this ... [11:33] bzr init --gc-plain . [11:33] igc: is there a windows vm running the testsuite yet? [11:33] bzr pull ../normal-repo [11:33] 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] lifeless: the normal repo I'm trying first is python [11:34] hi LarstiQ [11:34] 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] igc: heya :) [11:34] LarstiQ: not to my knowledge [11:34] igc: hmmm [11:34] igc: yes, the fetch logic is O(n^2) at the moment [11:34] I'm pretty sure jam is running on Windows these days [11:35] igc: the raw compressor is better, but *shrug* [11:35] lifeless: when n = # of revisions? [11:35] s/when/where/ [11:36] LarstiQ: and vila was for a while as well IIRC [11:36] igc: ok. I watched a run on markh's laptop, and it didn't look too good. === emgent_ is now known as emgent [11:37] igc: yeah; it caps at 20MB of raw output and resets, but it will be doing 1000's of extractions [11:37] igc: I should have a better InterObject done today [11:38] LarstiQ: as in the test suite didn't look good? or some particular bzr operations? [11:39] lifeless: ok. VM memory use for the pull is up to 780MB fwiw [11:39] lifeless: Is hard to say what happend becouse other person asks me to help with that ... [11:40] igc: mysql? ooo? [11:40] igc: test failures, including not entirely deterministic ones related to test cleanup [11:40] lilfeless: I'm planning to do those tonight but I was waiting for the python one to finish first [11:40] matkor: ok. well, if bzr st shows one as unknown, just use regular 'mv' etc [11:41] igc: it may well be faster to do a upgrade to --btree-plain first (or btree-rich-root etc9 [11:43] lilfeless: interesting. I did try the same thing with --btree-plain. That took 195 secs [11:43] which is slowly than a branch (170s) but not by a lot [11:43] igc: so the btree index layer won't bloat anywhere near as much as teh graphindex one [11:43] igc: 'bzr upgrade --btree-plain' will be _much_ faster than a pull :) [11:43] s/slowly/slower/ [11:55] igc: (upgrade --btree-plain will rewrite just the indices) [12:45] how do I cancel a merge? [12:45] ignas: Revert [12:45] bzr revert seems to only revert the changes [12:45] i still can see the merged revisions in the pending merges list [12:45] ignas: are y ou running 'bzr revert' [12:45] ignas: or something more complex ? [12:45] "bzr revert ." ;) [12:46] got the hint [12:46] ignas: the . tells revert not to touch pending merges :) [12:47] ignas: bzr revert --forget-merges [12:47] menesis: thanks, just plain "revert" worked too though [12:48] by the way - what is the correct way to resolve a tricky situation: [12:48] i have a release branch 2008.04 [12:48] and trunk [12:48] I had a bugfix branch for small bugfixes [12:48] it worked fine [12:48] but I have managed to do bzr pull from trunk to it [12:48] and now if I want to merge a couple more of the bugfixes to 2008.04 [12:49] i am getting all the new stuff from trunk that got pulled ... [12:49] i could -r rev1..rev2 the merge to my release branch [12:49] but then I will lose the history for separate commits (I think) [12:50] 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] that is based on some common ancestor of trunk and release [12:57] 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] 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] must I always branch specifically from the "branching" point of the release and trunk branches? [13:02] ignas: I generally branch features from trunk, and do a cherrypick merge if needed [13:02] 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] 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] 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] and features should not be merged into release branches that have been in use in general [13:06] well, different folk find different things work [13:06] I generally ignore history and just code to head; backporting is usually dead easy bzr-wise [13:07] and how do you do backporting? [13:07] cherry picking? [13:13] 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" === mw|out is now known as mw [13:57] ignas: yes, I cherry pick when needed [14:05] re [14:28] So, when is a new .pack file created? [14:29] the sizes are really different in my repository [14:29] I'm using a --rich-root-pack repos (that's best, right?) [14:29] uws, hi [14:29] hey jelmer [14:30] uws, rich-root-pack would probably be the best choice if you don't have to worry about pre-1.0 clients [14:30] i'm hip and up-to-date, so no worries there :) [14:31] (-: [14:31] jelmer: also, i'm cloning a svn repos using svn+http:// and it seems to open a new connection for each revision [14:31] is that right? [14:31] * jelmer catches up on three days of bzr-svn highlights [14:31] uws: No, that'd be a bug [14:32] svn+http:// is ok right? [14:32] though a known one if you're using particular older versions of bzr-svn [14:32] yeah, svn+http:// and http:// should both work [14:32] ii bzr-svn 0.4.10-2 Bazaar plugin providing Subversion integration [14:32] jelmer: I'd love a fix for the find_tags stage being very slow. [14:32] * spiv is about to sleep [14:32] jelmer: If i pull from the http:// one later after branching from svn+http://, will that download all revisions again? [14:33] uws: No, the identity of the repository does not depend on the location [14:33] so what does it depend on? [14:33] spiv: I may have a look at that in the next two days [14:33] uws: the subversion repository uuid [14:33] jelmer: wonderful! [14:33] * spiv -> sleep [14:33] uws, and the path in the repository [14:33] ah ok [14:34] spiv: goodnight [14:34] I'm cloning webkit svn ;) [14:34] takes a LONG time [14:34] ah, ok [14:34] I need to do more memory use profiling [14:34] jelmer: yeah, it leaks so I pull like 1000 revs at once [14:35] siretart: do you happen to be in .uk as well? [14:36] jelmer: it seems bzr-svn 0.4.10-2 (debian package) calls connect() to the http server quite often\ [14:36] my guess is each revision [14:37] uws: That should not be the case with the 0.4 branch of bzr-svn [14:38] 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] bzr-svn is also quite cpu bound it seems [14:38] lamalex_2: just type "bzr init" and you're done [14:38] uws, some of that has changed as well [14:38] 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] 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] uws: ... that's too easy [14:38] jelmer: ^^ i see that every few seconds [14:39] how do I control write access? [14:39] lamalex_2: to a shared repository? just file system access rights, or share a shell accoutn [14:39] ah ok [14:39] uws: Yeah, so that's a known issue which is fixed in the 0.4 branch [14:39] great thanks [14:40] jelmer: does it affect speed seriously? [14:40] uws: The reconnects probably don't matter much [14:41] jelmer: so I shouldn't have to upgrade manually (and remove the debian package) [14:41] uws: I can run a webkit import here as well with the 0.4 branch and see how fast that is [14:41] jelmer: it's really slow :) [14:41] uws, what's the URL? [14:41] jelmer: svn+http://svn.webkit.org/repository/webkit/trunk [14:41] I can't for the life of me get authentication.conf to work :( [14:41] I want it to change the username I connect to a server using, but it always ends up connecting as me. [14:41] jelmer: sorry, no [14:41] does running "bzr pack" once in a while help for speed? [14:42] jelmer: I'm .de [14:42] Anyone have any experience on this happening and knows what I'm doing wrong? [14:42] pickscrape: you can use sftp://username@host instead [14:42] 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] pickscrape: is it ssh? [14:42] yes [14:43] pickscrape: if so, you can also force it in ~/.ssh/config for that particular host [14:43] uws: why would I use init vs init-repository? [14:43] furthermore, urls for push/pull are remembered so it's really a one time thing [14:43] uws: Oh, thanks for that I'll look into it. [14:43] lamalex_2: depends on whether you will have multiple branches, which will share the same "backing storage" [14:44] 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] lamalex_2: "bzr help init-repository" versus "bzr help init" [14:46] that doesn't give me why I should use one or the other, advantages, disadvantages, etc [14:46] lamalex_2: branches created with "init" contain ALL history in .bzr [14:46] so if you have two branches for the same project, most history will be there twice, resulting in unnecessary disk usage [14:47] a repository holds all the revision data, and your branches (doesn't matter how many) just point to a specific revision, [14:47] ah [14:47] this results in the repository .bzr dir to be large, and the branch .bzr dirs to be really smalls (a few KB) [14:47] so it sounds like repository is the safer choice, are there any large disadvantages? [14:48] lamalex_2: you can't copy the branch directory using conventional means (cp, drag/drop in file browser) to other media [14:48] lamalex_2: but you can of course still create branches outside the repo as well [14:49] greetings asabil [14:49] Odd_Bloke: want some help with bug 160530? [14:49] Launchpad bug 160530 in bzr-pqm "pqm-submit is sending messages pqm doesn't understand" [Critical,Fix released] https://launchpad.net/bugs/160530 [14:49] hello pygi :) [14:53] 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] 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] jelmer: Working on bzr-gtk? [15:11] jam: I haven't really looked into it enough, I'll look into it further later. [15:11] Odd_Bloke: np [15:11] Someone certainly could have cleaned up PQM's message parsing and not mentioned it [15:12] jelmer: is it right that bzr-svn looks like it's cpu-bound? [15:13] PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND [15:13] 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] like that, all the time [15:13] (also 100% btw) [15:14] uws: Yeah, some bits may be CPU bound, especially in < 0.4.11 [15:14] colbrac: somewhat [15:15] jelmer: Is that account coming through? [15:23] colbrac, yep, just give me a few minutes [15:24] uws, it's pretty slow here as well, but not using a lot of cpu [15:24] 2497 jelmer 20 0 209m 178m 7992 S 14 11.8 8:11.88 python [15:25] jelmer: Hmm, your 0.4 branch installs ra.so and client.so (and some other files) directly into site-packages/ [15:25] is that right? [15:27] jelmer: Unable to load bzr-svn extensions - did you build it? [15:27] strange, I did [15:29] jelmer: http://news.launchpad.net/ppa/introducing-autoppa [15:29] lifeless, blegh, ubuntu only :-( Hopefully it works on Sid :-) === james_w_ is now known as james_w [15:37] rockstar: hi, are you still looking for me? [15:38] james_w, kinda. I've got some questions about using bzr-builddeb [15:38] rockstar: ah, sure, ask away [15:40] jam: hi [15:41] 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] james_w, ^^ [15:41] I don't use it that much :-) [15:41] what are you struggling with? [15:42] uws: is there any apache setup or anything I need to do to make this repo accessible? [15:44] wow no! this rules. bzr+ssh://host/path [15:44] 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] 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] uws, hmm, it is slow [15:45] uws, I'm at 800 revisions now [15:45] 28k to go :-) [15:45] jelmer: yeah, just stop it. you can branch from me later if you wish [15:46] I'm at ~18000 already [15:46] ah, ok - over how much time? [15:46] lifeless: I would be curious to know how you did remote testing of your btree code [15:46] ~1.5 days [15:46] wow, ok [15:46] As I'd like to put the new bloom stuff through its paces over a remote connection [15:46] uws: I guess the 0.4 branch is a bit faster then [15:46] jelmer: I couldn't get it to work [15:46] So far, I've just finally managed to do better than no blooms on a local filesystem [15:46] jelmer: complained about needing bzr 1.6, and it doesn't work with the 1.6b2 [15:47] complaining about make_knit_factory or something [15:47] Not a *lot* better yet, but *better* which means they are viable :) [15:47] uws: yeah, it needs bzr.dev [15:48] jelmer: will the speed improvements be an order of magnitude? [15:49] 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] uws, it's doing about one revision per three seconds here [15:49] what sort of speed are you seeing? [15:49] Though we could still *create* them, even if we didn't always use them yet. [15:49] jelmer: roughly that yes [15:49] jelmer: however I don't see that anywhere [15:49] jelmer: only from the "strace -econnect) [15:50] It just says "Pull phase 0/2" for a VERY long time [15:50] 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] rockstar: why, that almost sounds like a larstiq workflow ;) [15:51] jelmer: will speed be constant when the revision number gets higher for my bzr-svn branching? [15:51] At this point, what does bzr-builddeb provide over the standard debian tools? [15:51] uws, yeah, that's the idea [15:51] jelmer: Ok, I'll just let it run for the next few days then :S [15:52] launchpad doesn't have a mirror either [15:52]