[00:01] jelmer: you about? [00:09] johnf: hi [00:10] jelmer: don't worry I was wondering why the packaging process was so different for bzr-svn than for bzr and bzrtools and then realised your managing it yourself upstream [00:11] johnf: it's different choices wrt how the packaging is done [00:11] johnf: Debian/Ubuntu use the same style for bzr and bzrtools as bzr-svn [00:12] johnf: LarstIQ was looking at providing updated packages for bzr-svn in the PPA [00:12] jelmer: yes he it for hardy. I'm about to do it for everything else. I meant to do it a few days ago when I did bzr and bzr-svn but ran short on time in setting up my end for the different process [00:13] johnf: I think he wouldn't mind if you uploaded for bzr-svn as well [00:15] jelmer: is there a reason for lp:~bzr/bzr-svn/beta-ppa-hardy vs lp:~bzr/bzr-svn/hardy-ppa ? [00:16] johnf: not really [00:16] well, one is probably more up to date than the other :-) [00:16] ok I'll remove one of them [00:19] hmm I can't check them out. Something weird with the stacking [00:20] johnf: what's the error? [00:20] when checking out lp:~bzr/bzr-svn/beta-ppa-gutsy [00:20] bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~jelmer/bzr-svn/0.5/" [00:21] launchpad says it's stacked on lp:~jelmer/bzr-svn/0.5-mirrored [00:22] hmm, that's because lp:~jelmer/bzr-svn/0.5/ is now a "remote branch" [00:22] it used to be a "mirror branch", mirrorring the URL that's now mirrorred by lp:~jelmer/bzr-svn/0.5-mirrored [00:22] not sure if there's much that can be done about that [00:22] abentley: are you still there? [00:24] hello [00:25] heh trying to look at the revisions gices Internal Server error [00:26] johnf: looks like a launchpad bug then :-) [00:26] johnf: you might be able to fetch it over http [00:28] hmm don't think so. I think it is very unhappy because the parent has disappeared [00:28] johnf: hi [00:28] johnf: do the following [00:29] bzr branch --stacked lp:~jelmer/bzr-svn/0.5/ local [00:29] python [00:29] import bzrlib.repository [00:29] l = bzrlib.repository.Repository.open('local') [00:29] hi..! i forgot my ssh password. is possible to register another ssh public key in launchpad? [00:29] r = bzrlib.repository.Repository.open('sftp://bazaar.launchpad.net/~bzr/bzr-svn/beta-ppa-gutsy [00:29] i don't understand well about it [00:30] l.fetch(r) [00:30] then run bzr heads and do a pull . -r revid:real-head [00:30] yeonhoo: yes, in the web ui you can do that [00:30] 3 weeks ago i learn about bzr to upload and fetch... but now im totally new... [00:30] the things in my head gone !! [00:32] yeonhoo: https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair [00:32] lifeless: thank you very much...! i was looking for this page... [00:33] i have to up my search skill.... [00:33] lifeless: http://pastie.org/422536 [00:34] I'm very tempted at this stage to just create branches with debian directories similar to bzr and bzrtools. That way the scripts can just build all of them automatically [00:34] johnf: if you do that, please also update the instructions in bzr.dev for building bzr-svn for the PPA [00:34] johnf: oh, my bad [00:35] johnf: o = Repository.open('lp:~jelmer/bzr-svn/0.5/') [00:35] johnf: l.add_fallback_repository(o) [00:35] johnf: then do the fetch again [00:35] jelmer: yep already have a patch with other changes so I can do that [00:36] johnf: and please realise that that means it will no longer be possible to import changes from the Debian/Ubuntu package [00:36] (as they won't have any shared history) [00:36] jelmer: yeah I would need to do that manually [00:37] jelmer: if you could make that branch be mirrored again, at least until 1.14 hits lp, that would fix this [00:40] lifeless: hmmok [00:40] jelmer: its the gaol patch spiv put up that will fix this [00:43] ok, should be fixed now [00:43] johnf: please try again [00:43] lifeless: ah [00:45] which hasn't landed - but you can see that its a third-party site issue [00:51] jelmer: looks good, thanks [01:30] hummmm [01:30] i have want to commit whole directory but it's uploading not sub directories [01:31] is there some flag to include subdirectories? [01:39] jelmer: I think I will change the way bzr-svn packages are built. The problem in doing it this way is there will be conflicts in changelog every single time. [01:39] At the moment with bzr and bzrtools I can run 5 scripts and I'm done. Would be easier if bzr-svn worked the same way with just a quick check if any changes were made to debian dir since last time [01:40] alternatively I'm happy to leave it to you or someon else to update bzr-svn in the PPA [01:48] humm [01:48] bzr add <--- it's not adding subdirectories [01:49] how to include subdirectories? [01:50] bzr add . has same effect... [01:53] hm [01:58] ah.... [01:58] help [01:59] yeonhoo: what's the problem? [01:59] it is not adding subdirectories automatically [01:59] bzr add . [01:59] hmm it normally does [01:59] or bzr add [01:59] does "bzr ignored" indicate that it is ignoring them? [01:59] are they ignored? [01:59] and i tried on --no-recurse [02:00] or are they subtrees? [02:00] no.. [02:00] subtrees? [02:00] or do you have analias that makes add do no-recurse ? [02:00] it prints nothing with bzr ignored [02:00] nop.. [02:00] its doing recursively (as normal) [02:01] but if it is subtrees i dont know [02:01] how can i verify this? [02:01] i have a directory ..with many subdirectories... [02:01] is there simple command that does this? [02:02] when "bzr status" [02:02] it lists a lot of file not-versioned [02:02] it lists as unknown [02:02] Th/part [02:02] if bzr status lists the files as unknown [02:02] 'bzr add' should add them [02:03] i already try this [02:03] can you capture the output of 'bzr status' and then 'bzr add' and pastebin it for us ? [02:03] ok.. [02:03] wait! [02:06] http://pastebin.com/d29ec14ee [02:06] here.. [02:08] yeonhoo: what happens if you bar add rdfapi-php? [02:09] sorry i didn't got what you said [02:09] if i bar? [02:09] ah [02:09] ? [02:09] sorry bzr add rdfapi-php [02:10] nothing happens [02:10] just one more blank line [02:10] ok [02:10] is it bzr internal problem? [02:10] please run 'bzr --version' [02:10] i should reinstall ? [02:10] look for the line that says 'Bazaar log file:' [02:11] rename that file on your disk [02:11] ok [02:11] then run 'bzr info -v', 'bzr st', 'bzr add' [02:11] these will put data into th elog [02:11] upload the log somewhere [02:11] and also, what version of bzr do you have [02:13] ok [02:14] 1.11 version.. === ampelbein is now known as Ampelbein [02:18] lifeless : unknown is persisting .. [02:18] bug!? [02:19] according to info -v : i have 100 unknown files.. [02:20] well im going to switch to 1.3 [02:21] yeonhoo: did you upload the log file some where we can look at it? === d6g is now known as d6g|away [02:30] hum [02:30] switched to 1.3 but not solved problem [02:30] what i think is the project has in each directory .svn folder [02:31] i think it is affecting the add command.. or not -_-... [02:33] yeonhoo: have you uploaded the log for us yet? [02:33] also 1.3 is much older than 1.11 [02:34] ah sorry i didn't [02:34] i saw now [02:35] well the last log you mean? [02:37] http://pastebin.com/m4638006e [02:37] well its the last log file after changing log file's name [02:38] yeonhoo: ok, you are using bzr on a svn project, which is fine [02:38] yeonhoo: but I guess you don't have commit access to the svn repository> [02:38] ? [02:38] actually.. . [02:38] Unable to open with Subversion: Unable to open an ra_local session to URL [02:38] jelmer: ^ why isn't this showing an error for yeonhoo [02:39] yeonhoo: so whats happening is that: [02:39] C:/Users/yeonhoo/yeonhoo-serv is a bzr project [02:39] hum.. [02:39] yeonhoo: and all the folders under it are in svn [02:39] yes [02:40] yeonhoo: bzr looks at them, can see they are in svn, and ignores them because they count as nested trees [02:40] you can either work with them directly, or branch from svn to get your own bzr branch of the svn project, or remove the .svn directories, if you want to just copy the stuff on your disk into bzr [02:41] lifeless: does bzr have a concept similar to svn-externals? [02:41] johnf: nested trees [02:41] yes... then i stated to delete .svn folder in each directory manually [02:41] johnf: incomplete, being worked on [02:41] cool [02:41] but there are much..then i gave up [02:42] yeonhoo: as I don't know your overall goal, I can't recommend which course of action is best for you [02:42] ok..! [02:42] Did something change in bzr.dev or http://bazaar-vcs.org/bzr/bzr.dev/ this week? I swear pulling it is slower and uses more bandwidth. [02:42] thank you very much!! [02:42] * Peng_ should be unlazy and do a test. [02:43] i really apreciate your attention and help!! thank you guys! [02:43] Peng_: nothing that should affect that, no [02:43] well now im going to sleep then...bye! [02:46] It took 35-45 seconds to pull bzr.dev on the 16th and 17th, and 75 seconds yesterday and today. [02:47] http://bazaar-vcs.org/bzr/.bzr/repository/ got autopacked on the 20th, but that probably happens a lot. [02:57] Peng_: interesting; if you roll back your bzr.dev? [02:57] Hold on. [02:58] Plus I have bzr-search and the revgraph cache slowing things down a bit. [02:58] :P [02:58] it could be just more commits [02:59] I can't say about the commits, but on the 16th and 17th, pulling changed a lot more files than yesterday and today. [02:59] Yesterday and today, I think there were only 2-3 mainline revisions and maybe 6 merged revisions. [03:01] and you pull with bzr.dev itself yes? [03:02] Yes. [03:02] lifeless: sorry, just got back [03:02] Just took 41 seconds doing it with current bzr.dev in a new repo. Eh. [03:03] (No bzr-search indexes.) [03:03] lifeless: Did yeonhoo's problem get solved? If not, can you summarize it? [03:03] Maybe the layout of my repo is just hitting some bad case. [03:03] jelmer: have a look at the last pastebin [03:04] Peng_: perhaps your local repo autopacked [03:04] Peng_: some large power of 2 [03:04] jelmer: http://pastebin.com/m4638006e [03:04] jelmer: partly confusion, but he had a bzr tree with svn dirs in subdirectories [03:05] lifeless: what exactly didn't work? [03:05] (looking at the pastebin now) [03:05] jelmer: well, all the subdirs were detecte as nested trees [03:05] and thus ignored by bzr add [03:05] lifeless: Shouldn't autopacking make it faster? [03:05] thats the confusion bit [03:06] but the lack of errors is what I was noting, his RA connections were all failing, but nothing was said [03:06] Peng_: oh is it still slow? [03:06] lifeless: it's correct the RA connections are failing, since these were working trees not repositories [03:06] jelmer: ah [03:07] jelmer: do we need to log it in that case? [03:07] lifeless: This was on a fresh, fully packed repo. [03:07] [it confused me] [03:07] It took 43 seconds with bzr.dev -r date:2009-03-15. Maybe I'm just crazy. [03:08] Peng_: I'm confused by this :P [03:08] lifeless: Yeah, we probably shouldn't [03:09] jelmer: knowing its a svn tree is useful, seeing what looks like an error but is expected isn't :) [03:12] lifeless: Using the latest bzr.dev of the time, on the 16th and 17th, it took 35-45 seconds to pull the latest revisions of bzr.dev. Yesterday and today, it's taken 75. On a test repo missing the latest 2-3 revisions, it takes 40-45 seconds with both the latest bzr.dev and a week-old version, but that's without bzr-search indexes or a working tree, which could potentially take close to 30 seconds. [03:12] Oh, plus that it's better-packed. [03:20] Peng_: what happens if you use the bzr of the 15th to pull those 2-3 revs [03:21] lifeless: Err, you're right. This is confusing. I did do that: it was about the same pulling in the test repo. [03:22] I can't exactly test in my main repo since it already has the latest bzr.dev. [03:23] so, if bzr.dev and older-.dev are the same in the new repo [03:23] it suggests either the network changed, server changed, or your older repo changed [03:23] how many packs does your main repo have [03:24] there was that new theme put up [03:24] kfogel: ping [03:24] lifeless: 14 at the moment. [03:24] I suppose its possible some rewrite rule got botchified [03:24] oh [03:24] lifeless: hey, just responding to your mail [03:24] I wrote "takes" when I should have written "already has" in the opening of my mail, which probably led you to think that I had much less understanding of the bzr commit process than I do :-). [03:24] kfogel: cool [03:25] kfogel: :) [03:25] Hmm, I pull brisbane-core in the same repo, and it hasn't gotten slow. [03:25] Peng_: bbc is on lp [03:25] so [03:25] lifeless: Yeah, I know. But if something was wrong on my end, it should be affected (effected?). [03:25] indeed [03:26] lifeless: I'm not sold on my proposal -- fixing the root cause would be much better. But the bug's been open for two years with this user-visible manifestation :-). Nothing in the commit process conflicts with grabbing a commit message earlier and calculating a checksum -- they can be done before the commit is even *started* if we want. === Ampelbein is now known as ampelbein [03:26] kfogel: checksum of what [03:26] lifeless: the overall change. a change fingerprint. [03:26] kfogel: (and yes, it does - we show the diff in the commit message for people) [03:27] kfogel: how would we get the overall change without calculating the result? [03:27] Is it possible to check which revisions are in a specific .pack? "dump-btree" on the index? [03:27] Peng_: yes exactly, the .rix [03:27] lifeless: ? not sure I understand that question. We can calculate anything we want; it's a read operation... ? [03:28] lifeless: the current arrangement and sequence of code is not written in stone, I guess is what I mean. There definitely _is_ a performance implication here, of doing work twice, I see that. [03:28] kfogel: we're going to have to be much more specific, assume _no_ common ground or something [03:28] hmmmm [03:29] lifeless: so, as part of the commit process, bzr currently calculates an overall change fingerprint, right? [03:30] lifeless: I swear something odd is happening in my repo. Should a 15-line diff lead to a 2.5 MB .pack? [03:30] kfogel: no [03:30] it doesn't [03:30] Peng_: fulltexts can do that [03:31] lifeless: but ... here is the level of detail I'm not sure you want to go into. There is such a thing as "calculating a fingerprint for a VC change": there are known algorithms, they always produce the same fingerprint for the "same" change, etc. right? [03:31] kfogel: no, we don't do that [03:32] we fingerprint whole trees, not deltas, today. [03:32] lifeless: yes, I get that :-). I'm just asking a general algorithmic question. HOWEVER, I think it is really academic [03:32] the perf implications of my proposal are frightening even to me, I agree it's a no go on those grounds alone. [03:32] sure, one could define an algorithm to fingerprint a delta [03:32] lifeless: that's all I was ever talking about in my proposal. [03:33] I think I probably wrote it up in too few words, causing needless head-scratching. Oh well. [03:33] or perhaps too many :P [03:33] Well, only in the sense that the proposal itself might be too many :-). [03:33] I would have said something like ... 'can we just temporarily release the OS-lock on dirstate while we wait for the commit message' [03:33] But ... so what do we do? blocking read operations is a serious lose. [03:34] lifeless: but then the change could change under you [03:34] lifeless: then there *is* a race condition [03:34] lifeless: Oh, good point. It was probably a fulltext. Or 10? [03:34] because you couldn't necessarily detect it, right? [03:34] kfogel: uhm, you have skupe? [03:34] I want more bandwidth, to get you across these internals [03:35] lifeless: heh. I have two boxen; one at an office, where I *just* got skype working today, and one at home, where I haven't yet debugged my microphone sound problems. [03:35] I'm at home right now. [03:35] I did sketch it in my mail, but it seems lacking [03:35] ok [03:35] lifeless: where are you? [03:35] so.. [03:35] .au [03:35] hmmmm [03:35] what phone #? [03:35] (priv msg is fine) === abentley1 is now known as abentley [05:00] Moving a working tree to another partition will change all the inodes and make "bzr st" need to rescan everything, right? [05:08] yes [05:08] \o/ [05:15] thats pretty fast though [05:15] its just read the file once [05:16] if you have just copied it, its in cache etc [05:18] Yeah, I know. [07:24] lifeless: FWIW, I just pulled the latest 2 revisions of bzr.dev (with bzr.dev) in 32 seconds, on my original repo and branch. This was after moving it from a small, nearly-full ext3 partition to a much larger ReiserFS partition, though. :\ [07:25] Peng_: do you think that has anything to do with it? [07:25] lifeless: Probably. At the very least, it was rather unscientific of me to do. [07:25] :P [07:25] s/Probably/I don't know/ [07:26] That ext3 fs is probably fragmented badly. [07:26] fsck can tell you [07:27] Sorry, moving all of that data was terrifying enough. I'm afraid of doing something wrong with fsck and destroying my fs. :P [07:27] oh, you don't need to umount it [07:27] fsck -n [07:27] But accidentally fscking a mounted fs could ruin it. [07:27] not with -n [07:28] What if I forget -n? [07:28] Peng_: don't forget [07:28] Err, what the hell? bzr.dev's push location changed. [07:28] Oh, I bet I need to update locations.conf. [07:29] * Peng_ stops panicking. [07:52] vila: ping [07:58] jml: yo [09:06] lifeless: pong [09:07] vila: do you have a copy of tests.parallel with both our stuff in it? [09:08] lifeless: no, I have a loom with a lifeless thread where I import your modifications [09:08] It's at lp:~vila/bzr/parallel-selftest but it doesn't contain your latest ec2 changes [09:08] k [09:09] I would like the patches you promised me :P [09:09] and at that location it should be a simple branch [09:09] I'm shuffling stuff around lots still :) [09:09] oops, I didn't push [09:09] done [09:10] revno 4175 should contain the stuff I use here [09:10] vila: could you arrange for some patches? [09:10] vila: there are three projects involvled.. [09:12] AFAICT I have changes against bzr.dev only so far, let me see [09:12] vila: I know you do, I'm noting that this is what we need to split out [09:13] which is why I want to deal in patches rather than in branches [09:13] Agree, I'd want to be able to use it on any bzr branch [09:13] but using branches instead of patches is easier for me when applying :) [09:14] lifeless: bundle sent, check your mail [09:15] it contains some trivial fixes for bzr.dev irrelevant here so just ignore the noise :) [09:16] * vila goes back to its late breakfast [09:20] :P === abentley1 is now known as abentley === abentley1 is now known as abentley === d6g|away is now known as d6g [12:37] ok, ec2 polished a tad more..., 3m36 to do a test run === abentley1 is now known as abentley === abentley1 is now known as abentley [15:15] moin [15:16] johnf: I suppose at this time you are not awake? [15:31] johnf: anyway, I had troubles pushing the hard-ppa bzr-svn branch up to launchpad, intrepid-ppa is already pushed, packages for intrepid and hardy are in bzr-ppa and bzr-beta-ppa [15:31] johnf: I'll get to the rest today [15:31] johnf: as to the future, I'm open for suggestions. [16:27] Hi === d6g is now known as d6g|away [16:32] Can bzr work with avahi? [16:33] CMooney: yes, there is a plugin [16:33] brilliant! [16:36] jelmer, How reliable is it? [16:37] Also if I am using bzr on one computer on my network, how to do pull across a current version to another machine on that network (hence me asking about avahi)? Seems the guide assumes you connect to a server via http [16:38] CMooney: which guide? [16:39] Ah right, just read the official guide rather than the "Bzr in five minutes" and I think it has the information I need [16:41] got it. I can use stfp because I have ssh installed [16:45] the avahi plugin mainly allows you to announce and browse branches on the local network === abentley1 is now known as abentley [16:52] I am having a bit of trouble again. [16:52] I am able to checkout a version from one machine. I edit it on my laptop, commit the change, then try and merge. The merge doesnt work and I get "Nothing to do." from bzr [16:53] CMooney: merge what into what? Bzr thinks all the revisions of the branch are already in the branch. [16:54] LarstiQ, I thought you had to merge your changes into the main repo. eg merge the changes from my laptop to my main machine. [16:54] Do I need something else? [16:55] CMooney: if you have a checkout, and not a standalone branch, then when you commit in the checkout both locations will have the same set of revisions. [16:56] CMooney: if you don't have a checkout, and your branches haven't diverged (true so far), push/pull make more sense than merge. [16:57] So I have an edited (updated) document on my laptop, that I now want to send to my desktop. How would I do that? [16:58] LarstiQ, Ooops. Reading the documentation, I realise the word "Checkout" had a specific meaning, which I did not intend to use. I meant to say I have a branch on my laptop. (I think that's the correct terminology) [16:59] CMooney: how did you get the branch on your laptop? [16:59] bzr branch sftp://.../Writeup/ [17:00] CMooney: cool [17:00] CMooney: so, after you committed, do `bzr push :parent` [17:01] CMooney: after that first push, bzr will remember your push location. Also see `bzr info` [17:01] So if I open that file on the main computer (parent) now, it should be the version that I made on the laptop? [17:05] LarstiQ, So if I open that file on the main computer (parent) now, it should be the version that I made on the laptop? [17:09] CMooney: push doens't update the working tree, so you'd need to `bzr up` on the main computer [17:09] CMooney: but all the data in .bzr/ is as it should be. [17:10] so push put the updated file into .bzr and then "bzr up" accept the changes. [17:11] push will update the working tree for a filesystem-local push, though, right? [17:11] cmoomey: yep [17:16] Thanks for your help, LarstiQ [17:19] NfNitLoop: true [18:32] hi [18:33] i upgraded to jaunty and now my passphrase won't work [18:34] wait [18:34] nvm i think i know the problem === asabil_ is now known as asabil === abentley1 is now known as abentley [19:51] lifeless: what are the plans for porting bzr to python3? [19:51] moin ronny [19:52] ronny: why would there be plans like that? [19:53] trying to get a psf umbrella for a gsoc project, they have push python3 politics [19:53] silly peoples [19:54] SamB: for the unicode/bytestring seperation [19:54] evening ronny [19:54] yo LarstiQ [19:56] ronny: I'm not aware of any plans, dependencies like pycrypto and paramiko need to be tackled too [19:57] isnt paramiko from bzr people, too? [20:02] ronny: no, the paramiko author has contributed to bzr a bit, and vice versa, but it's a seperate project [20:04] ah, i see [20:04] wouldn't you also need to get plugin writers to switch at the same time? [20:05] SamB: we're not going to leave 2.x for a long while [20:05] SamB: I think (hope) the idea would be to support both Python2 and Python3 for a while [20:06] SamB: you're right you'd want plugins to work with 3, but luckily it doesn't have to happen all at once [20:06] what? both 2 and 3? [20:06] how? [20:06] Bazaar is terribly complicated. Concurrent 2 and 3 support would be difficult. [20:06] Peng_: Separate code bases perhaps [20:06] jelmer: very funny! [20:07] SamB: ? [20:07] I don't think that's *that* unreasonable [20:07] SamB: the recommended py3k support route is having it be generated from the 2.x codebase, no hand editing [20:07] oh [20:07] SamB: up to the point you drop 2.x support [20:08] Peng_: that could be true [20:08] LarstiQ: Yeah, but 2to3 isn't perfect. And you have to ditch 2.5 and 2.6 support. [20:08] Don't you? [20:08] Peng_: let's try it! :) [20:08] Peng_: no [20:08] Peng_: s/2.5 and 2.6/2.4 and 2.5/ ? [20:08] Peng_: 2.5 possibly [20:09] Peng_: depending on how you write it [20:09] jelmer: Err, yes. [20:09]