| lifeless | jelmer: what deltas does svn use? | 00:25 |
|---|---|---|
| lifeless | ideally you can provide an adaptor to allow you to use insert_record_stream | 00:25 |
| jelmer | it's byte-based | 00:26 |
| lifeless | ok | 00:26 |
| lifeless | so add_lines does get_lines(), applies delta, does a diff(), writes the text out | 00:26 |
| jelmer | basically it's a list of instructions like "insert this sequence of bytes at offset X" | 00:27 |
| lifeless | so we're doing twice as many get_lines() as needed | 00:27 |
| jelmer | ah, cool | 00:27 |
| lifeless | this will be nontrivial for you | 00:27 |
| lifeless | but look at insert_record_stream | 00:27 |
| lifeless | conceptually, you would define a new record type ('svn-delta') | 00:27 |
| lifeless | and then look at KnitVersionedFile.insert_record_stream to teach it how to coerce that to a more useful form | 00:28 |
| lifeless | 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:28 |
| jelmer | hmmok | 00:30 |
| lifeless | 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 |
| jelmer | 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:30 |
| AfC | lifeless: batteries not included | 00:31 |
| lifeless | jelmer: yes, for sure | 00:35 |
| === mw is now known as mw|out | ||
| TheMuso | c | 01:36 |
| === timchen1` is now known as nasloc__ | ||
| Toksyuryel | 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:26 |
| Rolly | Looks interesting | 03:42 |
| mneptok | KERNEL 2.6.35 = AWESOME QUALITY!!!! 10/10!!! PLZ SEED! (p.s. doesn't play on my 286. i have VLC). | 03:46 |
| lifeless | 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:39 |
| * Toksyuryel nods | 04:41 | |
| === sdboyer_ is now known as sdboyer | ||
| vila | hi all | 07:12 |
| lifeless | hi vila | 07:33 |
| lifeless | beuno: yo | 07:42 |
| beuno | lifeless, hey hey | 07:43 |
| lifeless | so | 07:43 |
| lifeless | I want to show you a little about using the profiling middleware | 07:43 |
| lifeless | cause it just confused me :) | 07:43 |
| lifeless | are you crashing yet, or got a few ? | 07:43 |
| beuno | I have a few. IRC or RL? | 07:44 |
| lifeless | IRC is fune | 07:44 |
| lifeless | *fine* | 07:44 |
| beuno | ok, sjoot | 07:44 |
| beuno | er | 07:44 |
| beuno | shoot | 07:44 |
| lifeless | to start with, get a browser with lh running against something that is indexed | 07:44 |
| lifeless | svn is best, but you probably haven't pulled all the branches etc yet | 07:44 |
| lifeless | so bzr.dev or lh itself or something, it sfine | 07:45 |
| beuno | I've got LH on LH indexed and running | 07:45 |
| lifeless | kay | 07:45 |
| lifeless | type something into the search box without hitting enter | 07:45 |
| lifeless | just to get completion results showing | 07:45 |
| lifeless | now, stop lh | 07:45 |
| lifeless | and run it with --profile | 07:45 |
| lifeless | then hit the down arrow key once in the browser, which will cause a single refresh of the completion results | 07:46 |
| === duzt_ is now known as duzt|sleep | ||
| lifeless | stop lh | 07:46 |
| lifeless | and run kcachegrind 1-stats.callgrind | 07:46 |
| beuno | http://paste.ubuntu.com/80740/ | 07:46 |
| beuno | traceback! | 07:46 |
| lifeless | you have an old bzr-search, I fixed that bug | 07:47 |
| * beuno pulls | 07:47 | |
| lifeless | TMI | 07:47 |
| === thekorn_ is now known as thekorn | ||
| beuno | hrm | 07:48 |
| beuno | pulling didn't do it | 07:48 |
| beuno | of course, it helps if I pull the right thing... | 07:49 |
| lifeless | what did you pull? | 07:50 |
| beuno | File "/var/lib/python-support/python2.5/paste/httpserver.py", line 166, in wsgi_start_response | 07:50 |
| beuno | assert 0, "Attempt to set headers a second time w/o an exc_info" | 07:50 |
| beuno | AssertionError: Attempt to set headers a second time w/o an exc_info | 07:50 |
| lifeless | heh | 07:51 |
| lifeless | well hit down again, until it works | 07:51 |
| beuno | I pulled bzr-search, but not the one that I'm using for bzr | 07:51 |
| lifeless | then cachegrind the one that worked | 07:51 |
| beuno | ok, nothing seems to be working | 07:52 |
| beuno | maybe I should stop doing it on a checkout | 07:52 |
| lifeless | just do bzr unbind | 07:52 |
| lifeless | you canbzr bind later | 07:52 |
| beuno | ok, now | 07:53 |
| beuno | let's run it through kcachegrind... | 07:54 |
| beuno | which I don't have, and will take 22 minutes to get with all it's deps....... | 07:55 |
| lifeless | heh | 07:55 |
| lifeless | get it, you needs it | 07:55 |
| * beuno stares at apt while it downloads | 07:56 | |
| lifeless | give it tha ol evil eye | 07:56 |
| lifeless | ok, so let it install, I show you tomorrow | 07:56 |
| beuno | kei | 07:57 |
| beuno | it's really insisting on taking those full 22 minutes | 07:57 |
| beuno | so it's downloading | 07:57 |
| beuno | and I haave that callgrind file | 07:57 |
| beuno | so we can have fun on the bus tomorrow | 07:58 |
| lifeless | :> | 07:58 |
| lifeless | I have a question | 07:58 |
| lifeless | what are 'apps' | 07:58 |
| beuno | 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 |
| lifeless | ok | 07:59 |
| lifeless | cause its the branch app that appears to be chewing up time | 08:00 |
| beuno | that's odd, it shouldn't really do much | 08:00 |
| lifeless | it calls get_history unconditionally AFAICT | 08:01 |
| beuno | which should have a nice cache | 08:01 |
| beuno | both internal and sqlite | 08:02 |
| lifeless | profile -> trasnlogger -> httpexceptions ->apps.error ->apps.filesystem ->apps.filesystem->apps.branch->search | 08:02 |
| lifeless | we call last_revision twice | 08:03 |
| beuno | ah, hm | 08:03 |
| lifeless | it takes 56% of the time | 08:03 |
| beuno | that's bad | 08:03 |
| lifeless | ciao! | 08:03 |
| lifeless | see you on ze bus | 08:04 |
| beuno | :) | 08:04 |
| beuno | have a good night | 08:04 |
| === awilkins_away is now known as awilkins | ||
| nbjayme | 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:49 |
| Peng_ | nbjayme: No, it didn't. | 10:52 |
| Peng_ | nbjayme: You might find #launchpad more helpful. | 10:54 |
| nbjayme | thanks Peng_. | 10:54 |
| nbjayme | my clumsiness.... bzr push sftp://bazaar.launchpad.net <---- is the right url. | 11:58 |
| === asac_ is now known as asac | ||
| === fta_ is now known as fta | ||
| === thunderstruck is now known as gnomefreak | ||
| jam | vila: ping | 13:26 |
| vila | jam: pong | 13:27 |
| jam | good morning | 13:29 |
| jam | Any chance you could try to review: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C493709CC.4090307%40arbash-meinel.com%3E | 13:29 |
| jam | I mentioned it to Aaron yesterday, but he hasn't commented. | 13:29 |
| jam | It seems it is a fairly serious regression in stacked repositories | 13:29 |
| jam | so I'd like to land it before 1.10 | 13:30 |
| jam | Also, I wanted to chat with someone whether I should be releasing 1.10-final today, or doing rc2 instead ? | 13:30 |
| jam | (Given that bug) | 13:30 |
| vila | Re-reading (but from last read you got at least a BB:I-like-the-topo-order-so-go-go-go :) | 13:32 |
| vila | You have one import pdb; pdb.set_trace() | 13:33 |
| vila | jam: My feeling there (having read the thread as it came in) is that sorting by topo order is the key. | 13:35 |
| vila | You know my feelings about it and here you say it makes things simpler (good) so it should make it more robust | 13:36 |
| jam | vila: thanks for catching the pdb, it sure stands out in BB :) | 13:37 |
| vila | 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 |
| jam | So... with just the topo-order fix, it will still create Fulltexts at merge revisions | 13:38 |
| vila | OrderingVersionedFilesDecorator is just a test helper ? | 13:38 |
| jam | OVFD is a test helper, yes | 13:38 |
| jam | I split it out into another patch | 13:38 |
| jam | though perhaps that got "superseded" | 13:38 |
| vila | Wow, so you really pinpoint the bug in the test | 13:38 |
| jam | yeah, it di: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C4936F5EF.2060208%40arbash-meinel.com%3E | 13:39 |
| vila | Ha, I thought I read that but wasn't finding it in the submission | 13:39 |
| jam | vila: yeah, the bug is really a cascade of about 3 different failures | 13:39 |
| jam | which made writing a test case.... interesting | 13:39 |
| jam | Considering the fix was small, it took me all day to finish the test case. | 13:40 |
| jam | but at least I got a full handle on the bug | 13:40 |
| vila | That itself grants aBB:approve I think | 13:40 |
| jam | and feel confident about the fix | 13:40 |
| vila | The code modification is light, you ran the full test suite ? | 13:40 |
| jam | I did not, I'm on win32 where it doesn't pass anyway | 13:41 |
| jam | I ran bits I thought were appropriate | 13:41 |
| jam | (And trust that PQM will run the whole thing for me :) | 13:41 |
| vila | Ok | 13:42 |
| vila | jam: voted | 13:43 |
| vila | 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 |
| vila | Are *you* the RM ? | 13:44 |
| jam | I'm the RM for 1.10-final(ish) | 13:47 |
| jam | yes | 13:47 |
| jam | poolie is away | 13:47 |
| vila | 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:53 |
| vila | I don't have a strong preference for rc2 or final anyway as long a 1.11 serie is opened anyway :-) | 13:54 |
| jam | vila: bug #304841 is on 1.10rc1 + martin's patch | 13:59 |
| ubottu | Launchpad bug 304841 in bzr "bzr push raises RevisionNotPresent" [Critical,Fix committed] https://launchpad.net/bugs/304841 | 13:59 |
| jam | his patch was for bug #303856 | 13:59 |
| ubottu | Launchpad bug 303856 in bzr "caching writes to pack repository causes ShortReadvError on pushing stacked branch" [High,Fix committed] https://launchpad.net/bugs/303856 | 13:59 |
| vila | I mixed up the two, thanks | 14:01 |
| vila | 303856 was targeted to 1.10final, that's a good hint to go with final | 14:01 |
| vila | I mean, you already put more polish on it (and addressed a critical bug), release ! | 14:03 |
| === thunderstruck is now known as gnomefreak | ||
| balor | 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:33 |
| balor | bzr remove | 14:35 |
| balor | just works | 14:35 |
| jam | balor: "bzr rm --keep" | 14:35 |
| balor | jam: I did bzr rm --force | 14:35 |
| balor | jam: then recreated the dir. | 14:35 |
| balor | jam: thanks though. | 14:35 |
| jam | np | 14:35 |
| jam | keep would have meant not needing to recreate it | 14:36 |
| LeoNerd | 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:51 |
| LeoNerd | The particular line that fails is File "/usr/lib/python2.5/site-packages/bzrlib/plugins/svn/remote.py", line 52, in __init__ | 14:54 |
| LeoNerd | assert svn_url.startswith(self.svn_root_url) | 14:54 |
| lifeless | balor: or bzr revert <dir> would have kept it too | 15:02 |
| LeoNerd | Ooh... OK.. bug perhaps? | 15:03 |
| LeoNerd | svn+ssh://server//root/path/here dies, svn+ssh://server/root/path/here works fine | 15:03 |
| jelmer | LeoNerd, any chance you can file a bug? | 15:04 |
| LeoNerd | debian reportbug be OK? | 15:05 |
| jelmer | yeah, sure | 15:05 |
| LeoNerd | done | 15:07 |
| lifeless | hi jelmer | 15:08 |
| === duzt|sleep is now known as duzt | ||
| jelmer | 'morning lifeless | 15:09 |
| lifeless | jelmer: did you see the bzr-svn branch I tossed up? | 15:15 |
| jelmer | lifeless, yeah, thanks for that | 15:15 |
| jelmer | lifeless, I'm about to rebase it on 0.5 | 15:16 |
| lifeless | jelmer: ok | 15:16 |
| jelmer | lifeless, merged into 0.5 | 15:18 |
| lifeless | jelmer: thanks. bzr-search needs get_transaction on repository (not direcyly, but for Repository.iter_file_bytes | 15:19 |
| jelmer | fwiw, bzr-svn doesn't do Repository.iter_file_bytes() | 15:20 |
| lifeless | File "/home/robertc/source/baz/bzr-test-fixes/bzrlib/repository.py", line 1399, in iter_files_bytes | 15:20 |
| lifeless | transaction = self.get_transaction() | 15:20 |
| lifeless | it inherits it | 15:20 |
| lifeless | File "/home/robertc/.bazaar/plugins/svn/repository.py", line 175, in get_transaction | 15:20 |
| lifeless | raise NotImplementedError(self.get_transaction) | 15:20 |
| LeoNerd | 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 |
| LeoNerd | It's been chewing away for about 10 minutes now.. | 15:21 |
| lifeless | jelmer: nvm, it canbe fixed in bzrlib. | 15:22 |
| lifeless | jelmer: this is a bit odd | 15:22 |
| lifeless | $ bzr search radix | 15:23 |
| lifeless | stacking support in bzr-svn is experimental. | 15:23 |
| lifeless | nevowlore.py in ... | 15:23 |
| lifeless | LeoNerd: it is calculating the shape of the repository in bzr terms | 15:33 |
| lifeless | LeoNerd: branches, per file graph and the like | 15:33 |
| LeoNerd | Right. It suddenly finished without warning :) I think the progress meter is broken | 15:34 |
| lifeless | LeoNerd: following that it will be able to start pulling | 15:34 |
| LeoNerd | It was claiming 0/204005 for aaages | 15:34 |
| LeoNerd | Hrm.. it doesn't preserve timestamps. No big issue, but it just upsets the stats a bit :P | 15:37 |
| lifeless | how do you mean? | 15:39 |
| LeoNerd | 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 |
| jelmer | LeoNerd, see the FAQ | 15:41 |
| jelmer | you can make bzr-svn modify the svn:date property, but it requires changing the settings in your svn repository | 15:42 |
| LeoNerd | Ahhright | 15:42 |
| lifeless | jelmer so - whats that stacknig warning about, that svn branch isn't stacked | 15:43 |
| jelmer | lifeless, it happens whenever versionedfiles are involved | 15:43 |
| lifeless | :( I know this is a repeating theme, but how can I turn that warning off? | 15:44 |
| jelmer | there's no way to disable it at the moment | 15:46 |
| jelmer | 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 |
| jelmer | and it allows people to do b0rked imports | 15:46 |
| jam | 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:46 |
| lifeless | jam: that was fast :P | 15:47 |
| lifeless | jam: tell me when to land it | 15:47 |
| lifeless | jelmer: how do you mean [borked imports] | 15:47 |
| jam | lifeless: I saw it on the bazaar-commits list while going through some other stuff :) | 15:47 |
| jam | I'll let you know when PQM is free | 15:48 |
| jelmer | lifeless, if you use "bzr branch --stacked" it uses versionedfiles and that can broken | 15:48 |
| jelmer | if there's some easy way to only warn when doing a stacking clone, I'm happy | 15:48 |
| jam | 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 |
| jam | I found a couple small issues for it | 15:48 |
| jam | and would like to get it merged into bzr.dev | 15:49 |
| jam | so we can have the improved version in-play and under-regular-testing | 15:49 |
| lifeless | jam: I had hit commit 2 seconds earlier :) | 15:49 |
| lifeless | jelmer: what goes wrong with the imports if they do this? | 15:50 |
| lifeless | jam: well first, add_inventory_delta, which poolie had some review feedback on | 15:50 |
| jam | lifeless: I don't see your "apply_inventory_delta" fix in BB | 15:51 |
| jam | ah, this one? http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ce01316480811102304s60b1df9cnf62aec9748a61346%40mail.gmail.com%3E | 15:51 |
| jelmer | lifeless, inconsistent text parents, text contents | 15:51 |
| lifeless | jelmer: ! | 15:51 |
| lifeless | jam: no | 15:51 |
| jelmer | lifeless: this is why there is a warning :-) | 15:52 |
| jam | yeah, looking closer I realized that | 15:52 |
| jam | still looking | 15:52 |
| lifeless | jelmer: your warning is not accurate :P its not experimental its known broke | 15:52 |
| jelmer | lifeless, I'm not aware of any cases where that has happened, but the code is not very well tested | 15:52 |
| jelmer | and that's the sort of thing that *would* happen | 15:52 |
| lifeless | jelmer: oh | 15:53 |
| lifeless | jam: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1223873271.9015.266.camel%40lifeless-64%3E | 15:53 |
| jam | lifeless: what do you think about calling it "add_inventory_by_delta" ? | 15:54 |
| jam | And was Martin's main complaint that it was against an arbitrary rev? Rather than only the basis? | 15:55 |
| jam | I guess you already agreed to _by_delta | 15:56 |
| lifeless | I'm fine with add_inventory_by_delta, it is more clear | 15:57 |
| jam | 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 |
| lifeless | thats the basis_delta list | 15:57 |
| jam | If you haven't said "recording_deletes = True" it is not an accurate delta? | 15:58 |
| lifeless | see the list for a convesation - bb deleted his initial comments when he commented again | 15:58 |
| lifeless | jam: yes | 15:58 |
| lifeless | jam: so I proposed to him that we make basis_delta be get_basis_delta() | 15:58 |
| jam | and we need to not have a delete for the current functionality? | 15:58 |
| lifeless | and if you haven't called recording_deletes, then get_basis_delta() errors | 15:58 |
| jam | 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 |
| jam | It seems like you would need it to update the WT as well | 15:59 |
| lifeless | the existing commit driver generates it's own basis delta object | 16:00 |
| lifeless | that is | 16:00 |
| lifeless | 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:00 |
| lifeless | 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 |
| Tak | are there existing bzr icons somewhere for things like branch, pull, merge, ...? | 16:01 |
| lifeless | Tak: bzr-gtk might have some | 16:01 |
| lifeless | jam: breakfast time | 16:01 |
| jam | lifeless: eat hardy. I think I have a feeling now | 16:02 |
| jam | so basically, you want get_basis_delta() to fail if you aren't aware of the new API | 16:02 |
| Tak | it appears to be using stock gnome icons atm | 16:02 |
| lifeless | jam: yah; simply if !self._recording_deletes: raise AssertionError("you can't use this until you've updated your apip usage per ...") | 16:02 |
| jam | 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 |
| jam | I suppose we have a slightly smaller api compatibility issue if we just have a function on CommitBuilder | 16:11 |
| jam | as SVNCB can just inherit that function | 16:12 |
| jam | (though if it doesn't respect it... we have a problem anyway, so probably better to have it fail) | 16:12 |
| jam | who are all these people that have bzr-dbus installed? | 16:13 |
| jam | Is it a Recommends somewhere? | 16:13 |
| lifeless | jam: for compatibility I avoided constructor | 16:36 |
| jam | yeah, I went that route too | 16:36 |
| lifeless | jam: a client that does not use the function will work fine | 16:36 |
| lifeless | 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:36 |
| lifeless | jam: probably | 16:37 |
| lifeless | (re bzr-dbus) | 16:37 |
| jam | ? | 16:40 |
| lifeless | 03:11 < jam> who are all these people that have bzr-dbus installed? | 16:40 |
| lifeless | 03:11 < jam> Is it a Recommends somewhere? | 16:40 |
| jam | Ah probably a Recommends | 16:41 |
| jam | sure | 16:41 |
| jam | I thought that was the last line of the previous statement. :) | 16:41 |
| jam | 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 |
| jam | It means requiring an Inventory.copy() which is a bit slow | 16:43 |
| jam | but is necessary for CHK inventories. | 16:43 |
| jam | We happen to know the lifetime of the inventory in add_inventory_by_delta is safe | 16:43 |
| jam | but apply_delta is not always a safe function otherwise. | 16:43 |
| lifeless | jam: I don't think so | 16:50 |
| jelmer | jam, bzr-gtk recommends bzr-dbus | 16:51 |
| lifeless | jam: create_by_apply_delta doesn't make sense to me on th ein memory invetory, not in the same way | 16:57 |
| lifeless | jam: the key ting here is that *repository* is the interface for adding inventories to | 16:57 |
| lifeless | jam: heading over to MV now, lets chat in about 2 hours ater the opening | 17:04 |
| jam | np | 17:05 |
| jam | enjoy the show :) | 17:05 |
| jam | lifeless: you can go ahead and submit your iter_files_bytes fix. | 17:28 |
| jkakar | 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 |
| jam | jkakar: bzr uncommit | 17:37 |
| jkakar | jam: That won't work, as I did the commit several revisions ago. | 17:37 |
| jam | jkakar: it would still work, you just have to do more to get things back | 17:37 |
| jkakar | 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 |
| jam | however, you can install the bzr-rebase plugin | 17:37 |
| jam | and have it help you recreate the extra revs | 17:38 |
| jkakar | bzr-rebase has never worked for me. I probably don't understand how to use it. | 17:38 |
| jam | jkakar: I *think* you want bzr uncommit -rBEFORE_I_WAS_FOOLISH | 17:38 |
| jam | bzr revert | 17:38 |
| jam | bzr replay -r AFTER_I_WAS_FOOLISH..-1 | 17:39 |
| jam | well, you probably need to keep 1 branch around to replay from | 17:39 |
| jkakar | Woah. I'll try that, thanks. | 17:39 |
| jam | make sure to check "bzr help replay" just in case I have some syntax wrong | 17:39 |
| jkakar | jam: It worked! Thanks a lot. :) | 17:58 |
| jam | np | 17:58 |
| === 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/ | ||
| lzhang | is there an easy way to see files that have been bzr rm'd in the file? | 18:45 |
| lzhang | in the current directory* | 18:46 |
| lzhang | bzr rm'd and committed in the past | 18:46 |
| etank | 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:53 |
| etank | the initial bzr init, etc was done on the ubuntu box | 18:54 |
| jam | 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 |
| jelmer | bleh, I suck at this | 18:55 |
| jelmer | jam, Sorry, that's at least the third time you have to remind me :-( | 18:55 |
| etank | i get the following when i try to do a branch | 18:56 |
| etank | C:\Documents and Settings\user\Desktop>bzr branch ssh://user@ipaddr:~/Code myCode | 18:56 |
| etank | bzr: ERROR: Unsupported protocol for url "ssh://user@157.184.82.74:~/Code" | 18:56 |
| jelmer | etank, you probably want sftp:// or bzr+ssh:// | 18:56 |
| jelmer | jam, should be tagged now | 18:57 |
| jam | jelmer: so you are now tagging it as "debian-0.4.16" right? | 18:58 |
| jam | rather than bzr-svn-0.4.16 | 18:58 |
| jam | btw, 0.4.15 also is not tagged | 18:58 |
| etank | jelmer: with either of those i get this now "bzr: ERROR: Invalid url supplied to transport: "invalid port number ~ in url:" | 18:58 |
| jelmer | etank, please use a / rather than a : | 18:59 |
| jam | etank: the URL you want is probably: sftp://user@host/~/Code | 18:59 |
| jam | if you want to use bzr+ssh then it would be | 18:59 |
| etank | ok | 18:59 |
| jam | bzr+ssh://user@host/home/user/Code | 18:59 |
| jelmer | jam, yeah, debian-0.4.16-1 | 18:59 |
| jam | bzr+ssh doesn't support ~ yet | 18:59 |
| === evarlast is now known as jmcw | ||
| jam | jelmer: that really messes up the bzr-builddeb I have | 18:59 |
| jam | as in... it always wants bzr-svn-0.4.16 | 18:59 |
| jelmer | jam, I'm still tagging the upstream release as bzr-svn-0.4.16 | 19:00 |
| jam | Ah, I guess I just need to edit .bzr-builddeb/defaults.conf | 19:00 |
| jelmer | jam, just the debian packaging as debian-0.4.16-1 | 19:00 |
| jelmer | jam, so you want to merge in debian-0.4.16-1 but have it build against bzr-svn-0.4.16 | 19:00 |
| jam | k, I should mention the bzr-svn-0.4.16 isn't there *either* | 19:01 |
| jam | and neither is 0.4.15 | 19:01 |
| jam | nor debian-0.4.15 | 19:01 |
| jelmer | 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:01 | |
| jam | 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 |
| jelmer | jam, now pushed with the original upstream tags | 19:02 |
| etank | bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is require | 19:02 |
| jam | I'm not sure why they aren't in your packaging branches | 19:02 |
| etank | d) | 19:02 |
| etank | HPSS calls: 1 <bzrlib.smart.medium.SmartSSHClientMedium object at 0x01714810> | 19:02 |
| jelmer | jam, bzr-builddeb's "bzr merge-upstream" command used to not pull in tags | 19:02 |
| etank | thats what i got with bzr+ssh | 19:02 |
| jelmer | I think James fixed that recently | 19:02 |
| jam | etank: if you are getting that, it means the ssh connection closed | 19:03 |
| jam | What version of the bzr client are you using ? | 19:03 |
| etank | im not sure why though | 19:03 |
| etank | one sec | 19:03 |
| jam | "bzr --version" should tell you | 19:03 |
| etank | bzr-setup-1.9.exe | 19:03 |
| etank | Bazaar (bzr) 1.9 | 19:03 |
| jam | k, that one should be fine | 19:03 |
| etank | i can ssh to the box with no problems using putty | 19:04 |
| jam | etank: are you using custom keys or anything like that? | 19:04 |
| jam | or just username & password? | 19:04 |
| etank | nope. password loging | 19:04 |
| etank | login i mean | 19:04 |
| jam | and when you do "bzr branch bzr+ssh://..." it doesn't prompt you for a password? | 19:05 |
| etank | jam: nope | 19:05 |
| etank | C:\Documents and Settings\elake\Desktop>bzr branch bzr+ssh://elake@157.184.82.74/Code myCode | 19:06 |
| etank | bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is require | 19:06 |
| etank | d) | 19:06 |
| etank | that is the exact ouput | 19:06 |
| etank | i wonder if it is something in the sshd_config that needs to be changed | 19:06 |
| === jmcw is now known as evarlast | ||
| jam | etank: ah, I have an idea | 19:08 |
| jam | try doing | 19:08 |
| jam | set BZR_SSH=paramiko | 19:09 |
| jam | on the command line | 19:09 |
| jam | and then running bzr branch | 19:09 |
| jam | and if that fails | 19:09 |
| jam | try | 19:09 |
| jam | set BZR_SSH=plink | 19:09 |
| jam | plink should fail because it doesn't support passwords as a sub-process | 19:09 |
| jam | but it may fail in a *different* way | 19:09 |
| jam | etank: did you rename "plink" to "ssh" btw? | 19:10 |
| jam | as that would probably confuse us | 19:10 |
| etank | nope | 19:10 |
| etank | neither of those worked | 19:10 |
| etank | pscp elake@elake-ibex:/home/elake/Code/mailer.py ./ <-- that command would work though | 19:10 |
| jam | etank: you might try looking at "My Documents\.bzr.log" to see if there is any more info there | 19:11 |
| etank | SocketConnectionError: Unable to connect to SSH host 157.184.82.74; EOF during negotiation | 19:11 |
| jam | jelmer: Why would "dch" keep trying to add a new record with your name instead of mine? | 19:11 |
| jelmer | I'm listed as maintainer | 19:12 |
| jelmer | debia/control | 19:12 |
| jam | jelmer: yeah, I was accidentally using "-m" thinking I needed it as the update message | 19:13 |
| jam | rather than realizing it set the "use the ID of a maintainer" flag | 19:13 |
| jelmer | I've done that a couple of times as well | 19:14 |
| jelmer | bzr commit ruined dch for me | 19:14 |
| jam | etank: does it say anything about failing to import paramiko, etc? | 19:14 |
| etank | jam: no but here is the output of the last two tests http://dpaste.com/96468/ | 19:18 |
| etank | maybe the .ssh/know_hosts part is the issue | 19:18 |
| jam | etank: can you try using "sftp://" just to see if that gives different results? | 19:19 |
| jam | (I don't expect it to, but we can try it) | 19:19 |
| etank | jam: same thing | 19:20 |
| * etank wonders where putty puts is known_host info | 19:20 | |
| jam | etank: with bzr-1.9 we shouldn't actually be using putty | 19:21 |
| jam | we should be using paramiko to connect | 19:21 |
| jam | as plink doesn't allow us to ask the user for a username and/or password | 19:21 |
| jam | (so it works only if you are using ssh keys) | 19:21 |
| etank | i was going to look at puttys file and place it where bzr wants to find it | 19:21 |
| jam | I don't *think* it is a known_hosts issue | 19:22 |
| jam | something weird is going on, though if both "BZR_SSH=paramiko" and "plink" are failing | 19:23 |
| etank | bzr: ERROR: Unable to connect to SSH host elake-ibex; (10061, 'Connection refused') | 19:23 |
| jam | what shell are you using? | 19:23 |
| etank | windows command shell | 19:23 |
| jam | and you don't have something like a non-standard ssh port, right? | 19:23 |
| etank | cmd.exe | 19:23 |
| etank | nope | 19:23 |
| etank | 22. default install on the ubuntu side | 19:23 |
| etank | back in a few | 19:27 |
| jam | etank: ... for the .bzr.log you gave, I can imagine that if BZR_SSH is plink it will fail because we cannot ask for a password | 19:32 |
| jam | for the "set BZR_SSH=paramiko" I don't see why it would be failing | 19:32 |
| jam | for the other one, it is definitely *using* paramiko | 19:33 |
| jam | as the exception traceback is coming from that code | 19:33 |
| lifeless | jam: so | 19:42 |
| lifeless | jam: I don't mind if you want to write a create_by_apply_delta for Inventory, but I don't think its going to be any faster or anything; and its another method to support | 19:42 |
| lifeless | create_by_apply_delta on CHKInventory was/is semi private | 19:43 |
| jam | I agree that it isn't going to be faster | 19:44 |
| jam | it is more about consistent apis between different Inventory implementations | 19:44 |
| jam | considering that "apply_delta" is public | 19:45 |
| jam | and certainly a more dangerous function than "create_by_apply_delta" | 19:45 |
| lifeless | apply_delta isn't on CHKInventory at all | 19:46 |
| LarstiQ | jelmer: how about a bzr-dch plugin? ;) | 20:04 |
| jam | lifeless: I seem to be getting build failures for bzr-svn because it can't find the bzr packages | 20:05 |
| jam | and the bzr-svn ones require >1.10 | 20:05 |
| jam | do you know if this is just transient? | 20:05 |
| jam | (I also happened to upload bzr-svn *before* I uploaded bzr, as I was trying to make sure I got all the packages built before I updated the ppa) | 20:05 |
| jam | (but I already did one "retry" and it still is unhappy) | 20:06 |
| lifeless | jam <-> jelmer | 20:10 |
| lifeless | jam: You'll need to up load bzr, upload bzrtools, upload bzr-svn, then update the ppa | 20:10 |
| lifeless | this requires a separate ppa and package copying | 20:10 |
| jelmer | jam, you may get away with a build-dependency on 1.9 | 20:11 |
| jam | So the specific error seems to be this line: | 20:12 |
| jam | After installing, the following source dependencies are still unsatisfied: bzr(inst 1.9-1~bazaar1~hardy1 ! >= wanted 1.10~) | 20:12 |
| jam | And I'm concerned about whether the 1.10-1~bazaar1~hardy1 | 20:12 |
| jam | is evaluating versus 1.10~ correctly | 20:12 |
| jam | well, *will* evaluate | 20:13 |
| jam | obviously it is only finding the old 1.9-1 so far | 20:13 |
| jam | hmm.. bzrtools built fine | 20:19 |
| jam | ah, but Jelmer didn't update the control file for bzrtools | 20:19 |
| jam | it still says 1.9~ | 20:19 |
| jelmer | jam, I didn't update the build dependency | 20:21 |
| LarstiQ | 1.9~ for what, the version of bzrtools, or the dependency on bzr? | 20:21 |
| jelmer | jam, that's still at >=1.9~, but shouldn't matter | 20:21 |
| jelmer | jam, the runtime dependency I did update | 20:21 |
| jam | LarstiQ: the bzrtools 1.10 package only depends on bzr 1.9 | 20:22 |
| jam | for some reason, the bzr-svn ppa is failing to build the 0.4.16 package because it depends on bzr >= 1.10~ | 20:22 |
| jam | I don't know if it was because my upload ordering was reverseed | 20:22 |
| jam | or if it is just having a problem finding the packages now that they are present in the ppa | 20:22 |
| jam | I would guess that my upload order confused the initial attempt | 20:23 |
| jelmer | jam, what makes you say bzrtools depends on bzr 1.9..? | 20:23 |
| rocky | jelmer: hey, is there a bzr-svn release for bzr 1.10 yet? | 20:23 |
| jam | but I would have thought it fixed when I did "retry" | 20:23 |
| jam | rocky: bzr-svn 0.4.16 | 20:23 |
| jam | jelmer: Build-Depends-Indep: bzr (>= 1.9~), rsync | 20:23 |
| jam | though I also see: | 20:23 |
| rocky | awesome, thanks | 20:23 |
| jam | After installing, the following source dependencies are still unsatisfied: bzr(inst 1.9-1~bazaar1~hardy1 ! >= wanted 1.10~) | 20:24 |
| jam | sorry | 20:24 |
| jelmer | jam, That's just saying building the package should work with 1.9 and 1.10 | 20:24 |
| jam | Depends: ${python:Depends}, bzr (>= 1.10~), bzr (<< 1.11~), patch | 20:24 |
| jelmer | jam, seems fine to me | 20:25 |
| jam | Well, bzr-svn does have "bzr >= 1.10~" in its "Build-Depends" | 20:25 |
| jam | which bzrtools doesn't have | 20:25 |
| LarstiQ | I don't think bzrtools needs it? | 20:26 |
| jam | to build? probably not | 20:26 |
| jam | I would have assumed bzr-svn wouldn't need it to *build* either | 20:27 |
| jam | The discussion may not matter in a bit | 20:27 |
| jam | as it seems the ppa *might* be figuring out that it really does have access to bzr >= 1.10 now | 20:27 |
| jam | at least, the link to the "lpia" build went away | 20:27 |
| jam | which I'm hoping means it successfully built | 20:28 |
| jam | In the future, I just need to make sure to upload bzr before any plugins | 20:28 |
| jam | It certainly has to be able to grab packages from the ppa itself, otherwise it wouldn't have been able to install bzr-1.9 either | 20:29 |
| jam | since that only exists in a ppa, IIRC | 20:29 |
| jam | I didn't think 1.9 has made it into any release | 20:29 |
| BratscherBen | is there a possibility to use Hooks as in subversion? As far as I see, hooks in bzr are registered in ~/.bazaar/plugins which affects all usage of bzr. In my concrete example I want to run a bzr export in a remote repository after push, but not in all my repositorys. | 20:41 |
| etank | jam: yeah i did the set for paramiko and it is still a no go | 20:42 |
| LarstiQ | BratscherBen: hooks can check which branch they're operating on, and have programmatice access to it's branch.conf | 20:42 |
| LarstiQ | (and to ~/.bazaar/ config as well if needed) | 20:43 |
| BratscherBen | yes, but I want that this command is run not only when I check something in, but also when others do | 20:43 |
| BratscherBen | so is the post_push hook called on the remote server, when somebody pushes or only on the machine that pushes? | 20:45 |
| BratscherBen | the docu says “runs on client” | 20:46 |
| jam | BratscherBen: there is a hook that is run on the server side (post-branch-tip-changed, IIRC) | 20:47 |
| BratscherBen | yes, just found it | 20:47 |
| jam | Apparently it may be getting a semi-bogus URL at the moment (because when run on the server things are run in a chroot) | 20:47 |
| etank | im not getting the bzr on windows thing :/ | 20:48 |
| BratscherBen | so I assume I have to install a plugin in /usr/share/pyshared/bzrlib/plugins for which I also need root access and have to check there, from which repository I am called | 20:49 |
| lifeless | BratscherBen: you should set the hook on the server, it will run for all branches on the server; you can then filter that down by checking its a branch you want to take the action on | 20:49 |
| jam | etank: unfortunately, it "just works" here... which makes it all the more difficult | 20:49 |
| jam | also, when we use an all-in-one installer we lose some of the ability to debug | 20:49 |
| jam | if it was installed into a regular python install | 20:50 |
| BratscherBen | sounds like a solution, but not a nice one | 20:50 |
| etank | i can do a regular python install | 20:50 |
| jam | then you can drop down into a python shell, and try various things | 20:50 |
| etank | jam: will it work with py2.6? | 20:50 |
| etank | the site said 2.4 and 2.5 so that is why i went with the all in one installer | 20:50 |
| jam | vila has been working on 2.6 compatibility. I believe it currently works | 20:50 |
| jam | They did some odd backwards-incompatible changes in 2.6 | 20:51 |
| LarstiQ | but there might not be a 2.6 installer | 20:51 |
| BratscherBen | the solution in other vcs are nicer, why bzr has not such an option to just run a shellscript in .bzr/hooks/post-tip-change ... | 20:51 |
| jam | LarstiQ: I would guarantee there isn't :) | 20:51 |
| jam | BratscherBen: in a distributed setup, you don't always have control over ".bzr/hooks/*" and that tends to lead to running $RANDOM other person's code | 20:52 |
| jam | which is a good way to have a security problem | 20:52 |
| jam | That said, there is a "shell-scripts" plugin that adds support for shell hooks | 20:52 |
| BratscherBen | the person who owns the repository has control over this | 20:52 |
| jam | I don't remember the exact name | 20:52 |
| lifeless | BratscherBen: there is a plugin that can do what you want; but you can as a user in your own account setup plugins too | 22:09 |
| === duzt|sleep is now known as duzt | ||
| BratscherBen | I managed it now with this shell-scripts plugin. Problem here is a bit, that the post_change_branch_tip_hook is executed while a still is in progress and so the lock is not free. I made a workaround like {sleep 3; bzr export foo.zip} around to avoid this, but it of course is not really nice | 22:23 |
| BratscherBen | but it works, thanks for the answers… | 22:24 |
| luigi | hi | 22:43 |
| luigi | is python 2.6 supported? | 22:43 |
| LarstiQ | luigi: it should be | 22:47 |
| luigi | ok | 22:47 |
| NfNitLoop | 3.0? ;p | 22:49 |
| luigi | yeah | 22:49 |
| NfNitLoop | ... really? | 22:50 |
| luigi | dont know | 22:50 |
| LarstiQ | NfNitLoop: no | 22:50 |
| NfNitLoop | I didn't figure so. :) | 23:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!