[00:03] I saw that lifeless - thanks [00:03] I'm good with your reply [00:03] you've seen the new bundle ? [00:04] it's come thru but I'm yet to look at it [00:04] in email at the moment [00:15] New bug: #156003 in bazaar ""Tree transform is malformed" error with "bzr import-dsc"" [Undecided,New] https://launchpad.net/bugs/156003 === mwh_ is now known as mwh === kiko is now known as kiko-zzz [00:51] New bug: #156015 in bzr "Typo in doc/en/user-guide/conflicts.txt" [Undecided,New] https://launchpad.net/bugs/156015 [01:26] Turns out gutsy's kernel doesn't like my firewall box. [01:27] ouch [01:27] seen that reconcile isn't ? [01:27] spiv: ^ [01:28] lifeless: no, I haven't. I assume there's mail about it? [01:28] there's a bug [01:28] * lifeless -> chemist [01:28] ring my mobile if you want to chat [01:29] * spiv finds the bug [01:34] poolie: ok, I understand the problem; the bug describes the situation pretty clearly. I'll add a test scenario for it. [01:35] spiv, ok [01:35] do you need to narrow it down [01:35] what i mean is, we want a narrower test than reconciling the whole branch [01:35] do you know what narrower test is likely to fail? [01:36] Well, I can write a narrower test than reconciling bzr.dev, I think. [01:37] it seems likely that creating a simple repository with about three revisions should be enough to reproduce it. [01:38] Is that what you meant? [01:41] it is [01:41] it's just that i would have thought that's what the existing tests do [01:42] in other words, do you know what's untested and causing this problem? [01:42] It appears the "file version X is actually removed from the repo (versions with X as a parent rewritten appropriately)" case is untested. [01:44] I'm re-reading the existing scenarios to double-check that. [01:45] but wasn't that the main point of the previous patch? [01:46] igc, ping? [01:46] hi poolie [01:46] Hmm, FileParentsNotReferencedByAnyInventoryScenario would seem to cover this case. [01:46] * spiv digs further [01:47] spiv, could it be to do with this being a no-op file merge (random guess) [01:47] igc, quick call? [01:47] sure - I'll call now [01:47] j [02:31] ` bzr diff`'s help says "Shows the difference in the working tree versus the last commit". when i run the command i dont get any output. i'm running the version of bzr shipped in Debian 4.0 [02:32] am i doing something wrong? [02:32] kgoetz, are there in fact any changes in the working tree? [02:33] what does bzr status show? [02:34] bzr status returns nothing, and yes i can confirm theres been changes made. [02:34] what does bzr --version show? [02:34] Bazaar (bzr) 0.11.0 [02:34] and bzr diff FILE on one modified file? [02:36] returns nothing [02:36] ok, this is pretty strange [02:37] has this happened before? [02:37] 0.11 is pretty old, is upgrading an option at all? [02:37] no, but this is the first time i've tried using bzr diff [02:38] yes it is, if theres decent debs [02:39] would these work? http://backports.org/debian/pool/main/b/bzr/ [02:39] i don't recall any bug like this, but that release is over a year old... [02:40] i'll check those out. [02:40] 0.18 doesnt seem much newer then what i'm on though [02:44] kgoetz: if status shows nothing [02:44] kgoetz: are the changes actually in this tree, to files that have been added and are not ignored ? [02:44] lifeless: i dont understand the 2nd bit [02:47] kgoetz: if you have ignored a file [02:47] then it can change, and bzr diff will not show it [02:47] whats the name of a file you have changed ? [02:48] lifeless: bzr info says i have 0 ignored [02:51] how many versioned files? [02:52] http://pastebin.ca/746222 heres some of the info fromb zr [02:52] 25+2 subdirs [02:52] what does bzr ls show? [02:53] did you just create this with bzr init. bzr add, or did you get the branch from somewhere else? [02:54] i branched rev 39 from home a few hours ago, bzr merged rev 40 from my mate , tried to bzr diff and it didnt [02:55] just instaleld the new bzr from backports [02:56] and because it asked, i upgraded the 'working tree format' [02:56] bzr info now has no info in it [02:57] just 'location' and 'related branches' [02:59] and 'bzr diff' and 'bzr diff file' still return nothing [02:59] bzr --version [02:59] Bazaar (bzr) 0.18.0 [03:00] if bzr st shows nothing [03:00] then I bet that your friend has not pushed their changes [03:00] so the merge had nothing to merge [03:00] if you try merge now it will probably say that, our feedback has improved since 0.11. [03:01] i can see a change i didnt make: [03:01] ### THIS IS BAD COUPLING - SHOULD BE RUN FROM builderrvcore (andrew) ### [03:01] perhaps you committed the merge already? what does 'bzr log -r -1' show ? [03:02] what part of it? revo: 40; commiter: andrew [03:02] I think perhaps you ran 'bzr pull' not 'bzr merge' [03:03] not sure. what would that mean? [03:03] pull gives you a mirror of another branch [03:03] it would mean you have what andrew has done in front of you [03:03] assuming you are not andrew ;) [03:04] then why dont i see uncommited files in bzr status? [03:04] because there are no changes [03:04] you have a copy of andrew's branch, not your branch with his changes merged and pending review [03:05] * kgoetz is confused. perhaps looking at the documentation can be this arvos timespender [03:05] a good way to check this would be [03:05] bzr missing ANDREWS_BRANCH_URL|less [03:08] says 'branches are up to date' [03:08] then it looks like you did pull from him rather than merge [03:08] in other words - he's already done the merge and there's nothing for you to do [03:09] so, be happy :) [03:09] so i have to bzr ci before i can see his stuff? [03:09] you can modify a file yourself to check that diff works [03:09] no [03:09] his stuff is in your tree now [03:09] lifeless, could it be that in 0.11 merge did --pull by default? [03:09] you're already looking at his stuff. If you want to see a diff of it, you can probably do 'bzr diff -r -2' [03:09] poolie: no [03:09] is there some way i can see what changes he made then? [03:09] poolie: I'm pretty sure it never did that [03:09] i didn't think so [03:09] oh, with switches [03:10] kgoetz: you can use bzr log to see the commit messages; bzr log -v will show the files changed in each commit, and if you find your prior commit in log (which I bet is one commit back), bzr diff -r REVNO will show you the difference from that to whats on disk. [03:11] lifeless: ok, thanks. [03:11] so before i start hacking again: is it ok for bzr ifno to not contain any info past thelocation+parent branch (having just updated the format after installing 0.18) [03:12] yes, we removed some bits that were expensive to calculate [03:12] you can get them with info -v [03:13] ah sweet. not sure how committers is calculated, but i'm guessing by system name [03:14] yes, or you can set it with bzr whoami [03:14] thanks. [03:15] I'm going to go for a walk; [03:16] good, enjoy [03:16] I need to think through this apply delta logic [03:16] can call if you want [03:17] thanks, but its not one of those problems, its one of these [03:17] I think I have a failing test for the reconcile bug. [03:17] you/spiv can ring me if you want to talk about anything [03:17] yay [03:17] spiv, tell me more? [03:19] Reconcile doesn't seem to actually remove unwanted file versions, although in all the tests so far it correctly updates other file versions to not use them as parents. [03:20] Perhaps it's more accurate to say that I have a failing test that appears to be related to the reconcile bug, but maybe not the same issue. [03:22] so I got as far as a shave before I had my answer [03:24] igc: so why do you object to bugfixed ? [03:24] it's not a word :-) [03:25] 85000 examples of it on google [03:25] try answers.com [03:26] what about answers.com ? [03:26] heh [03:26] spiv, may i call? [03:26] it's neat - dictionary definitions, synonyms, etc. [03:27] poolie: sure [03:27] still not getting the point :). [03:28] bugfixed appears to be more than uncommon [03:28] you asked why I objected - I told you [03:28] if not actually common [03:28] bugfixed doesn't add anything over just saying "fixed" but whatever :-) [03:28] it's not important right now [03:29] ok [03:33] lifeless: commit tweaks is now approved as well. Just the spelling errors raised by Rob Weir. [03:35] thanks [03:36] * igc food [04:56] jam-laptop: ping [04:56] lifeless: hi, typing one handed, though [04:57] TMI [04:57] lol [04:57] so, in dirstates memory representation [04:57] are fileids utf8 ? [04:57] yes [04:57] and have we made fileids utf8 outside that yet ? [04:57] IIRC, in memory everything is [04:57] file ids == utf8 in the core [04:58] greate [04:58] same with rev ids [04:59] kgoetz: this is why http://john.arbash-meinel.com/images/baby_face_01_small.jpg [05:00] lifeless: I'm probably heading off to bed [05:00] anything else you need? [05:01] sleep well [05:01] jam-laptop: later mate. vcute [05:04] jam-laptop: actually there is something [05:04] jam-laptop: do you recall a function to iterate the entries within a given path:fileid pair in dirstate ? [05:19] abentley, ping [05:20] lifeless, did packs land? [05:22] keir: its in final review at the moment [05:23] poolie is sheparding it through, I'm hacking on a native dirstate tweak for commit [05:23] nice [05:23] i want to write that faster index but i have been super busy :( [05:42] ok, my plan now is to make a patch to the pack code that makes it complain when copying a delta whose base is not copied [05:43] keir: no worries; at worst your work on taking my design goals and coming up with something concrete to meet them has been great. [05:43] keir: thats very nearly as valuable as code [05:44] poolie: FWIW, the smart server fetch does a similar sanity check. [05:52] spiv: why isn't the test for insert_data_stream doing that check a per-implementation test ? [05:53] spiv: or in other words, why are some implementations allowed to not check that ? [05:54] lifeless, is create_pack_from_packs active even when fetching from knits? [05:55] lifeless: hmm, good question. Probably an oversight :/ [05:56] poolie: no, but copying from knits copies all the data. [05:56] spiv: rule of thumb: all tests should be interface tests unless they cannot apply to the interface in general. [05:57] poolie: its pack to pack thats a problem [06:07] Hello all. [06:08] I would like to create a new branch (from an existing branch), but only of a subtree. Is this possible with BZR? What is the recommended procedure? [06:09] To be clear, I have a tree under source control: ~/a [06:09] And I'd like to create a branch from a subtree of it... bzr branch ~/a/path/to/subtree [06:09] Possible? [06:10] lifeless, are you sure? i think i'm seeing problems when branching from an existing knits repository into a new pack repository [06:10] i'll check [06:11] mrtuple, can you tell us more about what you want to do with the new branch after you've made it? [06:11] will it eventually merge back into the whole tree? [06:12] ooh. that would be cool... [06:12] poolie: yes; pulling from knits copies everything in the knit reachable by that knits index. Remember that in your source pack repo all the data was present. [06:14] Yes, i'd like to place the branch in a http:// space so that I can commit to it and a partner can branch from and merge from it. [06:14] i thought i had tested that... [06:14] ring me if you need a reminder; though I thought you were doing the review changes first ? [06:14] (And I would do the same with my partners branch -- I believe this workflow has a name in bzr docs, but I forget what it is). [06:15] Then, finally, I'd like to remerge with the original ~/a [06:15] (Once the project is complete). [06:15] New bug: #156091 in bzr "create_pack_from_packs should check that knit compression parents are present" [Undecided,New] https://launchpad.net/bugs/156091 [06:38] spivvo, how's it going? [06:39] mrtuple, there's some partial support for this at the moment, but for production use you're probably better off using the whole tree fro now [06:39] mrtuple, if you want to try it there is an experimental 'split' command [06:48] hi guys [06:49] hi [06:51] poolie: [06:51] All the changes in the delta should be changes synchronising the basis [06:51] tree with some or all of the working tree, with a change to a directory [06:51] requiring that its contents have been recursively included. That is, [06:51] this is not a general purpose tree modification routine, but a helper [06:51] for commit which is not required to handle situations that do not arise [06:51] outside of commit. [06:51] thats what I'm adding to the docstring, do you think it's clear enough? [06:51] i have the task of maintaining a patch and i need to forward port this to newer versions of the same code. my problem is that i want to continue developing the code on the old base, yet somehow update my forward ports when i do this. making any sense? [06:52] effbiae: just keep a branch for each one. Then you can merge from old to new whenever you want. [06:52] effbiae: if you have the patch in a branch [06:52] as AfC says :) [06:52] lifeless, that sounds clear [06:52] poolie: I've confirmed that reconcile isn't finding anything wrong with the join-branches.txt-... knit. I think I have a change that may fix it, I'm testing now. [06:53] is there any point keeping the more general version around, or yagni? [06:53] "not finding anything wrong" even though it should [06:53] AfC: so i won't have to go through resolving conflicts again? [06:54] poolie: right. [06:54] effbiae: in theory [06:55] effbiae: so long as you get the original state into Bazaar, then when you apply your patch on 'new' branch, it'll be a series of revisions that will diverge from the common base [06:55] poolie: if a file version is never used by any inventory, then clearly no other file version should be using it as a parent. But join-branches.txt-... has that problem. [06:55] poolie: yagni I think [06:55] effbiae: meanwhile, changes to 'old' will likewise be change to that common base. You _should_ be able to then just merge from 'old' to 'new' periodically [06:55] Hmm, while this runs I'm going to pop out for a quick lunch. [06:56] effbiae: it's not foolproof, but you'll find that Bazaar is incredibly robust in its merge performance. You should be alright. [06:57] AfC, thanks for all your help. i'll try that. [07:04] AfC, do i have to bind one branch to another? [07:04] Huh? No [07:04] poolie: (see what I mean about the bind command?) [07:04] effbiae: just have each of 'old' and 'new' be a full power branch in its own directory. [07:24] AfC: i tried that, but i continue to have to resolve conflicts each time a do a merge... [07:24] effbiae: if thats the case, are you changing the same region of code a lot ? It may be that basically your patch needs to be updated lots. [07:27] effbiae: as lifeless says :) [07:27] poolie: so here's a funny thing. [07:28] lifeless: How much faster than knits are packs? [07:28] poolie: the 'bad_revid' from your bug is one of unreferenced versions in that versioned file. [07:29] jelmer: depends on the use case. The most dramatic difference I'veheard of is 10 minutes or so down to 30 seconds for local operations [07:29] lifeless: And compared to rsync/ [07:29] poolie: so in some sense it shouldn't matter what the parent in the knit for it is, because it shouldn't be used. [07:29] jelmer: well, we already beat rsync, again depending on the scenario [07:30] lifeless: For initial push? [07:30] jelmer: in fact though, because you could teach rsync not to touch existing index and pack files, and only sync new ones and deletes, and pack-names, rsync should still be faster (if you don't want selected data copying) [07:30] jelmer: A month or so ago I benched it over my adsl to london as 80% of rsync speed [07:31] spiv: you sure? 20050919... ? Thats referenced [07:31] I thought. Dagnammit. [07:31] lifeless: hmm, reconcile thinks not anyway. [07:31] lifeless: (Pdb) pp revision_versions.get_text_version('join-branches.txt-20050309044946-f635037a889c0388', 'robertc@robertcollins.net-20050919060519-f582f62146b0b458') [07:32] 'mbp@sourcefrog.net-20050309045105-d02cd410a115da2c' [07:32] lifeless: and independently looking at the inventory agrees. [07:33] Well, if that file version is referenced, it's not referenced by the revision with the same name ;) [07:33] spiv: indeed, it is. [07:33] erm [07:33] I mean, indeed, that revision does not itself point at it. [07:34] but clearly something does or it wouldn't be getting copied [07:34] >>> i = r.get_inventory('robertc@robertcollins.net-20050919060519-f582f62146b0b458') [07:34] >>> i['join-branches.txt-20050309044946-f635037a889c0388'] [07:34] InventoryFile('join-branches.txt-20050309044946-f635037a889c0388', 'join-branches.txt', parent_id='doc-20050309044934-a811c79dd26eef58', sha1='b8148e34e1546e83acf1ed32f4ec4bb4cc3502ae', len=3260) [07:34] >>> i['join-branches.txt-20050309044946-f635037a889c0388'].revision [07:34] 'mbp@sourcefrog.net-20050309045105-d02cd410a115da2c' [07:35] file_ids_altered.... [07:35] is a good way to trap this [07:35] add a if fileid == thing and version == thing: pdb() [07:36] lifeless: is this all for a smart server using packs or just a dumb server? [07:36] dumb server [07:36] probably worse on the smart server today, at least until spiv gets push optimised too [07:37] because the file_stream method uses append() to write data incrementally [07:37] and that will bite. painfully. [07:37] down to 4 errors on the native update routine [07:40] lifeless, ah, ok - thanks [07:41] pull will be ok I think [07:41] just push will splatter chunky bits everywhere [07:47] lifeless: ok, I see, there are 1290 revisions in bzr.dev with inventories referencing that file version. [07:47] [earlier talking about merging with AfC] but if i do a merge, how can i continue developing my patch on an old branch and retain the resolution i had to provide for the new branch (i think i'm confused) [07:48] lifeless: and none referencing the "parent" that the knit claims it has. [07:48] spiv: but clearly, the inventory that *should* doesn't. Grah. [07:48] lifeless: right. [07:49] effbiae: perhaps we're confused. :( [07:49] lifeless: oh well, happily I think I can make a test case out of this. [07:49] spiv: so we need to rewrite that inventory too [07:50] spiv: or the inventories that point to it incorrectly. How can we tell which is which ? [07:50] lifeless: Will that break signed testaments? [07:50] spiv: I don't recall if they refer to content purely or last-changed. content only I thought [07:51] woot [07:52] all tests passing, but the code is incomplete, so clearly so are the tests. [07:53] however, for testing, I'm uncommenting poolies comment [07:53] and we'll see how long it takes on moz [07:54] lifeless: so, can we tell which inventories are wrong? [07:54] lifeless: hmm, in this case it's easy [07:54] fuck me, 4 seconds faster on initial commit [07:55] lifeless: oh, sorry, nm [07:55] 5 seconds faster on regular incremental commit [07:55] that's pretty nice [07:56] real 0m19.527s [07:56] user 0m17.473s [07:56] sys 0m1.388s [07:56] real 0m12.243s [07:56] user 0m10.905s [07:56] sys 0m0.568s [07:56] hmm thats hard to read [07:56] lifeless: neat [07:56] the first group of three is for 'bzr commit' with 5 new files [07:56] That's for a commit on Mozilla? [07:56] the second is 'bzr commit FILENAME' [07:56] with filename changed [07:56] Lo-lan-do: yes [07:56] Nice [07:56] lifeless: so, here's a fun fact [07:56] jelmer: no luck - "out of memory: killed process" [07:56] without this patch: [07:56] real 0m25.148s [07:56] user 0m22.729s [07:56] sys 0m1.368s [07:56] real 0m16.834s [07:57] user 0m15.537s [07:57] lifeless: all 12 file versions of that file have the same sha1 [07:57] sys 0m0.776s [07:57] spiv: ok [07:57] mdke: run it again, as-is [07:57] mdke: there is a memory leak :(, it will resume [07:58] poolie: I might finish this tomorrow, I need to write a new iterator for dirstate [07:59] to handle renames with children that are not altered [07:59] lifeless: I will, but it looks like it didn't get very far [07:59] mdke: well, start it, and what does the progress bar look like [08:00] lifeless: so presumably then the inventories that reference that version are mistaken, rather than the inventory in the revision corresponding to that version. [08:05] excuse me... [08:05] given this: [08:05] A---B---C topic [08:05] / [08:05] D---E---F---G master [08:05] and between E and F, files were moved around [08:05] i have to produce patches E->C, F->C, G->C [08:05] but i will be continuing development on branch 'topic' and have to continue prov [08:05] iding combinations of patches [08:05] lifeless, just one question if you're still here [08:06] when you've replied to a review, have you either done or responded to everything in it [08:06] poolie: rofl. [08:06] common sense says yes [08:06] I don't believe I have dropped items from the reviews silently. [08:07] if I have elided anything, I think it was either (a) in a review from someone else, or (b) actioned and clearly trivial. [08:08] sure [08:08] I'm still staggered by the performance difference [08:09] I expected 25% as an upper bound based on lsprof [08:09] to get 33% is very pleasing [08:09] That's great work [08:15] lifeless: looks like it has started again. Anyway, when it was killed from the scrollback it looks like it only got to about five "=" signs, still 0/9 on the first branch [08:16] mdke: what is the status message ? [08:16] lifeless: no "=" signs, 0/9 on the first branch [08:16] lifeless: i guess the best way forward is for me to ask the vcs-import guys in Launchpad to do an import for me [08:17] mdke: it should have english at the right hand side [08:17] mdke: I'd really like to know what words are there. [08:18] lemme see [08:18] "branches/dapper:3442 0/9" [08:19] that's all it has, aside from the progres bar [== ] [08:19] jelmer: ^ does that mean its finished the mapping ? [08:19] mdke: there is a big mapping it does right at the start, which I think is completed for you [08:20] lifeless: I think you are right, it has whizzed through "Finding branches" [08:20] and it has obviously downloaded quite a lot of material, the directory is 191MB already [08:21] mmm, a 64Gb flash chip [08:33] hi guys [08:34] What is the official delay between deprecation declaration and deletion from the code base ? [08:35] lifeless: you know, it says "branches/feisty" now, perhaps it is going a bit faster than I thought :) [08:37] spiv: the inventories [08:37] spiv: is the one 20050919 a merge/different exec bit/path/name/parent id ? [08:37] spiv: e.g. should it have recorded a new version in the per file graph ? [08:42] * spiv looks [08:43] * lifeless -> counterstrike source [08:44] if anyone needs my input tonight, ring my house [08:44] otherwise, chat tomorrow. [08:44] lifeless: thanks for your help. [08:49] lifeless: the answer to your question is "no", btw; there's no changes to the inventory entry for that fileid in that revision compared to the two parent revisions. [08:50] lifeless: so AFAICT it should not have recorded a new version in the per file graph. [09:00] right, thats teh calculation you need to perform to decide whether its good or not. [09:00] lifeless: I see. [09:00] lifeless: there's an alternative to rewriting inventories... [09:02] lifeless: I could (somewhat arbitrarily) make the parents in the versioned file be [version-referenced-by-corresponding-inventory]. It's not "correct", but I think it would solve poolie's problem. [09:03] lifeless: I only mention it because it might be more expedient to do that than fix it properly. I'll have a go at fixing it properly now though... [09:07] lifeless: I'm a little surprised that a change to the executable bit and nothing else apparently means there should be a new version in the knit? [09:07] lifeless: why shouldn't the inventory entry still point to the same old file version in that case? [09:10] lifeless: oh, it's because the per-file graph is used for merge calculations, and is punned with the knit index? [09:23] * igc food [10:13] hi all [10:13] i have downloaded loggerhead source for front end of bazaar [10:14] but there are no steps for installation or configurations in it [10:14] could some one please help me out in configuring the loggerhead for bazaar [11:20] spiv: the per file graph record all changes to that fileid, not just content changes. [11:21] spiv: content reconstruction is separated in pack repositories, in principle. [11:29] indraveni: hi, still looking for help with loggerhead? [11:29] mwhudson, hi yes === mrevell is now known as mrevell-hospital [11:34] mwhudson, i have installed bzr [11:34] and then downloaded loggerhead [11:34] but there are no instauctions of how to install or configure loggerhead [11:34] indraveni: there should be a loggerhead.conf.in file in the download [11:35] copy that to loggerhead.conf and edit it as appropriate [11:35] mwhudson, yes its tehre [11:35] then run ./start-loggerhead.py -f [11:35] where should i copy it to ? [11:35] loggerhead.conf in the same directory [11:36] i'm not sure what you mean by *installing* loggerhead [11:36] tbh there's no real point [11:36] i have saved the loggerhead source in my dekstop [11:37]