| igc | I saw that lifeless - thanks | 00:03 |
|---|---|---|
| igc | I'm good with your reply | 00:03 |
| lifeless | you've seen the new bundle ? | 00:03 |
| igc | it's come thru but I'm yet to look at it | 00:04 |
| igc | in email at the moment | 00:04 |
| ubotu | New bug: #156003 in bazaar ""Tree transform is malformed" error with "bzr import-dsc"" [Undecided,New] https://launchpad.net/bugs/156003 | 00:15 |
| === mwh_ is now known as mwh | ||
| === kiko is now known as kiko-zzz | ||
| ubotu | New bug: #156015 in bzr "Typo in doc/en/user-guide/conflicts.txt" [Undecided,New] https://launchpad.net/bugs/156015 | 00:51 |
| spiv | Turns out gutsy's kernel doesn't like my firewall box. | 01:26 |
| lifeless | ouch | 01:27 |
| lifeless | seen that reconcile isn't ? | 01:27 |
| lifeless | spiv: ^ | 01:27 |
| spiv | lifeless: no, I haven't. I assume there's mail about it? | 01:28 |
| lifeless | there's a bug | 01:28 |
| * lifeless -> chemist | 01:28 | |
| lifeless | ring my mobile if you want to chat | 01:28 |
| * spiv finds the bug | 01:29 | |
| spiv | poolie: ok, I understand the problem; the bug describes the situation pretty clearly. I'll add a test scenario for it. | 01:34 |
| poolie | spiv, ok | 01:35 |
| poolie | do you need to narrow it down | 01:35 |
| poolie | what i mean is, we want a narrower test than reconciling the whole branch | 01:35 |
| poolie | do you know what narrower test is likely to fail? | 01:35 |
| spiv | Well, I can write a narrower test than reconciling bzr.dev, I think. | 01:36 |
| spiv | it seems likely that creating a simple repository with about three revisions should be enough to reproduce it. | 01:37 |
| spiv | Is that what you meant? | 01:38 |
| poolie | it is | 01:41 |
| poolie | it's just that i would have thought that's what the existing tests do | 01:41 |
| poolie | in other words, do you know what's untested and causing this problem? | 01:42 |
| spiv | It appears the "file version X is actually removed from the repo (versions with X as a parent rewritten appropriately)" case is untested. | 01:42 |
| spiv | I'm re-reading the existing scenarios to double-check that. | 01:44 |
| poolie | but wasn't that the main point of the previous patch? | 01:45 |
| poolie | igc, ping? | 01:46 |
| igc | hi poolie | 01:46 |
| spiv | Hmm, FileParentsNotReferencedByAnyInventoryScenario would seem to cover this case. | 01:46 |
| * spiv digs further | 01:46 | |
| poolie | spiv, could it be to do with this being a no-op file merge (random guess) | 01:47 |
| poolie | igc, quick call? | 01:47 |
| igc | sure - I'll call now | 01:47 |
| poolie | j | 01:47 |
| kgoetz | ` 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:31 |
| kgoetz | am i doing something wrong? | 02:32 |
| poolie | kgoetz, are there in fact any changes in the working tree? | 02:32 |
| poolie | what does bzr status show? | 02:33 |
| kgoetz | bzr status returns nothing, and yes i can confirm theres been changes made. | 02:34 |
| poolie | what does bzr --version show? | 02:34 |
| kgoetz | Bazaar (bzr) 0.11.0 | 02:34 |
| poolie | and bzr diff FILE on one modified file? | 02:34 |
| kgoetz | returns nothing | 02:36 |
| poolie | ok, this is pretty strange | 02:36 |
| poolie | has this happened before? | 02:37 |
| poolie | 0.11 is pretty old, is upgrading an option at all? | 02:37 |
| kgoetz | no, but this is the first time i've tried using bzr diff | 02:37 |
| kgoetz | yes it is, if theres decent debs | 02:38 |
| poolie | would these work? http://backports.org/debian/pool/main/b/bzr/ | 02:39 |
| poolie | i don't recall any bug like this, but that release is over a year old... | 02:39 |
| kgoetz | i'll check those out. | 02:40 |
| kgoetz | 0.18 doesnt seem much newer then what i'm on though | 02:40 |
| lifeless | kgoetz: if status shows nothing | 02:44 |
| lifeless | kgoetz: are the changes actually in this tree, to files that have been added and are not ignored ? | 02:44 |
| kgoetz | lifeless: i dont understand the 2nd bit | 02:44 |
| lifeless | kgoetz: if you have ignored a file | 02:47 |
| lifeless | then it can change, and bzr diff will not show it | 02:47 |
| lifeless | whats the name of a file you have changed ? | 02:47 |
| kgoetz | lifeless: bzr info says i have 0 ignored | 02:48 |
| poolie | how many versioned files? | 02:51 |
| kgoetz | http://pastebin.ca/746222 heres some of the info fromb zr | 02:52 |
| kgoetz | 25+2 subdirs | 02:52 |
| poolie | what does bzr ls show? | 02:52 |
| poolie | did you just create this with bzr init. bzr add, or did you get the branch from somewhere else? | 02:53 |
| kgoetz | 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:54 |
| kgoetz | just instaleld the new bzr from backports | 02:55 |
| kgoetz | and because it asked, i upgraded the 'working tree format' | 02:56 |
| kgoetz | bzr info now has no info in it | 02:56 |
| kgoetz | just 'location' and 'related branches' | 02:57 |
| kgoetz | and 'bzr diff' and 'bzr diff file' still return nothing | 02:59 |
| kgoetz | bzr --version | 02:59 |
| kgoetz | Bazaar (bzr) 0.18.0 | 02:59 |
| lifeless | if bzr st shows nothing | 03:00 |
| lifeless | then I bet that your friend has not pushed their changes | 03:00 |
| lifeless | so the merge had nothing to merge | 03:00 |
| lifeless | if you try merge now it will probably say that, our feedback has improved since 0.11. | 03:00 |
| kgoetz | i can see a change i didnt make: | 03:01 |
| kgoetz | ### THIS IS BAD COUPLING - SHOULD BE RUN FROM builderrvcore (andrew) ### | 03:01 |
| lifeless | perhaps you committed the merge already? what does 'bzr log -r -1' show ? | 03:01 |
| kgoetz | what part of it? revo: 40; commiter: andrew | 03:02 |
| lifeless | I think perhaps you ran 'bzr pull' not 'bzr merge' | 03:02 |
| kgoetz | not sure. what would that mean? | 03:03 |
| lifeless | pull gives you a mirror of another branch | 03:03 |
| lifeless | it would mean you have what andrew has done in front of you | 03:03 |
| lifeless | assuming you are not andrew ;) | 03:03 |
| kgoetz | then why dont i see uncommited files in bzr status? | 03:04 |
| lifeless | because there are no changes | 03:04 |
| lifeless | you have a copy of andrew's branch, not your branch with his changes merged and pending review | 03:04 |
| * kgoetz is confused. perhaps looking at the documentation can be this arvos timespender | 03:05 | |
| poolie | a good way to check this would be | 03:05 |
| poolie | bzr missing ANDREWS_BRANCH_URL|less | 03:05 |
| kgoetz | says 'branches are up to date' | 03:08 |
| poolie | then it looks like you did pull from him rather than merge | 03:08 |
| poolie | in other words - he's already done the merge and there's nothing for you to do | 03:08 |
| poolie | so, be happy :) | 03:09 |
| kgoetz | so i have to bzr ci before i can see his stuff? | 03:09 |
| poolie | you can modify a file yourself to check that diff works | 03:09 |
| poolie | no | 03:09 |
| poolie | his stuff is in your tree now | 03:09 |
| poolie | lifeless, could it be that in 0.11 merge did --pull by default? | 03:09 |
| lifeless | 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 |
| lifeless | poolie: no | 03:09 |
| kgoetz | is there some way i can see what changes he made then? | 03:09 |
| lifeless | poolie: I'm pretty sure it never did that | 03:09 |
| poolie | i didn't think so | 03:09 |
| kgoetz | oh, with switches | 03:09 |
| lifeless | 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:10 |
| kgoetz | lifeless: ok, thanks. | 03:11 |
| kgoetz | 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:11 |
| poolie | yes, we removed some bits that were expensive to calculate | 03:12 |
| poolie | you can get them with info -v | 03:12 |
| kgoetz | ah sweet. not sure how committers is calculated, but i'm guessing by system name | 03:13 |
| poolie | yes, or you can set it with bzr whoami | 03:14 |
| kgoetz | thanks. | 03:14 |
| lifeless | I'm going to go for a walk; | 03:15 |
| poolie | good, enjoy | 03:16 |
| lifeless | I need to think through this apply delta logic | 03:16 |
| poolie | can call if you want | 03:16 |
| lifeless | thanks, but its not one of those problems, its one of these | 03:17 |
| spiv | I think I have a failing test for the reconcile bug. | 03:17 |
| lifeless | you/spiv can ring me if you want to talk about anything | 03:17 |
| poolie | yay | 03:17 |
| poolie | spiv, tell me more? | 03:17 |
| spiv | 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:19 |
| spiv | 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:20 |
| lifeless | so I got as far as a shave before I had my answer | 03:22 |
| lifeless | igc: so why do you object to bugfixed ? | 03:24 |
| igc | it's not a word :-) | 03:24 |
| lifeless | 85000 examples of it on google | 03:25 |
| igc | try answers.com | 03:25 |
| lifeless | what about answers.com ? | 03:26 |
| poolie | heh | 03:26 |
| poolie | spiv, may i call? | 03:26 |
| igc | it's neat - dictionary definitions, synonyms, etc. | 03:26 |
| spiv | poolie: sure | 03:27 |
| lifeless | still not getting the point :). | 03:27 |
| lifeless | bugfixed appears to be more than uncommon | 03:28 |
| igc | you asked why I objected - I told you | 03:28 |
| lifeless | if not actually common | 03:28 |
| igc | bugfixed doesn't add anything over just saying "fixed" but whatever :-) | 03:28 |
| igc | it's not important right now | 03:28 |
| lifeless | ok | 03:29 |
| igc | lifeless: commit tweaks is now approved as well. Just the spelling errors raised by Rob Weir. | 03:33 |
| lifeless | thanks | 03:35 |
| * igc food | 03:36 | |
| lifeless | jam-laptop: ping | 04:56 |
| jam-laptop | lifeless: hi, typing one handed, though | 04:56 |
| lifeless | TMI | 04:57 |
| kgoetz | lol | 04:57 |
| lifeless | so, in dirstates memory representation | 04:57 |
| lifeless | are fileids utf8 ? | 04:57 |
| jam-laptop | yes | 04:57 |
| lifeless | and have we made fileids utf8 outside that yet ? | 04:57 |
| jam-laptop | IIRC, in memory everything is | 04:57 |
| jam-laptop | file ids == utf8 in the core | 04:57 |
| lifeless | greate | 04:58 |
| jam-laptop | same with rev ids | 04:58 |
| jam-laptop | kgoetz: this is why http://john.arbash-meinel.com/images/baby_face_01_small.jpg | 04:59 |
| jam-laptop | lifeless: I'm probably heading off to bed | 05:00 |
| jam-laptop | anything else you need? | 05:00 |
| lifeless | sleep well | 05:01 |
| kgoetz | jam-laptop: later mate. vcute | 05:01 |
| lifeless | jam-laptop: actually there is something | 05:04 |
| lifeless | jam-laptop: do you recall a function to iterate the entries within a given path:fileid pair in dirstate ? | 05:04 |
| keir | abentley, ping | 05:19 |
| keir | lifeless, did packs land? | 05:20 |
| lifeless | keir: its in final review at the moment | 05:22 |
| lifeless | poolie is sheparding it through, I'm hacking on a native dirstate tweak for commit | 05:23 |
| keir | nice | 05:23 |
| keir | i want to write that faster index but i have been super busy :( | 05:23 |
| poolie | 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:42 |
| lifeless | 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 |
| lifeless | keir: thats very nearly as valuable as code | 05:43 |
| spiv | poolie: FWIW, the smart server fetch does a similar sanity check. | 05:44 |
| lifeless | spiv: why isn't the test for insert_data_stream doing that check a per-implementation test ? | 05:52 |
| lifeless | spiv: or in other words, why are some implementations allowed to not check that ? | 05:53 |
| poolie | lifeless, is create_pack_from_packs active even when fetching from knits? | 05:54 |
| spiv | lifeless: hmm, good question. Probably an oversight :/ | 05:55 |
| lifeless | poolie: no, but copying from knits copies all the data. | 05:56 |
| lifeless | spiv: rule of thumb: all tests should be interface tests unless they cannot apply to the interface in general. | 05:56 |
| lifeless | poolie: its pack to pack thats a problem | 05:57 |
| mrtuple | Hello all. | 06:07 |
| mrtuple | 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:08 |
| mrtuple | To be clear, I have a tree under source control: ~/a | 06:09 |
| mrtuple | And I'd like to create a branch from a subtree of it... bzr branch ~/a/path/to/subtree | 06:09 |
| mrtuple | Possible? | 06:09 |
| poolie | lifeless, are you sure? i think i'm seeing problems when branching from an existing knits repository into a new pack repository | 06:10 |
| poolie | i'll check | 06:10 |
| poolie | mrtuple, can you tell us more about what you want to do with the new branch after you've made it? | 06:11 |
| poolie | will it eventually merge back into the whole tree? | 06:11 |
| mrtuple | ooh. that would be cool... | 06:12 |
| lifeless | 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:12 |
| mrtuple | 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 |
| poolie | i thought i had tested that... | 06:14 |
| lifeless | ring me if you need a reminder; though I thought you were doing the review changes first ? | 06:14 |
| mrtuple | (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:14 |
| mrtuple | Then, finally, I'd like to remerge with the original ~/a | 06:15 |
| mrtuple | (Once the project is complete). | 06:15 |
| ubotu | 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:15 |
| poolie | spivvo, how's it going? | 06:38 |
| poolie | 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 |
| poolie | mrtuple, if you want to try it there is an experimental 'split' command | 06:39 |
| effbiae | hi guys | 06:48 |
| lifeless | hi | 06:49 |
| lifeless | poolie: | 06:51 |
| lifeless | All the changes in the delta should be changes synchronising the basis | 06:51 |
| lifeless | tree with some or all of the working tree, with a change to a directory | 06:51 |
| lifeless | requiring that its contents have been recursively included. That is, | 06:51 |
| lifeless | this is not a general purpose tree modification routine, but a helper | 06:51 |
| lifeless | for commit which is not required to handle situations that do not arise | 06:51 |
| lifeless | outside of commit. | 06:51 |
| lifeless | thats what I'm adding to the docstring, do you think it's clear enough? | 06:51 |
| effbiae | 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:51 |
| AfC | effbiae: just keep a branch for each one. Then you can merge from old to new whenever you want. | 06:52 |
| lifeless | effbiae: if you have the patch in a branch | 06:52 |
| lifeless | as AfC says :) | 06:52 |
| poolie | lifeless, that sounds clear | 06:52 |
| spiv | 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:52 |
| poolie | is there any point keeping the more general version around, or yagni? | 06:53 |
| poolie | "not finding anything wrong" even though it should | 06:53 |
| effbiae | AfC: so i won't have to go through resolving conflicts again? | 06:53 |
| spiv | poolie: right. | 06:54 |
| AfC | effbiae: in theory | 06:54 |
| AfC | 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 |
| spiv | 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 |
| lifeless | poolie: yagni I think | 06:55 |
| AfC | 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 |
| spiv | Hmm, while this runs I'm going to pop out for a quick lunch. | 06:55 |
| AfC | effbiae: it's not foolproof, but you'll find that Bazaar is incredibly robust in its merge performance. You should be alright. | 06:56 |
| effbiae | AfC, thanks for all your help. i'll try that. | 06:57 |
| effbiae | AfC, do i have to bind one branch to another? | 07:04 |
| AfC | Huh? No | 07:04 |
| AfC | poolie: (see what I mean about the bind command?) | 07:04 |
| AfC | effbiae: just have each of 'old' and 'new' be a full power branch in its own directory. | 07:04 |
| effbiae | AfC: i tried that, but i continue to have to resolve conflicts each time a do a merge... | 07:24 |
| lifeless | 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:24 |
| AfC | effbiae: as lifeless says :) | 07:27 |
| spiv | poolie: so here's a funny thing. | 07:27 |
| jelmer | lifeless: How much faster than knits are packs? | 07:28 |
| spiv | poolie: the 'bad_revid' from your bug is one of unreferenced versions in that versioned file. | 07:28 |
| lifeless | 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 |
| jelmer | lifeless: And compared to rsync/ | 07:29 |
| spiv | 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 |
| lifeless | jelmer: well, we already beat rsync, again depending on the scenario | 07:29 |
| jelmer | lifeless: For initial push? | 07:30 |
| lifeless | 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 |
| lifeless | jelmer: A month or so ago I benched it over my adsl to london as 80% of rsync speed | 07:30 |
| lifeless | spiv: you sure? 20050919... ? Thats referenced | 07:31 |
| lifeless | I thought. Dagnammit. | 07:31 |
| spiv | lifeless: hmm, reconcile thinks not anyway. | 07:31 |
| spiv | lifeless: (Pdb) pp revision_versions.get_text_version('join-branches.txt-20050309044946-f635037a889c0388', 'robertc@robertcollins.net-20050919060519-f582f62146b0b458') | 07:31 |
| spiv | 'mbp@sourcefrog.net-20050309045105-d02cd410a115da2c' | 07:32 |
| spiv | lifeless: and independently looking at the inventory agrees. | 07:32 |
| spiv | Well, if that file version is referenced, it's not referenced by the revision with the same name ;) | 07:33 |
| lifeless | spiv: indeed, it is. | 07:33 |
| lifeless | erm | 07:33 |
| lifeless | I mean, indeed, that revision does not itself point at it. | 07:33 |
| lifeless | but clearly something does or it wouldn't be getting copied | 07:34 |
| lifeless | >>> i = r.get_inventory('robertc@robertcollins.net-20050919060519-f582f62146b0b458') | 07:34 |
| lifeless | >>> i['join-branches.txt-20050309044946-f635037a889c0388'] | 07:34 |
| lifeless | InventoryFile('join-branches.txt-20050309044946-f635037a889c0388', 'join-branches.txt', parent_id='doc-20050309044934-a811c79dd26eef58', sha1='b8148e34e1546e83acf1ed32f4ec4bb4cc3502ae', len=3260) | 07:34 |
| lifeless | >>> i['join-branches.txt-20050309044946-f635037a889c0388'].revision | 07:34 |
| lifeless | 'mbp@sourcefrog.net-20050309045105-d02cd410a115da2c' | 07:34 |
| lifeless | file_ids_altered.... | 07:35 |
| lifeless | is a good way to trap this | 07:35 |
| lifeless | add a if fileid == thing and version == thing: pdb() | 07:35 |
| jelmer | lifeless: is this all for a smart server using packs or just a dumb server? | 07:36 |
| lifeless | dumb server | 07:36 |
| lifeless | probably worse on the smart server today, at least until spiv gets push optimised too | 07:36 |
| lifeless | because the file_stream method uses append() to write data incrementally | 07:37 |
| lifeless | and that will bite. painfully. | 07:37 |
| lifeless | down to 4 errors on the native update routine | 07:37 |
| jelmer | lifeless, ah, ok - thanks | 07:40 |
| lifeless | pull will be ok I think | 07:41 |
| lifeless | just push will splatter chunky bits everywhere | 07:41 |
| spiv | lifeless: ok, I see, there are 1290 revisions in bzr.dev with inventories referencing that file version. | 07:47 |
| effbiae | [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:47 |
| spiv | lifeless: and none referencing the "parent" that the knit claims it has. | 07:48 |
| lifeless | spiv: but clearly, the inventory that *should* doesn't. Grah. | 07:48 |
| spiv | lifeless: right. | 07:48 |
| lifeless | effbiae: perhaps we're confused. :( | 07:49 |
| spiv | lifeless: oh well, happily I think I can make a test case out of this. | 07:49 |
| lifeless | spiv: so we need to rewrite that inventory too | 07:49 |
| lifeless | spiv: or the inventories that point to it incorrectly. How can we tell which is which ? | 07:50 |
| spiv | lifeless: Will that break signed testaments? | 07:50 |
| lifeless | spiv: I don't recall if they refer to content purely or last-changed. content only I thought | 07:50 |
| lifeless | woot | 07:51 |
| lifeless | all tests passing, but the code is incomplete, so clearly so are the tests. | 07:52 |
| lifeless | however, for testing, I'm uncommenting poolies comment | 07:53 |
| lifeless | and we'll see how long it takes on moz | 07:53 |
| spiv | lifeless: so, can we tell which inventories are wrong? | 07:54 |
| spiv | lifeless: hmm, in this case it's easy | 07:54 |
| lifeless | fuck me, 4 seconds faster on initial commit | 07:54 |
| spiv | lifeless: oh, sorry, nm | 07:55 |
| lifeless | 5 seconds faster on regular incremental commit | 07:55 |
| poolie | that's pretty nice | 07:55 |
| lifeless | real 0m19.527s | 07:56 |
| lifeless | user 0m17.473s | 07:56 |
| lifeless | sys 0m1.388s | 07:56 |
| lifeless | real 0m12.243s | 07:56 |
| lifeless | user 0m10.905s | 07:56 |
| lifeless | sys 0m0.568s | 07:56 |
| lifeless | hmm thats hard to read | 07:56 |
| spiv | lifeless: neat | 07:56 |
| lifeless | the first group of three is for 'bzr commit' with 5 new files | 07:56 |
| Lo-lan-do | That's for a commit on Mozilla? | 07:56 |
| lifeless | the second is 'bzr commit FILENAME' | 07:56 |
| lifeless | with filename changed | 07:56 |
| lifeless | Lo-lan-do: yes | 07:56 |
| Lo-lan-do | Nice | 07:56 |
| spiv | lifeless: so, here's a fun fact | 07:56 |
| mdke | jelmer: no luck - "out of memory: killed process" | 07:56 |
| lifeless | without this patch: | 07:56 |
| lifeless | real 0m25.148s | 07:56 |
| lifeless | user 0m22.729s | 07:56 |
| lifeless | sys 0m1.368s | 07:56 |
| lifeless | real 0m16.834s | 07:56 |
| lifeless | user 0m15.537s | 07:57 |
| spiv | lifeless: all 12 file versions of that file have the same sha1 | 07:57 |
| lifeless | sys 0m0.776s | 07:57 |
| lifeless | spiv: ok | 07:57 |
| lifeless | mdke: run it again, as-is | 07:57 |
| lifeless | mdke: there is a memory leak :(, it will resume | 07:57 |
| lifeless | poolie: I might finish this tomorrow, I need to write a new iterator for dirstate | 07:58 |
| lifeless | to handle renames with children that are not altered | 07:59 |
| mdke | lifeless: I will, but it looks like it didn't get very far | 07:59 |
| lifeless | mdke: well, start it, and what does the progress bar look like | 07:59 |
| spiv | lifeless: so presumably then the inventories that reference that version are mistaken, rather than the inventory in the revision corresponding to that version. | 08:00 |
| effbiae | excuse me... | 08:05 |
| effbiae | given this: | 08:05 |
| effbiae | A---B---C topic | 08:05 |
| effbiae | / | 08:05 |
| effbiae | D---E---F---G master | 08:05 |
| effbiae | and between E and F, files were moved around | 08:05 |
| effbiae | i have to produce patches E->C, F->C, G->C | 08:05 |
| effbiae | but i will be continuing development on branch 'topic' and have to continue prov | 08:05 |
| effbiae | iding combinations of patches | 08:05 |
| poolie | lifeless, just one question if you're still here | 08:05 |
| poolie | when you've replied to a review, have you either done or responded to everything in it | 08:06 |
| lifeless | poolie: rofl. | 08:06 |
| poolie | common sense says yes | 08:06 |
| lifeless | I don't believe I have dropped items from the reviews silently. | 08:06 |
| lifeless | if I have elided anything, I think it was either (a) in a review from someone else, or (b) actioned and clearly trivial. | 08:07 |
| poolie | sure | 08:08 |
| lifeless | I'm still staggered by the performance difference | 08:08 |
| lifeless | I expected 25% as an upper bound based on lsprof | 08:09 |
| lifeless | to get 33% is very pleasing | 08:09 |
| AfC | That's great work | 08:09 |
| mdke | 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:15 |
| lifeless | mdke: what is the status message ? | 08:16 |
| mdke | lifeless: no "=" signs, 0/9 on the first branch | 08:16 |
| mdke | 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:16 |
| lifeless | mdke: it should have english at the right hand side | 08:17 |
| lifeless | mdke: I'd really like to know what words are there. | 08:17 |
| mdke | lemme see | 08:18 |
| mdke | "branches/dapper:3442 0/9" | 08:18 |
| mdke | that's all it has, aside from the progres bar [== ] | 08:19 |
| lifeless | jelmer: ^ does that mean its finished the mapping ? | 08:19 |
| lifeless | mdke: there is a big mapping it does right at the start, which I think is completed for you | 08:19 |
| mdke | lifeless: I think you are right, it has whizzed through "Finding branches" | 08:20 |
| mdke | and it has obviously downloaded quite a lot of material, the directory is 191MB already | 08:20 |
| lifeless | mmm, a 64Gb flash chip | 08:21 |
| vila | hi guys | 08:33 |
| vila | What is the official delay between deprecation declaration and deletion from the code base ? | 08:34 |
| mdke | lifeless: you know, it says "branches/feisty" now, perhaps it is going a bit faster than I thought :) | 08:35 |
| lifeless | spiv: the inventories | 08:37 |
| lifeless | spiv: is the one 20050919 a merge/different exec bit/path/name/parent id ? | 08:37 |
| lifeless | spiv: e.g. should it have recorded a new version in the per file graph ? | 08:37 |
| * spiv looks | 08:42 | |
| * lifeless -> counterstrike source | 08:43 | |
| lifeless | if anyone needs my input tonight, ring my house | 08:44 |
| lifeless | otherwise, chat tomorrow. | 08:44 |
| spiv | lifeless: thanks for your help. | 08:44 |
| spiv | 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:49 |
| spiv | lifeless: so AFAICT it should not have recorded a new version in the per file graph. | 08:50 |
| lifeless | right, thats teh calculation you need to perform to decide whether its good or not. | 09:00 |
| spiv | lifeless: I see. | 09:00 |
| spiv | lifeless: there's an alternative to rewriting inventories... | 09:00 |
| spiv | 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:02 |
| spiv | 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:03 |
| spiv | 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 |
| spiv | lifeless: why shouldn't the inventory entry still point to the same old file version in that case? | 09:07 |
| spiv | lifeless: oh, it's because the per-file graph is used for merge calculations, and is punned with the knit index? | 09:10 |
| * igc food | 09:23 | |
| indraveni | hi all | 10:13 |
| indraveni | i have downloaded loggerhead source for front end of bazaar | 10:13 |
| indraveni | but there are no steps for installation or configurations in it | 10:14 |
| indraveni | could some one please help me out in configuring the loggerhead for bazaar | 10:14 |
| lifeless | spiv: the per file graph record all changes to that fileid, not just content changes. | 11:20 |
| lifeless | spiv: content reconstruction is separated in pack repositories, in principle. | 11:21 |
| mwhudson | indraveni: hi, still looking for help with loggerhead? | 11:29 |
| indraveni | mwhudson, hi yes | 11:29 |
| === mrevell is now known as mrevell-hospital | ||
| indraveni | mwhudson, i have installed bzr | 11:34 |
| indraveni | and then downloaded loggerhead | 11:34 |
| indraveni | but there are no instauctions of how to install or configure loggerhead | 11:34 |
| mwhudson | indraveni: there should be a loggerhead.conf.in file in the download | 11:34 |
| mwhudson | copy that to loggerhead.conf and edit it as appropriate | 11:35 |
| indraveni | mwhudson, yes its tehre | 11:35 |
| mwhudson | then run ./start-loggerhead.py -f | 11:35 |
| indraveni | where should i copy it to ? | 11:35 |
| mwhudson | loggerhead.conf in the same directory | 11:35 |
| mwhudson | i'm not sure what you mean by *installing* loggerhead | 11:36 |
| mwhudson | tbh there's no real point | 11:36 |
| indraveni | i have saved the loggerhead source in my dekstop | 11:36 |
| indraveni | and there is a loggerhead.conf under the Desktop/loggerhead/loggerhead.conf | 11:37 |
| indraveni | i should copy and paste this where? | 11:37 |
| mwhudson | oh, if it's called loggerhead.conf already | 11:37 |
| mwhudson | then just edit it in place | 11:37 |
| mwhudson | it has lots of comments in | 11:37 |
| indraveni | mwhudson, what should i edit in this line | 11:39 |
| indraveni | folder='/Users/robey/code/loggerhead' | 11:39 |
| mwhudson | have you read the comment in the line above this line? | 11:40 |
| indraveni | mwhudson, there is no comment above this line | 11:40 |
| mwhudson | you want to put in the file path of the directory that contains the branch you want to browse | 11:40 |
| mwhudson | hm | 11:40 |
| indraveni | mwhudson, only a line like | 11:40 |
| indraveni | [[loggerhead]] | 11:40 |
| mwhudson | indraveni: where did you get the loggerhead source from? | 11:40 |
| indraveni | from http://www.lag.net/loggerhead/ | 11:41 |
| mwhudson | ah | 11:41 |
| mwhudson | https://code.edge.launchpad.net/~mwhudson/loggerhead/production <- this version of the code is better | 11:41 |
| indraveni | ok | 11:44 |
| indraveni | mwhudson, i downloaded, but it placesd all the source in a folder named production | 11:50 |
| indraveni | can i change the folder name? | 11:51 |
| mwhudson | yes | 11:51 |
| indraveni | mwhudson, what should i spcify for cachepath | 11:54 |
| indraveni | ? | 11:54 |
| mwhudson | indraveni: for now i would just comment it out | 11:55 |
| mwhudson | indraveni: how big are the branches that you want to browse (in terms of number of revisions, number of files)? | 11:55 |
| indraveni | it may reach atleast for 10 revisions for each branch | 11:56 |
| mwhudson | i'm not sure i understand | 11:57 |
| mwhudson | 10 revisions is a tiny number | 11:57 |
| indraveni | mwhudson, the project is in starting stage | 11:57 |
| mwhudson | ok | 11:57 |
| mwhudson | so don't worry about caching for now | 11:57 |
| mwhudson | it's only needed for pretty huge projects these days (10000+ revisions or 5000+ files) | 11:58 |
| indraveni | mwhudson, but if needed, how do i need to do ? | 11:58 |
| mwhudson | indraveni: you would put a path to some directory there | 11:58 |
| indraveni | mwhudson, ok, what does it do then ? | 11:59 |
| mwhudson | indraveni: it caches some information about the branch | 11:59 |
| indraveni | mwhudson, ok | 11:59 |
| mwhudson | most importantly the list of files changed between revisions | 11:59 |
| indraveni | mwhudson, next, the url value, is this needed now ? | 11:59 |
| mwhudson | (which is expensive to compute in bazaar today, at least for large branches) | 11:59 |
| indraveni | url = 'http://bazaar-ng.org/bzr/bzr.dev' | 12:00 |
| mwhudson | indraveni: the file you're reading now looks like this http://codebrowse.launchpad.net/~mwhudson/loggerhead/production/annotate/pqm%40pqm.ubuntu.com-20070910193149-jrabz72cwth1abup?file_id=loggerhead.conf-20061215091925-m5t3bxgioe500tx9-1 ? | 12:00 |
| indraveni | mwhudson, exacly | 12:01 |
| indraveni | mwhudson, exactly | 12:01 |
| mwhudson | indraveni: then it has comments in | 12:01 |
| mwhudson | indraveni: i suggest you read them | 12:01 |
| jelmer | lifeless, still awake? | 12:16 |
| lifeless | passing by from time to time | 12:19 |
| lifeless | whats up? | 12:19 |
| lifeless | jelmer: ^ | 12:19 |
| jelmer | lifeless: what's the timeframe on packs landing? | 12:20 |
| lifeless | jelmer: couple of days | 12:20 |
| lifeless | mwhudson: btw, the list copy reduction optimisation I landed for Peng, will help inventory extraction | 12:20 |
| mwhudson | lifeless: for packs or generically? | 12:21 |
| mwhudson | lifeless: cool, though | 12:21 |
| lifeless | mwhudson: but only when the two inventories are asked for separately; so doing the further optimisation I put in as FUTURE there would help a lot | 12:21 |
| jelmer | The discussion about VCS for Samba has come up again (git's UI is confusing people) and I'd like to show some impressive graphs (-: | 12:21 |
| lifeless | generically. | 12:21 |
| mwhudson | lifeless: will still help the revision view, i expect | 12:21 |
| lifeless | jelmer: did you see my commit speed stuff? 10 seconds for a specific file commit in a mozilla tree in my current uncommitted code | 12:21 |
| === kiko-zzz is now known as kiko | ||
| mwhudson | the changelog view gets a bunch of inventories all at once with getRevisionTrees, iirc | 12:22 |
| lifeless | mwhudson: that will not benefit as yet then | 12:22 |
| mwhudson | well, repository.revision_trees rather | 12:22 |
| mwhudson | lifeless: okidoke | 12:22 |
| jelmer | lifeless: no, I haven't | 12:23 |
| lifeless | mwhudson: turns out applying 3 list copies to thousands of items long lists is expensive. | 12:23 |
| lifeless | when you do that hundreds of times | 12:23 |
| lifeless | 16:56 < lifeless> real 0m25.148s | 12:23 |
| lifeless | 16:56 < lifeless> user 0m22.729s | 12:23 |
| lifeless | 16:56 < lifeless> sys 0m1.368s | 12:23 |
| lifeless | 16:56 < lifeless> real 0m16.834s | 12:23 |
| lifeless | 16:56 < lifeless> user 0m15.537s | 12:23 |
| lifeless | 16:56 < lifeless> sys 0m0.776s | 12:23 |
| lifeless | thats packs in my branch today | 12:23 |
| mwhudson | lifeless: who would have thought it | 12:23 |
| lifeless | first is commit of 5 new files | 12:24 |
| lifeless | second is commit of one changed file when we provide the file name | 12:24 |
| lifeless | 16:55 < lifeless> real 0m19.527s | 12:24 |
| lifeless | 16:55 < lifeless> user 0m17.473s | 12:24 |
| lifeless | 16:55 < lifeless> sys 0m1.388s | 12:24 |
| lifeless | 16:55 < lifeless> real 0m12.243s | 12:24 |
| lifeless | 16:55 < lifeless> user 0m10.905s | 12:24 |
| lifeless | 16:55 < lifeless> sys 0m0.568s | 12:24 |
| mwhudson | lifeless: in the firefox tree? | 12:24 |
| lifeless | thats with a patch that is not quite complete to update the dirstate from the delta that commit calculates | 12:24 |
| lifeless | for the same twocases | 12:24 |
| lifeless | you can see it saves 5 seconds consistently | 12:25 |
| lifeless | mwhudson: moz tree, yes. | 12:25 |
| lifeless | 55K files. | 12:25 |
| lifeless | well, 55K paths | 12:25 |
| mwhudson | lifeless: cool | 12:26 |
| jelmer | lifeless: Should the weave_store for packs still work as it used to earlier or should I use some other interface to add revisions to it? | 12:26 |
| lifeless | jelmer: as long as you take out a write group, it will still work, its just slower than the commit builder interface | 12:27 |
| mwhudson | lifeless: well, it's still a bit slow really, but at least it's competitive with the competition :-) | 12:27 |
| lifeless | mwhudson: pffft | 12:27 |
| mwhudson | probably the right answer is not to have branches with 55k paths in | 12:27 |
| lifeless | mwhudson: my laptop has slow disk, and its cryted | 12:27 |
| lifeless | mwhudson: *crypted* | 12:27 |
| mwhudson | lifeless: i know, i'm not being very realistic | 12:28 |
| mwhudson | lifeless: it's a bit like "how do escape from this pit full of lions" -- the preferred solution involving not getting thrown into the pit full of lions in the first place | 12:30 |
| lifeless | mwhudson: well. I think we can get down to 4-5 seconds for sure. | 12:31 |
| lifeless | going lower will require...some more time | 12:32 |
| lifeless | on thing I'm starting to seriously consider is a serialised euler tour variant for the revision graph | 12:32 |
| lifeless | stored persistently and synthesised together on access | 12:33 |
| lifeless | but I need a really clear head | 12:33 |
| lifeless | and about three industrial whiteboards | 12:33 |
| mwhudson | i guess there are probably higher priorities | 12:34 |
| mwhudson | lifeless: is tree building any faster with packs? | 12:35 |
| lifeless | its different | 12:35 |
| lifeless | ;) | 12:35 |
| lifeless | its not optimised yet | 12:35 |
| lifeless | so over sftp it will be worse | 12:36 |
| lifeless | but on local disk it appears a little worse, but branch is overall faster, so -for now- shrug. | 12:36 |
| mwhudson | it's pretty slow with launchpad currently | 12:36 |
| lifeless | well 5000 files | 12:38 |
| lifeless | convert a branch to packs. | 12:39 |
| lifeless | then you can see | 12:39 |
| mwhudson | hm, maybe it's not as bad as i thought | 12:40 |
| mwhudson | 20s the second time | 12:40 |
| lifeless | thats knit disk latency | 12:41 |
| lifeless | echo 1 to /proc/vm/drop_caches | 12:41 |
| lifeless | or whatever it is | 12:41 |
| lifeless | then it will be slow again. | 12:41 |
| lifeless | $ cat ~/bin/drop-caches | 12:42 |
| lifeless | #!/bin/sh | 12:42 |
| lifeless | # get written data to disk (not that its guaranteed) | 12:42 |
| lifeless | sync | 12:42 |
| lifeless | # (drop the unmodified pages) | 12:42 |
| lifeless | echo 1 | sudo tee /proc/sys/vm/drop_caches | 12:42 |
| lifeless | --- | 12:42 |
| mwhudson | right | 12:44 |
| lifeless | packs suffer from that less | 12:44 |
| mwhudson | cool | 12:44 |
| === Mez|Away is now known as Mez | ||
| === Mez is now known as Mez|Away | ||
| === Mez|Away is now known as Mez | ||
| jelmer | lifeless: is it correct that packs appear to be using a significant amount of memory less than knits? | 13:07 |
| lifeless | likely | 13:07 |
| lifeless | but much of the tweaks should apply to knits too | 13:08 |
| lifeless | so if you are comparing between different versions of bzr as well as disk formats, your measurements will be suspect | 13:08 |
| lifeless | there are really three interesting data points | 13:09 |
| lifeless | knits in last release your team tested | 13:09 |
| lifeless | knits in the packs branch | 13:09 |
| lifeless | packs in the packs branch | 13:09 |
| jelmer | ok, I'll keep that in mind | 13:10 |
| lifeless | (if you want before and after graphs I mean) | 13:11 |
| jelmer | I may actually do some unscientific benchmarking later, comparing to git and mercurial | 13:12 |
| jelmer | so far, it does at least feel as fast as things like mercurial or git | 13:13 |
| Lo-lan-do | If it turns out to be so, I guess a benchmark made on the kernel tree would be an interesting thing to brag about :-) | 13:14 |
| Lo-lan-do | By the way: is 0.92 right around the corner, or should I try and install it from bzr? | 13:20 |
| jelmer | Lo-lan-do: for packs? You'll need bzr.dev + the packs patch posted to the list or roberts packs branch | 13:23 |
| Lo-lan-do | Not for packs, but I'd like to check a recent bzr-svn | 13:24 |
| jelmer | I'm not sure what the plans for 0.92 are | 13:25 |
| indraveni | mwhudson, hi again | 13:40 |
| indraveni | mwhudson, i have configured all accordingly | 13:41 |
| indraveni | mwhudson, now i ran the command ./start-loggerhead.py -f | 13:41 |
| indraveni | mwhudson, but the output is as follows, | 13:41 |
| indraveni | http://pastebin.ca/746697 | 13:42 |
| indraveni | mwhudson, its saying distribution not found | 13:46 |
| indraveni | mwhudson, there? | 13:46 |
| indraveni | any one there who can solve my error in loggerhead | 13:55 |
| hmeland | indraveni: I've never tried loggerhead, but have you got TurboGears installed? | 13:59 |
| Lo-lan-do | jelmer: I see you haven't closed #145148... is it just because the fix hasn't been released, or is the bug still present in current code? | 14:01 |
| jelmer | Lo-lan-do: it's not fixed for certain corner cases yet | 14:02 |
| Lo-lan-do | Ah, but it might be fixed in my case? | 14:03 |
| Lo-lan-do | I'm trying to decide whether I want to install a recent bzr and bzr-svn, based on whether it'll unblock the changes I need to push to the Gforge SVN | 14:04 |
| jelmer | Lo-lan-do: yes, that should work now | 14:07 |
| jelmer | Lo-lan-do: there may be some issues replaying still, but recommitting your patches should fix that | 14:08 |
| Lo-lan-do | That's great :-) | 14:08 |
| Lo-lan-do | Aehm, so how exactly do I recommit my patches? Should I clean the SVN cache and the properties? | 14:16 |
| Lo-lan-do | (I get the same old error message when I just do ~/bzr.dev/bzr push) | 14:16 |
| jelmer | Lo-lan-do: create a separate copy of the svn branch using bzr-svn (in a different repository, or a standalone branch) | 14:18 |
| jelmer | and then manually apply + commit your changes from the original branch | 14:19 |
| jelmer | merging them from the original branch may also work, but I'm not sure | 14:20 |
| * Lo-lan-do tries that | 14:21 | |
| Lo-lan-do | Merging would be best, since I have derived branches too. | 14:22 |
| Lo-lan-do | Urgh, segfault | 14:27 |
| Lo-lan-do | During the "get" | 14:27 |
| Lo-lan-do | ~/bzr.dev/bzr get svn+https://svn.gforge.org/svn/gforge/trunk gforge-trunk-new | 14:28 |
| Lo-lan-do | / [ ] copying revision 1/4883Erreur de segmentation | 14:28 |
| * Lo-lan-do cries | 14:28 | |
| jelmer | :-/ | 14:29 |
| jelmer | what versions of bzr/bzr-svn? | 14:29 |
| jelmer | the bzr.dev and 0.4 branches? | 14:30 |
| Lo-lan-do | Up-to-date from bzr.dev andbzr-svn | 14:30 |
| Lo-lan-do | Right | 14:30 |
| jelmer | does "bzr selftest svn" pass or does that segfault too? | 14:30 |
| Lo-lan-do | I'll check | 14:31 |
| * jelmer meanwhile also tries to clone gforge trunk | 14:31 | |
| Lo-lan-do | Erm, re-trying a get seems to progress this time. | 14:31 |
| Lo-lan-do | It's copying revisions (40/4883 so far) | 14:32 |
| Lo-lan-do | And the selftests seem to work, too. Currently at 46/691 | 14:32 |
| Lo-lan-do | I'll let both run for a while, as I need to go out for a few minutes. | 14:33 |
| jelmer | k | 14:45 |
| Lo-lan-do | [691/691 in 989s, 3 known failures, 9 skipped] bzrlib.plugins.svn.tests.test_blackbox.TestBranch.test_log_empty | 14:52 |
| lifeless | sleep well all | 14:53 |
| Rotund | Can I get a little help on how to use bzr to run a webpage? | 14:54 |
| Lo-lan-do | The same as other SCM tools? | 14:56 |
| Rotund | So I did a checkout, but the site needs to basically do a bzr update | 14:58 |
| Rotund | but I don't have shell access on it. what do I do? | 14:58 |
| Rotund | do I do a push? | 14:59 |
| mwhudson | Rotund: what access do you have? | 15:00 |
| Rotund | sftp | 15:00 |
| Rotund | no ssh though | 15:01 |
| mwhudson | rsync, perhaps? | 15:01 |
| mwhudson | push over sftp doesn't update the working tree | 15:01 |
| Rotund | crap | 15:01 |
| Rotund | what DOES update the working tree? | 15:03 |
| Lo-lan-do | update, pull | 15:03 |
| mwhudson | running 'bzr up' on the server :/ | 15:03 |
| Rotund | is there a secure rsync? | 15:04 |
| mwhudson | i think you can rsync over sftp | 15:05 |
| mwhudson | never tried it myself, mind | 15:05 |
| LeoNerd | or ssh | 15:05 |
| LeoNerd | RSYNC_RSH=ssh rsync ... | 15:05 |
| Rotund | okay, well I don't have a shell | 15:05 |
| Rotund | crap. this stinks | 15:05 |
| Rotund | may need to write an extension | 15:07 |
| === cprov is now known as cprov-lunch | ||
| === mrevell-hospital is now known as mrevell | ||
| jam-laptop | effbiae: I think I saw that your questions got a little lost. If you are still around, I can try to help. | 15:51 |
| jam-laptop | effbiae: A pretty darn good discussion of it is here: http://www.venge.net/mtn-wiki/DaggyFixes | 16:24 |
| === cprov-lunch is now known as cprov | ||
| jelmer | Lo-lan-do, any luck? | 17:08 |
| Lo-lan-do | The bzr get hasn't completed yet. | 17:08 |
| Lo-lan-do | It grabs about one revision every 2s, and there are ~4900 revs to grab. | 17:09 |
| jelmer | ouch | 17:09 |
| jelmer | sorry you have to go through this :-/ | 17:10 |
| Lo-lan-do | Yeah. 800 revs to go... | 17:10 |
| Lo-lan-do | I'll definitely save a local copy of the branch before attempting to merge and push :-) | 17:10 |
| jelmer | (-: | 17:14 |
| Lo-lan-do | (700 left) | 17:14 |
| Lo-lan-do | I'll play a game or two while waiting | 17:15 |
| Lo-lan-do | jelmer: Trying to push the first revision now (which I merged from my old branch) | 18:13 |
| Lo-lan-do | It seems to take quite some time, and strace tells me bzr is opening and closing lots of sockets to the SVN server. | 18:13 |
| Lo-lan-do | Well, just the one, but it opens and closes it quite a lot. | 18:14 |
| jelmer | has it committed anything yet? | 18:14 |
| Lo-lan-do | Not as far as I can tell. | 18:14 |
| jelmer | (in SVN) | 18:14 |
| Lo-lan-do | Nope. svn update in a checkout brings no new revision. | 18:15 |
| Lo-lan-do | Other strange thing: my bzr branch is now 225 MB large, while the previous one was only 55 MB, is that known? | 18:16 |
| Lo-lan-do | Even the SVN checkout is "only" 139 MB | 18:17 |
| Lo-lan-do | Oh, I know. My fault actually. | 18:18 |
| Lo-lan-do | The previous branch was actually a lightweight checkout. | 18:18 |
| Lo-lan-do | Still running. I'll go for dinner, and leave bzr running for now. | 18:21 |
| Lo-lan-do | Pushed up to revision 4884. | 18:51 |
| Lo-lan-do | real 16m18.448s | 18:51 |
| Lo-lan-do | Yay! | 18:51 |
| Lo-lan-do | Although, 16 minutes to commit three properties... | 18:52 |
| * Lo-lan-do tries to push another merged change | 18:53 | |
| Lo-lan-do | Looks like it's going to take another quarter of an hour | 18:56 |
| Lo-lan-do | Ah, no, 8 minutes this time. | 19:05 |
| Lo-lan-do | Less than 2 minutes for the third change | 19:12 |
| Lo-lan-do | jelmer: It looks like I'll stop bothering you for a while :-) | 19:12 |
| jelmer | Lo-lan-do: It worked!? Nice :-) | 19:13 |
| Lo-lan-do | It's not over, note, and I'll need your help to sync the new branch into the old one (so I can continue using the old one, whose URL has been made public) | 19:13 |
| Lo-lan-do | But it seems to work, step by step. | 19:14 |
| Lo-lan-do | l=$(bzr missing --line ../gforge-trunk+bzr | tail -1) ; r=$(echo $l | cut -d: -f1) ; m=$(echo $l | cut -c29-) ; echo $r -- $m ; bzr merge -r$r ../gforge-trunk+bzr ; bzr commit -m"$m" ; time bzr push | 19:14 |
| Lo-lan-do | One commit at a time :-) | 19:14 |
| gdoubleu | is there a way to temporarily disable a plugin temporarily without having to remove the package from /bzrlib/plugins/ ? | 19:17 |
| james_w | gdoubleu: bzr --no-plugins might be too much for you. | 19:19 |
| james_w | gdoubleu: otherwise no, you have to move the directory. | 19:20 |
| jam-laptop | gdoubleu: you can put it in a subdirectory | 19:20 |
| jam-laptop | I use ~/.bazaar/plugins/DEACTIVATED myself | 19:20 |
| gdoubleu | ah, --no-plugins will work for me as I don't need any other plugins at the moment either | 19:21 |
| gdoubleu | I didn't see that option as it doesn't appear in the output of bzr help commands | 19:22 |
| gdoubleu | thanks, now back to coding | 19:25 |
| james_w | bzr help global-options lists it. | 19:31 |
| james_w | lets hope that bends the space time continuum to reach him before he actually logs off. | 19:31 |
| Lo-lan-do | You have an STC bender? | 19:32 |
| james_w | well, it's a work in progress, I wouldn't say it bends it yet, more strokes it gently. | 19:32 |
| Lo-lan-do | jelmer: Okay, apparently it all went smoothly. I did a pull from SVN in the old branch, and both branches seem identical now. | 19:48 |
| Lo-lan-do | bzr missing doesn't list any differences, nor does diff -ruN | 19:48 |
| jelmer | cool | 19:49 |
| jelmer | If weigon_ can also no longer reproduce the bug, I'll close it | 19:49 |
| weigon_ | jelmer: at least I don't have the problem case anymore | 19:49 |
| jelmer | weigon_: how do you mean? | 19:50 |
| weigon_ | I can merge and commit again after I uncomitted the change | 19:50 |
| jelmer | weigon_: As a workaround you mean? | 19:55 |
| weigon_ | yes | 19:55 |
| weigon_ | I havn't really turned it into a real testcase | 19:56 |
| jelmer | weigon_: but can you still reproduce the bug? | 20:02 |
| weigon_ | nope | 20:02 |
| weigon_ | I'm clean now | 20:02 |
| VSpike | Here to ask some more really silly questions, if I may.. I'm used to the model of something like perforce, where the entire structure of the remote repository is mirrored on the local machine, e.g. if something remotely is in DEPOT/ProjA/TestingBranch then that is where it is going to be relatively on your working system when you check it out... | 20:05 |
| VSpike | With bazaar would it be possible to have a single "working" directory on your workstation and check out whichever branch you wanted to work on at the time to that location? | 20:06 |
| VSpike | In otherwords, does it matter to bazaar where you make the branches on your local system? | 20:07 |
| jam-laptop | VSpike: Bazaar doesn't care where you put them | 20:07 |
| jam-laptop | I might recommend putting a shared repository (bzr init-repo --trees DEPOT) | 20:07 |
| jam-laptop | at the root | 20:07 |
| VSpike | jam-laptop: I'm doing that on what might be considered the main machine... shoudl I do the same on the second (the laptop) as well? | 20:08 |
| jam-laptop | VSpike: having a shared repository means if you have 2 branches of the same code, they can share storage | 20:09 |
| jam-laptop | so it sort of depends how you will work | 20:09 |
| VSpike | If I do that, the locations under that repository will become important, will they not? | 20:09 |
| Lo-lan-do | jelmer: I'm afraid you'll have to bear with me for some time still. | 20:12 |
| jelmer | Lo-lan-do, what's going wrong? | 20:13 |
| Lo-lan-do | SubversionException: ("File '/svn/gforge/trunk/gforge/debian/po/de.po' already exists", 175005) | 20:13 |
| Lo-lan-do | (again) | 20:13 |
| Lo-lan-do | I had the new and the old branch synced with SVN just fine. | 20:13 |
| Lo-lan-do | I tried pulling from another branch called sid, which was originally based from trunk | 20:14 |
| Lo-lan-do | Then pushing to SVN. | 20:14 |
| Lo-lan-do | Tried that via the old gforge-trunk+bzr branch and the new gforge-trunk-new branch (both being bzr-svn branches), got twice the same result. | 20:15 |
| jelmer | you can probably never directly pull from those branches that have the broken revision in their mainline | 20:15 |
| jelmer | only merge them | 20:15 |
| Lo-lan-do | Darn. | 20:15 |
| Lo-lan-do | If I merge them and then pull into them, will I still have the problem? | 20:15 |
| jelmer | I don't think so | 20:16 |
| Lo-lan-do | It's worth a try. | 20:17 |
| jelmer | the problem is that Subversion (the data in the properties) and Bazaar disagree about what the broken revision contains | 20:17 |
| VSpike | I'm also trying to understand how to manage the relationship between a project and a library with bzr. Both are under development by me. Again, with something like perforce, because it takes a view of the state of the entire repository, the relationship between the project and the library is always controlled, even if you branch both of them, because the branches are just new copies under the depot's tree. How can I control this with bzr? | 20:18 |
| jelmer | Lo-lan-do: this is the sort of bug that is a nightmare for bzr-svn, luckily you've been the only one so far with an issue like this, and this bug is not in any releases | 20:18 |
| VSpike | Do I need to make my repo structure contain the lib and the application side by side in each branch, and always keep them together? | 20:18 |
| VSpike | Because I started out going with /libA/main, libA/Branch1, /AppA/main, /AppA/BranchX and so on... | 20:20 |
| jelmer | Lo-Lan-Do: Once you've merged your branches, I'd recommend thrashing your existing branches and continuing from a fresh clone of the Subversion branch | 20:20 |
| VSpike | but will I have to do /main/libA, /main/AppA, /somebranch/libA, /somebranch/AppA instead... | 20:21 |
| VSpike | and always make sure I take both the lib and the app at the same time when branching? | 20:21 |
| Lo-lan-do | I'd love to, but will I be able to do so without changing them if they're stored in a shared repo? | 20:21 |
| Lo-lan-do | IOW: can I replace (or delete) a branch in a shared repository? | 20:22 |
| jelmer | No, but you could start over with a clean repository that only contains the main branch imported from Subversion | 20:23 |
| Lo-lan-do | Blargh, even merging sid into trunk and trying to push trunk to svn fails :-( | 20:24 |
| jelmer | if there are things you can't merge, you could "replay" them using the replay command | 20:25 |
| Lo-lan-do | bzr: ERROR: unknown command "replay" | 20:25 |
| jelmer | Lo-lan-do, it's part of the rebase plugin | 20:25 |
| Lo-lan-do | More recent than 0.1 then? | 20:26 |
| jelmer | yes, 0.2 | 20:26 |
| * Lo-lan-do fetches | 20:26 | |
| Lo-lan-do | $ bzr replay -r4877 ../gforge-sid/ | 20:29 |
| Lo-lan-do | bzr: ERROR: exceptions.NameError: global name 'replay_delta_workingtree' is not defined | 20:29 |
| * jelmer sighs | 20:30 | |
| * Lo-lan-do pulls his hair off | 20:30 | |
| Lo-lan-do | Another plugin I need to fetch? :-) | 20:30 |
| === cprov is now known as cprov-out | ||
| jelmer | one sec | 20:32 |
| james_w | VSpike: hi. | 20:36 |
| james_w | VSpike: can I explain some things that will hopefully help you understand better the model of Bazaar? You're questions got a little lost so it is hard to address them directly. | 20:37 |
| VSpike | james_w: I'd appreciate it, thanks | 20:38 |
| james_w | Firstly, the branch is the most important concept in Bazaar. Everybody has a branch that they work on. You can work in lockstep so that each branch is a mirror of the others. | 20:38 |
| james_w | or you can have branch as the term branch is used in SVN etc., to mean a separate line of development. | 20:39 |
| VSpike | I'm just having trouble making a mental switch from the model I'm used to... doesn't help that I just flew +7 time zones | 20:39 |
| james_w | Fundamentally Bazaar doesn't make the distinction here, so when 'branch' is used it doesn't always mean 'a separate line of development' it can just mean 'a copy of the code that allows you to make changes and commit'. | 20:40 |
| james_w | VSpike: well, give it 7 hours until your brain catches up and all should be fine. | 20:40 |
| VSpike | :) | 20:41 |
| james_w | The next concept to consider is the 'repository'. There is an unfortunate naming clash here, this isn't the same as an SVN repostiory. I've never used perforce, so I can't say how it differs there. | 20:41 |
| james_w | There have been discussion about using a different term in Bazaar, such as 'vault', 'locker' or 'archive', but other terms also have a disadvantage. | 20:42 |
| VSpike | perforce is very similar to svn in overall concepts | 20:43 |
| james_w | Think of a repository is just a store of revisions. There is no 'tip' revision or anything, it is just a big box where the revisions are kept. A standalone branch has a repository hidden away to keep this separation (you can see this if you do 'bzr init; ls .bzr'). | 20:43 |
| james_w | This means that a branch is just a pointer in to the 'box' that is the repository, which points at the commit that is the tip of the branch. | 20:44 |
| james_w | This tip then points to its parents, and they point to there parents, so if you pull the string that starts at this tip revision you get the full history of the branch. | 20:45 |
| james_w | Now, as the repository is just a 'box' you can have many branches that point to tip revisions within. The repository doesn't care if they are related in any way, or if two point to the same tip revision. | 20:46 |
| james_w | Therefore you can create a 'shared repository', which is just a box where multiple branches can store their revisions. | 20:47 |
| james_w | This is what you do with the 'init-repo' command. | 20:47 |
| Lo-lan-do | jelmer: I added replay_delta_workingtree to the "from rebase import ..." clause for class cmd_replay, seems to work better | 20:47 |
| james_w | Now when you have two branches of the same project inside a shared repository they can share some of the same revision data, and so save space compared to each having their own repository. This means you can just consider the shared repository as a storage optimisation. | 20:49 |
| james_w | and as the repository doesn't care about the branches that use it, you can name a branch inside a repository anything you like. | 20:50 |
| james_w | so, to hopefully address what I think was your first question, if you create a shared repository on your central server, then it doesn't matter whether you create one on your development machine or not. | 20:51 |
| james_w | If you do also create one on your development machine then you can name the branches within differently to the server if you like. | 20:51 |
| VSpike | OK, with you so far | 20:52 |
| james_w | This is because the repository knows knothing about the other machine. If you want to associate a branch on your development machine with a branch on your central server then you use the URI to do so. | 20:52 |
| james_w | This means you would use something like bzr+ssh://central/wherever/branch1 | 20:53 |
| james_w | so branches are associated using URIs, rather than by using their position relative to a repository like in SVN. | 20:53 |
| VSpike | OK | 20:54 |
| james_w | so if you have repo/branch1 and repo/branch2 on your server, you can have repo/branch3 and repo/branch4 on your development box, where 'bzr pull' in branch3 would pull from branch1, but 'bzr pull' in branch4 could pull from a completely different project on a completely different server. | 20:55 |
| james_w | This can lose you some convenience, but can be more flexible. | 20:55 |
| james_w | VSpike: happy with that? Does it answer your first set of questions? | 20:55 |
| VSpike | Yes thanks, I get that. It doesn't answer one of them, but I don't think that other question was possibly a red herring anyway | 20:56 |
| VSpike | So the next big one was about relationship between two sub projects | 20:57 |
| VSpike | btw, excellent explanations - thanks | 20:57 |
| james_w | < VSpike> With bazaar would it be possible to have a single "working" directory on your workstation and check out whichever branch you wanted to work on at the time to that location? | 20:57 |
| james_w | that one? | 20:57 |
| VSpike | yeah, that one I think is a red herring, but I'm curious | 20:59 |
| james_w | ok, short answer, yes it is possible. | 20:59 |
| VSpike | I can see how it would work without using a shared repository on the workstation, but I would have thought using a shared repository would make it impossible? | 21:00 |
| james_w | (but probably not as easy, as you don't have a known layout on the server). | 21:00 |
| james_w | to answer this we need to consider the third bzr concept: working trees. | 21:00 |
| james_w | A working tree is the files that you have on your machine to edit and commit from. | 21:01 |
| james_w | Many people wouldn't distinguish this from the branch, but they are different. | 21:01 |
| james_w | Each working tree has a pointer to a branch that it will commit to when you commit. | 21:01 |
| james_w | Usually this is not obvious, as it is just the branch that is in the same directory as the working tree. | 21:02 |
| james_w | However you can separate the two physically, and even put them on two different machines. | 21:02 |
| james_w | Doing this separation gives you a 'lightweight checkout'. | 21:03 |
| VSpike | ahhh okay | 21:03 |
| VSpike | I see how that would work I think | 21:03 |
| james_w | (Yes, there is a heavyweight checkout, I can explain them later if you like). | 21:03 |
| james_w | So, you create a lightweight checkout on your local machine of the branch you want to change on your server. | 21:03 |
| james_w | when you want to change the branch you install bzrtools and run 'bzr switch URL', where the URL is another branch on the server. | 21:04 |
| james_w | so as I said, it's not as easy, as you have to give a full URL. We would be glad to hear a good scheme to improve this. (You can use env vars to do it now if you do it load). | 21:05 |
| james_w | bzrtools is a set of plugins that add sometimes useful features to bzr. | 21:05 |
| james_w | does that answer the question? | 21:05 |
| VSpike | Yes thanks | 21:06 |
| james_w | good. | 21:06 |
| james_w | now for the libraries question. | 21:07 |
| VSpike | :) | 21:07 |
| james_w | This is a very common task, and one that we want to support. | 21:07 |
| james_w | The idea is to do something like svn:externals if you have used those. | 21:07 |
| james_w | We call it 'nested trees'. | 21:07 |
| james_w | The format that will hopefully support doing this is in recent versions of bzr. | 21:08 |
| james_w | The commands to manage this are not. | 21:09 |
| jam-laptop | I would interject one small thing, though | 21:09 |
| james_w | (I might have to go with 'these are not the commands you are looking for' if you look too hard). | 21:09 |
| jam-laptop | In that "nested-by-value" does work | 21:10 |
| jam-laptop | "nested-by-reference" (svn:externals) does not | 21:10 |
| jam-laptop | I've done it with nested-by-value, and it actually works pretty well | 21:10 |
| jam-laptop | but it means you have to be more careful when you want to pull any changes out of your subproject | 21:10 |
| james_w | I've never properly grasped by-value. | 21:11 |
| jam-laptop | james_w: It is just merging the files into the other tree | 21:11 |
| jam-laptop | such that they maintain their history and file ids | 21:11 |
| james_w | But Aaron is being quite insistent on this issue currently, so I didn't want to encourage it. | 21:11 |
| jam-laptop | (bzr merge -r0..? or bzr merge-into from the plugin) | 21:11 |
| jam-laptop | james_w: He is talking about by-reference | 21:11 |
| jam-laptop | but yeah, that was a pretty strong discussion | 21:11 |
| james_w | jam-laptop: I helped someone get merge-into working, did you get the patch for it? | 21:12 |
| jam-laptop | I don't remember seeing a patch for it | 21:12 |
| james_w | jam-laptop: ah, that distinction wasn't clear, thanks for clarifying. | 21:12 |
| VSpike | So maybe the simplest solution for me for now is to keep the two together and treat them as a single entity in bzr? | 21:13 |
| james_w | that would work yes. The other alternative is to keep them separate and just branch them both whenever you need them. | 21:13 |
| jam-laptop | VSpike: well, *I* would have 2 separate branches, which I then merged together | 21:13 |
| jam-laptop | And I would try to make changes to the sub-project in the split-out branch | 21:14 |
| jam-laptop | and then merge them into the combined one | 21:14 |
| VSpike | I think that will help my other other problem, which is how to make visual studio deal with it... that way, the relative path between one and the other will be unchanging | 21:14 |
| jam-laptop | but it *is* extra work | 21:14 |
| james_w | jam-laptop: bug #144108 | 21:14 |
| ubotu | Launchpad bug 144108 in bzr-merge-into "Doesn't work with 0.90 -- no attribute 'base_is_other_ancestor'" [Undecided,New] https://launchpad.net/bugs/144108 | 21:14 |
| james_w | VSpike: yes, simplest solution is to make one branch, but it gives you less flexibility later. | 21:14 |
| jam-laptop | you can always "bzr split" but your sub-project will keep tracking all the extra files from the combined project | 21:15 |
| james_w | jam-laptop: the problem that he mentions is what I wanted to ask you about. | 21:15 |
| james_w | unfortunately the salient details elude me. | 21:15 |
| jam-laptop | (well, grabbing just a branch of the subproject will also copy the history files for files which *used* to be there) | 21:15 |
| jam-laptop | james_w: you mean about 144108? | 21:15 |
| VSpike | true, but I think - without having used it yet - that the flexible branching in bzr will still allow me to do what I want | 21:16 |
| james_w | jam-laptop: yes, his final comment in the patch mail. | 21:16 |
| jam-laptop | I'm seeing lots of other failures trying to run with bzr.dev | 21:16 |
| jam-laptop | So I'm guessing some api's changed in ways I didn't expect | 21:16 |
| jam-laptop | Like instead of getting a path at one point, I'm getting a number | 21:17 |
| james_w | this was a while ago that we worked on it, so it might well be broken again. | 21:17 |
| james_w | jam-laptop: is it intened to support continually merging from the original branch? | 21:17 |
| jam-laptop | 'merge-into' ? | 21:17 |
| jam-laptop | Yes, you should be able to continue to merge from the original | 21:18 |
| jam-laptop | The only issue is that you need unique tree roots | 21:18 |
| jam-laptop | or adding a file in the root of the merged project | 21:18 |
| jam-laptop | will add it in the root of the combined project | 21:18 |
| james_w | actually I don't know whether he was doing 'merge' or 'merge-into' on subsequent tries. | 21:18 |
| james_w | I think that was one issue. | 21:19 |
| james_w | The other was that you got some sort of conflict when a file was deleted from the merged project. | 21:19 |
| james_w | I said this was a limitation at the time, but I can't remember why. | 21:19 |
| jam-laptop | james_w: I think the problem is that you have a rename of the file, versus a deletion | 21:20 |
| jam-laptop | so there is a conflict about paths | 21:20 |
| jam-laptop | (you have a change, they have a change that cannot apply exactly) | 21:20 |
| james_w | that's the badger. | 21:20 |
| jam-laptop | but I could be wrong | 21:20 |
| jam-laptop | I haven't tried it a lot | 21:20 |
| jam-laptop | I need to see if I have the latest version, something is weird | 21:21 |
| james_w | yeah, so every deletion is a conflict, because every file is always a rename compared to the other branch. | 21:21 |
| james_w | VSpike: all sorted now? | 21:23 |
| lifeless | moin | 21:24 |
| VSpike | jam-laptop: can you explain what you meant when you said you'd have two separate branches which you'd then merge together, and make changes to the subproject in the split out branch? | 21:24 |
| jam-laptop | bzr init project | 21:25 |
| jam-laptop | bzr init library | 21:25 |
| jam-laptop | cd project | 21:25 |
| VSpike | jam-laptop: I read it a few times, but I can't quite get it :) brains still lagging | 21:25 |
| james_w | hi lifeless | 21:25 |
| jam-laptop | bzr merge-into../library library | 21:25 |
| jam-laptop | bzr commit -m "Add library to project" | 21:25 |
| jam-laptop | VSpike: At this point, you have a project which has merged library into it | 21:25 |
| jam-laptop | Then when you make changes in the standalone "library" project | 21:26 |
| VSpike | james_w: on the verge of it, i think, thanks to you both | 21:26 |
| jam-laptop | you can then go to "project" | 21:26 |
| jam-laptop | and | 21:26 |
| jam-laptop | bzr merge ../library | 21:26 |
| jam-laptop | bzr commit -m "Merge the latest changes to library" | 21:26 |
| jam-laptop | VSpike: do you follow me so far? | 21:26 |
| jam-laptop | (of course, this is provided that I get merge-into working again) | 21:26 |
| james_w | VSpike: no problem, come back if you have any more issues. | 21:27 |
| VSpike | jam-laptop: i do .. yep.. amazingly | 21:27 |
| jam-laptop | Now, if you make changes to the library | 21:27 |
| jam-laptop | (the copy that is in "project") | 21:27 |
| jam-laptop | you have to "cherry-pick" them back into the separate 'library' project | 21:28 |
| jam-laptop | cd library, bzr merge -r 10..12 ../project; bzr commit -m "Cherry pick the changes out of project for library" | 21:28 |
| jam-laptop | The 10 should be the last revision *before* the changes, and the 12 is the last revision *of* the changes | 21:29 |
| jam-laptop | it may be easier if I give more specific examples | 21:29 |
| jam-laptop | which I can do | 21:29 |
| VSpike | I think I follow you | 21:29 |
| jam-laptop | VSpike: but if you follow me so far, it means I don't have to :) | 21:29 |
| jam-laptop | VSpike: Anyway, Bazaar should be smart enough to merge changes to the correct files after you do this | 21:29 |
| jam-laptop | though as james_w points out, it may tree deleted files as conflicts | 21:30 |
| VSpike | What is the advantage of doing it that way as opposed to keeping it monolithic? | 21:30 |
| jam-laptop | VSpike: if you want to have 4 projects which all share "library" | 21:30 |
| jam-laptop | Or you have philosophical reasons | 21:30 |
| james_w | (easy to rectify, but perhaps annoying if you do it often) | 21:30 |
| jam-laptop | like wanting to version "library" independently | 21:30 |
| VSpike | right, makes sense | 21:30 |
| jam-laptop | One company I worked for had about 90 separate branches that built together for the project | 21:31 |
| jam-laptop | where each plugin/module was a separate branch | 21:31 |
| jam-laptop | but the build stage built everything togethehr | 21:31 |
| jam-laptop | together | 21:31 |
| VSpike | because I was wondering how easy it would be if I have two branches, each with a monolithic proj+lib combination, and I made some fixed in the in library in branch A and wanted to merge them into branch B without getting any of the changes to the main project | 21:32 |
| jam-laptop | *I* think our eventual nested-by-reference will be the "Right Way" to do it. | 21:32 |
| jam-laptop | VSpike: that is where having a separate library branch helps | 21:32 |
| jam-laptop | in that you can cherry pick those changes out | 21:32 |
| jam-laptop | and then just merge them into the other project | 21:32 |
| jam-laptop | You actually could do that between just the monolithic projects | 21:33 |
| VSpike | But if I had three or four branches, i'd have to do it three or four time, while with your method i basically do the cherry picking once, and then merge into the other branches, right? | 21:33 |
| james_w | but that wouldn't necessarily satisfy my definiton of fun for some of the cases you could hit. | 21:34 |
| james_w | VSpike: yes, that's correct. | 21:34 |
| james_w | or just fix it in the library branch and merge in to all projects, depending on where you want to fix it first. | 21:34 |
| VSpike | true | 21:34 |
| VSpike | I think the fog is clearing :) | 21:35 |
| james_w | VSpike: obviously any help to make by-reference nested trees work better would be appreciated :) | 21:37 |
| VSpike | :) | 21:37 |
| james_w | I'm not convinced that the time spent doing that would be less that the time you spent cherry picking etc. with jam's system. | 21:37 |
| jam-laptop | Time spent getting by-reference working? | 21:38 |
| james_w | yeah. | 21:38 |
| jelmer | Lo-lan-do: thanks, now fixed upstream too | 21:39 |
| lifeless | jam-laptop: I have native update_basis_via_delta working. | 21:39 |
| lifeless | jam-laptop: 5 second win | 21:39 |
| jelmer | Lo-lan-do, any luck using replay? | 21:39 |
| jam-laptop | lifeless: nice | 21:40 |
| jam-laptop | certainly avoiding rebuilding the full tree is nice | 21:40 |
| Lo-lan-do | jelmer: Nope. I ended up doing a shell loop around bzr diff and patch -p1 | 21:40 |
| jam-laptop | lifeless: I had a question about _make_absent | 21:40 |
| jam-laptop | for bug #114615 | 21:40 |
| ubotu | Launchpad bug 114615 in bzr "Commit can fail and corrupt tree state after encountering some merge/conflicts" [High,Confirmed] https://launchpad.net/bugs/114615 | 21:40 |
| jam-laptop | The idea is that it tracks down all references to the row that is being removed | 21:40 |
| Lo-lan-do | I'm almost done, then I'll try pushing. If it works, then I'll trash the old branches and replace with clean new ones. | 21:41 |
| jam-laptop | and marks the current value as absent | 21:41 |
| jam-laptop | It has an assertion that they are not already marked as absent | 21:41 |
| jam-laptop | But that breaks when you rename inside a directory | 21:41 |
| jam-laptop | and then remove that directory | 21:41 |
| jam-laptop | (so that commit unversions the whole subtree) | 21:41 |
| jam-laptop | Because it finds one half of the rename, marks both sides absent, and then finds the other side | 21:41 |
| jam-laptop | and tries to do it again | 21:41 |
| lifeless | uhm | 21:42 |
| lifeless | so this is in set_parent_trees? | 21:42 |
| jam-laptop | unversion() | 21:42 |
| lifeless | oh | 21:42 |
| jam-laptop | I take it back | 21:42 |
| jam-laptop | it finds one half of the rename | 21:42 |
| jam-laptop | and marks just that entry as absent | 21:42 |
| jam-laptop | then finds the other half | 21:42 |
| jam-laptop | and tries to mark *both* sides absent | 21:42 |
| jam-laptop | Because we don't pay attention to the working tree | 21:43 |
| jam-laptop | but we do to all parents | 21:43 |
| lifeless | so this is a merge | 21:43 |
| lifeless | we have 3 trees | 21:43 |
| lifeless | what's the kind and pointer values at the unversioned path ? | 21:43 |
| lifeless | path being unversioned that is | 21:43 |
| jam-laptop | (it also has a chance to accidentally remove a file which is actually moved out of that directory, but I haven't simplified that down to a simple case yet) | 21:44 |
| jam-laptop | lifeless: doesn't have to be a merge | 21:44 |
| jam-laptop | see my last test case | 21:44 |
| jam-laptop | bzr init; mkdir dir; touch dir/file; bzr add; bzr commit | 21:44 |
| jam-laptop | bzr mv dir/file dir/z; rm -rf dir; bzr commit -m "boom" | 21:44 |
| jam-laptop | That first finds that all entries in "dir/" need to be removed | 21:45 |
| jam-laptop | Then it finds "file" | 21:45 |
| jam-laptop | which is shown to be renamed to "dir/z" | 21:45 |
| jam-laptop | oh, sorry | 21:45 |
| jam-laptop | it finds "dir/file" | 21:45 |
| jam-laptop | and marks it as absent | 21:45 |
| jam-laptop | then it finds "dir/z" | 21:45 |
| jam-laptop | and sees that it is renamed from "dir/file" (because that was the path in the basis" | 21:46 |
| jam-laptop | ) | 21:46 |
| jam-laptop | so it tries to mark dir/file absent again, and dir/z as absent | 21:46 |
| jam-laptop | but it fails because dir/file was already marked absent | 21:46 |
| jam-laptop | My "fix" is to just remove the assertion | 21:47 |
| jam-laptop | There is another bug present | 21:47 |
| jam-laptop | but that fixes the assertion error | 21:47 |
| jam-laptop | And it passes all the other tests | 21:47 |
| lifeless | and were considering dir/file at all because ? | 21:49 |
| lifeless | dir/file is not present in tree 0, unversion shouldn't be touching it | 21:49 |
| jam-laptop | lifeless: it is in the dirblock of 'dir' | 21:49 |
| lifeless | with 'r' | 21:50 |
| jam-laptop | while entry_index < len(block[1]): | 21:50 |
| jam-laptop | # Mark this file id as having been removed | 21:50 |
| lifeless | which is 'not here but renamed' | 21:50 |
| jam-laptop | entry = block[1][entry_index] | 21:50 |
| jam-laptop | ids_to_unversion.discard(entry[0][2]) | 21:50 |
| jam-laptop | if (entry[1][0][0] == 'a' | 21:50 |
| jam-laptop | or not state._make_absent(entry)): | 21:50 |
| jam-laptop | entry_index += 1 | 21:50 |
| jam-laptop | That is 'unversion' | 21:50 |
| jam-laptop | You could argue for "entry[1][0][0] in ('a', 'r')" | 21:50 |
| jam-laptop | Which I could also accept | 21:50 |
| lifeless | I think that would be more correct | 21:51 |
| jam-laptop | I'll see if the tests pass with that... | 21:51 |
| lifeless | because turning an 'r' into an 'a' is a massive problem | 21:51 |
| lifeless | what if the 'r' is outside this directory | 21:51 |
| lifeless | we'll lose our pointer, status will start misbehaving | 21:51 |
| lifeless | real 1m30.277s | 21:53 |
| lifeless | user 1m22.405s | 21:53 |
| lifeless | sys 0m4.648s | 21:53 |
| lifeless | initial | 21:53 |
| lifeless | real 0m25.044s | 21:53 |
| lifeless | user 0m17.357s | 21:53 |
| lifeless | sys 0m1.284s | 21:53 |
| jam-laptop | lifeless: do we have a specific "target" time? | 21:53 |
| lifeless | adding 5 files | 21:53 |
| lifeless | real 0m11.646s | 21:53 |
| lifeless | user 0m10.825s | 21:53 |
| lifeless | sys 0m0.632s | 21:53 |
| lifeless | changing one and specifying it on the command line | 21:53 |
| jam-laptop | lifeless: also, it would be easier to read if you did "/usr/bin/time XXX" rather than "time XXX" | 21:53 |
| jam-laptop | 0.14 real 0.00 user 0.00 sys | 21:53 |
| lifeless | jam-laptop: I'd like to get our cpu for initial commit down to only twice tar czf | 21:54 |
| jam-laptop | lifeless: and what time is that? | 21:54 |
| lifeless | for incremental operations, I'd like it to be roughly the time for 'st' | 21:54 |
| jam-laptop | sure, I'm just wondering what the actual number is | 21:54 |
| lifeless | on my machine, tar czf is | 21:55 |
| lifeless | hmm, not sure, but gzip of the tar is 35 seconds | 21:55 |
| lifeless | I find the vertical layout easiest to read, it may just be me | 21:56 |
| jam-laptop | lifeless: it is much easier to compare 2 copies | 21:56 |
| jam-laptop | when they line up | 21:56 |
| lifeless | right, I do that left to right | 21:56 |
| jam-laptop | then you should paste them here that way :) | 21:56 |
| lifeless | these three sets are not meant to be compared | 21:57 |
| lifeless | they are different use cases | 21:57 |
| jam-laptop | it still would be easier to read :) | 21:57 |
| lifeless | heh | 21:57 |
| jam-laptop | well, the fact that my IRC program uses a proportional font doesn't help | 21:59 |
| lifeless | so fix it ? :) | 22:00 |
| jam-laptop | except it is actually easier to read most text | 22:05 |
| jam-laptop | (softer on the eyes) | 22:05 |
| jam-laptop | lifeless: well if gzip of the tar is 35s, then you still have all the fs overhead, etc. 1m22s seems pretty close to your mark | 22:06 |
| jam-laptop | Unless you are just considering user/sys time? | 22:06 |
| lifeless | 1m22 is close | 22:07 |
| lifeless | but not there :) | 22:07 |
| lifeless | 1m30 wall clock time is considerably more clearly 'not there' | 22:08 |
| lifeless | 15 failures with this patch. | 22:08 |
| Lo-lan-do | jelmer: It's pushed! | 22:09 |
| lifeless | LarstiQ: ping | 22:09 |
| jelmer | Lo-lan-do: cool! | 22:09 |
| LarstiQ | lifeless: pong | 22:09 |
| lifeless | how are you? | 22:09 |
| lifeless | is your life stabilised ? | 22:10 |
| LarstiQ | lifeless: sorta kinda | 22:10 |
| jelmer | Lo-lan-do: hope this bug is finally fixed then | 22:10 |
| lifeless | I'd love it if you got the subtree patch out and made hot sweet love to it | 22:10 |
| Lo-lan-do | jelmer: I hope so too | 22:10 |
| jam-laptop | LarstiQ: good to see you around | 22:11 |
| LarstiQ | lifeless: anything in specific (ie, I recall a dirstate problem), or the entirety? | 22:11 |
| LarstiQ | jam-laptop: thanks | 22:11 |
| * LarstiQ wouldn't call himself 'around' just yet, but thanks nonetheless | 22:11 | |
| lifeless | LarstiQ: there's a heated discussion on malone at the moment | 22:11 |
| LarstiQ | lifeless: got a link to that? | 22:12 |
| lifeless | that revolves around knit3 repositories existing, but not being something that folk hacking on bzr.dev as the majority of their hacking time want to consider 'fully supported' yet. | 22:12 |
| jam-laptop | bug 131667 | 22:12 |
| ubotu | Launchpad bug 131667 in bzr "--dirstate-with-subtree is documented in the man page" [Medium,Fix committed] https://launchpad.net/bugs/131667 | 22:12 |
| jam-laptop | LarstiQ: ^ | 22:12 |
| lifeless | LarstiQ: the 'most recently touched' bug links are quite nice | 22:12 |
| LarstiQ | lifeless: ah, heated would imply that, yes | 22:13 |
| jam-laptop | lifeless: quick question on "unversion" does it's list include child entries? | 22:14 |
| jam-laptop | or does it just get the top-level dir ? | 22:14 |
| LarstiQ | lifeless: I see. | 22:17 |
| lifeless | jam-laptop: IIRC its handed in the user supplied path | 22:21 |
| lifeless | jam-laptop: so its expected to recurse | 22:21 |
| jam-laptop | lifeless: unversion() takes a list/set of file_ids | 22:21 |
| jam-laptop | it is called by the commit code | 22:21 |
| jam-laptop | after commit determines things to auto-remove | 22:21 |
| jam-laptop | But I can see that the code *does* recurse | 22:22 |
| jam-laptop | so I'm starting with that | 22:22 |
| lifeless | right, commit stops recursing at the top level path it finds missing | 22:22 |
| LarstiQ | jelmer: poke | 22:23 |
| jelmer | LarstiQ: porrrr | 22:24 |
| LarstiQ | jelmer: are you attending the bapc? | 22:24 |
| jelmer | yup, I'll be there | 22:24 |
| LarstiQ | jelmer: ok, have time for a chat then? | 22:24 |
| jelmer | Sure :-) | 22:25 |
| lifeless | bapc ? | 22:25 |
| LarstiQ | lifeless: I haven't really kept up, but I thought I saw some changes go into bzr.dev that might make subtrees slightly easier. | 22:25 |
| james_w | hi LarstiQ | 22:26 |
| LarstiQ | lifeless: I need to take a look at what the current combined status is before an assesement of the time involved can hope to be accurate, but I hope the major hurdles are solved. | 22:26 |
| LarstiQ | lifeless: Benelux Algorithm Programming Contest | 22:26 |
| LarstiQ | for some reason I got drafted into a spectator team *boggle* | 22:26 |
| nDuff | lifeless: I can reproduce having a massive time difference between initial commit and recommit, but the circumstances where it's completely reproducible, the extra time on the recommit appears to be mostly I/O -- it shows up under "real", but not "user" or "sys" under time, as opposed to the first time where it was just about all accounted to user. I'm generating callgrind files. | 22:28 |
| LarstiQ | james_w: heya | 22:28 |
| nDuff | s/but the circumstances/but under the circumstances/ | 22:28 |
| lifeless | nDuff: thanks | 22:29 |
| jam-laptop | nDuff: are you saying that the total real time doesn't change? Just that it moves out of user time? | 22:34 |
| lifeless | nDuff: oh, hangong. Are you saying that recommit got faster ? | 22:35 |
| lifeless | or that recommit was *slower* ? | 22:35 |
| nDuff | jam-laptop: no; the real time changes dramatically (4min initial vs 45min recommit), but the user time changes comparatively little (~2m40s on both). | 22:36 |
| jam-laptop | so recommit is 10x slower than initial commit | 22:36 |
| jam-laptop | hmm... | 22:36 |
| jam-laptop | that is after just doing | 22:36 |
| jam-laptop | bzr uncommit | 22:36 |
| jam-laptop | bzr commit | 22:36 |
| jam-laptop | right? | 22:36 |
| nDuff | yup. | 22:36 |
| jam-laptop | Is this the first commit? | 22:36 |
| jam-laptop | or an incremental commit | 22:37 |
| nDuff | right now, I'm testing with the first commit. previously, it was an incremental. | 22:37 |
| jam-laptop | so 4 versus 45 is for the first commit | 22:37 |
| nDuff | yes. | 22:37 |
| lifeless | nDuff: the only thing I can think of is autopack | 22:38 |
| lifeless | if this is a shared repository, or even just a branch you are reusing extensively | 22:38 |
| jam-laptop | lifeless: a second commit shouldn't autopack, right? | 22:38 |
| lifeless | nDuff: have a look in ~/.bzr.log | 22:38 |
| jam-laptop | it would be the 10th | 22:39 |
| lifeless | jam-laptop: right, but a reused branch or a shared repo will, because its the global rev count not the branch reachable revcount | 22:39 |
| jam-laptop | lifeless: sure | 22:39 |
| jam-laptop | but it would be a multiple of 10 | 22:39 |
| lifeless | nDuff: look for autopack | 22:40 |
| lifeless | jam-laptop: well not strictly no. Its whenever the desired pack count is greater than the real pack count | 22:40 |
| lifeless | jam-laptop: the desired pack count changes for every 10 revisions; and the real increments by one every write group | 22:41 |
| jam-laptop | ah, sure | 22:41 |
| jam-laptop | lifeless: I was thinking that maybe it was looking up the indexes for the files | 22:42 |
| jam-laptop | which are now non-empty | 22:42 |
| jam-laptop | even though the existing revision is not in the current history | 22:42 |
| jam-laptop | but autopack could also be an issue | 22:43 |
| james_w | it's not the hashcache being dropped again is it? | 22:44 |
| jam-laptop | james_w: I don't think that would account for 45 min | 22:44 |
| jam-laptop | and doing | 22:44 |
| lifeless | jam-laptop: it will look to see that the inserted revisions are really new I think still | 22:44 |
| jam-laptop | bzr uncommit; bzr status | 22:44 |
| jam-laptop | would restore the hash cache | 22:44 |
| nDuff | oh, %#$^ | 22:44 |
| lifeless | and while the index layer in packs has different tradeoffs, 10x slower is totally unexpected | 22:44 |
| jam-laptop | nDuff: ? | 22:45 |
| nDuff | I dropped the --experimental from my "bzr init"s | 22:45 |
| nDuff | okay, going back and starting from scratch. | 22:45 |
| lifeless | nDuff: rofl | 22:45 |
| lifeless | well, thank you for letting us know how long commit on knits is :) | 22:45 |
| jam-laptop | nDuff: is that for all your tests? | 22:46 |
| jam-laptop | (the 4 versus 45?) | 22:46 |
| jam-laptop | Or is that just for your --lsprof ones? | 22:46 |
| nDuff | jam-laptop: yes. consider everything I've said on the topic invalidated at this point; I'll get back after redoing them. | 22:47 |
| nDuff | (actually, this might explain why I couldn't reproduce the 15min-of-user-time case) | 22:48 |
| nDuff | oh. we're logging to ~/.bzr.log, eh? | 22:49 |
| nDuff | I just thought of something. | 22:49 |
| nDuff | my home directory is on very nonperformant network storage. | 22:50 |
| nDuff | large amounts of logging could explain cases where I see lots of wall-clock time but not user or system time. | 22:50 |
| * nDuff looks into redirecting that to a path on local disk. | 22:51 | |
| james_w | does BZR_HOME work for that? | 22:51 |
| lifeless | yes | 22:53 |
| lifeless | I think there is also a specific pathf or that | 22:53 |
| lifeless | we shouldn't be logging all that much | 22:53 |
| nDuff | lifeless: looking through ~/.bzr.log, I at least see a case where we're logging a line per file added. | 22:54 |
| nDuff | lifeless: on my tree, that's significant. | 22:54 |
| lifeless | nDuff: yes, that would be. damn, I thought we'd corrected that. | 22:54 |
| lifeless | its basically spam. | 22:54 |
| nDuff | lifeless: I didn't look at when it was logged; it may be from an older version of bzr. | 22:55 |
| lifeless | nDuff: oh, btw, bzr commit -q is faster too | 22:55 |
| * nDuff has been using -q | 22:55 | |
| lifeless | cool :) | 22:55 |
| jam-laptop | as is 'bzr add -q' :) | 22:55 |
| lifeless | ok, time to see if I've fixed all bugs | 22:55 |
| lifeless | fingers crossed | 22:56 |
| nDuff | okay, using -packs, I don't get that 4-vs-45min behavior on the initial commit. | 22:56 |
| lifeless | whew | 22:56 |
| jam-laptop | wow, you mean we get to set Fixed Released to all 581 bugs? | 22:56 |
| lifeless | blah | 22:56 |
| jam-laptop | thank you very much lifeless | 22:56 |
| lifeless | thou knowest what I mean | 22:57 |
| jam-laptop | sure, but a man can dream | 22:57 |
| lifeless | I had 15 failing tests | 22:57 |
| jam-laptop | I mean, I know you wake up early and all | 22:57 |
| mkanat | mwhudson: The production loggerhead branch seems to have a pretty serious memory leak. | 22:59 |
| mkanat | mwhudson: My process was 1.1GB after a few weeks of running. | 23:00 |
| dash | hi. i've got an Interesting Situation | 23:04 |
| dash | i have two branches and I want to merge one into the working copy of the other | 23:05 |
| dash | but I don't want to merge the two branches together. | 23:05 |
| dash | is this even reasonable to think about? | 23:05 |
| mkanat | dash: That's what merge does. | 23:06 |
| lifeless | wooooo | 23:09 |
| lifeless | dash: merge followed by revert --forget-merges is likley what you want | 23:09 |
| dash | lifeless: --forget-merges was indeed the thing I was looking for. | 23:13 |
| dash | basically, i've got an Eclipse workspace for a java project... and I want to merge in some changes for deployment on another server, in order to make an archive in eclipse | 23:13 |
| lifeless | jam-laptop: if you have time, a review of my just-mailed patch would be cool. | 23:18 |
| dash | huh. is --forget-merges in 0.90? | 23:20 |
| nDuff | lifeless, ~3m30s for the initial commit (and recommit) using -packs, ~20m (15m user time) for the first incremental commit. | 23:22 |
| lifeless | dash: no its not | 23:23 |
| lifeless | nDuff: thats rather bad isn't it. I've never seen incremental go *up* | 23:23 |
| lifeless | (over initial) | 23:23 |
| lifeless | assuming the incremental is a small relative change, of course. | 23:24 |
| dash | dang. and I thought I was doing so good, running gutsy | 23:24 |
| jam-laptop | certainly I would expect it to go up if the basic diffs are drastically different | 23:24 |
| jam-laptop | (every file doubles in size) | 23:24 |
| nDuff | lifeless: it's a pretty significant set of changes. | 23:25 |
| lifeless | nDuff: what revno of the packs branch are you using ? | 23:25 |
| * nDuff goes to gather some stats on that. | 23:25 | |
| jam-laptop | nDuff: have you done a 'make' tobuild the C extensions? | 23:25 |
| lifeless | there was a bad list-copy on text construction | 23:25 |
| nDuff | lifeless: r2851 | 23:26 |
| lifeless | nDuff: hmm, that has that fix | 23:26 |
| lifeless | 2852 has some bzr.dev fixes, and the new incremental update to the working tree | 23:26 |
| lifeless | nDuff: you have 100K files right ? | 23:26 |
| sabdfl | evening all | 23:26 |
| lifeless | hi sabdfl | 23:26 |
| sabdfl | how's tricks in this part of the world? | 23:27 |
| lifeless | good | 23:27 |
| lifeless | just sent in a review request for a 30% saving on 'bzr commit FOO' | 23:27 |
| sabdfl | in addition to prior numbers, or a new win? | 23:27 |
| lifeless | sabdfl: incremental on top of the existing | 23:27 |
| lifeless | measured with packs naturally | 23:27 |
| nDuff | lifeless: in the initial tree, about 100,000 files. after the first update, 127000 files in 25000 directories. | 23:28 |
| lifeless | so 15seconds to 10 seconds | 23:28 |
| lifeless | nDuff: ok, for this I expect 2852 will help some | 23:28 |
| lifeless | nDuff: but not at the scale you're seeing, something else is wrong there - jam-laptop's question about doing 'make' is a good one | 23:28 |
| lifeless | 2852 is just reannotating back to knit format for you to pull | 23:29 |
| lifeless | time for a new lsprof run with this update_basis code in place | 23:34 |
| nDuff | jam-laptop: argh. did that on the tarball snapshot, but didn't have the C extension built for the checkout; that makes a dramatic difference on the initial incremental commit, at least if recommit times are representative. | 23:34 |
| lifeless | nDuff: recommit is representative | 23:34 |
| jam-laptop | that is using python to do "diff" versus "C" | 23:34 |
| jam-laptop | which on my testing can be | 23:34 |
| jam-laptop | 100ms | 23:34 |
| jam-laptop | versus 5ms | 23:34 |
| lifeless | jam-laptop: good call there :) | 23:34 |
| sabdfl | lifeless: is there a big queue of bits to land on bzr.dev ? | 23:35 |
| lifeless | jam was just commenting yesterday that there is | 23:35 |
| lifeless | theres about 15 branches the authors think are finished in flight at the moment | 23:36 |
| sabdfl | yikes. hope it can all land before 0.92, before all-hands | 23:36 |
| jam-laptop | well, our test suite finishes a bit faster than LP's :) | 23:36 |
| lifeless | haha | 23:37 |
| lifeless | harsh | 23:37 |
| sabdfl | yeah, 15 branches would be 15 hours of PQM happiness in LP | 23:38 |
| jam-laptop | just 15? | 23:38 |
| jam-laptop | I thought the LP suite was closer to 2 hrs | 23:38 |
| sabdfl | we got the test suite down to 59 minutes at present | 23:38 |
| jam-laptop | At least it felt that long when we used to be waiting behind it for bazaar merges | 23:38 |
| jam-laptop | I'm glad to hear that you've improved it | 23:38 |
| sabdfl | there's still plenty of room for improvement | 23:39 |
| lifeless | nDuff: pull now | 23:39 |
| lifeless | r2852, in the pack-repository.knits branch | 23:39 |
| lifeless | nDuff: I'll expect this to cut about 10 seconds off your incremental commits | 23:40 |
| nDuff | lifeless: bzr: ERROR: Cannot lock LockDir(http://people.ubuntu.com/%7Erobertc/pack-repository.knits/.bzr/repository/lock): Transport operation not possible: http does not support mkdir() | 23:40 |
| nDuff | ...doing an update | 23:40 |
| lifeless | nDuff: oh, if you did 'checkout' just do 'bzr update' ;) | 23:40 |
| nDuff | ...yes, that is doing 'bzr-packs update' | 23:40 |
| lifeless | oh! | 23:40 |
| * nDuff unbinds and does a pull | 23:41 | |
| lifeless | I swear this has regressed. | 23:41 |
| lifeless | but poolie spent time looking at it and thought it hadn't. | 23:41 |
| lifeless | don't suppose you could grab the backtrace from your ~/.bzr.log and file a bug with it ? | 23:42 |
| nDuff | can do. | 23:42 |
| lifeless | you don't need to rebuild the C extensions after pulling | 23:43 |
| lifeless | they haven't altered | 23:43 |
| nDuff | lifeless: new bug, or look for a previous instance to this to reopen? | 23:43 |
| lifeless | uhm, new please | 23:43 |
| lifeless | I'll worry about joining if it is in fact a dupe | 23:43 |
| lifeless | ok, the callgraph is starting to look tolerable for commit | 23:45 |
| lifeless | populate_from_inventory is now up to 70% time | 23:45 |
| lifeless | jam-laptop: serialisation of the new inventory is now up to 12% of commit, claimeth lsprof | 23:46 |
| lifeless | and get_inventory is 8% + 5% | 23:46 |
| nDuff | lifeless: https://bugs.launchpad.net/bzr/+bug/156462 | 23:49 |
| ubotu | Launchpad bug 156462 in bzr ""cannot lock LockDir" on update over http" [Undecided,New] | 23:49 |
| lifeless | thanks | 23:51 |
| lifeless | so whats your incremental commit time now ? | 23:51 |
| nDuff | what I'm most impressed with right now is the time to do a status with a dirty cache. don't know if it was the C extension or the update, but that's dropped *dramatically*. haven't gotten to incremental commit yet... | 23:53 |
| nDuff | (I'm doing the initial add and commit in one tree then moving the .bzr directory to a different tree with the updates already applied; consequently, the cache is always dirty at that point) | 23:55 |
| jam-laptop | reading the .bzr/checkout/dirstate file has a C extension | 23:55 |
| jam-laptop | but I wouldn't think it would effect the dirty or not... | 23:55 |
| jam-laptop | oh, depending on the update, it might include Martin's "sha_file_by_name" fi | 23:56 |
| jam-laptop | fix | 23:56 |
| ubotu | New bug: #156462 in bzr ""cannot lock LockDir" on update over http" [Undecided,New] https://launchpad.net/bugs/156462 | 23:56 |
| jam-laptop | Which for a 55k tree changed it from 8s to 6s | 23:56 |
| lifeless | lsprof I hate thee | 23:58 |
| lifeless | brb | 23:58 |
| lifeless | jam-laptop: so - can you review that patch ? | 23:58 |
| jam-laptop | lifeless: currently in review | 23:58 |
| lifeless | cool thanks | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
