| === asak_ is now known as asak | ||
| lifeless | - | 01:00 |
|---|---|---|
| lifeless | hi AfC | 01:00 |
| lifeless | did you get the laptop ? | 01:00 |
| 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:01 |
| lifeless | :( | 01:07 |
| lifeless | You still running gentoo ? | 01:07 |
| 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:24 |
| 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: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 |
| jelmer | weigon_, no, only 0.92 at this point | 01:29 |
| jelmer | (bzr.dev0 | 01:29 |
| lifeless | okies, I'm off to yum cha | 01:33 |
| lifeless | laterz | 01:33 |
| 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:00 |
| 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:01 |
| bagueros | yes | 03:05 |
| bagueros | positive | 03:05 |
| bagueros | it didnt erase them | 03:05 |
| bagueros | it replaced them with older versions | 03:06 |
| bagueros | and got rid of all the new chnages | 03:06 |
| 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:09 |
| bagueros | it shows a list of modified files when i do bzr status | 03:10 |
| 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:11 |
| beuno | bagueros, and does "bzr log" output the revision you commited? | 03:12 |
| bagueros | bzr log doesnt show any of this | 03:13 |
| bagueros | last thing it shows is a commit from yesterday | 03:13 |
| 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:14 |
| * beuno goes to eat something | 03:20 | |
| === abadger199_afk is now known as abadger1999 | ||
| === Mez is now known as Mez|Away | ||
| === Mez|Away is now known as Mez | ||
| ubotu | New bug: #155281 in bzr "bzr diff causes exception (cannot load dispatch table from expat)" [Undecided,New] https://launchpad.net/bugs/155281 | 10:50 |
| lifeless | hmm interesting bug there | 10: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 push | 12: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 | ||
| jelmer | weigon: this is part of a series of commits you're trying to push? | 12:17 |
| jelmer | weigon: if so, one of the earlier commits was probably not pushed right | 12:18 |
| 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:19 |
| 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:20 |
| jelmer | LarstiQ: hi! | 12:22 |
| jelmer | LarstiQ: what's the status on nested trees? | 12:22 |
| weigon | jelmer: r265 is the same in svn log and bzr log, r266 is the faulty one | 12:26 |
| weigon | nothing of the stuff I want to commit seems to appear in the svn log | 12:28 |
| weigon | "$ bzr missing" shows only the r266 | 12:30 |
| weigon | how can I provide more (and useful) information | 12:30 |
| 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:31 |
| weigon | jelm.. http://p.caboo.se/109322 | 12:39 |
| weigon | jelmer: http://p.caboo.se/109322 | 12:41 |
| jelmer | weigon: thanks | 12:46 |
| jelmer | weigon: it looks indeed like it pushed r265 incorrectly and now anything on top of that breaks as well | 12:47 |
| weigon | how can I get it corrected ? | 12:49 |
| jelmer | redoing the commits in a new branch (perhaps using "bzr rebase") | 12:54 |
| jelmer | weigon: I'll be back in a few hours | 13:03 |
| GaryvdM | jelmer: Hi | 14:04 |
| 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:05 |
| jelmer | No, it will be (once the pqm is set up) | 14:06 |
| GaryvdM | Oh - ok I thought it was | 14:06 |
| jelmer | GaryvdM, merged now | 14:10 |
| GaryvdM | Cool | 14:10 |
| lifeless | ight | 14:28 |
| lifeless | night | 14:28 |
| Edulix | what's the best way to install bzr-svn 0.4.2 in ubuntu? | 15:15 |
| Edulix | I see no deb package... | 15:16 |
| Edulix | I get this http://pastebin.ca/744429 | 15:20 |
| Edulix | can anyone please enlighten me? | 15:20 |
| kiko | hey there | 15:28 |
| kiko | lifeless? | 15:28 |
| * Edulix is still alive | 15:29 | |
| dato | 15:28 <lifeless> night | 15:29 |
| Edulix | oh | 15:31 |
| Edulix | :P | 15:31 |
| Edulix | my bzr is the one without life | 15:31 |
| kiko | no, I can't branch from launchpad either | 15:33 |
| weigon | Edulix: just place it (or a symlink) in ~/.bazaar/plugins/ | 15:33 |
| 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 | 15:34 |
| ubotu | New bug: #155398 in bzr-eclipse "refresh log window after pull/commit" [Undecided,New] https://launchpad.net/bugs/155398 | 16:45 |
| 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 | 16:59 |
| jelmer | weigon, any luck getting you branch fixed? | 17:00 |
| 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:23 |
| 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:24 |
| jelmer | Edulix, that bug has been fixed in bzr.dev, the fix will be in 0.92 | 17:33 |
| schierbeck | jelmer: hello | 17:35 |
| jelmer | hi schierbeck | 17:35 |
| jelmer | schierbeck, sorry for not responding yesterday | 17:35 |
| 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:36 |
| 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:37 |
| schierbeck | preferable in its own package | 17:38 |
| schierbeck | or whatever the python term is | 17:38 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| schierbeck | jelmer: okay, i've sent in another merge request, this time removing duplicate window logic | 17:59 |
| schierbeck | when that's merged into mainline i'll sort out the other issue | 18:00 |
| jelmer | schierbeck: cool, thanks | 18:00 |
| schierbeck | np | 18:00 |
| === bigdo1 is now known as bigdog_ | ||
| Edulix | jelmer: is there any deb package with the bug fixed? | 20:06 |
| weigon_ | jelmer: let me branch and try again | 20:21 |
| weigon_ | jelmer: hmm, I use a shared repo containing 2 branches branched from the bzr-svn branch | 20:43 |
| lifeless | moin | 20:43 |
| weigon_ | *hmm* wait. looks that I don't get what rebase is all about | 20:44 |
| weigon_ | jelmer: if I rebase to another (new) branch, shouldn't the bzr info show me the new "parent" location ? | 20:49 |
| lifeless | abentley: ping | 20:57 |
| abentley | lifeless: pong | 21:04 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| lifeless | the other thing I wanted to run past you | 21:19 |
| 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:20 |
| 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:21 |
| abentley | Stop searching any will stop searching any of the specified revisions that are still being searched. | 21:22 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| lifeless | its better to be slow when you run out of memory | 21:28 |
| lifeless | let me just do some quick math | 21:28 |
| 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:31 |
| lifeless | 50K nodes | 21:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| abentley | I.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 |
| 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:38 |
| lifeless | 844m is the result for that. heh. | 21:39 |
| lifeless | but it may not have shared nodes. doing it again | 21:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| lifeless | thats 2237 across the middle | 21:43 |
| lifeless | and 2500000 in the paths worst case | 21:43 |
| 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:45 |
| 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:51 |
| lifeless | you don't have the lp certificate installed for pcurl | 21:52 |
| kiko | lifeless, when did this change? it did work at some point | 21:52 |
| === GaryvdM_ is now known as GaryvdM | ||
| kiko | did we start using pycurl under the covers? | 21:52 |
| kiko | lifeless, also, the lp certificate isn't self-signed | 21:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 21:59 |
| 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:00 |
| kiko | update-ca-certificates | 22:01 |
| lifeless | yeah working on feisty | 22:02 |
| 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:03 |
| 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:05 |
| === kiko is now known as kiko-fud | ||
| 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:08 |
| lifeless | 200 | 22:11 |
| lifeless | I agree that some tradeoff is reachable | 22:13 |
| lifeless | this is a cache thrashing nightmare though | 22:13 |
| lifeless | an interesting observation or two | 22:14 |
| 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:15 |
| lifeless | a bit array would be useful | 22: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 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:20 |
| weigon_ | I have svn -> (local) svn-bzr for pushing -> 2 bzr branches for development | 22:21 |
| 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:22 |
| 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:23 |
| jelmer | weigon_: you may be able to run 'bzr rebase <svn-url>' to fix the local branch | 22:24 |
| 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:25 |
| 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:26 |
| weigon_ | jelmer: bzr: ERROR: Already rebased on SvnBranch('svn+ssh://... isn't that expected ? | 22:27 |
| 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:28 |
| Vantage13 | hmeland: thanks | 22:29 |
| weigon_ | jelmer: getting rid of == uncommit ? | 22:29 |
| jelmer | weigon_, yes, that should be sufficient | 22:29 |
| 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:32 |
| lifeless | I'm going to go draw on the whiteboard for a bit | 22:33 |
| 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:47 |
| 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:48 |
| lifeless | which search needs to give all the parent data back to update this reachability answering class | 22:49 |
| 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:50 |
| lifeless | I'll then move onto a more complex answer, which is to turn 'reachable' into a range query | 22:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| jelmer | mdke: what exactly doesn't work? It starts over? | 22:55 |
| mdke | seemed to, yeah. I'll just try it again | 22:55 |
| 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:56 |
| 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:57 |
| weigon | jelmer: looks like I'm fine now | 22:58 |
| jelmer | cool | 22:59 |
| jelmer | it pushed ok? | 22:59 |
| 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:00 |
| 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:05 |
| lifeless | A:[B,C], B:[C], C:[] its 'A->B->C->B->A->C->A' | 23:06 |
| 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:07 |
| 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:08 |
| lifeless | we need to annotate this data a little more, because this double-entry is what I'm thinking about still | 23:09 |
| 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:10 |
| mdke | jelmer: oh dear, now a backtrace :( | 23:11 |
| 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:12 |
| jelmer | mdke: yes, that's the way it continues | 23:14 |
| jelmer | mdke, can you paste it somewhere? | 23:14 |
| jelmer | that'll use the same logic | 23:15 |
| 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:17 |
| 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:18 |
| jelmer | I don't think there are any listed pull bugs in bzr-svn at the moment | 23:19 |
| igc | morning | 23:33 |
| lifeless | abentley: and I know know why we access to much history | 23:35 |
| 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:36 |
| 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:37 |
| 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:39 |
| abentley | Or which method specifically? | 23:40 |
| lifeless | heads() | 23:51 |
| lifeless | the results are accurate | 23:52 |
| lifeless | but it accesses too much data | 23:52 |
| lifeless | in the current code; stop_searching_any() is the culprit | 23:53 |
| 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 | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!