[01:00] <lifeless> -
[01:00] <lifeless> hi AfC
[01:00] <lifeless> did you get the laptop ?
[01:01] <AfC> lifeless: yes we did.
[01:01] <lifeless> does it work well ?
[01:01] <AfC> It'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 up
[01:01] <AfC> {sigh}
[01:07] <lifeless> :(
[01:07] <lifeless> You still running gentoo ?
[01:24] <AfC> lifeless: yeah
[01:24] <AfC> lifeless: The UK guys just helped me out
[01:24] <AfC> It turns out its a regression in newer kernels
[01:25] <AfC> the newer SATA code causes the old IDE code (present for cdrom) to knock out the bus or whatever
[01:25] <lifeless> ouch
[01: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:29] <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] <jelmer> weigon_, no, only 0.92 at this point
[01:29] <jelmer> (bzr.dev0
[01:33] <lifeless> okies, I'm off to yum cha
[01:33] <lifeless> laterz
[03:00] <bagueros> please 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 changed
[03:01] <bagueros> so we lost all these files with all these changes
[03:01] <bagueros> where did they go?!
[03:01] <beuno> bagueros, a commit shouldn't erase any files
[03:01] <beuno> are you sure he just did a commit?
[03:05] <bagueros> yes
[03:05] <bagueros> positive
[03:05] <bagueros> it didnt erase them
[03:06] <bagueros> it replaced them with older versions
[03:06] <bagueros> and got rid of all the new chnages
[03:09] <beuno> bagueros, have him execute:    bzr status
[03:09] <beuno> and let's see what's the current state
[03:09] <beuno> (commit shouldn't modify the working tree at all)
[03:10] <bagueros> it shows a list of modified files when i do bzr status
[03:11] <bagueros> one of the files is one that got overwritten with a previous version
[03:11] <bagueros> but other files that happened to arent on there
[03:12] <beuno> bagueros, and does "bzr log" output the revision you commited?
[03:13] <bagueros> bzr log doesnt show any of this
[03:13] <bagueros> last thing it shows is a commit from yesterday
[03:14] <beuno> bagueros, I'd recommend first to duplicate the folder, so we can try and work with a copy and don't risk loosing more information
[03:14] <beuno> then, I'd try   bzr revert
[03:14] <beuno> and see if that leaves the version you want
[03:14] <beuno> and if you could paste somewhere the output of the error, that would help
[03:20]  * beuno goes to eat something
[10:50] <ubotu> New bug: #155281 in bzr "bzr diff causes exception (cannot load dispatch table from expat)" [Undecided,New] https://launchpad.net/bugs/155281
[10:55] <lifeless> hmm interesting bug there
[12:02] <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 push
[12:03] <weigon__> SubversionException: ("File already exists: filesystem '/.../mysql-proxy/db', transaction '265-1', path '/trunk/tests/suite/base/r/query_analizer1.result'", 160020)
[12:17] <jelmer> weigon: this is part of a series of commits you're trying to push?
[12:18] <jelmer> weigon: if so, one of the earlier commits was probably not pushed right
[12:19] <weigon> the file was committed with SVN to that tree already. I merged it to the local tree, adjusted it and wanted to push it back again
[12:20] <jelmer> weigon: 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:22] <jelmer> LarstiQ: hi!
[12:22] <jelmer> LarstiQ: what's the status on nested trees?
[12:26] <weigon> jelmer: r265 is the same in svn log and bzr log, r266 is the faulty one
[12:28] <weigon> nothing of the stuff I want to commit seems to appear in the svn log
[12:30] <weigon> "$ bzr missing" shows only the r266
[12:30] <weigon> how can I provide more (and useful) information
[12:31] <jelmer> is this a public project? if so, the bzr branch you're trying to push and an svndump of the repository would help
[12:31] <jelmer> otherwise, the current "bzr log --show-ids" (for the last few revisions) and "svn log -v"
[12:39] <weigon> jelm.. http://p.caboo.se/109322
[12:41] <weigon> jelmer: http://p.caboo.se/109322
[12:46] <jelmer> weigon: thanks
[12:47] <jelmer> weigon: it looks indeed like it pushed r265 incorrectly and now anything on top of that breaks as well
[12:49] <weigon> how can I get it corrected ?
[12:54] <jelmer> redoing the commits in a new branch (perhaps using "bzr rebase")
[13:03] <jelmer> weigon: I'll be back in a few hours
[14:04] <GaryvdM> jelmer: Hi
[14:05] <jelmer> GaryvdM: Hi!
[14:05] <GaryvdM> http://145.97.196.157:8089/request/%3C1192969205.16037.4.camel%40dasch.egmont-kol.dk%3E has been approved, but has not been merged
[14:05] <GaryvdM> Is there a log or something that I can look at to see why?
[14:05] <jelmer> Thanks, I'll merge it
[14:05] <GaryvdM> Is it not automatic?
[14:06] <jelmer> No, it will be (once the pqm is set up)
[14:06] <GaryvdM> Oh - ok I thought it was
[14:10] <jelmer> GaryvdM, merged now
[14:10] <GaryvdM> Cool
[14:28] <lifeless> ight
[14:28] <lifeless> night
[15:15] <Edulix> what's the best way to install bzr-svn 0.4.2 in ubuntu?
[15:16] <Edulix> I see no deb package...
[15:20] <Edulix>  I get this http://pastebin.ca/744429
[15:20] <Edulix> can anyone please enlighten me?
[15:28] <kiko> hey there
[15:28] <kiko> lifeless?
[15:29]  * Edulix is still alive
[15:29] <dato> 15:28 <lifeless> night
[15:31] <Edulix> oh
[15:31] <Edulix> :P
[15:31] <Edulix> my bzr is the one without life
[15:33] <kiko> no, I can't branch from launchpad either
[15:33] <weigon> Edulix: just place it (or a symlink) in ~/.bazaar/plugins/
[15:34] <weigon> Edulix: I run it directly from the branched bzr-svn tree locally
[15:34] <Edulix> well I've noticed that my problem is not with bzr-svn
[16:45] <ubotu> New bug: #155398 in bzr-eclipse "refresh log window after pull/commit" [Undecided,New] https://launchpad.net/bugs/155398
[16:59] <jelmer> Edulix, see https://bugs.launchpad.net/bzr/+bug/141105
[16:59] <ubotu> Launchpad bug 141105 in bzr "Crash with authenticated https checkout" [High,Fix released]
[16:59] <jelmer> hi weigon
[17:00] <jelmer> weigon, any luck getting you branch fixed?
[17:23] <Edulix> jelmer: I've seen it, but that's when using bzr-svn and I'm not using it ¿?
[17:23] <jelmer> Edulix, no, that's not specific to bzr-svn
[17:23] <jelmer> Edulix: for bzr-svn there is a workaround
[17:24] <jelmer> for other situations I'm not sure
[17:24] <Edulix> ok
[17:24] <Edulix> I refered to that bug in the email I've sent to bazaar@lists.ubuntu.com
[17:33] <jelmer> Edulix, that bug has been fixed in bzr.dev, the fix will be in 0.92
[17:35] <schierbeck> jelmer: hello
[17:35] <jelmer> hi schierbeck
[17:35] <jelmer> schierbeck, sorry for not responding yesterday
[17:36] <schierbeck> oh, no problem
[17:36] <jelmer> schierbeck, I hadn't seen your messages until about an hour later
[17:36] <schierbeck> :)
[17:36] <schierbeck> i've worked some more on the viz -- i think it's pretty good now
[17:36] <jelmer> cool
[17:37] <jelmer> I would still very much like to see some sort of switch to turn off the brokenlines behaviour
[17:37] <schierbeck> i think we should wait until the revision history view (the treeview part) is completely encapsulated
[17:38] <schierbeck> preferable in its own package
[17:38] <schierbeck> or whatever the python term is
[17:51] <jelmer> schierbeck, ok
[17:51] <mdke> hi there. can bzr-svn be used for importing svn repositories and creating bzr branches from them?
[17:51] <mdke> ah, jelmer, my lucky day
[17:51] <jelmer> schierbeck, I think we should hold off releasing until that is fixed though
[17:51] <jelmer> mdke, hi
[17:51] <jelmer> mdke, yes
[17:51] <jelmer> mdke, importing all branches in a repository can be done using the 'svn-import' command
[17:52] <mdke> jelmer: 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:53] <mdke> is that the right sort of thing?
[17:53] <jelmer> mdke, yes, that's what it does
[17:53] <mdke> rock
[17:53] <mdke> and is this better than using svn2bzr?
[17:54] <schierbeck> jelmer: that's okay with me
[17:54] <jelmer> mdke: same thing, different codebase
[17:54] <AnMaster> how do I roll back a merge, that is I did merge now I want to revert it, I haven't commited it yet
[17:55] <AnMaster> so revert files and remove list of pending merges from bzr st
[17:55] <schierbeck> jelmer: i'll see if i can get it fixed
[17:55] <jelmer> AnMaster: bzr revert
[17:55] <mdke> jelmer: ok, fine. After the above command can I just push straight to Launchpad, or is there an intermediate stage required?
[17:55] <AnMaster> jelmer, doesn't remove the pending merges list though
[17:55] <AnMaster> I tried it
[17:55] <AnMaster> it does revert the files
[17:55] <jelmer> AnMaster: bzr revert without any arguments
[17:55] <AnMaster> jelmer, ah ok thanks
[17:56] <jelmer> mdke: yes, the created branches should just be like any other bzr branch
[17:56] <mdke> jelmer: lovely. Thanks a lot for working on that tool
[17:59] <schierbeck> jelmer: okay, i've sent in another merge request, this time removing duplicate window logic
[18:00] <schierbeck> when that's merged into mainline i'll sort out the other issue
[18:00] <jelmer> schierbeck: cool, thanks
[18:00] <schierbeck> np
[20:06] <Edulix> jelmer: is there any deb package with the bug fixed?
[20:21] <weigon_> jelmer: let me branch and try again
[20:43] <weigon_> jelmer: hmm, I use a shared repo containing 2 branches branched from the bzr-svn branch
[20:43] <lifeless> moin
[20:44] <weigon_> *hmm* wait. looks that I don't get what rebase is all about
[20:49] <weigon_> jelmer: if I rebase to another (new) branch, shouldn't the bzr info show me the new "parent" location ?
[20:57] <lifeless> abentley: ping
[21:04] <abentley> lifeless: pong
[21:11] <lifeless> hi
[21:11] <lifeless> I have a neighbour with a loud car that left at 5:30 this morning. Blech.
[21:11] <lifeless> So I'm working on graph query rate
[21:12] <lifeless> To fix the key bug, I'm changing the _search_revisions set to a dict
[21:12] <lifeless> which maps key:keys_that_reached_key
[21:13] <lifeless> This doesn't help find_seen_revisions, but it makes it possible for stop_searching_any() to take points that are not the tip
[21:15] <abentley> What do you mean by tip?
[21:15] <lifeless> thus 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 examined
[21:15] <lifeless> oh, the tips of the search, _search_revisions.keys() in my new code; _search_revisions in bzr.dev.
[21:15] <abentley> It was not able to take them before?
[21:16] <lifeless> indeed
[21:16] <lifeless> heads() currently does a find_seen_revisions() call
[21:16] <lifeless> which does a new graph search to calculate them
[21:17] <abentley> Are you sure it had to use tip revisions before?  That seems entirely useless.
[21:17] <lifeless> its the second last function in graph.py
[21:17] <lifeless> and its 3 lines long; please feel free to check I'm reading it right :)
[21:18] <lifeless> You 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:19] <lifeless> the other thing I wanted to run past you
[21:20] <lifeless> is 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 again
[21:21] <lifeless> e.g. it could return [(key, parents), (key, parents), ...]
[21:21] <lifeless> or {key:parents, key2:parents, ...} which is easier to use but slightly more expensive to create
[21:22] <abentley> Stop searching any will stop searching any of the specified revisions that are still being searched.
[21:24] <abentley> So 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] <lifeless> yes
[21:25] <lifeless> for those ancestors this search has seen only
[21:25] <abentley> Well, I made a guess about the time/space tradeoff there.  It's possible the guess was wrong.
[21:26] <abentley> I'm just very aware that if you track reachability, it's easy to scale with the square of the number of nodes.
[21:26] <lifeless> right
[21:26] <lifeless> at the moment we have nodes^2 repeated queries
[21:27] <lifeless> and I want to change that to nodes^2 obj references in sets
[21:27] <abentley> Isn't it better to be slow than to run out of memory?
[21:28] <lifeless> its better to be slow when you run out of memory
[21:28] <lifeless> let me just do some quick math
[21:31] <lifeless> I 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 tip
[21:31] <lifeless> if each was a straight line, this is 20MB
[21:31] <lifeless> erm, mistake, brb
[21:32] <lifeless> 50K nodes
[21:33] <lifeless> if thats in a square, which is the worst case for traversing non-manually generate graphs
[21:33] <lifeless> (it can fan out faster, it can't join faster)
[21:34] <lifeless> then we'll have 224 active search tips at the widest point of the square
[21:34] <lifeless> with an area of 25K-224 or 24.7K nodes each
[21:35] <lifeless> or 5.5Million items in sets
[21:35] <lifeless> all the content is shared key values
[21:35] <lifeless> so the overhead is just the set overhead
[21:36] <abentley> I.e. the length of revision-ids is irrelevant.
[21:37] <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:38] <abentley> Bazaar has 2.9 K nodes, so 50K isn't a very high number.
[21:38] <lifeless> this will setup a toy of that scenario
[21:39] <lifeless> 844m is the result for that. heh.
[21:39] <lifeless> but it may not have shared nodes. doing it again
[21:40] <abentley> Actually, 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" % x
[21:40] <lifeless> ...
[21: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:41] <lifeless> ...
[21:41] <lifeless> 31369 robertc   15   0 75632  53m 2080 S    0  2.7   0:01.05 python
[21:41] <lifeless> this is on a 64-bit machine
[21:41] <lifeless> so I'd expect that to be half on a 32-bit machine
[21:41] <abentley> So I would think that we should be aiming at more like 5M nodes.
[21:42] <lifeless> startup of python on its own
[21:42] <lifeless> 31376 robertc   16   0 24812 3836 2080 S    0  0.2   0:00.02 python
[21:42] <lifeless> ok, let me see
[21:43] <lifeless> thats 2237 across the middle
[21:43] <lifeless> and 2500000 in the paths worst case
[21:45] <lifeless> 31376 robertc   16   0  107m  39m 4148 S    0  2.0   0:00.67 python
[21:45] <lifeless> thats the size to hold the keys
[21:45] <lifeless> now adding the sets
[21:51] <kiko> vila, lifeless: ping?
[21:51] <kiko> lifeless, why is bzr branch lp:python failing?
[21:51] <lifeless> hmm?
[21:51] <kiko> bzr: ERROR: pycurl.error: (60, 'server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt')
[21:51] <kiko> is it a pebcak?
[21:52] <lifeless> you don't have the lp certificate installed for pcurl
[21:52] <kiko> lifeless, when did this change? it did work at some point
[21:52] <kiko> did we start using pycurl under the covers?
[21:52] <kiko> lifeless, also, the lp certificate isn't self-signed
[21:53] <lifeless> we've used pycurl for ages
[21:53] <lifeless> but its optional
[21:53] <kiko> so what has changed?
[21:53] <lifeless> you can remove it at it will use httplib
[21:53] <kiko> hmmm
[21:53] <lifeless> I don't know the answer to your question
[21:53] <kiko> is it on by default on gutsy maybe?
[21:53] <lifeless> yes
[21:54] <kiko> and it wasn't the default in feisty, perhaps?
[21:54] <lifeless> it was recommended in feisty too
[21:54] <kiko> odd.
[21:54] <kiko> I had never seem a complaint, and today I've seen quite a few
[21:54] <lifeless> so
[21:55] <lifeless> I don't know why the validation is failing
[21:55] <lifeless> it may be you don't have the right ca roots available ?
[21:55] <lifeless> abentley: ok, I killed that a 2mumble gig
[21:55] <kiko> it's weird, I agree, but I shouldn't need to do anything to get it to work, I expect
[21:56] <kiko> so uninstalling pycurl would be a workaround for a problem I don't yet know of
[21:56] <lifeless> yes
[21:56] <lifeless> the only difference for us, in 0.91 is that httplib doesn't do cert validation
[21:57] <kiko> aha
[21:57] <kiko> I don't have the ca-certificates file
[21:57] <kiko> lifeless, do you have one?
[21:57] <kiko> /etc/ssl/certs/ca-certificates.crt?
[21:57] <lifeless> no
[21:57] <kiko> hmmmmm
[21:57] <lifeless> this is a clean install of gutsy
[21:57] <lifeless> let me check fisty
[21:58] <lifeless> I have one on fisty
[21:58] <kiko> this is highly suspicious
[21:58] <lifeless> I am not aware of creating one by hand
[21:58] <kiko> me neither
[21:58] <kiko> hmmm
[21:59] <kiko> lifeless, "bzr branch lp:python" doesn't work for you either right?
[21:59] <lifeless> dpkg -S that file reports nothing
[21:59] <lifeless> so its not package owned
[21:59] <kiko> same here
[21:59] <lifeless> (on fisty, where the file exists)
[21:59] <kiko> hmmmmmmm
[22:00] <lifeless> bzr: ERROR: Connection error: curl connection error (problem with the SSL CA cert (path? access rights?))
[22:00] <kiko> hmmmmm
[22:00] <kiko> does it work on feisty?
[22:00] <lifeless> waiting for it to tell me :)
[22:00] <kiko> heh
[22:00] <lifeless> looks like it, link is saturating
[22:00] <kiko> odd.
[22:01] <kiko> update-ca-certificates
[22:02] <lifeless> yeah working on feisty
[22:03] <kiko> it doesn't work on /my/ feisty box
[22:03] <kiko> so it's definitely related to the presence of that file (as the error message does point out kindly)
[22:03] <lifeless> abentley: 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:05] <abentley> Hmm.  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:08] <abentley> That 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] <lifeless> I've just instrumented next()  alittle
[22:08] <lifeless> highest figure I'm seeing with bzr is 120 on a merge commit so far
[22:11] <lifeless> 200
[22:13] <lifeless> I agree that some tradeoff is reachable
[22:13] <lifeless> this is a cache thrashing nightmare though
[22:14] <lifeless> an interesting observation or two
[22:15] <lifeless> one is that for a given breadth first search, many of the revisions in each search tip should be common
[22:15] <jelmer> Edulix: of bzr? not yet
[22:15] <jelmer> weigon_, no, rebase won't change the parent location
[22:18] <lifeless> a bit array would be useful
[22:19] <weigon_> jelmer: but the idea was that I do branch from the svn-tree again and throw the old branch away, right ?
[22:20] <weigon_> I don't see the full picture yet to get it all running smooth again
[22:20] <jelmer> weigon_: if you can do that, there's no need for rebase
[22:20] <jelmer> simply rebuild your branch and then push it again
[22:21] <weigon_> I have svn -> (local) svn-bzr for pushing -> 2 bzr branches for development
[22:22] <weigon_> the svn-tree itself is remote and not under my control. The svn-bzr one and the other local bzr trees are
[22:22] <weigon_> I can throw the svn-bzr tree away and run bzr branch svn+ssh://... again, no problem
[22:22] <jelmer> the 2 bzr branches are based on the svn-bzr one I guess?
[22:22] <weigon_> yep
[22:23] <jelmer> and the svn-bzr one is up to date with svn?
[22:23] <abentley> lifeless: 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 from
[22:23] <abentley> If you query about a ghost, you'll get None back in the corresponding location.
[22:23] <Vantage13> is 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 pushable
[22:24] <jelmer> weigon_: you may be able to run 'bzr rebase <svn-url>' to fix the local branch
[22:25] <abentley> Returning 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] <jelmer> weigon_: 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] <jelmer> weigon_: yes
[22:25] <Edulix> does 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] <jelmer> weigon_: bzr-rebase 0.2 (or the current version in bzr)
[22:26] <Edulix> i'm using bzr.dev by the way
[22:26] <weigon_> jelmer: I run trunk
[22:26] <jelmer> weigon_: ok, that should be fine
[22: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] <abentley> In principle, a different value than None could be used for this situation, and I think that would work pretty well.
[22:27] <weigon_> jelmer: bzr: ERROR: Already rebased on SvnBranch('svn+ssh://... isn't that expected ?
[22:28] <jelmer> weigon_: yeah, kinda :-/
[22:28] <weigon_> let me trash the svn-bzr tree and check it out again
[22:28] <jelmer> weigon_: looks like you'll have to get rid of r265 by recommitting r265 and all revisions that followed it
[22:28] <hmeland> Vantage13: You want "bzr switch", but I think that assumes you are working with lightweight checkouts.
[22:28] <weigon_> jelmer: no problem
[22:28] <jelmer> weigon_: in the svn-bzr tree and the bzr trees
[22:29] <Vantage13> hmeland: thanks
[22:29] <weigon_> jelmer: getting rid of == uncommit ?
[22:29] <jelmer> weigon_, yes, that should be sufficient
[22:32] <lifeless> abentley: I can see some callers caring; doing a dict with key:None, or tuples (key, None) will also handle that.
[22:32] <lifeless> I don't think a dict mapping to None is any more or less confusing than None as a positional return value
[22:33] <lifeless> I'm going to go draw on the whiteboard for a bit
[22:47] <Vantage13> Workflow 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 b
[22:47] <lifeless> abentley: I think I have a good answer no
[22:47] <lifeless> *now*
[22:48] <lifeless> abentley: heads() is basically defined as 'find what is reachable from each other'
[22:48] <lifeless> so 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 once
[22:49] <lifeless> which search needs to give all the parent data back to update this reachability answering class
[22:50] <lifeless> for answering reachability, one answer is to cache the key:parent answers as we get them
[22:50] <lifeless> and 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:51] <lifeless> I'll then move onto a more complex answer, which is to turn 'reachable' into a range query
[22:52] <mdke> if 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] <abentley> lifeless: That sounds good.
[22:52] <lifeless> where a key X is reachable from Y, if X is > y0 and <y1
[22:52] <jelmer> mdke: just running the same command again should make it continue
[22:52] <lifeless> so we start with a forest of range structures, and then as nodes find each other we join them
[22:53] <mdke> jelmer: I'll try again, it didn't seem to work last time
[22:53] <jelmer> mdke, what version of bzr-svn are you using?
[22:53] <abentley> I don't know what y0 and y1 are.
[22:53] <lifeless> oh
[22:53] <lifeless> in a range query solution each key is in the vector twice
[22:53] <lifeless> a low value and a high value
[22:53] <mdke> jelmer: whatever is in gutsy
[22:54] <lifeless> I 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] <mdke> or, to be precise, 0.4.1-14
[22:54] <lifeless> anyhow, I'll start with the suppport refactoring first.
[22:54] <mdke> cough. 0.4.1-1
[22:55] <jelmer> mdke: what exactly doesn't work? It starts over?
[22:55] <mdke> seemed to, yeah. I'll just try it again
[22:56] <mdke> jelmer: now it says that there is a lock
[22:56] <jelmer> mdke: try running 'bzr break-lock' on the bzr repository
[22:56] <mdke> jelmer: it hasn't returned me to the prompt yet, should I wait?
[22:56] <lifeless> abentley: its simple to describe for trees, so I'll do so. Do you know what an Euler tour is ?
[22:57] <jelmer> mdke: 0.4.1 is not the latest, but I don't think there's any bugs fixed wrt svn-import since
[22:57] <jelmer> mdke: yes
[22:57] <mdke> ok, waiting
[22:58] <weigon> jelmer: looks like I'm fine now
[22:59] <jelmer> cool
[22:59] <jelmer> it pushed ok?
[23:00] <weigon> I uncommitted and now have to reapply the patch
[23:00] <weigon> should be fine now
[23:00] <weigon> but first I'll upgrade to 7.10 :)
[23:00] <weigon> after the uncommit the push was empty (as expected)
[23:05] <lifeless> abentley: anyhow, an euler tour is the record of the nodes a depth first search goes to
[23:05] <lifeless> so for A:[] its 'A->A'
[23:05] <lifeless> for A:[B], B:[], its 'A->B->A'
[23:06] <lifeless> A:[B,C], B:[C], C:[] its 'A->B->C->B->A->C->A'
[23:07] <lifeless> (this is a slightly modified tour'
[23:07] <mdke> jelmer: 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:08] <lifeless> anyhow, 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:09] <lifeless> we need to annotate this data a little more, because this double-entry is what I'm thinking about still
[23:10] <lifeless> but in principle, C is reachable from B because 2>1 and 2<3
[23:10] <lifeless> (the B list there should be B:[1,3]
[23:11] <mdke> jelmer: oh dear, now a backtrace :(
[23:12] <mdke> I'll try and get a dump of the repository and do it on that rather than doing it from the remote server
[23:14] <jelmer> mdke: yes, that's the way it continues
[23:14] <jelmer> mdke, can you paste it somewhere?
[23:15] <jelmer> that'll use the same logic
[23:17] <mdke> jelmer: 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] <mdke> jelmer: thanks for all your help so far
[23:18] <jelmer> k
[23:18] <jelmer> goodnight :-)
[23:18] <mdke> night
[23:18] <jelmer> mdke: in either case, I would be interested in seeing the backtrace
[23:19] <jelmer> I don't think there are any listed pull bugs in bzr-svn at the moment
[23:33] <igc> morning
[23:35] <lifeless> abentley: and I know know why we access to much history
[23:36] <lifeless> abentley: 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 history
[23:36] <lifeless> consider:
[23:37] <lifeless> A:[CD], B:[D], C:[E], D:[E]
[23:37] <lifeless> first round lookup gives D in common
[23:37] <lifeless> but if we dont get D's parents, we'll follow E all the way to the origin
[23:39] <abentley> Well, I knew it was wrong in terms of giving inaccurate results, but I didn't realize it would also cause this problem.
[23:39] <abentley> But which algorithm are we talking about?
[23:40] <abentley> Or which method specifically?
[23:51] <lifeless> heads()
[23:52] <lifeless> the results are accurate
[23:52] <lifeless> but it accesses too much data
[23:53] <lifeless> in the current code; stop_searching_any() is the culprit
[23:54] <lifeless> it should remove the nodes given as reasons to continue searching
[23:54] <lifeless> but it should not remove them from things to continue querying