[00:25] jelmer: what deltas does svn use? [00:25] ideally you can provide an adaptor to allow you to use insert_record_stream [00:26] it's byte-based [00:26] ok [00:26] so add_lines does get_lines(), applies delta, does a diff(), writes the text out [00:27] basically it's a list of instructions like "insert this sequence of bytes at offset X" [00:27] so we're doing twice as many get_lines() as needed [00:27] ah, cool [00:27] this will be nontrivial for you [00:27] but look at insert_record_stream [00:27] conceptually, you would define a new record type ('svn-delta') [00:28] and then look at KnitVersionedFile.insert_record_stream to teach it how to coerce that to a more useful form [00:28] the key thing is that in that function you can e.g. emit a knit record directly (because you may know what lines were altered, or something similar) [00:30] hmmok [00:30] some assembly will be required, but the goal of the interface is to permit this - as the first external user, you'll have to poke things to line up more [00:30] I'll file a bug about this, it's something nice to look at in the future but I'd like to get 0.5 out at all first [00:31] lifeless: batteries not included [00:35] jelmer: yes, for sure === mw is now known as mw|out [01:36] c === timchen1` is now known as nasloc__ [03:26] Is a feature like this planned for bzr? 'cause that would be pretty awesome http://tech.slashdot.org/tech/08/12/04/1625226.shtml [03:42] Looks interesting [03:46] KERNEL 2.6.35 = AWESOME QUALITY!!!! 10/10!!! PLZ SEED! (p.s. doesn't play on my 286. i have VLC). [04:39] Toksyuryel: I don't know of anyone working directly on it; doing dissemination based networking is probably better down further down the stack so that mor ethings can benefit, but - if someone gets the bug and haks it up, the more the merrier [04:41] * Toksyuryel nods === sdboyer_ is now known as sdboyer [07:12] hi all [07:33] hi vila [07:42] beuno: yo [07:43] lifeless, hey hey [07:43] so [07:43] I want to show you a little about using the profiling middleware [07:43] cause it just confused me :) [07:43] are you crashing yet, or got a few ? [07:44] I have a few. IRC or RL? [07:44] IRC is fune [07:44] *fine* [07:44] ok, sjoot [07:44] er [07:44] shoot [07:44] to start with, get a browser with lh running against something that is indexed [07:44] svn is best, but you probably haven't pulled all the branches etc yet [07:45] so bzr.dev or lh itself or something, it sfine [07:45] I've got LH on LH indexed and running [07:45] kay [07:45] type something into the search box without hitting enter [07:45] just to get completion results showing [07:45] now, stop lh [07:45] and run it with --profile [07:46] then hit the down arrow key once in the browser, which will cause a single refresh of the completion results === duzt_ is now known as duzt|sleep [07:46] stop lh [07:46] and run kcachegrind 1-stats.callgrind [07:46] http://paste.ubuntu.com/80740/ [07:46] traceback! [07:47] you have an old bzr-search, I fixed that bug [07:47] * beuno pulls [07:47] TMI === thekorn_ is now known as thekorn [07:48] hrm [07:48] pulling didn't do it [07:49] of course, it helps if I pull the right thing... [07:50] what did you pull? [07:50] File "/var/lib/python-support/python2.5/paste/httpserver.py", line 166, in wsgi_start_response [07:50] assert 0, "Attempt to set headers a second time w/o an exc_info" [07:50] AssertionError: Attempt to set headers a second time w/o an exc_info [07:51] heh [07:51] well hit down again, until it works [07:51] I pulled bzr-search, but not the one that I'm using for bzr [07:51] then cachegrind the one that worked [07:52] ok, nothing seems to be working [07:52] maybe I should stop doing it on a checkout [07:52] just do bzr unbind [07:52] you canbzr bind later [07:53] ok, now [07:54] let's run it through kcachegrind... [07:55] which I don't have, and will take 22 minutes to get with all it's deps....... [07:55] heh [07:55] get it, you needs it [07:56] * beuno stares at apt while it downloads [07:56] give it tha ol evil eye [07:56] ok, so let it install, I show you tomorrow [07:57] kei [07:57] it's really insisting on taking those full 22 minutes [07:57] so it's downloading [07:57] and I haave that callgrind file [07:58] so we can have fun on the bus tomorrow [07:58] :> [07:58] I have a question [07:58] what are 'apps' [07:59] that's a question for mwhudson. He chose the name, and I just made it work in my head. To me, it's the paste stuff. [07:59] ok [08:00] cause its the branch app that appears to be chewing up time [08:00] that's odd, it shouldn't really do much [08:01] it calls get_history unconditionally AFAICT [08:01] which should have a nice cache [08:02] both internal and sqlite [08:02] profile -> trasnlogger -> httpexceptions ->apps.error ->apps.filesystem ->apps.filesystem->apps.branch->search [08:03] we call last_revision twice [08:03] ah, hm [08:03] it takes 56% of the time [08:03] that's bad [08:03] ciao! [08:04] see you on ze bus [08:04] :) [08:04] have a good night === awilkins_away is now known as awilkins [10:49] hello all. greetings from the philippines! did launchpad change the port number of the bzr+ssh access? i keept on having a Connection timeout error on port 22. :( [10:52] nbjayme: No, it didn't. [10:54] nbjayme: You might find #launchpad more helpful. [10:54] thanks Peng_. [11:58] my clumsiness.... bzr push sftp://bazaar.launchpad.net <---- is the right url. === asac_ is now known as asac === fta_ is now known as fta === thunderstruck is now known as gnomefreak [13:26] vila: ping [13:27] jam: pong [13:29] good morning [13:29] Any chance you could try to review: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C493709CC.4090307%40arbash-meinel.com%3E [13:29] I mentioned it to Aaron yesterday, but he hasn't commented. [13:29] It seems it is a fairly serious regression in stacked repositories [13:30] so I'd like to land it before 1.10 [13:30] Also, I wanted to chat with someone whether I should be releasing 1.10-final today, or doing rc2 instead ? [13:30] (Given that bug) [13:32] Re-reading (but from last read you got at least a BB:I-like-the-topo-order-so-go-go-go :) [13:33] You have one import pdb; pdb.set_trace() [13:35] jam: My feeling there (having read the thread as it came in) is that sorting by topo order is the key. [13:36] You know my feelings about it and here you say it makes things simpler (good) so it should make it more robust [13:37] vila: thanks for catching the pdb, it sure stands out in BB :) [13:38] Now, as you describe it, this bug is nasty and hard to reproduce which testify that you have a good grasp on it. As such, you make reviewer life hard: either I give you an approve nased on trust or I need to work as hard as you :) [13:38] So... with just the topo-order fix, it will still create Fulltexts at merge revisions [13:38] OrderingVersionedFilesDecorator is just a test helper ? [13:38] OVFD is a test helper, yes [13:38] I split it out into another patch [13:38] though perhaps that got "superseded" [13:38] Wow, so you really pinpoint the bug in the test [13:39] yeah, it di: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C4936F5EF.2060208%40arbash-meinel.com%3E [13:39] Ha, I thought I read that but wasn't finding it in the submission [13:39] vila: yeah, the bug is really a cascade of about 3 different failures [13:39] which made writing a test case.... interesting [13:40] Considering the fix was small, it took me all day to finish the test case. [13:40] but at least I got a full handle on the bug [13:40] That itself grants aBB:approve I think [13:40] and feel confident about the fix [13:40] The code modification is light, you ran the full test suite ? [13:41] I did not, I'm on win32 where it doesn't pass anyway [13:41] I ran bits I thought were appropriate [13:41] (And trust that PQM will run the whole thing for me :) [13:42] Ok [13:43] jam: voted [13:44] Now, regarding inclusion in 1.10, I'm not the RM, but given the effort that went into stacked branches related bugs, I'll vote for inclusion [13:44] Are *you* the RM ? [13:47] I'm the RM for 1.10-final(ish) [13:47] yes [13:47] poolie is away [13:53] So, I didn't follow closely the bug history, were there some feedback that triggered your patch based on 1.10rc1 or is it just a work-in-progress that happens to be finished now ? [13:54] I don't have a strong preference for rc2 or final anyway as long a 1.11 serie is opened anyway :-) [13:59] vila: bug #304841 is on 1.10rc1 + martin's patch [13:59] Launchpad bug 304841 in bzr "bzr push raises RevisionNotPresent" [Critical,Fix committed] https://launchpad.net/bugs/304841 [13:59] his patch was for bug #303856 [13:59] Launchpad bug 303856 in bzr "caching writes to pack repository causes ShortReadvError on pushing stacked branch" [High,Fix committed] https://launchpad.net/bugs/303856 [14:01] I mixed up the two, thanks [14:01] 303856 was targeted to 1.10final, that's a good hint to go with final [14:03] I mean, you already put more polish on it (and addressed a critical bug), release ! === thunderstruck is now known as gnomefreak [14:33] I accidently added a directory to my bzr repo. I've not checked in the change. Is there any way to undo adding the directory (and it's contents) before I check in? [14:35] bzr remove [14:35] just works [14:35] balor: "bzr rm --keep" [14:35] jam: I did bzr rm --force [14:35] jam: then recreated the dir. [14:35] jam: thanks though. [14:35] np [14:36] keep would have meant not needing to recreate it [14:51] I've just installed bzr-svn and I'm trying to bzr push svn+ssh://server/path from my existing bzr native branch. I get an instant assert error, which doesnt' seem to give much detail. Anything I can try to debug this? [14:54] The particular line that fails is File "/usr/lib/python2.5/site-packages/bzrlib/plugins/svn/remote.py", line 52, in __init__ [14:54] assert svn_url.startswith(self.svn_root_url) [15:02] balor: or bzr revert would have kept it too [15:03] Ooh... OK.. bug perhaps? [15:03] svn+ssh://server//root/path/here dies, svn+ssh://server/root/path/here works fine [15:04] LeoNerd, any chance you can file a bug? [15:05] debian reportbug be OK? [15:05] yeah, sure [15:07] done [15:08] hi jelmer === duzt|sleep is now known as duzt [15:09] 'morning lifeless [15:15] jelmer: did you see the bzr-svn branch I tossed up? [15:15] lifeless, yeah, thanks for that [15:16] lifeless, I'm about to rebase it on 0.5 [15:16] jelmer: ok [15:18] lifeless, merged into 0.5 [15:19] jelmer: thanks. bzr-search needs get_transaction on repository (not direcyly, but for Repository.iter_file_bytes [15:20] fwiw, bzr-svn doesn't do Repository.iter_file_bytes() [15:20] File "/home/robertc/source/baz/bzr-test-fixes/bzrlib/repository.py", line 1399, in iter_files_bytes [15:20] transaction = self.get_transaction() [15:20] it inherits it [15:20] File "/home/robertc/.bazaar/plugins/svn/repository.py", line 175, in get_transaction [15:20] raise NotImplementedError(self.get_transaction) [15:21] Mm.. So this "determining changes" it's running on a new repo.. What's that for, and how long is it going to take? [15:21] It's been chewing away for about 10 minutes now.. [15:22] jelmer: nvm, it canbe fixed in bzrlib. [15:22] jelmer: this is a bit odd [15:23] $ bzr search radix [15:23] stacking support in bzr-svn is experimental. [15:23] nevowlore.py in ... [15:33] LeoNerd: it is calculating the shape of the repository in bzr terms [15:33] LeoNerd: branches, per file graph and the like [15:34] Right. It suddenly finished without warning :) I think the progress meter is broken [15:34] LeoNerd: following that it will be able to start pulling [15:34] It was claiming 0/204005 for aaages [15:37] Hrm.. it doesn't preserve timestamps. No big issue, but it just upsets the stats a bit :P [15:39] how do you mean? [15:41] I've pushed a bzr branch into the svn repo, and according to our "trac" view of svn, it was all modified a few minutes ago, rather than last week [15:41] LeoNerd, see the FAQ [15:42] you can make bzr-svn modify the svn:date property, but it requires changing the settings in your svn repository [15:42] Ahhright [15:43] jelmer so - whats that stacknig warning about, that svn branch isn't stacked [15:43] lifeless, it happens whenever versionedfiles are involved [15:44] :( I know this is a repeating theme, but how can I turn that warning off? [15:46] there's no way to disable it at the moment [15:46] I'd rather not allow turning that off, at least not in any released versions of bzr-svn, as the versionedfiles stuff is pretty much untested [15:46] and it allows people to do b0rked imports [15:46] lifeless: BB:approve on the iter_file_bytes fix, though if you could wait to submit it until after I've gotten 1.10 out the door, I would appreciate it [15:47] jam: that was fast :P [15:47] jam: tell me when to land it [15:47] jelmer: how do you mean [borked imports] [15:47] lifeless: I saw it on the bazaar-commits list while going through some other stuff :) [15:48] I'll let you know when PQM is free [15:48] lifeless, if you use "bzr branch --stacked" it uses versionedfiles and that can broken [15:48] if there's some easy way to only warn when doing a stacking clone, I'm happy [15:48] lifeless: for your InterDifferingSerializer change (where you buffer 100 revs at-a-time, and use apply_inventory_delta). What tests should I be looking at bringing across? [15:48] I found a couple small issues for it [15:49] and would like to get it merged into bzr.dev [15:49] so we can have the improved version in-play and under-regular-testing [15:49] jam: I had hit commit 2 seconds earlier :) [15:50] jelmer: what goes wrong with the imports if they do this? [15:50] jam: well first, add_inventory_delta, which poolie had some review feedback on [15:51] lifeless: I don't see your "apply_inventory_delta" fix in BB [15:51] ah, this one? http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ce01316480811102304s60b1df9cnf62aec9748a61346%40mail.gmail.com%3E [15:51] lifeless, inconsistent text parents, text contents [15:51] jelmer: ! [15:51] jam: no [15:52] lifeless: this is why there is a warning :-) [15:52] yeah, looking closer I realized that [15:52] still looking [15:52] jelmer: your warning is not accurate :P its not experimental its known broke [15:52] lifeless, I'm not aware of any cases where that has happened, but the code is not very well tested [15:52] and that's the sort of thing that *would* happen [15:53] jelmer: oh [15:53] jam: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1223873271.9015.266.camel%40lifeless-64%3E [15:54] lifeless: what do you think about calling it "add_inventory_by_delta" ? [15:55] And was Martin's main complaint that it was against an arbitrary rev? Rather than only the basis? [15:56] I guess you already agreed to _by_delta [15:57] I'm fine with add_inventory_by_delta, it is more clear [15:57] I guess I'm a bit confused by his comment: "I still think it's dangerous to have something that looks like a delta but is not," [15:57] thats the basis_delta list [15:58] If you haven't said "recording_deletes = True" it is not an accurate delta? [15:58] see the list for a convesation - bb deleted his initial comments when he commented again [15:58] jam: yes [15:58] jam: so I proposed to him that we make basis_delta be get_basis_delta() [15:58] and we need to not have a delete for the current functionality? [15:58] and if you haven't called recording_deletes, then get_basis_delta() errors [15:59] that sounds ok, but I don't quite have a grasp on when/why you need to *not* record the deletes in the basis_delta [15:59] It seems like you would need it to update the WT as well [16:00] the existing commit driver generates it's own basis delta object [16:00] that is [16:00] in bzr.dev, and anything like plugins that is using CommitBuilder directly, code makes its own delta by using the return value from record_entry and adding deletes by hand [16:01] with the patch, commit.py is fixed, but other clients wouldn't be - they would end up with a CommitBuilder object with what 'looks' like a good delta, but still wouldn't have deletes in it [16:01] are there existing bzr icons somewhere for things like branch, pull, merge, ...? [16:01] Tak: bzr-gtk might have some [16:01] jam: breakfast time [16:02] lifeless: eat hardy. I think I have a feeling now [16:02] so basically, you want get_basis_delta() to fail if you aren't aware of the new API [16:02] it appears to be using stock gnome icons atm [16:02] jam: yah; simply if !self._recording_deletes: raise AssertionError("you can't use this until you've updated your apip usage per ...") [16:11] lifeless: So... to set this variable True... we could do a Constructor variable, or bikeshed a bit on the proposed name (will_record_deletes()?). I prefer the constructor approach, except you have to pass it through Repository.get_commit_builder() which is a bit ugly [16:11] I suppose we have a slightly smaller api compatibility issue if we just have a function on CommitBuilder [16:12] as SVNCB can just inherit that function [16:12] (though if it doesn't respect it... we have a problem anyway, so probably better to have it fail) [16:13] who are all these people that have bzr-dbus installed? [16:13] Is it a Recommends somewhere? [16:36] jam: for compatibility I avoided constructor [16:36] yeah, I went that route too [16:36] jam: a client that does not use the function will work fine [16:36] jam: because they won't try to get the delta, and the finish_inventory method knows to only use the delta if it is going to be valid [16:37] jam: probably [16:37] (re bzr-dbus) [16:40] ? [16:40] 03:11 < jam> who are all these people that have bzr-dbus installed? [16:40] 03:11 < jam> Is it a Recommends somewhere? [16:41] Ah probably a Recommends [16:41] sure [16:41] I thought that was the last line of the previous statement. :) [16:43] lifeless: for the default implementation of "add_inventory_by_delta". Should we be adding "create_by_apply_delta" to Inventory and using it instead? [16:43] It means requiring an Inventory.copy() which is a bit slow [16:43] but is necessary for CHK inventories. [16:43] We happen to know the lifetime of the inventory in add_inventory_by_delta is safe [16:43] but apply_delta is not always a safe function otherwise. [16:50] jam: I don't think so [16:51] jam, bzr-gtk recommends bzr-dbus [16:57] jam: create_by_apply_delta doesn't make sense to me on th ein memory invetory, not in the same way [16:57] jam: the key ting here is that *repository* is the interface for adding inventories to [17:04] jam: heading over to MV now, lets chat in about 2 hours ater the opening [17:05] np [17:05] enjoy the show :) [17:28] lifeless: you can go ahead and submit your iter_files_bytes fix. [17:37] I've just added 11MB of crap to a branch and committed it... and then realized that will bloat subsequent branches after merging this one to trunk. [17:37] jkakar: bzr uncommit [17:37] jam: That won't work, as I did the commit several revisions ago. [17:37] jkakar: it would still work, you just have to do more to get things back [17:37] jam: I've realized I can trim down that 11MB to 300k and now want to remove the history of that 11MB entirely... [17:37] however, you can install the bzr-rebase plugin [17:38] and have it help you recreate the extra revs [17:38] bzr-rebase has never worked for me. I probably don't understand how to use it. [17:38] jkakar: I *think* you want bzr uncommit -rBEFORE_I_WAS_FOOLISH [17:38] bzr revert [17:39] bzr replay -r AFTER_I_WAS_FOOLISH..-1 [17:39] well, you probably need to keep 1 branch around to replay from [17:39] Woah. I'll try that, thanks. [17:39] make sure to check "bzr help replay" just in case I have some syntax wrong [17:58] jam: It worked! Thanks a lot. :) [17:58] np === jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | 1.10 is released! (5 Dec) | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ [18:45] is there an easy way to see files that have been bzr rm'd in the file? [18:46] in the current directory* [18:46] bzr rm'd and committed in the past [18:53] I have bzr installed on an ubuntu box and the windows bzr installer on a XP box. how can i do a checkout/branch/clone of my repo to on the Windows box? [18:54] the initial bzr init, etc was done on the ubuntu box [18:55] jelmer: ping, you just announced bzr-svn 0.4.16, but it doesn't seem to be tagged in http://bzr.debian.org/pkg-bazaar/bzr-svn/experimental/ [18:55] bleh, I suck at this [18:55] jam, Sorry, that's at least the third time you have to remind me :-( [18:56] i get the following when i try to do a branch [18:56] C:\Documents and Settings\user\Desktop>bzr branch ssh://user@ipaddr:~/Code myCode [18:56] bzr: ERROR: Unsupported protocol for url "ssh://user@157.184.82.74:~/Code" [18:56] etank, you probably want sftp:// or bzr+ssh:// [18:57] jam, should be tagged now [18:58] jelmer: so you are now tagging it as "debian-0.4.16" right? [18:58] rather than bzr-svn-0.4.16 [18:58] btw, 0.4.15 also is not tagged [18:58] jelmer: with either of those i get this now "bzr: ERROR: Invalid url supplied to transport: "invalid port number ~ in url:" [18:59] etank, please use a / rather than a : [18:59] etank: the URL you want is probably: sftp://user@host/~/Code [18:59] if you want to use bzr+ssh then it would be [18:59] ok [18:59] bzr+ssh://user@host/home/user/Code [18:59] jam, yeah, debian-0.4.16-1 [18:59] bzr+ssh doesn't support ~ yet === evarlast is now known as jmcw [18:59] jelmer: that really messes up the bzr-builddeb I have [18:59] as in... it always wants bzr-svn-0.4.16 [19:00] jam, I'm still tagging the upstream release as bzr-svn-0.4.16 [19:00] Ah, I guess I just need to edit .bzr-builddeb/defaults.conf [19:00] jam, just the debian packaging as debian-0.4.16-1 [19:00] jam, so you want to merge in debian-0.4.16-1 but have it build against bzr-svn-0.4.16 [19:01] k, I should mention the bzr-svn-0.4.16 isn't there *either* [19:01] and neither is 0.4.15 [19:01] nor debian-0.4.15 [19:01] ah, that's actually a bzr-builddeb bug that I think has been fixed [19:01] * etank is wondering if using the python sources would be better [19:02] anyway, if I go back and "bzr merge lp:bzr-svn && bzr revert && bzr merge lp:bzr-svn/0.4" I seem to have all the tags [19:02] jam, now pushed with the original upstream tags [19:02] bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is require [19:02] I'm not sure why they aren't in your packaging branches [19:02] d) [19:02] HPSS calls: 1 [19:02] jam, bzr-builddeb's "bzr merge-upstream" command used to not pull in tags [19:02] thats what i got with bzr+ssh [19:02] I think James fixed that recently [19:03] etank: if you are getting that, it means the ssh connection closed [19:03] What version of the bzr client are you using ? [19:03] im not sure why though [19:03] one sec [19:03] "bzr --version" should tell you [19:03] bzr-setup-1.9.exe [19:03] Bazaar (bzr) 1.9 [19:03] k, that one should be fine [19:04] i can ssh to the box with no problems using putty [19:04] etank: are you using custom keys or anything like that? [19:04] or just username & password? [19:04] nope. password loging [19:04] login i mean [19:05] and when you do "bzr branch bzr+ssh://..." it doesn't prompt you for a password? [19:05] jam: nope [19:06] C:\Documents and Settings\elake\Desktop>bzr branch bzr+ssh://elake@157.184.82.74/Code myCode [19:06] bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is require [19:06] d) [19:06] that is the exact ouput [19:06] i wonder if it is something in the sshd_config that needs to be changed === jmcw is now known as evarlast [19:08] etank: ah, I have an idea [19:08] try doing [19:09] set BZR_SSH=paramiko [19:09] on the command line [19:09] and then running bzr branch [19:09] and if that fails [19:09] try [19:09] set BZR_SSH=plink [19:09] plink should fail because it doesn't support passwords as a sub-process [19:09] but it may fail in a *different* way [19:10] etank: did you rename "plink" to "ssh" btw? [19:10] as that would probably confuse us [19:10] nope [19:10] neither of those worked [19:10] pscp elake@elake-ibex:/home/elake/Code/mailer.py ./ <-- that command would work though [19:11] etank: you might try looking at "My Documents\.bzr.log" to see if there is any more info there [19:11] SocketConnectionError: Unable to connect to SSH host 157.184.82.74; EOF during negotiation [19:11] jelmer: Why would "dch" keep trying to add a new record with your name instead of mine? [19:12] I'm listed as maintainer [19:12] debia/control [19:13] jelmer: yeah, I was accidentally using "-m" thinking I needed it as the update message [19:13] rather than realizing it set the "use the ID of a maintainer" flag [19:14] I've done that a couple of times as well [19:14] bzr commit ruined dch for me [19:14] etank: does it say anything about failing to import paramiko, etc? [19:18]