[00:28] yay, bzr-svn is now feature complete \o/ [00:28] jelmer: oh? [00:28] spiv, annotate and eliminating svn-push were the last remaining bits [00:30] \o/ [00:30] jelmer: sweet [00:30] * james_w opens the champagne [00:31] wow way to go [00:33] jelmer: someone on another channel asks about svn:externals ;) [00:33] spiv: that requires bzr itself to support them first :-) [00:33] jelmer: :) [00:34] the server side ("bzr svn-serve" or "bzr serve --svn") is also not done yet [00:34] jelmer: that's ok, neither is native "bzr serve" ;) [00:48] jelmer: yay [00:50] jelmer: will there be a 0.6 or will this be 0.5.3 ? [00:51] mwhudson, 0.5.3 or 1.0.0 [00:51] jelmer: cool [00:51] jelmer: are you going to make lp:bzr-svn non-remote again at some point? [00:52] mwhudson: Only if there's some way to keep the copy on launchpad up-to-date rather than between 0 and 8 hours out of date [00:53] it _should_ be possible to write a hook that uses the api to request a mirror by now [00:53] but i don't think one has been written [00:54] lifeless: trailing whitespace just bit me too [00:56] heh [00:56] jelmer: grats [00:56] jelmer: there is an xmlrpc thing you can call, apparently. [00:57] ah actually no [00:57] it was a literal tab, and that was worth catching [00:57] heh [00:57] yes they are worth catching [00:58] did you resubmit your test_source patch? [00:58] if not i will [00:58] mwhudson, yeah, I still need to look at that [00:58] mwhudson, or hope somebody else does :-) [00:59] jelmer: i'll take your requirements on board :) [00:59] poolie: no, because marius said he would [00:59] poolie: the more clean version [01:00] now I remember one of the issues with bzr-svn, it gets exponentially slower as it goes. [01:01] Jerub, Which version are you using? [01:01] 0.5 [01:01] Jerub, try 0.5.2 [01:01] that should be significantly faster [01:01] in particular on large repositories [01:01] jelmer: why don't you use hosted branches btw? [01:04] jelmer: well, I've just cancelled the svn-import that had been going for over an hour [01:04] jelmer: so I hope this is faster. [01:06] mwhudson: It ties me into Launchpad, over which I have no control. [01:07] mwhudson: Hosting on a different machine and mirrorring into launchpad (which is still done, just not into lp:bzr-svn) means there's always a backup [01:07] *also means [01:07] fair enough [01:07] though i hope launchpad isn't going to go away any time soon :) [01:08] we have backups on tape too [01:08] why bother? raid is good enough to back everything up. [01:09] Jerub: raid isn't very good at preserving data eaten by fat fingers :) [01:09] or fires [01:10] mwhudson: pfft, nature [01:10] Sorry, I couldn't help it. My sarcasm exploded over the channel. [01:11] (I've actually had an office fire, and recovered from offsite backups) [01:12] Jerub: :) [01:13] http://www.facebook.com/pages/Bazaar/128354670412?sid=7bd5847db77e5312163ecf237785b8c9&ref=s [01:13] Jerub: backup strategies is a topic a bit like editor or vcs preferences... [01:13] mwhudson: that's a bit random [01:14] Maybe we should replace our wiki with a myspace page ;) [01:17] spiv: I think until you've had to count the minutes until the wholesaler turns their phone system on in the morning so you can ask for immedate delivery of half a dozen servers, you can't really appreciate the value of offsite backups fully. [01:18] igc1: how are you going [01:18] spiv: also, I've a _huge_ long pull going from python.org [01:18] 1448 byte packes [01:19] jelmer: is there a reason I should be told to upgrade to svn 1.5 if I'm using svn 1.5 already? [01:19] jelmer: hours now :(. So not sure sure why [01:19] lifeless: 1448 is better than 510! [01:20] jelmer: also, this is /significantly/ faster. after 20 minutes I'm past branch discovery and on copying revisions, last run I'd not gotten through 75% of branch discovery [01:20] spiv: 510 was the window size :( [01:21] spiv: we should use facebook for canonical's calendaring needs! [01:21] Jerub: The 1.5 warning should be fixed in the next version [01:22] jelmer: awesome [01:26] spiv: I've stopped it after 99m [01:26] spiv: oh! I have an idea [01:27] spiv: ping [01:27] you're going to try TCP/spiv? [01:27] james_w: no, I think we might be partial-reading from the socket [01:27] which will lead to acking less than we can [01:28] ah [01:28] lifeless: have you straced it to see how big the reads are? [01:28] Jerub: about to [01:29] lifeless: pong [01:30] spiv: see before [01:30] Hmm, read sizes? [01:32] lifeless: it should always be trying 64k when reading from a TCP socket [01:32] spiv: yeah, I've just validated that [01:32] spiv: and its often getting way less [01:33] recvfrom(4, "\0\1\242B406\ntexts\n\nknit-ft-gz\n2160@6"..., 65536, 0, NULL, NULL) = 5792 [01:33] recvfrom(4, "cc4771:python%2Ftrunk:Lib%2Ftest"..., 65536, 0, NULL, NULL) = 1448 [01:33] recvfrom(4, "\2\377\255\223\273\262\333 \20\206{?\3056\231\330\216\344"..., 65536, 0, NULL, NULL) = 5792 [01:33] (It is less optimisitic when reading the pipe from a bzr+ssh connection, but that's not the issue here obviously) [01:34] spiv: however, we haven't tested raw protocol from the dc [01:34] spiv: it could be :P [02:14] Hello all! Let's see how much I can learn tonight. First time VCS user, reviewed CVS/SVN/Git, and all those other ones, and decided on this one ^_^ [02:14] Just because the commands made alot more sense, then those other ones. Like "whoami", simple, lol [02:16] Anyways, just got through the quick user guide, and my question is this. Okay, I commit my file, lets say I finished my project, and want to look back, how do I do that? [02:16] bzr log? [02:17] Like, what Im trying to say, I'm working on my project, and I decide to try something new. So I go route A, decide it's "okay", and start going a different route, route B, can I do that? And revert back to the "fork" in the road [02:19] I don't know, I tried that in the documentation, it worked, but isn't working now. And It just showed my commits, not the file itself :/ [02:24] also, bzr diff, and log, aren't working anymore, wtf [02:24] do I have to specify a file or something? [02:24] bzr log filename ? [02:26] riyo: no, they default to the whole tree [02:26] riyo: are you in the right directory? [02:31] Yeah I am [02:32] so what do you mean by not working? [02:32] do you get an error msg? [02:33] Let me upload a picture ^_^ [02:35] http://i44.tinypic.com/141teu8.png [02:35] There, is it supposed to do that? It just shows comments, which btw, is that a mispelling? commits? [02:35] :) [02:36] that's what bzr log is meant to do, yeah [02:36] 'committer' is the person who committed [02:36] Is that pronounced "comment-er", or "commit-er"? [02:36] the second [02:37] they're called commits, not comments [02:38] But...they....are comments, lol [02:38] How confusing. [02:38] Anyways, what's the point? Don't I want to see what source code of mine changed? [02:39] i don't know, do you? :) [02:40] Ugh, yeah, otherwise theres no point, lol [02:40] I wish it was just a hotkey, for a "snapshot", and I could scroll through each picture, lol [02:41] riyo: you can do "bzr diff -c 2" to see changes made in commit 2. [02:43] WTF does that mean, lol --> @@ -0,0 +1,1 @@ [02:43] ...is this some sick joke :P [02:43] riyo: thats standard notation for showing a textual change of a file [02:44] riyo: it means from line 0, for 0, to line 1, for 1 [02:45] This is overly complciated. [02:45] Is this really the answer I'm looking for? [02:45] Cause heres my problem. [02:46] I create php websites, take the index.php file for example. I work on it, but before I do, I make a backup, just incase I mess up everything [02:46] I end up with 100's of copies, lol, untill I'm finished or have scraped it. [02:46] Is this my solution? [02:47] riyo: yes [02:47] riyo: you might find that some of the GUI tools make exploring the saved history a bit easier [02:48] riyo: with bzr you won't need as many copies, the bzr-upload plugin can make deploying your websites easier [02:48] riyo: if your installation has the "qbzr" plugin, then "bzr qlog" is quite good. [02:49] riyo: if you just want to view a file as it was at an earlier revision, use "bzr cat -r 2 path/to/file" [03:14] I wish there was a video tutorial. If I ever get the hang of this, I'm so making one. [03:16] bzr: ERROR: QBzr require at least PyQt 4.1 and Qt 4.2 to run. Please check your install [03:17] * igc1 lunch [03:36] spiv: doing get_parent [03:39] igc1: ping [03:50] hi jml [03:50] igc1: hi [03:50] igc1: I have a story about logging that I'd like your help with [03:51] igc1: I've heard a rumour that you touched log last? [03:51] jml: :-) [03:51] igc1: so... what I want to do is find all the commits that I've made to Launchpad via PQM since the last release. [03:52] igc1: the way I can tell if a commit was mine is if I'm the author of one of the parents of a mainline revision [03:52] I can write that as a predicate function with little to no worries [03:52] igc1: what I want is a way of passing a predicate function to show_log to filter the revisions I see. [03:53] jml: hmm [03:54] jml: log needs restructuring and vila and I still don't agree on how [03:54] igc1: ok. [03:54] I'd do a filter [03:54] it can buffer a little and so on and feed it out [03:54] igc1: so, doing 'if foo(revision): yield revision' is going to be a bit slow, obviously [03:54] then give the filte ra predicate as a parameter [03:55] jml: I think we ought to add a --user option (or something like that) that matches on a name ... [03:55] igc1: +1 on more capabilities, -1 on new options, I'd really rather agree on a search language and use that [03:55] what I *really* want is Bazaar Query Language [03:55] possibly propagatng upwards to the mainline as file filtering does [03:55] igc1: so that bzr-search can do it fast [03:55] lifeless: great minds :) [03:56] BQL is Python :-) [03:56] jml: as a short-term thing ... [03:57] log --line -n0 | grep Lange [03:57] make it a contenxt grep if that helps [03:58] igc1: ... and then filter that to find the mainline revisions .... [03:58] lifeless: bzr-search is nice but it doesn't exclude making log easier to use [03:58] bzr log --user me [03:59] and [03:59] bzr log --user @names-in-file [03:59] have plenty of value to casual users - a query language is just too advanced for them [04:01] lifeless: we can use bzr-search behind the scenes to make it efficent of course [04:01] igc1: so, if I could do that and then only see mainline revisions which I pqm-submitted, I'd be happy [04:01] iff it's installed [04:01] (although the *real* bug there is that PQM doesn't set author) [04:02] jml: right [04:02] jml: but even if it did, there would still be a use for seeing mainline revisions where a user authored one of the merged revisions [04:03] igc1: bzr log -m user:me [04:03] I guess the new multiple author field could simplify that [04:03] igc1: I do think some sort of domain-specific language/API for specifying searches would be a good idea. [04:03] igc1: bzr-search is orthogonal yes, but adding many many options is not great [04:04] jml: so *just* matching against a revision isn't smart enough [04:04] igc1: agreed. [04:05] although it's smart enough if I'm writing the revision-matching function :) [04:06] igc1: I wasn't proposing depending on bzr-search, I was proposing that many-options is not a better UI [04:06] jml: but log, except for file filtering, isn't structured that way btw [04:06] igc1: the revision filters are iterators, or they were [04:06] lifeless: sure [04:06] igc1: so it should handle arbitrary filtering just fine [04:06] igc1: ok [04:07] but the level filtering takes out merged revisions it's never going to display before those iterators are called [04:07] so log -n0 only passes you the mainline revisions [04:08] it's all part of "don't generate stuff you don't need" [04:08] "smart" filtering like jml wants means ... [04:09] hello knowledgeable people [04:09] what port does git talk to the internet over? [04:09] a revision filter needs to say "give me everything and then post filter the levels out" [04:09] except for file filtering, we don't do that currently [04:10] lifeless: I like the -m user:me idea btw [04:11] igc1: can't the level filtering happen as a normal filter in the chain so you can get there first? [04:12] lifeless: there's a high cost (> 60 sec overhead) for getting all levels for mainline for large repos [04:12] s/for/vs/ [04:13] we only want to do it if we really need to [04:14] oh wow, bzr-svn 0.5.2 actually worked. [04:15] jml: so the short answer is ... [04:15] post processing log --line -n0 is an order of magnitude easier than extending log as you want right now [04:15] hmm - maybe 2 orders of magnitude [04:16] heh, ok. [04:16] I'm going to try for a middle way, writing my own crappy log-like command. [04:17] lifeless: on anotrher topic and answering your earlier Q, I'm making much better progress ... [04:17] thanks to your assistance yesterday [04:17] I'm hacking repodetails as discussed [04:18] spiv: ping [04:18] jelmer: why does bzr-svn count down for 'discovering revisions' while doing a bzr pull [04:18] though *generating* branches in the new formats is still proving painful [04:19] upgrade works for development5 but simply refuses to for ... [04:19] formats like gc-plain-chk255, even for really simple branches [04:20] at least now I know enough to stand a chance of traking down the problems [04:20] lifeless: pong [04:20] spiv: tommorrow I'm likely to be largely offline [04:20] spiv: and its freeze then [04:20] I'm just finishing off branch.get_parent verb [04:20] have you been working on stacked pull ? [04:21] though the immutable nature of CHKInventories means fastimport is currently out of service as a test branch generation avenue [04:22] lifeless: no, not yet :/ [04:22] igc1: if fastimport was mutating invnetories inRevisionTree's, it was being naughty [04:22] igc1: thats *never* been a intended capability [04:22] crud, that was my problem. I thought I wanted bzr svn-import when I actually wanted bzr checkout [04:22] lifeless: it wasn't [04:23] it was copying the basis and then using the API (add/del, rename, remove_recursive_id) to build the new one [04:23] ok [04:23] that would be slow [04:24] using CommitBuilder would be better [04:24] because it will calculate the per file graph for you [04:24] it now has a code path for building deltas and calling create_by_apply_delta() but the root handling is still screwing me around [04:24] igc1: how so? [04:25] essentially there are three interfaces for adding data to a repository - fetch, repository.add_revisions, and get_commit_builder [04:25] *any* other code path is immediately suspect and probably a reimplementation of one of the others [04:26] it's not clear what the initial root_id of the first inv should be [04:26] I was setting it to inventory.ROOT_ID but then the root mproperty was falling over 'cause self[root_id] didn't exist [04:27] also does the first delta need an entry for the root? [04:27] that sort of stuff is very unclear [04:28] I think the first revision is now genewrating but a subsequence call to directories() is falling over [04:29] anyhow, I'll leave fastexport on hold and get back to repodetails [04:29] yes it does [04:29] lifeless: fwiw as well, fast-export was *much* quicker not going through commit-builder, at least many months ago [04:30] igc1: so, either fast-import was buggy, or commit-builder was [04:30] :P [04:30] commit-builder is good for adding one revision but not optimise at all for multiple revision loading [04:30] igc1: I don't see why it would be different [04:31] lifeless: let's talk about it next week [04:31] igc1: anyhow, lets ignore that; we have shiny new things [04:36] I wrote a blog post detailing my Bazaar setup on my Mac. I thought others maybe interested and wanted to share it with the community: [04:36] http://925html.com/techniques/using-bazaar-on-a-mac/ [04:47] lifeless: just landed your addSkip patch === r0bby_ is now known as r0bby [04:50] thanks [04:51] so subunit's one needs a review [05:27] ciao [05:43] hm. almost an entire branch without a status updae :\ [06:00] eferraiuolo: nice [06:23] * fullermd sure hopes those streaming changes will improve committing in checkouts across the smart server :| [06:28] fullermd: almost certainly. You're welcome to try installing bzr.dev and letting us know how it goes :) [06:28] Well, I have bzr.dev. Just only on the client side :p [06:28] Just messes with your flow when commit takes upward of 20 seconds... [06:28] Yeah. [06:29] I'm just trying to figure out whether that's an actual failing of bzr, or a clever trick somebody added to convince people not to work directly on trunk... [06:30] Personally, I think it's a failing. [06:30] I think there are valid use cases for working on a checkout of trunk. [06:31] Man, some people just don't know how to help build a good conspiracy theory... [06:33] The proper response would have been something like "Not only is it _intended_, it was intended by SPACE ALIENS, who encoded those coding choices in our DNA while forcing us to build the Pyramids." [06:35] That way not only do we have an excuse for why it happens, but we demonstrate that bzr is the oldest VCS at the same time. [06:35] (it was just only circa 2005 that it was translated into python from limestone...) [06:40] spiv: There are also often valid use cases for working on a checkout of a branch that multiple people are working on at once... [06:42] wgrant: right [07:35] hi all [07:39] jfroy: pong [07:40] vila: yo [07:40] so, I implemented a crude keychain auth provider. [07:40] Plugin, that is. [07:40] jfroy: great, publish it on lp :) [07:40] I ran into one limitation, and one weird thing while doing so. [07:41] vila: I need to clear it with Apple legal first. [07:41] jfroy: ? You're working for Apple ? [07:41] Yeah [07:41] ok [07:41] I managed to get Bazaar approved for inclusion in internal builds of Mac OS X :) [07:42] jfroy: congrats :) [07:42] And I want to bundle a few useful plug-ins with it. [07:42] Eh, well git and hg are already there, but anyways. [07:42] OK, so first of all, the realm isn't passed down to auth providers [07:43] I trivially patched bzr.dev to do so [07:43] jfroy: send a patch so I can review it [07:43] It's useful to look up Subversion repository passwords since they are stored as " realm" generic passwords [07:44] Secondly, the authentication.conf section *name* is passed to the auth provider [07:44] bzr-svn is taking care of that, so I thought we already fixed the realm bit with Jelmer... [07:44] Unfortunately, the credentials are needed for probing [07:44] otherwise, you get prompted *twice* for your credentials. [07:45] it's a miserable user experience, in other words [07:45] jfroy: if the auth provider knows about the credentials, you don't get prompted [07:45] yes. that's quite correct [07:46] if it doesn't (and *because* we don't save credentials so far) you get prompted twice [07:46] that's the actual limitation [07:46] I understand that -- the keychain auth provider works beautifully [07:46] but it needs all the information to do a useful search [07:46] host, port, realm, path, username [07:46] technically, it doesn't need the username [07:47] ayou should have them as part of the credentials parameter in decode_password [07:47] So in any case, passing the auth section name to providers seems odd. Your own netrc plug-in looks for the key "host" in the credentials argument, yet that's *never* stored in the credentials dictionary by bzr.dev [07:47] if you don't, that's a bug I should fix [07:49] AuthenticationConfig.get_credentials should certainly set the credential attributes from the received parameters, it seems it still doesn't [07:49] * jfroy pasted http://pastie.textmate.org/408078 [07:49] Now that you mentioned it, it may be that Jelmer worked around that and I thought he fixed it when in fact it's still to be fixed [07:50] that's the current code in bzr.dev [07:50] so basically in my prototype I hacked some code to create a new AuthenticationConfig object, load its config (private method, bad), get the section using the provided name, and get at the info I need. [07:50] jfroy: yup, that's where things should be tweaked, damn, no realm there :-/ [07:51] And even that's not a good solution, since a partial patch based on the keys in the section is possible. The information should come from the actual request. [07:51] bzr-svn itself handles authentication through the svn libraries [07:51] there's no work to be done there [07:51] the probing process is entirely in bzrlib [07:51] jfroy: we agree, when I say add the attributes to credentials, I'm talking about the actual request ones [07:51] right [07:51] including realm [07:52] What I was worried about is that I didn't understand at all how the code works, since with that code, *your* plug-in is also broken [07:52] it depends on a 'host' key being set in credentials [07:52] and that's clearly not being done [07:52] jfroy: it could be that the tests are not good enough [07:53] * jfroy pasted http://pastie.textmate.org/408081 [07:53] from the netrc plug-in [07:53] jfroy: indeed, it seems I'm testing at a too low level to catch that and that the tests always provide a host [07:53] it seems there's a disconnect in the credential provider plug-in protocol / interface [07:54] If you want, I can provide a comprehensive patch to address those issues tomorrow. [07:54] There are other issues [07:54] jfroy: sure ! [07:54] Namely one of performance [07:55] get_user and get_password both use get_credentials [07:55] jfroy: note that I'll be traveling for the next 48 hours so there will be some lag [07:55] and they don't cache [07:55] which implies credentials will be searched for / fetched on average twice [07:55] that's fine, I'm aiming at getting this in 1.13 [07:56] jfroy: don't bother about performances here, that's called once per connection which will cost far more anyway [07:56] I think the changes are low risk enough to be OK. [07:56] that's not necessarily true [07:56] 1.13rc1 is due tomorrow, but try anyway [07:56] For instance, someone conscious about security might authorize bzr to access his or her keychain only once [07:57] under this code, he will get prompted twice [07:57] granted, the keychain provider could cache [07:57] But it seems to be a flaw that should be addressed upstream [07:57] you're talking about UI here, not performance and yes, the keychain provider can cache [07:57] I'm not going to include that in my patch, it's a secondary and separate issue [07:58] The last thing is a ER for later. [07:58] We could add a "probe username" method to the credential provider interface. [07:58] Certain providers, like the keychain one, can provide credentials with only a the request parameters. [07:59] That is, you can wildcard the username and request "give me any item that matches the server part of things" [07:59] This would allow bzr to match the user experience of svn [08:00] I'm wondering if get_user might not already allow for this to happen [08:00] And damn, rc1 tomorrow huh.... [08:00] hello jfroy [08:01] poolie: greetings! [08:02] jfroy: there is bug #321918 to address that I think [08:02] Launchpad bug 321918 in bzr "ability to register credentials providers that are always queried" [Wishlist,Triaged] https://launchpad.net/bugs/321918 [08:03] Ah yes, true, unless the provider is configured in authentication.conf it won't happen [08:04] jfroy: that's the point, user choice is always respected [08:04] I don't think that's correct [08:04] Not entirely [08:04] jfroy: the user is right [08:04] neither you and me can change that :) [08:04] Respecting user preferences is of the utmost importance [08:04] *however* [08:05] Unless the user takes explicit action, defaults should reflect the user's *expected* behavior [08:05] And on Mac OS X, as far as credential storage and queries go, that's the keychain. [08:05] default applies when user says nothing [08:05] yes, agreed [08:05] * igc1 dinner [08:06] Once your plugin register itself as being always queried unless the user says otherwise, you get what you're asking for [08:06] yes, that's the ideal user experience I'm aiming for. [08:06] jfroy: we all agree there [08:07] But there should definitely be a way to disable the provider globally or for a specific host. [08:07] In any case, that's not for the 1.13 timeline [08:08] I'm hoping I can write a narrow enough patch for the config module it will make it past what I assume are very stringent requirements for including a patch in a release that's reached RC. [08:09] jfroy: don't get focused on releases, send your patch, I'll do my best to get it included asap, even if asap is 1.14 :) [08:10] I suppose. [08:12] vila, i guess you'll be leaving within 24h? [08:13] poolie: yup in less than 8h even [08:15] vila, so should it be you, or bob tanner for 1.13 RM? [08:15] i'd like to expand the group of people who do it but [08:16] he isn't on the core team yet and it's kind of a high responsibility place to starte [08:16] start* [08:16] If we can shift the dates by a week, that will be perfect for me [08:16] you'd do it on your last day here? [08:17] that would be ok, except that beuno and james_w would rather we do it sooner so it's in jaunty [08:17] because cutting a release while traveling is a sure recipe for disaster [08:17] we can probably still get it in if we do rc1 tomorrow but not if it's a week later [08:17] i know [08:17] what do you think re bob? [08:18] That would indeed be the first time someone without vote or pqm access will be RM, which make that harder if only on technical ground [08:19] Otherwise I'm fine with bob, as I said I can act as the backup so may be I can team with him and try a double-head RM :) [09:12] jseutter: did you get it to work? === montywi|zzz is now known as montywi [10:43] hi [10:43] where can I find the plugin for network manager? [10:44] the link in the website lead to an empty directory [11:22]