=== asak_ is now known as asak
lifelesshi AfC01:00
lifelessdid you get the laptop ?01:00
AfClifeless: yes we did.01:01
lifelessdoes it work well ?01:01
AfCIt's going mostly well, although get this: a livecd boots it almost no problem, but when I tried my tried and true kernel from *my* laptop, the SATA disks don't come up01:01
lifelessYou still running gentoo ?01:07
AfClifeless: yeah01:24
AfClifeless: The UK guys just helped me out01:24
AfCIt turns out its a regression in newer kernels01:24
AfCthe newer SATA code causes the old IDE code (present for cdrom) to knock out the bus or whatever01:25
AfC(the really misleading thing was that it *worked* in the livecd's 2.6.19, but failed in my transplanted 2.6.22)01:25
weigon_jelmer: would the 0.4-tree work against 0.91 ?01:29
weigon_jelmer: or do I have to upgrade to bzr 0.92-bzr too ?01:29
jelmerweigon_, no, only 0.92 at this point01:29
lifelessokies, I'm off to yum cha01:33
baguerosplease help!!!!!!!!!!!! my friend did a normal commit to bzr, it gave him a permission denied error, and then ERASED all of his files that were changed03:00
baguerosso we lost all these files with all these changes03:01
bagueroswhere did they go?!03:01
beunobagueros, a commit shouldn't erase any files03:01
beunoare you sure he just did a commit?03:01
baguerosit didnt erase them03:05
baguerosit replaced them with older versions03:06
baguerosand got rid of all the new chnages03:06
beunobagueros, have him execute:    bzr status03:09
beunoand let's see what's the current state03:09
beuno(commit shouldn't modify the working tree at all)03:09
baguerosit shows a list of modified files when i do bzr status03:10
baguerosone of the files is one that got overwritten with a previous version03:11
baguerosbut other files that happened to arent on there03:11
beunobagueros, and does "bzr log" output the revision you commited?03:12
baguerosbzr log doesnt show any of this03:13
bagueroslast thing it shows is a commit from yesterday03:13
beunobagueros, I'd recommend first to duplicate the folder, so we can try and work with a copy and don't risk loosing more information03:14
beunothen, I'd try   bzr revert03:14
beunoand see if that leaves the version you want03:14
beunoand if you could paste somewhere the output of the error, that would help03:14
* beuno goes to eat something03:20
=== abadger199_afk is now known as abadger1999
=== Mez is now known as Mez|Away
=== Mez|Away is now known as Mez
ubotuNew bug: #155281 in bzr "bzr diff causes exception (cannot load dispatch table from expat)" [Undecided,New] https://launchpad.net/bugs/15528110:50
lifelesshmm interesting bug there10:55
weigon__jelmer: with (v0.4) r742 I stuff have the clash. Keep in mind that I already have my changes committed and only want to push12:02
weigon__SubversionException: ("File already exists: filesystem '/.../mysql-proxy/db', transaction '265-1', path '/trunk/tests/suite/base/r/query_analizer1.result'", 160020)12:03
=== weigon__ is now known as weigon
jelmerweigon: this is part of a series of commits you're trying to push?12:17
jelmerweigon: if so, one of the earlier commits was probably not pushed right12:18
weigonthe file was committed with SVN to that tree already. I merged it to the local tree, adjusted it and wanted to push it back again12:19
jelmerweigon: right, but was the push already halfway finished when the error occurred?12:20
jelmer(will "svn log" show any revisions that originated from bzr?)12:20
jelmerLarstiQ: hi!12:22
jelmerLarstiQ: what's the status on nested trees?12:22
weigonjelmer: r265 is the same in svn log and bzr log, r266 is the faulty one12:26
weigonnothing of the stuff I want to commit seems to appear in the svn log12:28
weigon"$ bzr missing" shows only the r26612:30
weigonhow can I provide more (and useful) information12:30
jelmeris this a public project? if so, the bzr branch you're trying to push and an svndump of the repository would help12:31
jelmerotherwise, the current "bzr log --show-ids" (for the last few revisions) and "svn log -v"12:31
weigonjelm.. http://p.caboo.se/10932212:39
weigonjelmer: http://p.caboo.se/10932212:41
jelmerweigon: thanks12:46
jelmerweigon: it looks indeed like it pushed r265 incorrectly and now anything on top of that breaks as well12:47
weigonhow can I get it corrected ?12:49
jelmerredoing the commits in a new branch (perhaps using "bzr rebase")12:54
jelmerweigon: I'll be back in a few hours13:03
GaryvdMjelmer: Hi14:04
jelmerGaryvdM: Hi!14:05
GaryvdMhttp:// has been approved, but has not been merged14:05
GaryvdMIs there a log or something that I can look at to see why?14:05
jelmerThanks, I'll merge it14:05
GaryvdMIs it not automatic?14:05
jelmerNo, it will be (once the pqm is set up)14:06
GaryvdMOh - ok I thought it was14:06
jelmerGaryvdM, merged now14:10
Edulixwhat's the best way to install bzr-svn 0.4.2 in ubuntu?15:15
EdulixI see no deb package...15:16
Edulix I get this http://pastebin.ca/74442915:20
Edulixcan anyone please enlighten me?15:20
kikohey there15:28
* Edulix is still alive15:29
dato15:28 <lifeless> night15:29
Edulixmy bzr is the one without life15:31
kikono, I can't branch from launchpad either15:33
weigonEdulix: just place it (or a symlink) in ~/.bazaar/plugins/15:33
weigonEdulix: I run it directly from the branched bzr-svn tree locally15:34
Edulixwell I've noticed that my problem is not with bzr-svn15:34
ubotuNew bug: #155398 in bzr-eclipse "refresh log window after pull/commit" [Undecided,New] https://launchpad.net/bugs/15539816:45
jelmerEdulix, see https://bugs.launchpad.net/bzr/+bug/14110516:59
ubotuLaunchpad bug 141105 in bzr "Crash with authenticated https checkout" [High,Fix released]16:59
jelmerhi weigon16:59
jelmerweigon, any luck getting you branch fixed?17:00
Edulixjelmer: I've seen it, but that's when using bzr-svn and I'm not using it ¿?17:23
jelmerEdulix, no, that's not specific to bzr-svn17:23
jelmerEdulix: for bzr-svn there is a workaround17:23
jelmerfor other situations I'm not sure17:24
EdulixI refered to that bug in the email I've sent to bazaar@lists.ubuntu.com17:24
jelmerEdulix, that bug has been fixed in bzr.dev, the fix will be in 0.9217:33
schierbeckjelmer: hello17:35
jelmerhi schierbeck17:35
jelmerschierbeck, sorry for not responding yesterday17:35
schierbeckoh, no problem17:36
jelmerschierbeck, I hadn't seen your messages until about an hour later17:36
schierbecki've worked some more on the viz -- i think it's pretty good now17:36
jelmerI would still very much like to see some sort of switch to turn off the brokenlines behaviour17:37
schierbecki think we should wait until the revision history view (the treeview part) is completely encapsulated17:37
schierbeckpreferable in its own package17:38
schierbeckor whatever the python term is17:38
jelmerschierbeck, ok17:51
mdkehi there. can bzr-svn be used for importing svn repositories and creating bzr branches from them?17:51
mdkeah, jelmer, my lucky day17:51
jelmerschierbeck, I think we should hold off releasing until that is fixed though17:51
jelmermdke, hi17:51
jelmermdke, yes17:51
jelmermdke, importing all branches in a repository can be done using the 'svn-import' command17:51
mdkejelmer: I'm looking to import different svn branches in a repository to different bzr branches. I've started doing "bzr branch local/path/to/svn/checkout"17:52
mdkeis that the right sort of thing?17:53
jelmermdke, yes, that's what it does17:53
mdkeand is this better than using svn2bzr?17:53
schierbeckjelmer: that's okay with me17:54
jelmermdke: same thing, different codebase17:54
AnMasterhow do I roll back a merge, that is I did merge now I want to revert it, I haven't commited it yet17:54
AnMasterso revert files and remove list of pending merges from bzr st17:55
schierbeckjelmer: i'll see if i can get it fixed17:55
jelmerAnMaster: bzr revert17:55
mdkejelmer: ok, fine. After the above command can I just push straight to Launchpad, or is there an intermediate stage required?17:55
AnMasterjelmer, doesn't remove the pending merges list though17:55
AnMasterI tried it17:55
AnMasterit does revert the files17:55
jelmerAnMaster: bzr revert without any arguments17:55
AnMasterjelmer, ah ok thanks17:55
jelmermdke: yes, the created branches should just be like any other bzr branch17:56
mdkejelmer: lovely. Thanks a lot for working on that tool17:56
schierbeckjelmer: okay, i've sent in another merge request, this time removing duplicate window logic17:59
schierbeckwhen that's merged into mainline i'll sort out the other issue18:00
jelmerschierbeck: cool, thanks18:00
=== bigdo1 is now known as bigdog_
Edulixjelmer: is there any deb package with the bug fixed?20:06
weigon_jelmer: let me branch and try again20:21
weigon_jelmer: hmm, I use a shared repo containing 2 branches branched from the bzr-svn branch20:43
weigon_*hmm* wait. looks that I don't get what rebase is all about20:44
weigon_jelmer: if I rebase to another (new) branch, shouldn't the bzr info show me the new "parent" location ?20:49
lifelessabentley: ping20:57
abentleylifeless: pong21:04
lifelessI have a neighbour with a loud car that left at 5:30 this morning. Blech.21:11
lifelessSo I'm working on graph query rate21:11
lifelessTo fix the key bug, I'm changing the _search_revisions set to a dict21:12
lifelesswhich maps key:keys_that_reached_key21:12
lifelessThis doesn't help find_seen_revisions, but it makes it possible for stop_searching_any() to take points that are not the tip21:13
abentleyWhat do you mean by tip?21:15
lifelessthus a question for you - do you think it is ok to allow stop_searching_any to be expanded to 'stops searching any revisions that the searcher is or has examined21:15
lifelessoh, the tips of the search, _search_revisions.keys() in my new code; _search_revisions in bzr.dev.21:15
abentleyIt was not able to take them before?21:15
lifelessheads() currently does a find_seen_revisions() call21:16
lifelesswhich does a new graph search to calculate them21:16
abentleyAre you sure it had to use tip revisions before?  That seems entirely useless.21:17
lifelessits the second last function in graph.py21:17
lifelessand its 3 lines long; please feel free to check I'm reading it right :)21:17
lifelessYou can pass it more than the current search tips, but it doesn't stop search if it had seen something you pass unless it is a search tip.21:18
lifelessthe other thing I wanted to run past you21:19
lifelessis either changing get_parents, or adding a get_parents_dict/get_parents_2 which returns the key it was looking up as part of the answer, rather than being purely positional, so callers don't have to izip() things back together again21:20
lifelesse.g. it could return [(key, parents), (key, parents), ...]21:21
lifelessor {key:parents, key2:parents, ...} which is easier to use but slightly more expensive to create21:21
abentleyStop searching any will stop searching any of the specified revisions that are still being searched.21:22
abentleySo you want to change it so that you can pass in an ancestor of a revision being searched, yet stop that revision from being searched?21:24
lifelessfor those ancestors this search has seen only21:25
abentleyWell, I made a guess about the time/space tradeoff there.  It's possible the guess was wrong.21:25
abentleyI'm just very aware that if you track reachability, it's easy to scale with the square of the number of nodes.21:26
lifelessat the moment we have nodes^2 repeated queries21:26
lifelessand I want to change that to nodes^2 obj references in sets21:27
abentleyIsn't it better to be slow than to run out of memory?21:27
lifelessits better to be slow when you run out of memory21:28
lifelesslet me just do some quick math21:28
lifelessI expect that for a 50,0000 rev square graph, which peaks at 25,000 search tips this will hold a depth of 223 revisions per tip21:31
lifelessif each was a straight line, this is 20MB21:31
lifelesserm, mistake, brb21:31
lifeless50K nodes21:32
lifelessif thats in a square, which is the worst case for traversing non-manually generate graphs21:33
lifeless(it can fan out faster, it can't join faster)21:33
lifelessthen we'll have 224 active search tips at the widest point of the square21:34
lifelesswith an area of 25K-224 or 24.7K nodes each21:34
lifelessor 5.5Million items in sets21:35
lifelessall the content is shared key values21:35
lifelessso the overhead is just the set overhead21:35
abentleyI.e. the length of revision-ids is irrelevant.21:36
lifeless>>> for y in xrange(224):21:37
lifeless...   for x in xrange(25000-224):21:37
lifeless...     sets.setdefault(y, set()).add("%d" %x)21:37
abentleyBazaar has 2.9 K nodes, so 50K isn't a very high number.21:38
lifelessthis will setup a toy of that scenario21:38
lifeless844m is the result for that. heh.21:39
lifelessbut it may not have shared nodes. doing it again21:39
abentleyActually, Bazaar's graph has 14 K nodes.21:40
lifeless>>> keys = {}21:40
lifeless>>> for x in xrange(25000-224):21:40
lifeless...   keys[x] = "%d" % x21:40
lifeless>>> sets = {}21:40
lifeless>>> for y in xrange(22):21:40
lifeless...   sets[y] = set()21:40
lifeless...   for x in xrange(25000-224):21:40
lifeless...     sets[y].add(keys[x])21:40
lifeless31369 robertc   15   0 75632  53m 2080 S    0  2.7   0:01.05 python21:41
lifelessthis is on a 64-bit machine21:41
lifelessso I'd expect that to be half on a 32-bit machine21:41
abentleySo I would think that we should be aiming at more like 5M nodes.21:41
lifelessstartup of python on its own21:42
lifeless31376 robertc   16   0 24812 3836 2080 S    0  0.2   0:00.02 python21:42
lifelessok, let me see21:42
lifelessthats 2237 across the middle21:43
lifelessand 2500000 in the paths worst case21:43
lifeless31376 robertc   16   0  107m  39m 4148 S    0  2.0   0:00.67 python21:45
lifelessthats the size to hold the keys21:45
lifelessnow adding the sets21:45
kikovila, lifeless: ping?21:51
kikolifeless, why is bzr branch lp:python failing?21:51
kikobzr: ERROR: pycurl.error: (60, 'server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt')21:51
kikois it a pebcak?21:51
lifelessyou don't have the lp certificate installed for pcurl21:52
kikolifeless, when did this change? it did work at some point21:52
=== GaryvdM_ is now known as GaryvdM
kikodid we start using pycurl under the covers?21:52
kikolifeless, also, the lp certificate isn't self-signed21:52
lifelesswe've used pycurl for ages21:53
lifelessbut its optional21:53
kikoso what has changed?21:53
lifelessyou can remove it at it will use httplib21:53
lifelessI don't know the answer to your question21:53
kikois it on by default on gutsy maybe?21:53
kikoand it wasn't the default in feisty, perhaps?21:54
lifelessit was recommended in feisty too21:54
kikoI had never seem a complaint, and today I've seen quite a few21:54
lifelessI don't know why the validation is failing21:55
lifelessit may be you don't have the right ca roots available ?21:55
lifelessabentley: ok, I killed that a 2mumble gig21:55
kikoit's weird, I agree, but I shouldn't need to do anything to get it to work, I expect21:55
kikoso uninstalling pycurl would be a workaround for a problem I don't yet know of21:56
lifelessthe only difference for us, in 0.91 is that httplib doesn't do cert validation21:56
kikoI don't have the ca-certificates file21:57
kikolifeless, do you have one?21:57
lifelessthis is a clean install of gutsy21:57
lifelesslet me check fisty21:57
lifelessI have one on fisty21:58
kikothis is highly suspicious21:58
lifelessI am not aware of creating one by hand21:58
kikome neither21:58
kikolifeless, "bzr branch lp:python" doesn't work for you either right?21:59
lifelessdpkg -S that file reports nothing21:59
lifelessso its not package owned21:59
kikosame here21:59
lifeless(on fisty, where the file exists)21:59
lifelessbzr: ERROR: Connection error: curl connection error (problem with the SSL CA cert (path? access rights?))22:00
kikodoes it work on feisty?22:00
lifelesswaiting for it to tell me :)22:00
lifelesslooks like it, link is saturating22:00
lifelessyeah working on feisty22:02
kikoit doesn't work on /my/ feisty box22:03
kikoso it's definitely related to the presence of that file (as the error message does point out kindly)22:03
lifelessabentley: so, looks like my smallest-approach fix, while it will work for all our current users, will blow up nicely on 500K revision scenarios.22:03
abentleyHmm.  It seems like it should be possible to combine the two approaches: only list some revisions in the reachability index, and then do a breadth search on those.22:05
=== kiko is now known as kiko-fud
abentleyThat would allow us a fixed size for the reachability index, and mean that we'd trade speed for size as we exceeded that.22:08
lifelessI've just instrumented next()  alittle22:08
lifelesshighest figure I'm seeing with bzr is 120 on a merge commit so far22:08
lifelessI agree that some tradeoff is reachable22:13
lifelessthis is a cache thrashing nightmare though22:13
lifelessan interesting observation or two22:14
lifelessone is that for a given breadth first search, many of the revisions in each search tip should be common22:15
jelmerEdulix: of bzr? not yet22:15
jelmerweigon_, no, rebase won't change the parent location22:15
lifelessa bit array would be useful22:18
weigon_jelmer: but the idea was that I do branch from the svn-tree again and throw the old branch away, right ?22:19
weigon_I don't see the full picture yet to get it all running smooth again22:20
jelmerweigon_: if you can do that, there's no need for rebase22:20
jelmersimply rebuild your branch and then push it again22:20
weigon_I have svn -> (local) svn-bzr for pushing -> 2 bzr branches for development22:21
weigon_the svn-tree itself is remote and not under my control. The svn-bzr one and the other local bzr trees are22:22
weigon_I can throw the svn-bzr tree away and run bzr branch svn+ssh://... again, no problem22:22
jelmerthe 2 bzr branches are based on the svn-bzr one I guess?22:22
jelmerand the svn-bzr one is up to date with svn?22:23
abentleylifeless: I think my reasoning for the get_parents return value was that it handled ghosts clearly.22:23
weigon_currently it is the one I can't push back from22:23
abentleyIf you query about a ghost, you'll get None back in the corresponding location.22:23
Vantage13is there a way in bzr to switch your current working tree to another branch w/o creating a new directory to keep the two branches in?22:23
weigon_so it is up to date (bzr pull), but not pushable22:23
jelmerweigon_: you may be able to run 'bzr rebase <svn-url>' to fix the local branch22:24
abentleyReturning a dictionary where ghosts keys mapped to None seemed confusing, as did returning a dictionary where ghost keys were not present.22:25
weigon_on the bzr-svn'ed branch ?22:25
jelmerweigon_: you may have to get rid of r265 though, and that would mean having to recommit r265 and all revisions that followed it..22:25
jelmerweigon_: yes22:25
Edulixdoes bzr branch https://launchpad.net/dark-extermination works for you? I get "bzr: ERROR: Connection error: curl connection error (problem with the SSL CA cert (path? access rights?))"22:25
jelmerweigon_: bzr-rebase 0.2 (or the current version in bzr)22:25
Edulixi'm using bzr.dev by the way22:26
weigon_jelmer: I run trunk22:26
jelmerweigon_: ok, that should be fine22:26
weigon_I usually just symlink the bzr'ed plugins into .bazaar/plugins/22:26
Edulix(oh and that project is in revision 0, not many files to download ;))22:26
abentleyIn principle, a different value than None could be used for this situation, and I think that would work pretty well.22:26
weigon_jelmer: bzr: ERROR: Already rebased on SvnBranch('svn+ssh://... isn't that expected ?22:27
jelmerweigon_: yeah, kinda :-/22:28
weigon_let me trash the svn-bzr tree and check it out again22:28
jelmerweigon_: looks like you'll have to get rid of r265 by recommitting r265 and all revisions that followed it22:28
hmelandVantage13: You want "bzr switch", but I think that assumes you are working with lightweight checkouts.22:28
weigon_jelmer: no problem22:28
jelmerweigon_: in the svn-bzr tree and the bzr trees22:28
Vantage13hmeland: thanks22:29
weigon_jelmer: getting rid of == uncommit ?22:29
jelmerweigon_, yes, that should be sufficient22:29
lifelessabentley: I can see some callers caring; doing a dict with key:None, or tuples (key, None) will also handle that.22:32
lifelessI don't think a dict mapping to None is any more or less confusing than None as a positional return value22:32
lifelessI'm going to go draw on the whiteboard for a bit22:33
Vantage13Workflow question.  Let's say I'm a developer working on multiple features for a release of a projects.  So I make a branch of our most recent version to record my changes that will go into the next release.  Now let's say I've got 5 features I'm adding.  I get them done, commit them all locally, but then let's say a feature gets pulled.  Is there a way to identify code belonging to a feature so that it can be easily added/removed without creating a b22:47
lifelessabentley: I think I have a good answer no22:47
lifelessabentley: heads() is basically defined as 'find what is reachable from each other'22:48
lifelessso rather than a breadth first searcher, I propose a class that is able to answer reachability efficiently, and a single breadth first search across all nodes at once22:48
lifelesswhich search needs to give all the parent data back to update this reachability answering class22:49
lifelessfor answering reachability, one answer is to cache the key:parent answers as we get them22:50
lifelessand I'll do this in the initial refactoring, which will make knits and packs the same speed here, if we cache that in the repository state or somewhere.22:50
lifelessI'll then move onto a more complex answer, which is to turn 'reachable' into a range query22:51
mdkeif bzr-svn breaks in the middle, is there a way to carry on where it left off, rather than starting from scratch? it takes rather a long time...22:52
abentleylifeless: That sounds good.22:52
lifelesswhere a key X is reachable from Y, if X is > y0 and <y122:52
jelmermdke: just running the same command again should make it continue22:52
lifelessso we start with a forest of range structures, and then as nodes find each other we join them22:52
mdkejelmer: I'll try again, it didn't seem to work last time22:53
jelmermdke, what version of bzr-svn are you using?22:53
abentleyI don't know what y0 and y1 are.22:53
lifelessin a range query solution each key is in the vector twice22:53
lifelessa low value and a high value22:53
mdkejelmer: whatever is in gutsy22:53
lifelessI think it becomes 2N times, where N is the number of branches made from it actually. I'm still sketching this specific bit.22:54
mdkeor, to be precise, 0.4.1-1422:54
lifelessanyhow, I'll start with the suppport refactoring first.22:54
mdkecough. 0.4.1-122:54
jelmermdke: what exactly doesn't work? It starts over?22:55
mdkeseemed to, yeah. I'll just try it again22:55
mdkejelmer: now it says that there is a lock22:56
jelmermdke: try running 'bzr break-lock' on the bzr repository22:56
mdkejelmer: it hasn't returned me to the prompt yet, should I wait?22:56
lifelessabentley: its simple to describe for trees, so I'll do so. Do you know what an Euler tour is ?22:56
jelmermdke: 0.4.1 is not the latest, but I don't think there's any bugs fixed wrt svn-import since22:57
jelmermdke: yes22:57
mdkeok, waiting22:57
weigonjelmer: looks like I'm fine now22:58
jelmerit pushed ok?22:59
weigonI uncommitted and now have to reapply the patch23:00
weigonshould be fine now23:00
weigonbut first I'll upgrade to 7.10 :)23:00
weigonafter the uncommit the push was empty (as expected)23:00
lifelessabentley: anyhow, an euler tour is the record of the nodes a depth first search goes to23:05
lifelessso for A:[] its 'A->A'23:05
lifelessfor A:[B], B:[], its 'A->B->A'23:05
lifelessA:[B,C], B:[C], C:[] its 'A->B->C->B->A->C->A'23:06
lifeless(this is a slightly modified tour'23:07
mdkejelmer: hmm. perhaps it is carrying on. It says "copying revisions" and it started at 1/x but x is a lower number than it was when I ran the thing before.23:07
lifelessanyhow, if you put the keys in an array: [A,B,C,B,A,C,A] and index into that from the keys: A:[0,4,6], B:[1,2], C:[2,5]23:08
lifelesswe need to annotate this data a little more, because this double-entry is what I'm thinking about still23:09
lifelessbut in principle, C is reachable from B because 2>1 and 2<323:10
lifeless(the B list there should be B:[1,3]23:10
mdkejelmer: oh dear, now a backtrace :(23:11
mdkeI'll try and get a dump of the repository and do it on that rather than doing it from the remote server23:12
jelmermdke: yes, that's the way it continues23:14
jelmermdke, can you paste it somewhere?23:14
jelmerthat'll use the same logic23:15
mdkejelmer: I can't paste it right now, I can't seem to scroll up in my terminal, and it's past my bedtime. I'll try running it overnight, but I might end up asking the LP guys to do the import for me if I struggle...23:17
mdkejelmer: thanks for all your help so far23:17
jelmergoodnight :-)23:18
jelmermdke: in either case, I would be interested in seeing the backtrace23:18
jelmerI don't think there are any listed pull bugs in bzr-svn at the moment23:19
lifelessabentley: and I know know why we access to much history23:35
lifelessabentley: you stop searching a node (and its children) when all searches reach a node; this is wrong. We should stop considering a search *relevant* when we reach it from all start points, but we have to keep reading it to avoid hitting all history23:36
lifelessA:[CD], B:[D], C:[E], D:[E]23:37
lifelessfirst round lookup gives D in common23:37
lifelessbut if we dont get D's parents, we'll follow E all the way to the origin23:37
abentleyWell, I knew it was wrong in terms of giving inaccurate results, but I didn't realize it would also cause this problem.23:39
abentleyBut which algorithm are we talking about?23:39
abentleyOr which method specifically?23:40
lifelessthe results are accurate23:52
lifelessbut it accesses too much data23:52
lifelessin the current code; stop_searching_any() is the culprit23:53
lifelessit should remove the nodes given as reasons to continue searching23:54
lifelessbut it should not remove them from things to continue querying23:54

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