igcI saw that lifeless - thanks00:03
igcI'm good with your reply00:03
lifelessyou've seen the new bundle ?00:03
igcit's come thru but I'm yet to look at it00:04
igcin email at the moment00:04
ubotuNew bug: #156003 in bazaar ""Tree transform is malformed" error with "bzr import-dsc"" [Undecided,New] https://launchpad.net/bugs/15600300:15
=== mwh_ is now known as mwh
=== kiko is now known as kiko-zzz
ubotuNew bug: #156015 in bzr "Typo in doc/en/user-guide/conflicts.txt" [Undecided,New] https://launchpad.net/bugs/15601500:51
spivTurns out gutsy's kernel doesn't like my firewall box.01:26
lifelessseen that reconcile isn't ?01:27
lifelessspiv: ^01:27
spivlifeless: no, I haven't.  I assume there's mail about it?01:28
lifelessthere's a bug01:28
* lifeless -> chemist01:28
lifelessring my mobile if you want to chat01:28
* spiv finds the bug01:29
spivpoolie: ok, I understand the problem; the bug describes the situation pretty clearly.  I'll add a test scenario for it.01:34
pooliespiv, ok01:35
pooliedo you need to narrow it down01:35
pooliewhat i mean is, we want a narrower test than reconciling the whole branch01:35
pooliedo you know what narrower test is likely to fail?01:35
spivWell, I can write a narrower test than reconciling bzr.dev, I think.01:36
spivit seems likely that creating a simple repository with about three revisions should be enough to reproduce it.01:37
spivIs that what you meant?01:38
poolieit is01:41
poolieit's just that i would have thought that's what the existing tests do01:41
pooliein other words, do you know what's untested and causing this problem?01:42
spivIt appears the "file version X is actually removed from the repo (versions with X as a parent rewritten appropriately)" case is untested.01:42
spivI'm re-reading the existing scenarios to double-check that.01:44
pooliebut wasn't that the main point of the previous patch?01:45
poolieigc, ping?01:46
igchi poolie01:46
spivHmm, FileParentsNotReferencedByAnyInventoryScenario would seem to cover this case.01:46
* spiv digs further01:46
pooliespiv, could it be to do with this being a no-op file merge (random guess)01:47
poolieigc, quick call?01:47
igcsure - I'll call now01: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.002:31
kgoetzam i doing something wrong?02:32
pooliekgoetz, are there in fact any changes in the working tree?02:32
pooliewhat does bzr status show?02:33
kgoetzbzr status returns nothing, and yes i can confirm theres been changes made.02:34
pooliewhat does bzr --version show?02:34
kgoetzBazaar (bzr) 0.11.002:34
poolieand bzr diff FILE on one modified file?02:34
kgoetzreturns nothing02:36
poolieok, this is pretty strange02:36
pooliehas this happened before?02:37
poolie0.11 is pretty old, is upgrading an option at all?02:37
kgoetzno, but this is the first time i've tried using bzr diff02:37
kgoetzyes it is, if theres decent debs02:38
pooliewould these work? http://backports.org/debian/pool/main/b/bzr/02:39
pooliei don't recall any bug like this, but that release is over a year old...02:39
kgoetzi'll check those out.02:40
kgoetz0.18 doesnt seem much newer then what i'm on though02:40
lifelesskgoetz: if status shows nothing02:44
lifelesskgoetz: are the changes actually in this tree, to files that have been added and are not ignored ?02:44
kgoetzlifeless: i dont understand the 2nd bit02:44
lifelesskgoetz: if you have ignored a file02:47
lifelessthen it can change, and bzr diff will not show it02:47
lifelesswhats the name of a file you have changed ?02:47
kgoetzlifeless: bzr info says i have 0 ignored02:48
pooliehow many versioned files?02:51
kgoetzhttp://pastebin.ca/746222 heres some of the info fromb zr02:52
kgoetz25+2 subdirs02:52
pooliewhat does bzr ls show?02:52
pooliedid you just create this with bzr init. bzr add, or did you get the branch from somewhere else?02:53
kgoetzi branched rev 39 from home a few hours ago, bzr merged rev 40 from my mate , tried to bzr diff and it didnt02:54
kgoetzjust instaleld the new bzr from backports02:55
kgoetzand because it asked, i upgraded the 'working tree format'02:56
kgoetzbzr info now has no info in it02:56
kgoetzjust 'location' and 'related branches'02:57
kgoetzand 'bzr diff' and 'bzr diff file' still return nothing02:59
kgoetzbzr --version02:59
kgoetzBazaar (bzr) 0.18.002:59
lifelessif bzr st shows nothing03:00
lifelessthen I bet that your friend has not pushed their changes03:00
lifelessso the merge had nothing to merge03:00
lifelessif you try merge now it will probably say that, our feedback has improved since 0.11.03:00
kgoetzi can see a change i didnt make:03:01
kgoetz### THIS IS BAD COUPLING - SHOULD BE RUN FROM builderrvcore (andrew) ###03:01
lifelessperhaps you committed the merge already? what does 'bzr log -r -1' show ?03:01
kgoetzwhat part of it? revo: 40; commiter: andrew03:02
lifelessI think perhaps you ran 'bzr pull' not 'bzr merge'03:02
kgoetznot sure. what would that mean?03:03
lifelesspull gives you a mirror of another branch03:03
lifelessit would mean you have what andrew has done in front of you03:03
lifelessassuming you are not andrew ;)03:03
kgoetzthen why dont i see uncommited files in bzr status?03:04
lifelessbecause there are no changes03:04
lifelessyou have a copy of andrew's branch, not your branch with his changes merged and pending review03:04
* kgoetz is confused. perhaps looking at the documentation can be this arvos timespender03:05
pooliea good way to check this would be03:05
pooliebzr missing ANDREWS_BRANCH_URL|less03:05
kgoetzsays 'branches are up to date'03:08
pooliethen it looks like you did pull from him rather than merge03:08
pooliein other words - he's already done the merge and there's nothing for you to do03:08
poolieso, be happy :)03:09
kgoetzso i have to bzr ci before i can see his stuff?03:09
poolieyou can modify a file yourself to check that diff works03:09
pooliehis stuff is in your tree now03:09
poolielifeless, could it be that in 0.11 merge did --pull by default?03:09
lifelessyou'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
lifelesspoolie: no03:09
kgoetzis there some way i can see what changes he made then?03:09
lifelesspoolie: I'm pretty sure it never did that03:09
pooliei didn't think so03:09
kgoetzoh, with switches03:09
lifelesskgoetz: 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
kgoetzlifeless: ok, thanks.03:11
kgoetzso 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
poolieyes, we removed some bits that were expensive to calculate03:12
poolieyou can get them with info -v03:12
kgoetzah sweet. not sure how committers is calculated, but i'm guessing by system name03:13
poolieyes, or you can set it with bzr whoami03:14
lifelessI'm going to go for a walk;03:15
pooliegood, enjoy03:16
lifelessI need to think through this apply delta logic03:16
pooliecan call if you want03:16
lifelessthanks, but its not one of those problems, its one of these03:17
spivI think I have a failing test for the reconcile bug.03:17
lifelessyou/spiv can ring me if you want to talk about anything03:17
pooliespiv, tell me more?03:17
spivReconcile 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
spivPerhaps 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
lifelessso I got as far as a shave before I had my answer03:22
lifelessigc: so why do you object to bugfixed ?03:24
igcit's not a word :-)03:24
lifeless85000 examples of it on google03:25
igctry answers.com03:25
lifelesswhat about answers.com ?03:26
pooliespiv, may i call?03:26
igcit's neat - dictionary definitions, synonyms, etc.03:26
spivpoolie: sure03:27
lifelessstill not getting the point :).03:27
lifelessbugfixed appears to be more than uncommon03:28
igcyou asked why I objected - I told you03:28
lifelessif not actually common03:28
igcbugfixed doesn't add anything over just saying "fixed" but whatever :-)03:28
igcit's not important right now03:28
igclifeless: commit tweaks is now approved as well. Just the spelling errors raised by Rob Weir.03:33
* igc food03:36
lifelessjam-laptop: ping04:56
jam-laptoplifeless: hi, typing one handed, though04:56
lifelessso, in dirstates memory representation04:57
lifelessare fileids utf8 ?04:57
lifelessand have we made fileids utf8 outside that yet ?04:57
jam-laptopIIRC, in memory everything is04:57
jam-laptopfile ids == utf8 in the core04:57
jam-laptopsame with rev ids04:58
jam-laptopkgoetz: this is why http://john.arbash-meinel.com/images/baby_face_01_small.jpg04:59
jam-laptoplifeless: I'm probably heading off to bed05:00
jam-laptopanything else you need?05:00
lifelesssleep well05:01
kgoetzjam-laptop: later mate. vcute05:01
lifelessjam-laptop: actually there is something05:04
lifelessjam-laptop: do you recall a function to iterate the entries within a given path:fileid pair in dirstate ?05:04
keirabentley, ping05:19
keirlifeless, did packs land?05:20
lifelesskeir: its in final review at the moment05:22
lifelesspoolie is sheparding it through, I'm hacking on a native dirstate tweak for commit05:23
keiri want to write that faster index but i have been super busy :(05:23
poolieok, my plan now is to make a patch to the pack code that makes it complain when copying a delta whose base is not copied05:42
lifelesskeir: 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
lifelesskeir: thats very nearly as valuable as code05:43
spivpoolie: FWIW, the smart server fetch does a similar sanity check.05:44
lifelessspiv: why isn't the test for insert_data_stream doing that check a per-implementation test ?05:52
lifelessspiv: or in other words, why are some implementations allowed to not check that ?05:53
poolielifeless, is create_pack_from_packs active even when fetching from knits?05:54
spivlifeless: hmm, good question.  Probably an oversight :/05:55
lifelesspoolie: no, but copying from knits copies all the data.05:56
lifelessspiv: rule of thumb: all tests should be interface tests unless they cannot apply to the interface in general.05:56
lifelesspoolie: its pack to pack thats a problem05:57
mrtupleHello all.06:07
mrtupleI 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
mrtupleTo be clear, I have a tree under source control:  ~/a06:09
mrtupleAnd I'd like to create a branch from a subtree of it...  bzr branch ~/a/path/to/subtree06:09
poolielifeless, are you sure?  i think i'm seeing problems when branching from an existing knits repository into a new pack repository06:10
pooliei'll check06:10
pooliemrtuple, can you tell us more about what you want to do with the new branch after you've made it?06:11
pooliewill it eventually merge back into the whole tree?06:11
mrtupleooh. that would be cool...06:12
lifelesspoolie: 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
mrtupleYes, 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
pooliei thought i had tested that...06:14
lifelessring 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
mrtupleThen, finally, I'd like to remerge with the original ~/a06:15
mrtuple(Once the project is complete).06:15
ubotuNew bug: #156091 in bzr "create_pack_from_packs should check that knit compression parents are present" [Undecided,New] https://launchpad.net/bugs/15609106:15
pooliespivvo, how's it going?06:38
pooliemrtuple, there's some partial support for this at the moment, but for production use you're probably better off using the whole tree fro now06:39
pooliemrtuple, if you want to try it there is an experimental 'split' command06:39
effbiaehi guys06:48
lifeless        All the changes in the delta should be changes synchronising the basis06:51
lifeless        tree with some or all of the working tree, with a change to a directory06: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 helper06:51
lifeless        for commit which is not required to handle situations that do not arise06:51
lifeless        outside of commit.06:51
lifelessthats what I'm adding to the docstring, do you think it's clear enough?06:51
effbiaei 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
AfCeffbiae: just keep a branch for each one. Then you can merge from old to new whenever you want.06:52
lifelesseffbiae: if you have the patch in a branch06:52
lifelessas AfC says :)06:52
poolielifeless, that sounds clear06:52
spivpoolie: 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
poolieis there any point keeping the more general version around, or yagni?06:53
poolie"not finding anything wrong" even though it should06:53
effbiaeAfC: so i won't have to go through resolving conflicts again?06:53
spivpoolie: right.06:54
AfCeffbiae: in theory06:54
AfCeffbiae: 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 base06:55
spivpoolie: 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
lifelesspoolie: yagni I think06:55
AfCeffbiae: meanwhile, changes to 'old' will likewise be change to that common base. You _should_ be able to then just merge from 'old' to 'new' periodically06:55
spivHmm, while this runs I'm going to pop out for a quick lunch.06:55
AfCeffbiae: it's not foolproof, but you'll find that Bazaar is incredibly robust in its merge performance. You should be alright.06:56
effbiaeAfC, thanks for all your help.  i'll try that.06:57
effbiaeAfC, do i have to bind one branch to another?07:04
AfCHuh? No07:04
AfCpoolie: (see what I mean about the bind command?)07:04
AfCeffbiae: just have each of 'old' and 'new' be a full power branch in its own directory.07:04
effbiaeAfC: i tried that, but i continue to have to resolve conflicts each time a do a merge...07:24
lifelesseffbiae: 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
AfCeffbiae: as lifeless says :)07:27
spivpoolie: so here's a funny thing.07:27
jelmerlifeless: How much faster than knits are packs?07:28
spivpoolie: the 'bad_revid' from your bug is one of unreferenced versions in that versioned file.07:28
lifelessjelmer: depends on the use case. The most dramatic difference I'veheard of is 10 minutes or so down to 30 seconds for local operations07:29
jelmerlifeless: And compared to rsync/07:29
spivpoolie: 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
lifelessjelmer: well, we already beat rsync, again depending on the scenario07:29
jelmerlifeless: For initial push?07:30
lifelessjelmer: 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
lifelessjelmer: A month or so ago I benched it over my adsl to london as 80% of rsync speed07:30
lifelessspiv: you sure? 20050919... ? Thats referenced07:31
lifelessI thought. Dagnammit.07:31
spivlifeless: hmm, reconcile thinks not anyway.07:31
spivlifeless: (Pdb) pp revision_versions.get_text_version('join-branches.txt-20050309044946-f635037a889c0388', 'robertc@robertcollins.net-20050919060519-f582f62146b0b458')07:31
spivlifeless: and independently looking at the inventory agrees.07:32
spivWell, if that file version is referenced, it's not referenced by the revision with the same name ;)07:33
lifelessspiv: indeed, it is.07:33
lifelessI mean, indeed, that revision does not itself point at it.07:33
lifelessbut clearly something does or it wouldn't be getting copied07:34
lifeless>>> i = r.get_inventory('robertc@robertcollins.net-20050919060519-f582f62146b0b458')07:34
lifeless>>> i['join-branches.txt-20050309044946-f635037a889c0388']07:34
lifelessInventoryFile('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'].revision07:34
lifelessis a good way to trap this07:35
lifelessadd a if fileid == thing and version == thing: pdb()07:35
jelmerlifeless: is this all for a smart server using packs or just a dumb server?07:36
lifelessdumb server07:36
lifelessprobably worse on the smart server today, at least until spiv gets push optimised too07:36
lifelessbecause the file_stream method uses append() to write data incrementally07:37
lifelessand that will bite. painfully.07:37
lifelessdown to 4 errors on the native update routine07:37
jelmerlifeless, ah, ok - thanks07:40
lifelesspull will be ok I think07:41
lifelessjust push will splatter chunky bits everywhere07:41
spivlifeless: 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
spivlifeless: and none referencing the "parent" that the knit claims it has.07:48
lifelessspiv: but clearly, the inventory that *should* doesn't. Grah.07:48
spivlifeless: right.07:48
lifelesseffbiae: perhaps we're confused. :(07:49
spivlifeless: oh well, happily I think I can make a test case out of this.07:49
lifelessspiv: so we need to rewrite that inventory too07:49
lifelessspiv: or the inventories that point to it incorrectly. How can we tell which is which ?07:50
spivlifeless: Will that break signed testaments?07:50
lifelessspiv: I don't recall if they refer to content purely or last-changed. content only I thought07:50
lifelessall tests passing, but the code is incomplete, so clearly so are the tests.07:52
lifelesshowever, for testing, I'm uncommenting poolies comment07:53
lifelessand we'll see how long it takes on moz07:53
spivlifeless: so, can we tell which inventories are wrong?07:54
spivlifeless: hmm, in this case it's easy07:54
lifelessfuck me, 4 seconds faster on initial commit07:54
spivlifeless: oh, sorry, nm07:55
lifeless5 seconds faster on regular incremental commit07:55
pooliethat's pretty nice07:55
lifelessreal    0m19.527s07:56
lifelessuser    0m17.473s07:56
lifelesssys     0m1.388s07:56
lifelessreal    0m12.243s07:56
lifelessuser    0m10.905s07:56
lifelesssys     0m0.568s07:56
lifelesshmm thats hard to read07:56
spivlifeless: neat07:56
lifelessthe first group of three is for 'bzr commit' with 5 new files07:56
Lo-lan-doThat's for a commit on Mozilla?07:56
lifelessthe second is 'bzr commit FILENAME'07:56
lifelesswith filename changed07:56
lifelessLo-lan-do: yes07:56
spivlifeless: so, here's a fun fact07:56
mdkejelmer: no luck - "out of memory: killed process"07:56
lifelesswithout this patch:07:56
lifelessreal    0m25.148s07:56
lifelessuser    0m22.729s07:56
lifelesssys     0m1.368s07:56
lifelessreal    0m16.834s07:56
lifelessuser    0m15.537s07:57
spivlifeless: all 12 file versions of that file have the same sha107:57
lifelesssys     0m0.776s07:57
lifelessspiv: ok07:57
lifelessmdke: run it again, as-is07:57
lifelessmdke: there is a memory leak :(, it will resume07:57
lifelesspoolie: I might finish this tomorrow, I need to write a new iterator for dirstate07:58
lifelessto handle renames with children that are not altered07:59
mdkelifeless: I will, but it looks like it didn't get very far07:59
lifelessmdke: well, start it, and what does the progress bar look like07:59
spivlifeless: so presumably then the inventories that reference that version are mistaken, rather than the inventory in the revision corresponding to that version.08:00
effbiaeexcuse me...08:05
effbiaegiven this:08:05
effbiae          A---B---C topic08:05
effbiae         /08:05
effbiae    D---E---F---G master08:05
effbiaeand between E and F, files were moved around08:05
effbiaei have to produce patches E->C, F->C, G->C08:05
effbiaebut i will be continuing development on branch 'topic' and have to continue prov08:05
effbiaeiding combinations of patches08:05
poolielifeless, just one question if you're still here08:05
pooliewhen you've replied to a review, have you either done or responded to everything in it08:06
lifelesspoolie: rofl.08:06
pooliecommon sense says yes08:06
lifelessI don't believe I have dropped items from the reviews silently.08:06
lifelessif I have elided anything, I think it was either (a) in a review from someone else, or (b) actioned and clearly trivial.08:07
lifelessI'm still staggered by the performance difference08:08
lifelessI expected 25% as an upper bound based on lsprof08:09
lifelessto get 33% is very pleasing08:09
AfCThat's great work08:09
mdkelifeless: 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 branch08:15
lifelessmdke: what is the status message ?08:16
mdkelifeless: no "=" signs, 0/9 on the first branch08:16
mdkelifeless: i guess the best way forward is for me to ask the vcs-import guys in Launchpad to do an import for me08:16
lifelessmdke: it should have english at the right hand side08:17
lifelessmdke: I'd really like to know what words are there.08:17
mdkelemme see08:18
mdke"branches/dapper:3442 0/9"08:18
mdkethat's all it has, aside from the progres bar [==              ]08:19
lifelessjelmer: ^ does that mean its finished the mapping ?08:19
lifelessmdke: there is a big mapping it does right at the start, which I think is completed for you08:19
mdkelifeless: I think you are right, it has whizzed through "Finding branches"08:20
mdkeand it has obviously downloaded quite a lot of material, the directory is 191MB already08:20
lifelessmmm, a 64Gb flash chip08:21
vilahi guys08:33
vilaWhat is the official delay between deprecation declaration and deletion from the code base ?08:34
mdkelifeless: you know, it says "branches/feisty" now, perhaps it is going a bit faster than I thought :)08:35
lifelessspiv: the inventories08:37
lifelessspiv: is the one 20050919 a merge/different exec bit/path/name/parent id ?08:37
lifelessspiv: e.g. should it have recorded a new version in the per file graph ?08:37
* spiv looks08:42
* lifeless -> counterstrike source08:43
lifelessif anyone needs my input tonight, ring my house08:44
lifelessotherwise, chat tomorrow.08:44
spivlifeless: thanks for your help.08:44
spivlifeless: 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
spivlifeless: so AFAICT it should not have recorded a new version in the per file graph.08:50
lifelessright, thats teh calculation you need to perform to decide whether its good or not.09:00
spivlifeless: I see.09:00
spivlifeless: there's an alternative to rewriting inventories...09:00
spivlifeless: 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
spivlifeless: 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
spivlifeless: 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
spivlifeless: why shouldn't the inventory entry still point to the same old file version in that case?09:07
spivlifeless: oh, it's because the per-file graph is used for merge calculations, and is punned with the knit index?09:10
* igc food09:23
indravenihi all10:13
indravenii have downloaded loggerhead source for front end of bazaar10:13
indravenibut there are no steps for installation or configurations in it10:14
indravenicould some one please help me out in configuring the loggerhead for bazaar10:14
lifelessspiv: the per file graph record all changes to that fileid, not just content changes.11:20
lifelessspiv: content reconstruction is separated in pack repositories, in principle.11:21
mwhudsonindraveni: hi, still looking for help with loggerhead?11:29
indravenimwhudson, hi yes11:29
=== mrevell is now known as mrevell-hospital
indravenimwhudson, i have installed  bzr11:34
indraveniand then downloaded loggerhead11:34
indravenibut there are no instauctions of how to install or configure loggerhead11:34
mwhudsonindraveni: there should be a loggerhead.conf.in file in the download11:34
mwhudsoncopy that to loggerhead.conf and edit it as appropriate11:35
indravenimwhudson, yes its tehre11:35
mwhudsonthen run ./start-loggerhead.py -f11:35
indraveniwhere should i copy it to ?11:35
mwhudsonloggerhead.conf in the same directory11:35
mwhudsoni'm not sure what you mean by *installing* loggerhead11:36
mwhudsontbh there's no real point11:36
indravenii  have saved the loggerhead source in my dekstop11:36
indraveniand there is a loggerhead.conf under the Desktop/loggerhead/loggerhead.conf11:37
indravenii should copy and paste this where?11:37
mwhudsonoh, if it's called loggerhead.conf already11:37
mwhudsonthen just edit it in place11:37
mwhudsonit has lots of comments in11:37
indravenimwhudson, what should i edit in this line11:39
mwhudsonhave you read the comment in the line above this line?11:40
indravenimwhudson, there is no comment above this line11:40
mwhudsonyou want to put in the file path of the directory that contains the branch you want to browse11:40
indravenimwhudson, only a line like11:40
mwhudsonindraveni: where did you get the loggerhead source from?11:40
indravenifrom http://www.lag.net/loggerhead/11:41
mwhudsonhttps://code.edge.launchpad.net/~mwhudson/loggerhead/production <- this version of the code is better11:41
indravenimwhudson, i downloaded, but it placesd all the source in a folder named production11:50
indravenican i change the folder name?11:51
indravenimwhudson, what should i spcify for cachepath11:54
mwhudsonindraveni: for now i would just comment it out11:55
mwhudsonindraveni: how big are the branches that you want to browse (in terms of number of revisions, number of files)?11:55
indraveniit may reach atleast for 10 revisions for each branch11:56
mwhudsoni'm not sure i understand11:57
mwhudson10 revisions is a tiny number11:57
indravenimwhudson, the project is in starting stage11:57
mwhudsonso don't worry about caching for now11:57
mwhudsonit's only needed for pretty huge projects these days (10000+ revisions or 5000+ files)11:58
indravenimwhudson, but if needed, how do i need to do ?11:58
mwhudsonindraveni: you would put a path to some directory there11:58
indravenimwhudson, ok, what does it do then ?11:59
mwhudsonindraveni: it caches some information about the branch11:59
indravenimwhudson, ok11:59
mwhudsonmost importantly the list of files changed between revisions11:59
indravenimwhudson, 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
mwhudsonindraveni: 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
indravenimwhudson, exacly12:01
indravenimwhudson, exactly12:01
mwhudsonindraveni: then it has comments in12:01
mwhudsonindraveni: i suggest you read them12:01
jelmerlifeless, still awake?12:16
lifelesspassing by from time to time12:19
lifelesswhats up?12:19
lifelessjelmer: ^12:19
jelmerlifeless: what's the timeframe on packs landing?12:20
lifelessjelmer: couple of days12:20
lifelessmwhudson: btw, the list copy reduction optimisation I landed for Peng, will help inventory extraction12:20
mwhudsonlifeless: for packs or generically?12:21
mwhudsonlifeless: cool, though12:21
lifelessmwhudson: but only when the two inventories are asked for separately; so doing the further optimisation I put in as FUTURE there would help a lot12:21
jelmerThe 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
mwhudsonlifeless: will still help the revision view, i expect12:21
lifelessjelmer: did you see my commit speed stuff? 10 seconds for a specific file commit in a mozilla tree in my current uncommitted code12:21
=== kiko-zzz is now known as kiko
mwhudsonthe changelog view gets a bunch of inventories all at once with getRevisionTrees, iirc12:22
lifelessmwhudson: that will not benefit as yet then12:22
mwhudsonwell, repository.revision_trees rather12:22
mwhudsonlifeless: okidoke12:22
jelmerlifeless: no, I haven't12:23
lifelessmwhudson: turns out applying 3 list copies to thousands of items long lists is expensive.12:23
lifelesswhen you do that hundreds of times12:23
lifeless16:56 < lifeless> real    0m25.148s12:23
lifeless16:56 < lifeless> user    0m22.729s12:23
lifeless16:56 < lifeless> sys     0m1.368s12:23
lifeless16:56 < lifeless> real    0m16.834s12:23
lifeless16:56 < lifeless> user    0m15.537s12:23
lifeless16:56 < lifeless> sys     0m0.776s12:23
lifelessthats packs in my branch today12:23
mwhudsonlifeless: who would have thought it12:23
lifelessfirst is commit of 5 new files12:24
lifelesssecond is commit of one changed file when we provide the file name12:24
lifeless16:55 < lifeless> real    0m19.527s12:24
lifeless16:55 < lifeless> user    0m17.473s12:24
lifeless16:55 < lifeless> sys     0m1.388s12:24
lifeless16:55 < lifeless> real    0m12.243s12:24
lifeless16:55 < lifeless> user    0m10.905s12:24
lifeless16:55 < lifeless> sys     0m0.568s12:24
mwhudsonlifeless: in the firefox tree?12:24
lifelessthats with a patch that is not quite complete to update the dirstate from the delta that commit calculates12:24
lifelessfor the same twocases12:24
lifelessyou can see it saves 5 seconds consistently12:25
lifelessmwhudson: moz tree, yes.12:25
lifeless55K files.12:25
lifelesswell, 55K paths12:25
mwhudsonlifeless: cool12:26
jelmerlifeless: 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
lifelessjelmer: as long as you take out a write group, it will still work, its just slower than the commit builder interface12:27
mwhudsonlifeless: well, it's still a bit slow really, but at least it's competitive with the competition :-)12:27
lifelessmwhudson: pffft12:27
mwhudsonprobably the right answer is not to have branches with 55k paths in12:27
lifelessmwhudson: my laptop has slow disk, and its cryted12:27
lifelessmwhudson: *crypted*12:27
mwhudsonlifeless: i know, i'm not being very realistic12:28
mwhudsonlifeless: 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 place12:30
lifelessmwhudson: well. I think we can get down to 4-5 seconds for sure.12:31
lifelessgoing lower will require...some more time12:32
lifelesson thing I'm starting to seriously consider is a serialised euler tour variant for the revision graph12:32
lifelessstored persistently and synthesised together on access12:33
lifelessbut I need a really clear head12:33
lifelessand about three industrial whiteboards12:33
mwhudsoni guess there are probably higher priorities12:34
mwhudsonlifeless: is tree building any faster with packs?12:35
lifelessits different12:35
lifelessits not optimised yet12:35
lifelessso over sftp it will be worse12:36
lifelessbut on local disk it appears a little worse, but branch is overall faster, so -for now- shrug.12:36
mwhudsonit's pretty slow with launchpad currently12:36
lifelesswell 5000 files12:38
lifelessconvert a branch to packs.12:39
lifelessthen you can see12:39
mwhudsonhm, maybe it's not as bad as i thought12:40
mwhudson20s the second time12:40
lifelessthats knit disk latency12:41
lifelessecho 1 to /proc/vm/drop_caches12:41
lifelessor whatever it is12:41
lifelessthen it will be slow again.12:41
lifeless$ cat ~/bin/drop-caches12:42
lifeless# get written data to disk (not that its guaranteed)12:42
lifeless# (drop the unmodified pages)12:42
lifelessecho 1 | sudo tee /proc/sys/vm/drop_caches12:42
lifelesspacks suffer from that less12:44
=== Mez|Away is now known as Mez
=== Mez is now known as Mez|Away
=== Mez|Away is now known as Mez
jelmerlifeless: is it correct that packs appear to be using a significant amount of memory less than knits?13:07
lifelessbut much of the tweaks should apply to knits too13:08
lifelessso if you are comparing between different versions of bzr as well as disk formats, your measurements will be suspect13:08
lifelessthere are really three interesting data points13:09
lifelessknits in last release your team tested13:09
lifelessknits in the packs branch13:09
lifelesspacks in the packs branch13:09
jelmerok, I'll keep that in mind13:10
lifeless(if you want before and after graphs I mean)13:11
jelmerI may actually do some unscientific benchmarking later, comparing to git and mercurial13:12
jelmerso far, it does at least feel as fast as things like mercurial or git13:13
Lo-lan-doIf 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-doBy the way: is 0.92 right around the corner, or should I try and install it from bzr?13:20
jelmerLo-lan-do: for packs? You'll need bzr.dev + the packs patch posted to the list or roberts packs branch13:23
Lo-lan-doNot for packs, but I'd like to check a recent bzr-svn13:24
jelmerI'm not sure what the plans for 0.92 are13:25
indravenimwhudson, hi again13:40
indravenimwhudson, i have configured all accordingly13:41
indravenimwhudson, now i ran the command ./start-loggerhead.py -f13:41
indravenimwhudson, but  the output is as follows,13:41
indravenimwhudson, its saying distribution not found13:46
indravenimwhudson, there?13:46
indraveniany one there who can solve my error in loggerhead13:55
hmelandindraveni: I've never tried loggerhead, but have you got TurboGears installed?13:59
Lo-lan-dojelmer: 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
jelmerLo-lan-do: it's not fixed for certain corner cases yet14:02
Lo-lan-doAh, but it might be fixed in my case?14:03
Lo-lan-doI'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 SVN14:04
jelmerLo-lan-do: yes, that should work now14:07
jelmerLo-lan-do: there may be some issues replaying still, but recommitting your patches should fix that14:08
Lo-lan-doThat's great :-)14:08
Lo-lan-doAehm, 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
jelmerLo-lan-do: create a separate copy of the svn branch using bzr-svn (in a different repository, or a standalone branch)14:18
jelmerand then manually apply + commit your changes from the original branch14:19
jelmermerging them from the original branch may also work, but I'm not sure14:20
* Lo-lan-do tries that14:21
Lo-lan-doMerging would be best, since I have derived branches too.14:22
Lo-lan-doUrgh, segfault14:27
Lo-lan-doDuring the "get"14:27
Lo-lan-do~/bzr.dev/bzr get svn+https://svn.gforge.org/svn/gforge/trunk gforge-trunk-new14:28
Lo-lan-do/ [                                                                          ] copying revision    1/4883Erreur de segmentation14:28
* Lo-lan-do cries14:28
jelmerwhat versions of bzr/bzr-svn?14:29
jelmerthe bzr.dev and 0.4 branches?14:30
Lo-lan-doUp-to-date from bzr.dev andbzr-svn14:30
jelmerdoes "bzr selftest svn" pass or does that segfault too?14:30
Lo-lan-doI'll check14:31
* jelmer meanwhile also tries to clone gforge trunk14:31
Lo-lan-doErm, re-trying a get seems to progress this time.14:31
Lo-lan-doIt's copying revisions (40/4883 so far)14:32
Lo-lan-doAnd the selftests seem to work, too.  Currently at 46/69114:32
Lo-lan-doI'll let both run for a while, as I need to go out for a few minutes.14:33
Lo-lan-do[691/691 in 989s, 3 known failures, 9 skipped] bzrlib.plugins.svn.tests.test_blackbox.TestBranch.test_log_empty14:52
lifelesssleep well all14:53
RotundCan I get a little help on how to use bzr to run a webpage?14:54
Lo-lan-doThe same as other SCM tools?14:56
RotundSo I did a checkout, but the site needs to basically do a bzr update14:58
Rotundbut I don't have shell access on it.  what do I do?14:58
Rotunddo I do a push?14:59
mwhudsonRotund: what access do you have?15:00
Rotundno ssh though15:01
mwhudsonrsync, perhaps?15:01
mwhudsonpush over sftp doesn't update the working tree15:01
Rotundwhat DOES update the working tree?15:03
Lo-lan-doupdate, pull15:03
mwhudsonrunning 'bzr up' on the server :/15:03
Rotundis there a secure rsync?15:04
mwhudsoni think you can rsync over sftp15:05
mwhudsonnever tried it myself, mind15:05
LeoNerdor ssh15:05
LeoNerdRSYNC_RSH=ssh rsync ...15:05
Rotundokay, well I don't have a shell15:05
Rotundcrap.  this stinks15:05
Rotundmay need to write an extension15:07
=== cprov is now known as cprov-lunch
=== mrevell-hospital is now known as mrevell
jam-laptopeffbiae: I think I saw that your questions got a little lost. If you are still around, I can try to help.15:51
jam-laptopeffbiae: A pretty darn good discussion of it is here: http://www.venge.net/mtn-wiki/DaggyFixes16:24
=== cprov-lunch is now known as cprov
jelmerLo-lan-do, any luck?17:08
Lo-lan-doThe bzr get hasn't completed yet.17:08
Lo-lan-doIt grabs about one revision every 2s, and there are ~4900 revs to grab.17:09
jelmersorry you have to go through this :-/17:10
Lo-lan-doYeah.  800 revs to go...17:10
Lo-lan-doI'll definitely save a local copy of the branch before attempting to merge and push :-)17:10
Lo-lan-do(700 left)17:14
Lo-lan-doI'll play a game or two while waiting17:15
Lo-lan-dojelmer: Trying to push the first revision now (which I merged from my old branch)18:13
Lo-lan-doIt 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-doWell, just the one, but it opens and closes it quite a lot.18:14
jelmerhas it committed anything yet?18:14
Lo-lan-doNot as far as I can tell.18:14
jelmer(in SVN)18:14
Lo-lan-doNope.  svn update in a checkout brings no new revision.18:15
Lo-lan-doOther 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-doEven the SVN checkout is "only" 139 MB18:17
Lo-lan-doOh, I know.  My fault actually.18:18
Lo-lan-doThe previous branch was actually a lightweight checkout.18:18
Lo-lan-doStill running.  I'll go for dinner, and leave bzr running for now.18:21
Lo-lan-doPushed up to revision 4884.18:51
Lo-lan-doreal    16m18.448s18:51
Lo-lan-doAlthough, 16 minutes to commit three properties...18:52
* Lo-lan-do tries to push another merged change18:53
Lo-lan-doLooks like it's going to take another quarter of an hour18:56
Lo-lan-doAh, no, 8 minutes this time.19:05
Lo-lan-doLess than 2 minutes for the third change19:12
Lo-lan-dojelmer: It looks like I'll stop bothering you for a while :-)19:12
jelmerLo-lan-do: It worked!? Nice :-)19:13
Lo-lan-doIt'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-doBut it seems to work, step by step.19:14
Lo-lan-dol=$(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 push19:14
Lo-lan-doOne commit at a time :-)19:14
gdoubleuis there a way to temporarily disable a plugin temporarily without having to remove the package from /bzrlib/plugins/ ?19:17
james_wgdoubleu: bzr --no-plugins might be too much for you.19:19
james_wgdoubleu: otherwise no, you have to move the directory.19:20
jam-laptopgdoubleu: you can put it in a subdirectory19:20
jam-laptopI use ~/.bazaar/plugins/DEACTIVATED myself19:20
gdoubleuah, --no-plugins will work for me as I don't need any other plugins at the moment either19:21
gdoubleuI didn't see that option as it doesn't appear in the output of bzr help commands19:22
gdoubleuthanks, now back to coding19:25
james_wbzr help global-options lists it.19:31
james_wlets hope that bends the space time continuum to reach him before he actually logs off.19:31
Lo-lan-doYou have an STC bender?19:32
james_wwell, it's a work in progress, I wouldn't say it bends it yet, more strokes it gently.19:32
Lo-lan-dojelmer: 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-dobzr missing doesn't list any differences, nor does diff -ruN19:48
jelmerIf weigon_ can also no longer reproduce the bug, I'll close it19:49
weigon_jelmer: at least I don't have the problem case anymore19:49
jelmerweigon_: how do you mean?19:50
weigon_I can merge and commit again after I uncomitted the change19:50
jelmerweigon_: As a workaround you mean?19:55
weigon_I havn't really turned it into a real testcase19:56
jelmerweigon_: but can you still reproduce the bug?20:02
weigon_I'm clean now20:02
VSpikeHere 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
VSpikeWith 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
VSpikeIn otherwords, does it matter to bazaar where you make the branches on your local system?20:07
jam-laptopVSpike: Bazaar doesn't care where you put them20:07
jam-laptopI might recommend putting a shared repository (bzr init-repo --trees DEPOT)20:07
jam-laptopat the root20:07
VSpikejam-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-laptopVSpike: having a shared repository means if you have 2 branches of the same code, they can share storage20:09
jam-laptopso it sort of depends how you will work20:09
VSpikeIf I do that, the locations under that repository will become important, will they not?20:09
Lo-lan-dojelmer: I'm afraid you'll have to bear with me for some time still.20:12
jelmerLo-lan-do, what's going wrong?20:13
Lo-lan-doSubversionException: ("File '/svn/gforge/trunk/gforge/debian/po/de.po' already exists", 175005)20:13
Lo-lan-doI had the new and the old branch synced with SVN just fine.20:13
Lo-lan-doI tried pulling from another branch called sid, which was originally based from trunk20:14
Lo-lan-doThen pushing to SVN.20:14
Lo-lan-doTried 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
jelmeryou can probably never directly pull from those branches that have the broken revision in their mainline20:15
jelmeronly merge them20:15
Lo-lan-doIf I merge them and then pull into them, will I still have the problem?20:15
jelmerI don't think so20:16
Lo-lan-doIt's worth a try.20:17
jelmerthe problem is that Subversion (the data in the properties) and Bazaar disagree about what the broken revision contains20:17
VSpikeI'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
jelmerLo-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 releases20:18
VSpikeDo 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
VSpikeBecause I started out going with /libA/main, libA/Branch1, /AppA/main, /AppA/BranchX and so on...20:20
jelmerLo-Lan-Do: Once you've merged your branches, I'd recommend thrashing your existing branches and continuing from a fresh clone of the Subversion branch20:20
VSpikebut will I have to do /main/libA, /main/AppA, /somebranch/libA, /somebranch/AppA instead...20:21
VSpikeand always make sure I take both the lib and the app at the same time when branching?20:21
Lo-lan-doI'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-doIOW: can I replace (or delete) a branch in a shared repository?20:22
jelmerNo, but you could start over with a clean repository that only contains the main branch imported from Subversion20:23
Lo-lan-doBlargh, even merging sid into trunk and trying to push trunk to svn fails :-(20:24
jelmerif there are things you can't merge, you could "replay" them using the replay command20:25
Lo-lan-dobzr: ERROR: unknown command "replay"20:25
jelmerLo-lan-do, it's part of the rebase plugin20:25
Lo-lan-doMore recent than 0.1 then?20:26
jelmeryes, 0.220:26
* Lo-lan-do fetches20:26
Lo-lan-do$ bzr replay -r4877 ../gforge-sid/20:29
Lo-lan-dobzr: ERROR: exceptions.NameError: global name 'replay_delta_workingtree' is not defined20:29
* jelmer sighs20:30
* Lo-lan-do pulls his hair off20:30
Lo-lan-doAnother plugin I need to fetch? :-)20:30
=== cprov is now known as cprov-out
jelmerone sec20:32
james_wVSpike: hi.20:36
james_wVSpike: 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
VSpikejames_w: I'd appreciate it, thanks20:38
james_wFirstly, 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_wor you can have branch as the term branch is used in SVN etc., to mean a separate line of development.20:39
VSpikeI'm just having trouble making a mental switch from the model I'm used to... doesn't help that I just flew +7 time zones20:39
james_wFundamentally 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_wVSpike: well, give it 7 hours until your brain catches up and all should be fine.20:40
james_wThe 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_wThere 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
VSpikeperforce is very similar to svn in overall concepts20:43
james_wThink 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_wThis 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_wThis 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_wNow, 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_wTherefore you can create a 'shared repository', which is just a box where multiple branches can store their revisions.20:47
james_wThis is what you do with the 'init-repo' command.20:47
Lo-lan-dojelmer: I added replay_delta_workingtree to the "from rebase import ..." clause for class cmd_replay, seems to work better20:47
james_wNow 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_wand 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_wso, 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_wIf 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
VSpikeOK, with you so far20:52
james_wThis 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_wThis means you would use something like bzr+ssh://central/wherever/branch120:53
james_wso branches are associated using URIs, rather than by using their position relative to a repository like in SVN.20:53
james_wso 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_wThis can lose you some convenience, but can be more flexible.20:55
james_wVSpike: happy with that? Does it answer your first set of questions?20:55
VSpikeYes thanks, I get that.  It doesn't answer one of them, but I don't think that other question was possibly a red herring anyway20:56
VSpikeSo the next big one was about relationship between two sub projects20:57
VSpikebtw, excellent explanations - thanks20: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_wthat one?20:57
VSpikeyeah, that one I think is a red herring, but I'm curious20:59
james_wok, short answer, yes it is possible.20:59
VSpikeI 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_wto answer this we need to consider the third bzr concept: working trees.21:00
james_wA working tree is the files that you have on your machine to edit and commit from.21:01
james_wMany people wouldn't distinguish this from the branch, but they are different.21:01
james_wEach working tree has a pointer to a branch that it will commit to when you commit.21:01
james_wUsually this is not obvious, as it is just the branch that is in the same directory as the working tree.21:02
james_wHowever you can separate the two physically, and even put them on two different machines.21:02
james_wDoing this separation gives you a 'lightweight checkout'.21:03
VSpikeahhh okay21:03
VSpikeI see how that would work I think21:03
james_w(Yes, there is a heavyweight checkout, I can explain them later if you like).21:03
james_wSo, you create a lightweight checkout on your local machine of the branch you want to change on your server.21:03
james_wwhen 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_wso 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_wbzrtools is a set of plugins that add sometimes useful features to bzr.21:05
james_wdoes that answer the question?21:05
VSpikeYes thanks21:06
james_wnow for the libraries question.21:07
james_wThis is a very common task, and one that we want to support.21:07
james_wThe idea is to do something like svn:externals if you have used those.21:07
james_wWe call it 'nested trees'.21:07
james_wThe format that will hopefully support doing this is in recent versions of bzr.21:08
james_wThe commands to manage this are not.21:09
jam-laptopI would interject one small thing, though21: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-laptopIn that "nested-by-value" does work21:10
jam-laptop"nested-by-reference" (svn:externals) does not21:10
jam-laptopI've done it with nested-by-value, and it actually works pretty well21:10
jam-laptopbut it means you have to be more careful when you want to pull any changes out of your subproject21:10
james_wI've never properly grasped by-value.21:11
jam-laptopjames_w: It is just merging the files into the other tree21:11
jam-laptopsuch that they maintain their history and file ids21:11
james_wBut 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-laptopjames_w: He is talking about by-reference21:11
jam-laptopbut yeah, that was a pretty strong discussion21:11
james_wjam-laptop: I helped someone get merge-into working, did you get the patch for it?21:12
jam-laptopI don't remember seeing a patch for it21:12
james_wjam-laptop: ah, that distinction wasn't clear, thanks for clarifying.21:12
VSpikeSo 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_wthat would work yes. The other alternative is to keep them separate and just branch them both whenever you need them.21:13
jam-laptopVSpike: well, *I* would have 2 separate branches, which I then merged together21:13
jam-laptopAnd I would try to make changes to the sub-project in the split-out branch21:14
jam-laptopand then merge them into the combined one21:14
VSpikeI 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 unchanging21:14
jam-laptopbut it *is* extra work21:14
james_wjam-laptop: bug #14410821:14
ubotuLaunchpad bug 144108 in bzr-merge-into "Doesn't work with 0.90 --  no attribute 'base_is_other_ancestor'" [Undecided,New] https://launchpad.net/bugs/14410821:14
james_wVSpike: yes, simplest solution is to make one branch, but it gives you less flexibility later.21:14
jam-laptopyou can always "bzr split" but your sub-project will keep tracking all the extra files from the combined project21:15
james_wjam-laptop: the problem that he mentions is what I wanted to ask you about.21:15
james_wunfortunately 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-laptopjames_w: you mean about 144108?21:15
VSpiketrue, but I think - without having used it yet - that the flexible branching in bzr will still allow me to do what I want21:16
james_wjam-laptop: yes, his final comment in the patch mail.21:16
jam-laptopI'm seeing lots of other failures trying to run with bzr.dev21:16
jam-laptopSo I'm guessing some api's changed in ways I didn't expect21:16
jam-laptopLike instead of getting a path at one point, I'm getting a number21:17
james_wthis was a while ago that we worked on it, so it might well be broken again.21:17
james_wjam-laptop: is it intened to support continually merging from the original branch?21:17
jam-laptop'merge-into' ?21:17
jam-laptopYes, you should be able to continue to merge from the original21:18
jam-laptopThe only issue is that you need unique tree roots21:18
jam-laptopor adding a file in the root of the merged project21:18
jam-laptopwill add it in the root of the combined project21:18
james_wactually I don't know whether he was doing 'merge' or 'merge-into' on subsequent tries.21:18
james_wI think that was one issue.21:19
james_wThe other was that you got some sort of conflict when a file was deleted from the merged project.21:19
james_wI said this was a limitation at the time, but I can't remember why.21:19
jam-laptopjames_w: I think the problem is that you have a rename of the file, versus a deletion21:20
jam-laptopso there is a conflict about paths21:20
jam-laptop(you have a change, they have a change that cannot apply exactly)21:20
james_wthat's the badger.21:20
jam-laptopbut I could be wrong21:20
jam-laptopI haven't tried it a lot21:20
jam-laptopI need to see if I have the latest version, something is weird21:21
james_wyeah, so every deletion is a conflict, because every file is always a rename compared to the other branch.21:21
james_wVSpike: all sorted now?21:23
VSpikejam-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-laptopbzr init project21:25
jam-laptopbzr init library21:25
jam-laptopcd project21:25
VSpikejam-laptop: I read it a few times, but I can't quite get it :) brains still lagging21:25
james_whi lifeless21:25
jam-laptopbzr merge-into../library library21:25
jam-laptopbzr commit -m "Add library to project"21:25
jam-laptopVSpike: At this point, you have a project which has merged library into it21:25
jam-laptopThen when you make changes in the standalone "library" project21:26
VSpikejames_w: on the verge of it, i think, thanks to you both21:26
jam-laptopyou can then go to "project"21:26
jam-laptopbzr merge ../library21:26
jam-laptopbzr commit -m "Merge the latest changes to library"21:26
jam-laptopVSpike: 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_wVSpike: no problem, come back if you have any more issues.21:27
VSpikejam-laptop: i do .. yep.. amazingly21:27
jam-laptopNow, if you make changes to the library21:27
jam-laptop(the copy that is in "project")21:27
jam-laptopyou have to "cherry-pick" them back into the separate 'library' project21:28
jam-laptopcd library, bzr merge -r 10..12 ../project; bzr commit -m "Cherry pick the changes out of project for library"21:28
jam-laptopThe 10 should be the last revision *before* the changes, and the 12 is the last revision *of* the changes21:29
jam-laptopit may be easier if I give more specific examples21:29
jam-laptopwhich I can do21:29
VSpikeI think I follow you21:29
jam-laptopVSpike: but if you follow me so far, it means I don't have to :)21:29
jam-laptopVSpike: Anyway, Bazaar should be smart enough to merge changes to the correct files after you do this21:29
jam-laptopthough as james_w points out, it may tree deleted files as conflicts21:30
VSpikeWhat is the advantage of doing it that way as opposed to keeping it monolithic?21:30
jam-laptopVSpike: if you want to have 4 projects which all share "library"21:30
jam-laptopOr you have philosophical reasons21:30
james_w(easy to rectify, but perhaps annoying if you do it often)21:30
jam-laptoplike wanting to version "library" independently21:30
VSpikeright, makes sense21:30
jam-laptopOne company I worked for had about 90 separate branches that built together for the project21:31
jam-laptopwhere each plugin/module was a separate branch21:31
jam-laptopbut the build stage built everything togethehr21:31
VSpikebecause 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 project21:32
jam-laptop*I* think our eventual nested-by-reference will be the "Right Way" to do it.21:32
jam-laptopVSpike: that is where having a separate library branch helps21:32
jam-laptopin that you can cherry pick those changes out21:32
jam-laptopand then just merge them into the other project21:32
jam-laptopYou actually could do that between just the monolithic projects21:33
VSpikeBut 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_wbut that wouldn't necessarily satisfy my definiton of fun for some of the cases you could hit.21:34
james_wVSpike: yes, that's correct.21:34
james_wor just fix it in the library branch and merge in to all projects, depending on where you want to fix it first.21:34
VSpikeI think the fog is clearing :)21:35
james_wVSpike: obviously any help to make by-reference nested trees work better would be appreciated :)21:37
james_wI'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-laptopTime spent getting by-reference working?21:38
jelmerLo-lan-do: thanks, now fixed upstream too21:39
lifelessjam-laptop: I have native update_basis_via_delta working.21:39
lifelessjam-laptop: 5 second win21:39
jelmerLo-lan-do, any luck using replay?21:39
jam-laptoplifeless: nice21:40
jam-laptopcertainly avoiding rebuilding the full tree is nice21:40
Lo-lan-dojelmer: Nope.  I ended up doing a shell loop around bzr diff and patch -p121:40
jam-laptoplifeless: I had a question about _make_absent21:40
jam-laptopfor bug #11461521:40
ubotuLaunchpad bug 114615 in bzr "Commit can fail and corrupt tree state after encountering some merge/conflicts" [High,Confirmed] https://launchpad.net/bugs/11461521:40
jam-laptopThe idea is that it tracks down all references to the row that is being removed21:40
Lo-lan-doI'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-laptopand marks the current value as absent21:41
jam-laptopIt has an assertion that they are not already marked as absent21:41
jam-laptopBut that breaks when you rename inside a directory21:41
jam-laptopand then remove that directory21:41
jam-laptop(so that commit unversions the whole subtree)21:41
jam-laptopBecause it finds one half of the rename, marks both sides absent, and then finds the other side21:41
jam-laptopand tries to do it again21:41
lifelessso this is in set_parent_trees?21:42
jam-laptopI take it back21:42
jam-laptopit finds one half of the rename21:42
jam-laptopand marks just that entry as absent21:42
jam-laptopthen finds the other half21:42
jam-laptopand tries to mark *both* sides absent21:42
jam-laptopBecause we don't pay attention to the working tree21:43
jam-laptopbut we do to all parents21:43
lifelessso this is a merge21:43
lifelesswe have 3 trees21:43
lifelesswhat's the kind and pointer values at the unversioned path ?21:43
lifelesspath being unversioned that is21: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-laptoplifeless: doesn't have to be a merge21:44
jam-laptopsee my last test case21:44
jam-laptopbzr init; mkdir dir; touch dir/file; bzr add; bzr commit21:44
jam-laptopbzr mv dir/file dir/z; rm -rf dir; bzr commit -m "boom"21:44
jam-laptopThat first finds that all entries in "dir/" need to be removed21:45
jam-laptopThen it finds "file"21:45
jam-laptopwhich is shown to be renamed to "dir/z"21:45
jam-laptopoh, sorry21:45
jam-laptopit finds "dir/file"21:45
jam-laptopand marks it as absent21:45
jam-laptopthen it finds "dir/z"21:45
jam-laptopand sees that it is renamed from "dir/file" (because that was the path in the basis"21:46
jam-laptopso it tries to mark dir/file absent again, and dir/z as absent21:46
jam-laptopbut it fails because dir/file was already marked absent21:46
jam-laptopMy "fix" is to just remove the assertion21:47
jam-laptopThere is another bug present21:47
jam-laptopbut that fixes the assertion error21:47
jam-laptopAnd it passes all the other tests21:47
lifelessand were considering dir/file at all because ?21:49
lifelessdir/file is not present in tree 0, unversion shouldn't be touching it21:49
jam-laptoplifeless: it is in the dirblock of 'dir'21:49
lifelesswith 'r'21:50
jam-laptop                while entry_index < len(block[1]):21:50
jam-laptop                    # Mark this file id as having been removed21:50
lifelesswhich 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 += 121:50
jam-laptopThat is 'unversion'21:50
jam-laptopYou could argue for "entry[1][0][0] in ('a', 'r')"21:50
jam-laptopWhich I could also accept21:50
lifelessI think that would be more correct21:51
jam-laptopI'll see if the tests pass with that...21:51
lifelessbecause turning an 'r' into an 'a' is a massive problem21:51
lifelesswhat if the 'r' is outside this directory21:51
lifelesswe'll lose our pointer, status will start misbehaving21:51
lifelessreal    1m30.277s21:53
lifelessuser    1m22.405s21:53
lifelesssys     0m4.648s21:53
lifelessreal    0m25.044s21:53
lifelessuser    0m17.357s21:53
lifelesssys     0m1.284s21:53
jam-laptoplifeless: do we have a specific "target" time?21:53
lifelessadding 5 files21:53
lifelessreal    0m11.646s21:53
lifelessuser    0m10.825s21:53
lifelesssys     0m0.632s21:53
lifelesschanging one and specifying it on the command line21:53
jam-laptoplifeless: 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 sys21:53
lifelessjam-laptop: I'd like to get our cpu for initial commit down to only twice tar czf21:54
jam-laptoplifeless: and what time is that?21:54
lifelessfor incremental operations, I'd like it to be roughly the time for 'st'21:54
jam-laptopsure, I'm just wondering what the actual number is21:54
lifelesson my machine, tar czf is21:55
lifelesshmm, not sure, but gzip of the tar is 35 seconds21:55
lifelessI find the vertical layout easiest to read, it may just be me21:56
jam-laptoplifeless: it is much easier to compare 2 copies21:56
jam-laptopwhen they line up21:56
lifelessright, I do that left to right21:56
jam-laptopthen you should paste them here that way :)21:56
lifelessthese three sets are not meant to be compared21:57
lifelessthey are different use cases21:57
jam-laptopit still would be easier to read :)21:57
jam-laptopwell, the fact that my IRC program uses a proportional font doesn't help21:59
lifelessso fix it ? :)22:00
jam-laptopexcept it is actually easier to read most text22:05
jam-laptop(softer on the eyes)22:05
jam-laptoplifeless: well if gzip of the tar is 35s, then you still have all the fs overhead, etc. 1m22s seems pretty close to your mark22:06
jam-laptopUnless you are just considering user/sys time?22:06
lifeless1m22 is close22:07
lifelessbut not there :)22:07
lifeless1m30 wall clock time is considerably more clearly 'not there'22:08
lifeless15 failures with this patch.22:08
Lo-lan-dojelmer: It's pushed!22:09
lifelessLarstiQ: ping22:09
jelmerLo-lan-do: cool!22:09
LarstiQlifeless: pong22:09
lifelesshow are you?22:09
lifelessis your life stabilised ?22:10
LarstiQlifeless: sorta kinda22:10
jelmerLo-lan-do: hope this bug is finally fixed then22:10
lifelessI'd love it if you got the subtree patch out and made hot sweet love to it22:10
Lo-lan-dojelmer: I hope so too22:10
jam-laptopLarstiQ: good to see you around22:11
LarstiQlifeless: anything in specific (ie, I recall a dirstate problem), or the entirety?22:11
LarstiQjam-laptop: thanks22:11
* LarstiQ wouldn't call himself 'around' just yet, but thanks nonetheless22:11
lifelessLarstiQ: there's a heated discussion on malone at the moment22:11
LarstiQlifeless: got a link to that?22:12
lifelessthat 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-laptopbug 13166722:12
ubotuLaunchpad bug 131667 in bzr "--dirstate-with-subtree is documented in the man page" [Medium,Fix committed] https://launchpad.net/bugs/13166722:12
jam-laptopLarstiQ: ^22:12
lifelessLarstiQ: the 'most recently touched' bug links are quite nice22:12
LarstiQlifeless: ah, heated would imply that, yes22:13
jam-laptoplifeless: quick question on "unversion" does it's list include child entries?22:14
jam-laptopor does it just get the top-level dir ?22:14
LarstiQlifeless: I see.22:17
lifelessjam-laptop: IIRC its handed in the user supplied path22:21
lifelessjam-laptop: so its expected to recurse22:21
jam-laptoplifeless: unversion() takes a list/set of file_ids22:21
jam-laptopit is called by the commit code22:21
jam-laptopafter commit determines things to auto-remove22:21
jam-laptopBut I can see that the code *does* recurse22:22
jam-laptopso I'm starting with that22:22
lifelessright, commit stops recursing at the top level path it finds missing22:22
LarstiQjelmer: poke22:23
jelmerLarstiQ: porrrr22:24
LarstiQjelmer: are you attending the bapc?22:24
jelmeryup, I'll be there22:24
LarstiQjelmer: ok, have time for a chat then?22:24
jelmerSure :-)22:25
lifelessbapc ?22:25
LarstiQlifeless: 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_whi LarstiQ22:26
LarstiQlifeless: 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
LarstiQlifeless: Benelux Algorithm Programming Contest22:26
LarstiQfor some reason I got drafted into a spectator team *boggle*22:26
nDufflifeless: 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
LarstiQjames_w: heya22:28
nDuffs/but the circumstances/but under the circumstances/22:28
lifelessnDuff: thanks22:29
jam-laptopnDuff: are you saying that the total real time doesn't change? Just that it moves out of user time?22:34
lifelessnDuff: oh, hangong. Are you saying that recommit got faster ?22:35
lifelessor that recommit was *slower* ?22:35
nDuffjam-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-laptopso recommit is 10x slower than initial commit22:36
jam-laptopthat is after just doing22:36
jam-laptopbzr uncommit22:36
jam-laptopbzr commit22:36
jam-laptopIs this the first commit?22:36
jam-laptopor an incremental commit22:37
nDuffright now, I'm testing with the first commit. previously, it was an incremental.22:37
jam-laptopso 4 versus 45 is for the first commit22:37
lifelessnDuff: the only thing I can think of is autopack22:38
lifelessif this is a shared repository, or even just a branch you are reusing extensively22:38
jam-laptoplifeless: a second commit shouldn't autopack, right?22:38
lifelessnDuff: have a look in ~/.bzr.log22:38
jam-laptopit would be the 10th22:39
lifelessjam-laptop: right, but a reused branch or a shared repo will, because its the global rev count not the branch reachable revcount22:39
jam-laptoplifeless: sure22:39
jam-laptopbut it would be a multiple of 1022:39
lifelessnDuff: look for autopack22:40
lifelessjam-laptop: well not strictly no. Its whenever the desired pack count is greater than the real pack count22:40
lifelessjam-laptop: the desired pack count changes for every 10 revisions; and the real increments by one every write group22:41
jam-laptopah, sure22:41
jam-laptoplifeless: I was thinking that maybe it was looking up the indexes for the files22:42
jam-laptopwhich are now non-empty22:42
jam-laptopeven though the existing revision is not in the current history22:42
jam-laptopbut autopack could also be an issue22:43
james_wit's not the hashcache being dropped again is it?22:44
jam-laptopjames_w: I don't think that would account for 45 min22:44
jam-laptopand doing22:44
lifelessjam-laptop: it will look to see that the inserted revisions are really new I think still22:44
jam-laptopbzr uncommit; bzr status22:44
jam-laptopwould restore the hash cache22:44
nDuffoh, %#$^22:44
lifelessand while the index layer in packs has different tradeoffs, 10x slower is totally unexpected22:44
jam-laptopnDuff: ?22:45
nDuffI dropped the --experimental from my "bzr init"s22:45
nDuffokay, going back and starting from scratch.22:45
lifelessnDuff: rofl22:45
lifelesswell, thank you for letting us know how long commit on knits is :)22:45
jam-laptopnDuff: is that for all your tests?22:46
jam-laptop(the 4 versus 45?)22:46
jam-laptopOr is that just for your --lsprof ones?22:46
nDuffjam-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
nDuffoh. we're logging to ~/.bzr.log, eh?22:49
nDuffI just thought of something.22:49
nDuffmy home directory is on very nonperformant network storage.22:50
nDufflarge 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_wdoes BZR_HOME work for that?22:51
lifelessI think there is also a specific pathf or that22:53
lifelesswe shouldn't be logging all that much22:53
nDufflifeless: looking through ~/.bzr.log, I at least see a case where we're logging a line per file added.22:54
nDufflifeless: on my tree, that's significant.22:54
lifelessnDuff: yes, that would be. damn, I thought we'd corrected that.22:54
lifelessits basically spam.22:54
nDufflifeless: I didn't look at when it was logged; it may be from an older version of bzr.22:55
lifelessnDuff: oh, btw, bzr commit -q is faster too22:55
* nDuff has been using -q22:55
lifelesscool :)22:55
jam-laptopas is 'bzr add -q' :)22:55
lifelessok, time to see if I've fixed all bugs22:55
lifelessfingers crossed22:56
nDuffokay, using -packs, I don't get that 4-vs-45min behavior on the initial commit.22:56
jam-laptopwow, you mean we get to set Fixed Released to all 581 bugs?22:56
jam-laptopthank you very much lifeless22:56
lifelessthou knowest what I mean22:57
jam-laptopsure, but a man can dream22:57
lifelessI had 15 failing tests22:57
jam-laptopI mean, I know you wake up early and all22:57
mkanatmwhudson: The production loggerhead branch seems to have a pretty serious memory leak.22:59
mkanatmwhudson: My process was 1.1GB after a few weeks of running.23:00
dashhi. i've got an Interesting Situation23:04
dashi have two branches and I want to merge one into the working copy of the other23:05
dashbut I don't want to merge the two branches together.23:05
dashis this even reasonable to think about?23:05
mkanatdash: That's what merge does.23:06
lifelessdash: merge followed by revert --forget-merges is likley what you want23:09
dashlifeless: --forget-merges was indeed the thing I was looking for.23:13
dashbasically, 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 eclipse23:13
lifelessjam-laptop: if you have time, a review of my just-mailed patch would be cool.23:18
dashhuh. is --forget-merges in 0.90?23:20
nDufflifeless, ~3m30s for the initial commit (and recommit) using -packs, ~20m (15m user time) for the first incremental commit.23:22
lifelessdash: no its not23:23
lifelessnDuff: thats rather bad isn't it. I've never seen incremental go *up*23:23
lifeless(over initial)23:23
lifelessassuming the incremental is a small relative change, of course.23:24
dashdang. and I thought I was doing so good, running gutsy23:24
jam-laptopcertainly I would expect it to go up if the basic diffs are drastically different23:24
jam-laptop(every file doubles in size)23:24
nDufflifeless: it's a pretty significant set of changes.23:25
lifelessnDuff: what revno of the packs branch are you using ?23:25
* nDuff goes to gather some stats on that.23:25
jam-laptopnDuff: have you done a 'make' tobuild the C extensions?23:25
lifelessthere was a bad list-copy on text construction23:25
nDufflifeless: r285123:26
lifelessnDuff: hmm, that has that fix23:26
lifeless2852 has some bzr.dev fixes, and the new incremental update to the working tree23:26
lifelessnDuff: you have 100K files right ?23:26
sabdflevening all23:26
lifelesshi sabdfl23:26
sabdflhow's tricks in this part of the world?23:27
lifelessjust sent in a review request for a 30% saving on 'bzr commit FOO'23:27
sabdflin addition to prior numbers, or a new win?23:27
lifelesssabdfl: incremental on top of the existing23:27
lifelessmeasured with packs naturally23:27
nDufflifeless: in the initial tree, about 100,000 files. after the first update, 127000 files in 25000 directories.23:28
lifelessso 15seconds to 10 seconds23:28
lifelessnDuff: ok, for this I expect 2852 will help some23:28
lifelessnDuff: but not at the scale you're seeing, something else is wrong there - jam-laptop's question about doing 'make' is a good one23:28
lifeless2852 is just reannotating back to knit format for you to pull23:29
lifelesstime for a new lsprof run with this update_basis code in place23:34
nDuffjam-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
lifelessnDuff: recommit is representative23:34
jam-laptopthat is using python to do "diff" versus "C"23:34
jam-laptopwhich on my testing can be23:34
jam-laptopversus 5ms23:34
lifelessjam-laptop: good call there :)23:34
sabdfllifeless: is there a big queue of bits to land on bzr.dev ?23:35
lifelessjam was just commenting yesterday that there is23:35
lifelesstheres about 15 branches the authors think are finished in flight at the moment23:36
sabdflyikes. hope it can all land before 0.92, before all-hands23:36
jam-laptopwell, our test suite finishes a bit faster than LP's :)23:36
sabdflyeah, 15 branches would be 15 hours of PQM happiness in LP23:38
jam-laptopjust 15?23:38
jam-laptopI thought the LP suite was closer to 2 hrs23:38
sabdflwe got the test suite down to 59 minutes at present23:38
jam-laptopAt least it felt that long when we used to be waiting behind it for bazaar merges23:38
jam-laptopI'm glad to hear that you've improved it23:38
sabdflthere's still plenty of room for improvement23:39
lifelessnDuff: pull now23:39
lifelessr2852, in the pack-repository.knits branch23:39
lifelessnDuff: I'll expect this to cut about 10 seconds off your incremental commits23:40
nDufflifeless: 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 update23:40
lifelessnDuff: oh, if you did 'checkout' just do 'bzr update' ;)23:40
nDuff...yes, that is doing 'bzr-packs update'23:40
* nDuff unbinds and does a pull23:41
lifelessI swear this has regressed.23:41
lifelessbut poolie spent time looking at it and thought it hadn't.23:41
lifelessdon't suppose you could grab the backtrace from your ~/.bzr.log and file a bug with it ?23:42
nDuffcan do.23:42
lifelessyou don't need to rebuild the C extensions after pulling23:43
lifelessthey haven't altered23:43
nDufflifeless: new bug, or look for a previous instance to this to reopen?23:43
lifelessuhm, new please23:43
lifelessI'll worry about joining if it is in fact a dupe23:43
lifelessok, the callgraph is starting to look tolerable for commit23:45
lifelesspopulate_from_inventory is now up to 70% time23:45
lifelessjam-laptop: serialisation of the new inventory is now up to 12% of commit, claimeth lsprof23:46
lifelessand get_inventory is 8% + 5%23:46
nDufflifeless: https://bugs.launchpad.net/bzr/+bug/15646223:49
ubotuLaunchpad bug 156462 in bzr ""cannot lock LockDir" on update over http" [Undecided,New]23:49
lifelessso whats your incremental commit time now ?23:51
nDuffwhat 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-laptopreading the .bzr/checkout/dirstate file has a C extension23:55
jam-laptopbut I wouldn't think it would effect the dirty or not...23:55
jam-laptopoh, depending on the update, it might include Martin's "sha_file_by_name" fi23:56
ubotuNew bug: #156462 in bzr ""cannot lock LockDir" on update over http" [Undecided,New] https://launchpad.net/bugs/15646223:56
jam-laptopWhich for a 55k tree changed it from 8s to 6s23:56
lifelesslsprof I hate thee23:58
lifelessjam-laptop: so - can you review that patch ?23:58
jam-laptoplifeless: currently in review23:58
lifelesscool thanks23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!