| jelmer | yay, bzr-svn is now feature complete \o/ | 00:28 |
|---|---|---|
| spiv | jelmer: oh? | 00:28 |
| jelmer | spiv, annotate and eliminating svn-push were the last remaining bits | 00:28 |
| james_w | \o/ | 00:30 |
| spiv | jelmer: sweet | 00:30 |
| * james_w opens the champagne | 00:30 | |
| poolie | wow way to go | 00:31 |
| spiv | jelmer: someone on another channel asks about svn:externals ;) | 00:33 |
| jelmer | spiv: that requires bzr itself to support them first :-) | 00:33 |
| spiv | jelmer: :) | 00:33 |
| jelmer | the server side ("bzr svn-serve" or "bzr serve --svn") is also not done yet | 00:34 |
| spiv | jelmer: that's ok, neither is native "bzr serve" ;) | 00:34 |
| mwhudson | jelmer: yay | 00:48 |
| mwhudson | jelmer: will there be a 0.6 or will this be 0.5.3 ? | 00:50 |
| jelmer | mwhudson, 0.5.3 or 1.0.0 | 00:51 |
| mwhudson | jelmer: cool | 00:51 |
| mwhudson | jelmer: are you going to make lp:bzr-svn non-remote again at some point? | 00:51 |
| jelmer | 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:52 |
| mwhudson | it _should_ be possible to write a hook that uses the api to request a mirror by now | 00:53 |
| mwhudson | but i don't think one has been written | 00:53 |
| poolie | lifeless: trailing whitespace just bit me too | 00:54 |
| lifeless | heh | 00:56 |
| lifeless | jelmer: grats | 00:56 |
| lifeless | jelmer: there is an xmlrpc thing you can call, apparently. | 00:56 |
| poolie | ah actually no | 00:57 |
| poolie | it was a literal tab, and that was worth catching | 00:57 |
| lifeless | heh | 00:57 |
| lifeless | yes they are worth catching | 00:57 |
| poolie | did you resubmit your test_source patch? | 00:58 |
| poolie | if not i will | 00:58 |
| jelmer | mwhudson, yeah, I still need to look at that | 00:58 |
| jelmer | mwhudson, or hope somebody else does :-) | 00:58 |
| mwhudson | jelmer: i'll take your requirements on board :) | 00:59 |
| lifeless | poolie: no, because marius said he would | 00:59 |
| lifeless | poolie: the more clean version | 00:59 |
| Jerub | now I remember one of the issues with bzr-svn, it gets exponentially slower as it goes. | 01:00 |
| jelmer | Jerub, Which version are you using? | 01:01 |
| Jerub | 0.5 | 01:01 |
| jelmer | Jerub, try 0.5.2 | 01:01 |
| jelmer | that should be significantly faster | 01:01 |
| jelmer | in particular on large repositories | 01:01 |
| mwhudson | jelmer: why don't you use hosted branches btw? | 01:01 |
| Jerub | jelmer: well, I've just cancelled the svn-import that had been going for over an hour | 01:04 |
| Jerub | jelmer: so I hope this is faster. | 01:04 |
| jelmer | mwhudson: It ties me into Launchpad, over which I have no control. | 01:06 |
| jelmer | 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 |
| jelmer | *also means | 01:07 |
| mwhudson | fair enough | 01:07 |
| mwhudson | though i hope launchpad isn't going to go away any time soon :) | 01:07 |
| mwhudson | we have backups on tape too | 01:08 |
| Jerub | why bother? raid is good enough to back everything up. | 01:08 |
| spiv | Jerub: raid isn't very good at preserving data eaten by fat fingers :) | 01:09 |
| mwhudson | or fires | 01:09 |
| spiv | mwhudson: pfft, nature | 01:10 |
| Jerub | Sorry, I couldn't help it. My sarcasm exploded over the channel. | 01:10 |
| Jerub | (I've actually had an office fire, and recovered from offsite backups) | 01:11 |
| spiv | Jerub: :) | 01:12 |
| mwhudson | http://www.facebook.com/pages/Bazaar/128354670412?sid=7bd5847db77e5312163ecf237785b8c9&ref=s | 01:13 |
| spiv | Jerub: backup strategies is a topic a bit like editor or vcs preferences... | 01:13 |
| spiv | mwhudson: that's a bit random | 01:13 |
| spiv | Maybe we should replace our wiki with a myspace page ;) | 01:14 |
| Jerub | 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:17 |
| lifeless | igc1: how are you going | 01:18 |
| lifeless | spiv: also, I've a _huge_ long pull going from python.org | 01:18 |
| lifeless | 1448 byte packes | 01:18 |
| Jerub | 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 |
| lifeless | jelmer: hours now :(. So not sure sure why | 01:19 |
| spiv | lifeless: 1448 is better than 510! | 01:19 |
| Jerub | 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 |
| lifeless | spiv: 510 was the window size :( | 01:20 |
| mwhudson | spiv: we should use facebook for canonical's calendaring needs! | 01:21 |
| jelmer | Jerub: The 1.5 warning should be fixed in the next version | 01:21 |
| Jerub | jelmer: awesome | 01:22 |
| lifeless | spiv: I've stopped it after 99m | 01:26 |
| lifeless | spiv: oh! I have an idea | 01:26 |
| lifeless | spiv: ping | 01:27 |
| james_w | you're going to try TCP/spiv? | 01:27 |
| lifeless | james_w: no, I think we might be partial-reading from the socket | 01:27 |
| lifeless | which will lead to acking less than we can | 01:27 |
| james_w | ah | 01:28 |
| Jerub | lifeless: have you straced it to see how big the reads are? | 01:28 |
| lifeless | Jerub: about to | 01:28 |
| spiv | lifeless: pong | 01:29 |
| lifeless | spiv: see before | 01:30 |
| spiv | Hmm, read sizes? | 01:30 |
| spiv | lifeless: it should always be trying 64k when reading from a TCP socket | 01:32 |
| lifeless | spiv: yeah, I've just validated that | 01:32 |
| lifeless | spiv: and its often getting way less | 01:32 |
| lifeless | recvfrom(4, "\0\1\242B406\ntexts\n\nknit-ft-gz\n2160@6"..., 65536, 0, NULL, NULL) = 5792 | 01:33 |
| lifeless | recvfrom(4, "cc4771:python%2Ftrunk:Lib%2Ftest"..., 65536, 0, NULL, NULL) = 1448 | 01:33 |
| lifeless | recvfrom(4, "\2\377\255\223\273\262\333 \20\206{?\3056\231\330\216\344"..., 65536, 0, NULL, NULL) = 5792 | 01:33 |
| spiv | (It is less optimisitic when reading the pipe from a bzr+ssh connection, but that's not the issue here obviously) | 01:33 |
| lifeless | spiv: however, we haven't tested raw protocol from the dc | 01:34 |
| lifeless | spiv: it could be :P | 01:34 |
| riyo | 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 |
| riyo | Just because the commands made alot more sense, then those other ones. Like "whoami", simple, lol | 02:14 |
| riyo | 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 |
| lifeless | bzr log? | 02:16 |
| riyo | 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:17 |
| riyo | 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:19 |
| riyo | also, bzr diff, and log, aren't working anymore, wtf | 02:24 |
| riyo | do I have to specify a file or something? | 02:24 |
| riyo | bzr log filename ? | 02:24 |
| poolie | riyo: no, they default to the whole tree | 02:26 |
| poolie | riyo: are you in the right directory? | 02:26 |
| riyo | Yeah I am | 02:31 |
| poolie | so what do you mean by not working? | 02:32 |
| poolie | do you get an error msg? | 02:32 |
| riyo | Let me upload a picture ^_^ | 02:33 |
| riyo | http://i44.tinypic.com/141teu8.png | 02:35 |
| riyo | There, is it supposed to do that? It just shows comments, which btw, is that a mispelling? commits? | 02:35 |
| poolie | :) | 02:35 |
| poolie | that's what bzr log is meant to do, yeah | 02:36 |
| poolie | 'committer' is the person who committed | 02:36 |
| riyo | Is that pronounced "comment-er", or "commit-er"? | 02:36 |
| poolie | the second | 02:36 |
| poolie | they're called commits, not comments | 02:37 |
| riyo | But...they....are comments, lol | 02:38 |
| riyo | How confusing. | 02:38 |
| riyo | Anyways, what's the point? Don't I want to see what source code of mine changed? | 02:38 |
| poolie | i don't know, do you? :) | 02:39 |
| riyo | Ugh, yeah, otherwise theres no point, lol | 02:40 |
| riyo | I wish it was just a hotkey, for a "snapshot", and I could scroll through each picture, lol | 02:40 |
| spiv | riyo: you can do "bzr diff -c 2" to see changes made in commit 2. | 02:41 |
| riyo | WTF does that mean, lol --> @@ -0,0 +1,1 @@ | 02:43 |
| riyo | ...is this some sick joke :P | 02:43 |
| lifeless | riyo: thats standard notation for showing a textual change of a file | 02:43 |
| lifeless | riyo: it means from line 0, for 0, to line 1, for 1 | 02:44 |
| riyo | This is overly complciated. | 02:45 |
| riyo | Is this really the answer I'm looking for? | 02:45 |
| riyo | Cause heres my problem. | 02:45 |
| riyo | 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 |
| riyo | I end up with 100's of copies, lol, untill I'm finished or have scraped it. | 02:46 |
| riyo | Is this my solution? | 02:46 |
| spiv | riyo: yes | 02:47 |
| spiv | riyo: you might find that some of the GUI tools make exploring the saved history a bit easier | 02:47 |
| lifeless | riyo: with bzr you won't need as many copies, the bzr-upload plugin can make deploying your websites easier | 02:48 |
| spiv | riyo: if your installation has the "qbzr" plugin, then "bzr qlog" is quite good. | 02:48 |
| spiv | riyo: if you just want to view a file as it was at an earlier revision, use "bzr cat -r 2 path/to/file" | 02:49 |
| riyo | I wish there was a video tutorial. If I ever get the hang of this, I'm so making one. | 03:14 |
| riyo | bzr: ERROR: QBzr require at least PyQt 4.1 and Qt 4.2 to run. Please check your install | 03:16 |
| * igc1 lunch | 03:17 | |
| lifeless | spiv: doing get_parent | 03:36 |
| jml | igc1: ping | 03:39 |
| igc1 | hi jml | 03:50 |
| jml | igc1: hi | 03:50 |
| jml | igc1: I have a story about logging that I'd like your help with | 03:50 |
| jml | igc1: I've heard a rumour that you touched log last? | 03:51 |
| igc1 | jml: :-) | 03:51 |
| jml | 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:51 |
| jml | 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 |
| jml | I can write that as a predicate function with little to no worries | 03:52 |
| jml | igc1: what I want is a way of passing a predicate function to show_log to filter the revisions I see. | 03:52 |
| igc1 | jml: hmm | 03:53 |
| igc1 | jml: log needs restructuring and vila and I still don't agree on how | 03:54 |
| jml | igc1: ok. | 03:54 |
| lifeless | I'd do a filter | 03:54 |
| lifeless | it can buffer a little and so on and feed it out | 03:54 |
| jml | igc1: so, doing 'if foo(revision): yield revision' is going to be a bit slow, obviously | 03:54 |
| lifeless | then give the filte ra predicate as a parameter | 03:54 |
| igc1 | jml: I think we ought to add a --user option (or something like that) that matches on a name ... | 03:55 |
| lifeless | igc1: +1 on more capabilities, -1 on new options, I'd really rather agree on a search language and use that | 03:55 |
| jml | what I *really* want is Bazaar Query Language | 03:55 |
| igc1 | possibly propagatng upwards to the mainline as file filtering does | 03:55 |
| lifeless | igc1: so that bzr-search can do it fast | 03:55 |
| jml | lifeless: great minds :) | 03:55 |
| igc1 | BQL is Python :-) | 03:56 |
| igc1 | jml: as a short-term thing ... | 03:56 |
| igc1 | log --line -n0 | grep Lange | 03:57 |
| igc1 | make it a contenxt grep if that helps | 03:57 |
| jml | igc1: ... and then filter that to find the mainline revisions .... | 03:58 |
| igc1 | lifeless: bzr-search is nice but it doesn't exclude making log easier to use | 03:58 |
| igc1 | bzr log --user me | 03:58 |
| igc1 | and | 03:59 |
| igc1 | bzr log --user @names-in-file | 03:59 |
| igc1 | have plenty of value to casual users - a query language is just too advanced for them | 03:59 |
| igc1 | lifeless: we can use bzr-search behind the scenes to make it efficent of course | 04:01 |
| jml | igc1: so, if I could do that and then only see mainline revisions which I pqm-submitted, I'd be happy | 04:01 |
| igc1 | iff it's installed | 04:01 |
| jml | (although the *real* bug there is that PQM doesn't set author) | 04:01 |
| igc1 | jml: right | 04:02 |
| igc1 | 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:02 |
| lifeless | igc1: bzr log -m user:me | 04:03 |
| igc1 | I guess the new multiple author field could simplify that | 04:03 |
| jml | igc1: I do think some sort of domain-specific language/API for specifying searches would be a good idea. | 04:03 |
| lifeless | igc1: bzr-search is orthogonal yes, but adding many many options is not great | 04:03 |
| igc1 | jml: so *just* matching against a revision isn't smart enough | 04:04 |
| jml | igc1: agreed. | 04:04 |
| jml | although it's smart enough if I'm writing the revision-matching function :) | 04:05 |
| lifeless | igc1: I wasn't proposing depending on bzr-search, I was proposing that many-options is not a better UI | 04:06 |
| igc1 | jml: but log, except for file filtering, isn't structured that way btw | 04:06 |
| lifeless | igc1: the revision filters are iterators, or they were | 04:06 |
| igc1 | lifeless: sure | 04:06 |
| lifeless | igc1: so it should handle arbitrary filtering just fine | 04:06 |
| jml | igc1: ok | 04:06 |
| igc1 | but the level filtering takes out merged revisions it's never going to display before those iterators are called | 04:07 |
| igc1 | so log -n0 only passes you the mainline revisions | 04:07 |
| igc1 | it's all part of "don't generate stuff you don't need" | 04:08 |
| igc1 | "smart" filtering like jml wants means ... | 04:08 |
| mwhudson | hello knowledgeable people | 04:09 |
| mwhudson | what port does git talk to the internet over? | 04:09 |
| igc1 | a revision filter needs to say "give me everything and then post filter the levels out" | 04:09 |
| igc1 | except for file filtering, we don't do that currently | 04:09 |
| igc1 | lifeless: I like the -m user:me idea btw | 04:10 |
| lifeless | igc1: can't the level filtering happen as a normal filter in the chain so you can get there first? | 04:11 |
| igc1 | lifeless: there's a high cost (> 60 sec overhead) for getting all levels for mainline for large repos | 04:12 |
| igc1 | s/for/vs/ | 04:12 |
| igc1 | we only want to do it if we really need to | 04:13 |
| Jerub | oh wow, bzr-svn 0.5.2 actually worked. | 04:14 |
| igc1 | jml: so the short answer is ... | 04:15 |
| igc1 | post processing log --line -n0 is an order of magnitude easier than extending log as you want right now | 04:15 |
| igc1 | hmm - maybe 2 orders of magnitude | 04:15 |
| jml | heh, ok. | 04:16 |
| jml | I'm going to try for a middle way, writing my own crappy log-like command. | 04:16 |
| igc1 | lifeless: on anotrher topic and answering your earlier Q, I'm making much better progress ... | 04:17 |
| igc1 | thanks to your assistance yesterday | 04:17 |
| igc1 | I'm hacking repodetails as discussed | 04:17 |
| lifeless | spiv: ping | 04:18 |
| Jerub | jelmer: why does bzr-svn count down for 'discovering revisions' while doing a bzr pull | 04:18 |
| igc1 | though *generating* branches in the new formats is still proving painful | 04:18 |
| igc1 | upgrade works for development5 but simply refuses to for ... | 04:19 |
| igc1 | formats like gc-plain-chk255, even for really simple branches | 04:19 |
| igc1 | at least now I know enough to stand a chance of traking down the problems | 04:20 |
| spiv | lifeless: pong | 04:20 |
| lifeless | spiv: tommorrow I'm likely to be largely offline | 04:20 |
| lifeless | spiv: and its freeze then | 04:20 |
| lifeless | I'm just finishing off branch.get_parent verb | 04:20 |
| lifeless | have you been working on stacked pull ? | 04:20 |
| igc1 | though the immutable nature of CHKInventories means fastimport is currently out of service as a test branch generation avenue | 04:21 |
| spiv | lifeless: no, not yet :/ | 04:22 |
| lifeless | igc1: if fastimport was mutating invnetories inRevisionTree's, it was being naughty | 04:22 |
| lifeless | igc1: thats *never* been a intended capability | 04:22 |
| Jerub | crud, that was my problem. I thought I wanted bzr svn-import when I actually wanted bzr checkout | 04:22 |
| igc1 | lifeless: it wasn't | 04:22 |
| igc1 | it was copying the basis and then using the API (add/del, rename, remove_recursive_id) to build the new one | 04:23 |
| lifeless | ok | 04:23 |
| lifeless | that would be slow | 04:23 |
| lifeless | using CommitBuilder would be better | 04:24 |
| lifeless | because it will calculate the per file graph for you | 04:24 |
| igc1 | 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 |
| lifeless | igc1: how so? | 04:24 |
| lifeless | essentially there are three interfaces for adding data to a repository - fetch, repository.add_revisions, and get_commit_builder | 04:25 |
| lifeless | *any* other code path is immediately suspect and probably a reimplementation of one of the others | 04:25 |
| igc1 | it's not clear what the initial root_id of the first inv should be | 04:26 |
| igc1 | I was setting it to inventory.ROOT_ID but then the root mproperty was falling over 'cause self[root_id] didn't exist | 04:26 |
| igc1 | also does the first delta need an entry for the root? | 04:27 |
| igc1 | that sort of stuff is very unclear | 04:27 |
| igc1 | I think the first revision is now genewrating but a subsequence call to directories() is falling over | 04:28 |
| igc1 | anyhow, I'll leave fastexport on hold and get back to repodetails | 04:29 |
| lifeless | yes it does | 04:29 |
| igc1 | lifeless: fwiw as well, fast-export was *much* quicker not going through commit-builder, at least many months ago | 04:29 |
| lifeless | igc1: so, either fast-import was buggy, or commit-builder was | 04:30 |
| lifeless | :P | 04:30 |
| igc1 | commit-builder is good for adding one revision but not optimise at all for multiple revision loading | 04:30 |
| lifeless | igc1: I don't see why it would be different | 04:30 |
| igc1 | lifeless: let's talk about it next week | 04:31 |
| lifeless | igc1: anyhow, lets ignore that; we have shiny new things | 04:31 |
| eferraiuolo | 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 |
| eferraiuolo | http://925html.com/techniques/using-bazaar-on-a-mac/ | 04:36 |
| jml | lifeless: just landed your addSkip patch | 04:47 |
| === r0bby_ is now known as r0bby | ||
| lifeless | thanks | 04:50 |
| lifeless | so subunit's one needs a review | 04:51 |
| lifeless | ciao | 05:27 |
| Kamping_Kaiser | hm. almost an entire branch without a status updae :\ | 05:43 |
| poolie | eferraiuolo: nice | 06:00 |
| * fullermd sure hopes those streaming changes will improve committing in checkouts across the smart server :| | 06:23 | |
| spiv | fullermd: almost certainly. You're welcome to try installing bzr.dev and letting us know how it goes :) | 06:28 |
| fullermd | Well, I have bzr.dev. Just only on the client side :p | 06:28 |
| fullermd | Just messes with your flow when commit takes upward of 20 seconds... | 06:28 |
| spiv | Yeah. | 06:28 |
| fullermd | 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:29 |
| spiv | Personally, I think it's a failing. | 06:30 |
| spiv | I think there are valid use cases for working on a checkout of trunk. | 06:30 |
| fullermd | Man, some people just don't know how to help build a good conspiracy theory... | 06:31 |
| fullermd | 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:33 |
| fullermd | 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 |
| fullermd | (it was just only circa 2005 that it was translated into python from limestone...) | 06:35 |
| wgrant | 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:40 |
| spiv | wgrant: right | 06:42 |
| vila | hi all | 07:35 |
| vila | jfroy: pong | 07:39 |
| jfroy | vila: yo | 07:40 |
| jfroy | so, I implemented a crude keychain auth provider. | 07:40 |
| jfroy | Plugin, that is. | 07:40 |
| vila | jfroy: great, publish it on lp :) | 07:40 |
| jfroy | I ran into one limitation, and one weird thing while doing so. | 07:40 |
| jfroy | vila: I need to clear it with Apple legal first. | 07:41 |
| vila | jfroy: ? You're working for Apple ? | 07:41 |
| jfroy | Yeah | 07:41 |
| vila | ok | 07:41 |
| jfroy | I managed to get Bazaar approved for inclusion in internal builds of Mac OS X :) | 07:41 |
| vila | jfroy: congrats :) | 07:42 |
| jfroy | And I want to bundle a few useful plug-ins with it. | 07:42 |
| jfroy | Eh, well git and hg are already there, but anyways. | 07:42 |
| jfroy | OK, so first of all, the realm isn't passed down to auth providers | 07:42 |
| jfroy | I trivially patched bzr.dev to do so | 07:43 |
| vila | jfroy: send a patch so I can review it | 07:43 |
| jfroy | It's useful to look up Subversion repository passwords since they are stored as "<scheme://host:port/path> realm" generic passwords | 07:43 |
| jfroy | Secondly, the authentication.conf section *name* is passed to the auth provider | 07:44 |
| vila | bzr-svn is taking care of that, so I thought we already fixed the realm bit with Jelmer... | 07:44 |
| jfroy | Unfortunately, the credentials are needed for probing | 07:44 |
| jfroy | otherwise, you get prompted *twice* for your credentials. | 07:44 |
| jfroy | it's a miserable user experience, in other words | 07:45 |
| vila | jfroy: if the auth provider knows about the credentials, you don't get prompted | 07:45 |
| jfroy | yes. that's quite correct | 07:45 |
| vila | if it doesn't (and *because* we don't save credentials so far) you get prompted twice | 07:46 |
| vila | that's the actual limitation | 07:46 |
| jfroy | I understand that -- the keychain auth provider works beautifully | 07:46 |
| jfroy | but it needs all the information to do a useful search | 07:46 |
| jfroy | host, port, realm, path, username | 07:46 |
| jfroy | technically, it doesn't need the username | 07:46 |
| vila | ayou should have them as part of the credentials parameter in decode_password | 07:47 |
| jfroy | 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 |
| vila | if you don't, that's a bug I should fix | 07:47 |
| vila | 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 | |
| vila | 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:49 |
| jfroy | that's the current code in bzr.dev | 07:50 |
| jfroy | 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 |
| vila | jfroy: yup, that's where things should be tweaked, damn, no realm there :-/ | 07:50 |
| jfroy | 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 |
| jfroy | bzr-svn itself handles authentication through the svn libraries | 07:51 |
| jfroy | there's no work to be done there | 07:51 |
| jfroy | the probing process is entirely in bzrlib | 07:51 |
| vila | jfroy: we agree, when I say add the attributes to credentials, I'm talking about the actual request ones | 07:51 |
| jfroy | right | 07:51 |
| vila | including realm | 07:51 |
| jfroy | 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 |
| jfroy | it depends on a 'host' key being set in credentials | 07:52 |
| jfroy | and that's clearly not being done | 07:52 |
| vila | jfroy: it could be that the tests are not good enough | 07:52 |
| * jfroy pasted http://pastie.textmate.org/408081 | 07:53 | |
| jfroy | from the netrc plug-in | 07:53 |
| vila | 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 |
| jfroy | it seems there's a disconnect in the credential provider plug-in protocol / interface | 07:53 |
| jfroy | If you want, I can provide a comprehensive patch to address those issues tomorrow. | 07:54 |
| jfroy | There are other issues | 07:54 |
| vila | jfroy: sure ! | 07:54 |
| jfroy | Namely one of performance | 07:54 |
| jfroy | get_user and get_password both use get_credentials | 07:55 |
| vila | jfroy: note that I'll be traveling for the next 48 hours so there will be some lag | 07:55 |
| jfroy | and they don't cache | 07:55 |
| jfroy | which implies credentials will be searched for / fetched on average twice | 07:55 |
| jfroy | that's fine, I'm aiming at getting this in 1.13 | 07:55 |
| vila | jfroy: don't bother about performances here, that's called once per connection which will cost far more anyway | 07:56 |
| jfroy | I think the changes are low risk enough to be OK. | 07:56 |
| jfroy | that's not necessarily true | 07:56 |
| vila | 1.13rc1 is due tomorrow, but try anyway | 07:56 |
| jfroy | For instance, someone conscious about security might authorize bzr to access his or her keychain only once | 07:56 |
| jfroy | under this code, he will get prompted twice | 07:57 |
| jfroy | granted, the keychain provider could cache | 07:57 |
| jfroy | But it seems to be a flaw that should be addressed upstream | 07:57 |
| vila | you're talking about UI here, not performance and yes, the keychain provider can cache | 07:57 |
| jfroy | I'm not going to include that in my patch, it's a secondary and separate issue | 07:57 |
| jfroy | The last thing is a ER for later. | 07:58 |
| jfroy | We could add a "probe username" method to the credential provider interface. | 07:58 |
| jfroy | Certain providers, like the keychain one, can provide credentials with only a the request parameters. | 07:58 |
| jfroy | That is, you can wildcard the username and request "give me any item that matches the server part of things" | 07:59 |
| jfroy | This would allow bzr to match the user experience of svn | 07:59 |
| jfroy | I'm wondering if get_user might not already allow for this to happen | 08:00 |
| jfroy | And damn, rc1 tomorrow huh.... | 08:00 |
| poolie | hello jfroy | 08:00 |
| jfroy | poolie: greetings! | 08:01 |
| vila | jfroy: there is bug #321918 to address that I think | 08:02 |
| ubottu | Launchpad bug 321918 in bzr "ability to register credentials providers that are always queried" [Wishlist,Triaged] https://launchpad.net/bugs/321918 | 08:02 |
| jfroy | Ah yes, true, unless the provider is configured in authentication.conf it won't happen | 08:03 |
| vila | jfroy: that's the point, user choice is always respected | 08:04 |
| jfroy | I don't think that's correct | 08:04 |
| jfroy | Not entirely | 08:04 |
| vila | jfroy: the user is right | 08:04 |
| vila | neither you and me can change that :) | 08:04 |
| jfroy | Respecting user preferences is of the utmost importance | 08:04 |
| jfroy | *however* | 08:04 |
| jfroy | Unless the user takes explicit action, defaults should reflect the user's *expected* behavior | 08:05 |
| jfroy | And on Mac OS X, as far as credential storage and queries go, that's the keychain. | 08:05 |
| vila | default applies when user says nothing | 08:05 |
| jfroy | yes, agreed | 08:05 |
| * igc1 dinner | 08:05 | |
| vila | Once your plugin register itself as being always queried unless the user says otherwise, you get what you're asking for | 08:06 |
| jfroy | yes, that's the ideal user experience I'm aiming for. | 08:06 |
| vila | jfroy: we all agree there | 08:06 |
| jfroy | But there should definitely be a way to disable the provider globally or for a specific host. | 08:07 |
| jfroy | In any case, that's not for the 1.13 timeline | 08:07 |
| jfroy | 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:08 |
| vila | 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:09 |
| jfroy | I suppose. | 08:10 |
| poolie | vila, i guess you'll be leaving within 24h? | 08:12 |
| vila | poolie: yup in less than 8h even | 08:13 |
| poolie | vila, so should it be you, or bob tanner for 1.13 RM? | 08:15 |
| poolie | i'd like to expand the group of people who do it but | 08:15 |
| poolie | he isn't on the core team yet and it's kind of a high responsibility place to starte | 08:16 |
| poolie | start* | 08:16 |
| vila | If we can shift the dates by a week, that will be perfect for me | 08:16 |
| poolie | you'd do it on your last day here? | 08:16 |
| poolie | that would be ok, except that beuno and james_w would rather we do it sooner so it's in jaunty | 08:17 |
| vila | because cutting a release while traveling is a sure recipe for disaster | 08:17 |
| poolie | we can probably still get it in if we do rc1 tomorrow but not if it's a week later | 08:17 |
| poolie | i know | 08:17 |
| poolie | what do you think re bob? | 08:17 |
| vila | 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:18 |
| vila | 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 :) | 08:19 |
| LarstiQ | jseutter: did you get it to work? | 09:12 |
| === montywi|zzz is now known as montywi | ||
| mattions | hi | 10:43 |
| mattions | where can I find the plugin for network manager? | 10:43 |
| mattions | the link in the website lead to an empty directory | 10:44 |
| mattions | Does anybody knows how to make bzr-svn remember my svn password | 11:22 |
| mattions | ? | 11:22 |
| === quicksil1er is now known as quicksilver | ||
| igc | night all | 12:39 |
| loxs | http://dpaste.com/6962/ --- this happens when I try to use bzr on a network drive. Everything is fine when I use it on a local drive. Any ideas? | 12:49 |
| mneptok | loxs: sorry, haven't used Windows in >10 years | 12:56 |
| loxs | me too... :( | 12:56 |
| mneptok | not that it's a Windows issue per se, but backslashes and drive letters make me run away in fright. :) | 12:58 |
| spiv | loxs: not sure, but what sort of network drive? | 13:03 |
| loxs | spiv, it's a novell share | 13:04 |
| spiv | loxs: it looks like the problem is something like a network drive where "mkdir mydir; touch mydir/myfile; mv mydir foo; cat foo/myfile" isn't reliable | 13:04 |
| loxs | the strange thing is that it worked till yesterday (before reinstall of the system) | 13:05 |
| spiv | loxs: i.e. bzr has renamed a lock directory, then gone to read the info file out of that directory (to make sure it really is the lock this process owns), and suddenly the info file is gone. | 13:05 |
| spiv | loxs: it's quite likely to be an intermittent issue if I'm right; i.e. if you try again a couple of times it might work. | 13:06 |
| spiv | loxs: also | 13:06 |
| spiv | loxs: it would be interesting to know if S:/Bespoke/Cashless Vending/Cashless | 13:06 |
| spiv | Vending/Database/trunk/.bzr/checkout/lock/releasing.n0oxup06wmyexxs1agxg.tmp/in | 13:06 |
| spiv | fo | 13:06 |
| spiv | still exists. | 13:06 |
| loxs | spiv, nothing in the lock directory | 13:07 |
| spiv | loxs: hmm, interesting! | 13:07 |
| spiv | loxs: I don't know what could cause that. It's possible that it's due to wacky network filesystem semantics, but I struggle to imagine plausible network drive behaviour that would cause that. | 13:07 |
| loxs | you are probably right... as it used to work yesterday | 13:08 |
| spiv | loxs: a bug report would be appreciated, though. | 13:08 |
| loxs | spiv, what kind of information should I supply for this? | 13:08 |
| spiv | loxs: the error message, the traceback from the bzr log file (see 'bzr version' for its location), the fact its a network share, and that the info file isn't there when you look manually | 13:09 |
| spiv | loxs: oh, and of course that it's *novell* share :) | 13:10 |
| loxs | ok, I'll do it now | 13:10 |
| spiv | loxs: plus anything else you think interesting, but we can always ask for more info if necessary. | 13:10 |
| spiv | loxs: feel free to just paste this IRC conversation into the bug report if that makes your life easier ;) | 13:11 |
| loxs | thanks :) | 13:12 |
| loxs | hm, spiv... in the log file... before the error you saw, there it says that it's some kind of translate error File "bzrlib\transport\__init__.pyo, line 307, in _translate_error | 13:18 |
| loxs | yesterday, the locales of my workstation were different | 13:18 |
| spiv | loxs: that's not related to locales | 13:22 |
| spiv | loxs: that's code for turning errors accessing files and directories from platform-specific into bzr-internal error codes. | 13:23 |
| loxs | spiv, https://bugs.launchpad.net/bzr/+bug/338220 | 13:30 |
| ubottu | Launchpad bug 338220 in bzr "bzr fails on a novell share on windows" [Undecided,New] | 13:30 |
| loxs | spiv, actually the lock directory is not empty... only the windows explorer can't see this files O.o | 13:35 |
| loxs | when using dir through the command prompt, they are there | 13:35 |
| spiv | loxs: interesting. So it does have an 'info' file? | 13:38 |
| loxs | yes | 13:38 |
| loxs | and the bad part... that files has broken encoding bits in it .... | 13:39 |
| spiv | Ok, then I guess my first hypothesis is correct. | 13:39 |
| spiv | Oh? | 13:40 |
| loxs | some of the letters in that file are "squares" probably the encoding on the novell share differs from mine | 13:40 |
| loxs | no, no problem with this... the squares are unix line terminators | 13:41 |
| spiv | Oh, right. Yes, bzr will always use \n as the line terminator in that file. | 13:42 |
| === UdontKnow is now known as root | ||
| loxs | spiv, when I enable the "show system folders" option in windows explorer, now I can see these "missing" directories | 14:07 |
| loxs | but bzr still doesn't work | 14:07 |
| === root is now known as Wowbagger | ||
| salgado | Source format does not support stacking, using format: '1.6' | 14:23 |
| salgado | Packs 5 (adds stacking support, requires bzr 1.6) | 14:23 |
| salgado | I got that when trying to push a branch to Launchpad. does it mean bzr will push all history on that branch? | 14:24 |
| beuno | salgado, yes | 14:26 |
| beuno | try upgrading the repository (ie ~/canonical/lp-branches) | 14:26 |
| beuno | upgrade --1.9 | 14:26 |
| beuno | you can do 1.6, but 1.9 is fater | 14:26 |
| salgado | beuno, I don't think it did, though. it took only a couple minutes to complete | 14:27 |
| salgado | (just finished) | 14:27 |
| beuno | s/fater/faster | 14:27 |
| beuno | that was a very bad typo | 14:27 |
| beuno | salgado, try: bzr info | 14:27 |
| beuno | it should tell you | 14:27 |
| salgado | Shared repository with trees (format: 1.6) | 14:28 |
| beuno | and the branch? | 14:28 |
| salgado | I've pushing branches from this repo for ages, and stacking always worked | 14:28 |
| salgado | Repository tree (format: unnamed) | 14:28 |
| beuno | salgado, but rsync sometimes breaks stuff | 14:29 |
| beuno | where do you get unnamed? | 14:29 |
| salgado | I got that error after interrupting a push which was working fine (i.e. no message about stacking not being supported) | 14:30 |
| salgado | s/error/warn | 14:30 |
| salgado | beuno, on the branch I was trying to push | 14:30 |
| beuno | salgado, delete de branch and push again | 14:30 |
| beuno | AFAIK, there's no way to resume pushing a stacked branch | 14:30 |
| salgado | right, I was not trying that | 14:31 |
| salgado | this is another branch | 14:31 |
| salgado | the one I interrupted I deleted | 14:31 |
| spiv | salgado: 1.6 is a stacking-capable format | 14:38 |
| spiv | salgado: there's a bug that for some reason bzr.dev sometimes thinks that source branches in a stacking-capable format aren't in a stacking-capable format. | 14:39 |
| salgado | spiv, for some reason one of the branches in my (1.6) repo ended up created in a different format (unnamed, it seems) | 14:39 |
| spiv | salgado: so bzr gives that bogus warning. And "upgrades" 1.9 source branches to 1.6 on the server :( | 14:40 |
| salgado | sounds like what I just saw | 14:40 |
| spiv | "unnamed" isn't a format as such, it's just "bzr info" getting confused. | 14:40 |
| spiv | It gets confused if the combination of branch format and repo format is outside a very narrow set :( | 14:41 |
| spiv | info -v can be helpful when that happens, because it will describe the components formats individually. | 14:41 |
| spiv | salgado: jml filed the bug, feel free to subscribe and/or update it with some info | 14:41 |
| spiv | salgado: we want to fix it for the 1.13 release, although at this stage I'd be doubtful about it getting fixed in time for 1.13rc1 | 14:42 |
| spiv | salgado: also, upgrade to 1.9 already ;) | 14:42 |
| * spiv -> zzz | 14:43 | |
| salgado | thanks for the help spiv. I'll do that | 14:43 |
| vila | spiv: does 'second push failed to complete a fetch set' rings a bell ? | 14:45 |
| mattions | is there any way to tell the bzr-svn tool to remember my subversion password? I have to type two or three times every commit. | 14:58 |
| jelmer | mattions: you can get subversion to cache your password for you | 14:59 |
| mattions | how? | 14:59 |
| jelmer | mattions, force subversion to cache the password somehow, e.g. by running "svn ls <url>" | 14:59 |
| mattions | it's strange | 15:01 |
| mattions | i ran it and it still ask the password | 15:01 |
| mattions | twice, actually | 15:01 |
| mattions | svn 0.4.16dev0 | 15:01 |
| mattions | Bazaar (bzr) 1.9dev | 15:02 |
| jelmer | you may need 0.5 for thi | 15:02 |
| jelmer | s | 15:02 |
| mattions | I see | 15:02 |
| mattions | well, I'm on intrepid | 15:02 |
| mattions | is there any bzr packages? | 15:02 |
| mattions | I mean 0.5 is available for intrepid? | 15:02 |
| mattions | ok, found it | 15:03 |
| mattions | I'll try | 15:03 |
| mattions | jelmer: one more question: is the network-manager plugin dismissed? | 15:03 |
| jelmer | mattions, dismissed ? | 15:04 |
| mattions | the link brings to an empty directory | 15:05 |
| jelmer | it's a bzr branch | 15:05 |
| mattions | ah | 15:05 |
| mattions | and nothing is showed | 15:05 |
| mattions | when you look from http | 15:05 |
| mattions | ok, thanks :) | 15:06 |
| mattions | the network-manager plugin is not on the PPA right? | 15:19 |
| jelmer | mattions, no | 15:20 |
| jblount | I have a branch that gives me "No Public branch set for /path/to/branch_name" on pqm-submit, and I'm a little lost on how to fix this. | 15:20 |
| jblount | The public branch is a lp branch | 15:20 |
| jseutter | LarstiQ: Yes, it works fine now. The problem was with me, not bzr. :) | 15:30 |
| jam | jblount: echo 'public_branch = lp:...' >> .bzr/branch/branch.conf | 15:44 |
| jam | Or configure a policy in ~/.bazaar/locations.conf | 15:45 |
| jblount | jam: Thanks for the help, I had my ~/.bazaar/locations.conf b0rked and didn't remember where the setting came from. | 15:49 |
| radix | Does anyone know what all needs to be upgraded (software & branch-formats & repository-formats) in order to take advantage of stacked branches (on Launchpad)? | 15:52 |
| jam | radix: generally your repo needs to be upgraded to 1.6 or newer (I recommend 1.9 a lot) | 15:53 |
| jam | which implies the bzr version | 15:53 |
| radix | jam: on which side? | 15:53 |
| jam | radix: Launchpad already supports 1.9 and newer | 15:53 |
| jam | so just the client | 15:53 |
| radix | both sides? only server? only clients? | 15:53 |
| jam | or is there another server involved? | 15:54 |
| radix | jam: sure, launchpad supports 1.9, but my repository there is not on 1.9 format | 15:54 |
| jam | radix: so if you upgrade your local repo to 1.9 | 15:54 |
| jam | when pushing to LP | 15:54 |
| jam | bzr will create a new branch+repo that can stack on older formats | 15:54 |
| radix | (at least, I don't think it is. I can't figure out how to check what repo format my lp repo is in) | 15:54 |
| jam | you *can* upgrade the repo on LP | 15:54 |
| jam | and there are reasons to do so | 15:54 |
| jam | but it isn't necessary | 15:54 |
| jam | stacking cares that the Stacked branch is in the new format, not the stacked-on branch? | 15:54 |
| jam | does that make sense? | 15:55 |
| radix | jam: okay, so I should just tell all my developers to upgrade to >= 1.9 and do "bzr upgrade --1.9" in their repositories (anything about branches?) | 15:55 |
| jam | radix: it is good to upgrade the branches, but not strictly necessary | 15:55 |
| jam | as we will auto-upgrade when we need to | 15:55 |
| radix | okay, I'll do this and find out whether it speeds up new branch pushing for my team | 15:56 |
| radix | thanks very much for the advice jam :) | 15:56 |
| jam | radix: what team? | 15:56 |
| radix | landscape | 15:56 |
| radix | jam: I think what you said about stacked vs stacked-on makes sense, yes. | 15:57 |
| salgado | jam, if I have a 1.9 repo with a 1.6 branch inside it. what happens if I create a new branch out of the 1.6 one; will it be 1.6 or 1.9? | 15:57 |
| radix | jam: but did you actually mean the "Stacked branch's repository" instead of "Stacked branch"? | 15:57 |
| jam | salgado: 1.9 branches == 1.6 branches. Only the repo changes | 15:57 |
| salgado | oh, cool. so upgrading my repo to 1.9 (from 1.6) should be everything I need to do? | 15:58 |
| jam | radix: for the most part, yes. The stacking location is actually set in the branch (so if you had a shared repo, with lots of stacked branches, they could potentially be stacked on lots of different locations) | 15:58 |
| jam | salgado: yep | 15:58 |
| radix | I think there used to be a message printed to the console when doing a push that used a stacking branch, but now I don't see those any more. | 16:00 |
| radix | oh awit | 16:00 |
| radix | there it is! | 16:00 |
| radix | okay, I think I got it working :-) | 16:00 |
| jelmer | luke-jr, ping | 16:01 |
| jam | radix: so pushing up a stacked branch doesn't have to push the whole history, but at the moment the data it *does* have to push is a bit slower to transfer than before | 16:01 |
| jam | so for *small* projects, stacking isn't a win yet | 16:01 |
| jam | landscape may be big enough | 16:01 |
| radix | yeah, Landscape is definitely big enough | 16:01 |
| jam | I believe if everything goes as planned, 1.13 will fix some of the remaining rough edges | 16:02 |
| radix | our repo is 39MB, and that's really painful for the brazilians and the italians | 16:02 |
| thekorn | jelmer, I think I fixed 294396, now I would like to test my changes, is there any way to test olive without installing it system-wide? | 16:14 |
| jelmer | bug 294396 | 16:14 |
| jelmer | ? | 16:14 |
| ubottu | Launchpad bug 294396 in bzr-gtk "Branch, get... cancel, fail" [Undecided,In progress] https://launchpad.net/bugs/294396 | 16:14 |
| jelmer | thekorn, you should be able to run it in-place | 16:15 |
| thekorn | yeah, sorry, bug of course | 16:15 |
| jelmer | thekorn, I just mentioned that to trigger ubottu as I wasn't sure what bug or project that was | 16:16 |
| thekorn | hmm, it always picks the version from /usr/lib/python2.5/site-packages/bzrlib/plugins/gtk/branchbox.py | 16:17 |
| jelmer | thekorn, you'll need bzr-gtk installed in ~/.bazaar/plugins/gtk | 16:27 |
| thekorn | jelmer, no this also did not work, "Unable to load plugin 'gtk' from '/home/markus/.bazaar/plugins'", so I just tested my fix in a gtk.Window with two instances of this widget | 16:35 |
| jelmer | thekorn, please check ~/.bzr.log | 16:36 |
| thekorn | jelmer, http://paste.ubuntu.com/126791/ looks like another bug, maybe my bzr version is too old | 16:38 |
| jelmer | thekorn, yes, your bzr is too old | 16:38 |
| thekorn | jelmer, do you know off hand which version I need | 16:39 |
| jelmer | 1.10 or 1.11 I think | 16:40 |
| thekorn | ok, getting 1.12* from the PPA now | 16:41 |
| thekorn | jelmer, ok, thanks for your help, it worked now, adding a branch with a fix now to this bug | 16:45 |
| jelmer | thekorn, bzr-gtk doesn't use merge proposals on launchpad | 17:05 |
| jelmer | thekorn, please submit the merge request to the bzr-gtk mailing list | 17:06 |
| thekorn | oh, ok | 17:07 |
| jelmer | Peng_, do notifications work for lp:bzr-svn ? | 17:08 |
| === thunderstruck is now known as gnomefreak | ||
| nekohayo | hey there, I have someone trying to push to launchpad and getting an error that it's locked... while not being able to break the lock | 17:09 |
| nekohayo | anyone knows what's going on in http://pastebin.ca/1353627 ? | 17:11 |
| jam | nekohayo: your lp:// url either needs 3 / or none | 17:15 |
| jam | bzr break-lock lp~woutc/specto/specto-woutc | 17:15 |
| jam | sorry | 17:15 |
| jam | bzr break-lock lp:~woutc/specto/specto-woutc | 17:15 |
| jam | or | 17:15 |
| jam | bzr break-lock lp:///~woutc/specto/specto-woutc | 17:15 |
| nekohayo | on the other hand, why was bazaar giving a false suggestion then? | 17:16 |
| jam | nekohayo: well, it was using a three / url, though it should have stripped the extra numbers from 'lp-XXXX' | 17:17 |
| nekohayo | is that a known bug? | 17:18 |
| jam | nekohayo: I believe I've seen that bug reported before, yes | 17:19 |
| nekohayo | jam: ah, https://bugs.launchpad.net/bzr/+bug/255062 I guess | 17:24 |
| ubottu | Launchpad bug 255062 in bzr "Advice to "use bzr break-lock lp-NNNN:///..." is incorrect (dup-of: 250451)" [High,Confirmed] | 17:24 |
| ubottu | Launchpad bug 250451 in bzr "bzr suggests wrong URL for break-lock with a LP hosted branch" [High,Confirmed] | 17:24 |
| === salgado is now known as salgado-lunch | ||
| jelmer | rocky, hi | 18:04 |
| === montywi is now known as montywi|food | ||
| seb_kuzminsky | i'm transitioning from a git repo to bzr, and i want to reorganize it a bit in the process | 18:06 |
| seb_kuzminsky | we've got an upstream tarball and a bunch of local patches | 18:06 |
| seb_kuzminsky | the old git repo has the contents of the tarball as its first commit | 18:07 |
| seb_kuzminsky | then a bunch of commits of locally-generated patches | 18:07 |
| seb_kuzminsky | then another patch from upstream, then more local stuff, etc | 18:07 |
| seb_kuzminsky | it's all in a single branch in the git repo | 18:07 |
| seb_kuzminsky | what i want in the new bzr repo is an "upstream" branch without any of our stuff in it, and a "local" branch | 18:08 |
| seb_kuzminsky | the local branch should ideally consist of a branch off the first upstream commit, then some local commits, then a merge from the second upstream commit, etc | 18:08 |
| seb_kuzminsky | but i'd settle for importing the old git repo as the "local" bzr branch, as long as I could sensibly diff and merge between upstream and local after the inital setup is done | 18:09 |
| seb_kuzminsky | so i used git-fast-export | bzr fast-import to turn the git repo into a bzr "local" branch, and that worked great | 18:09 |
| seb_kuzminsky | then i made an "upstream" branch and committed all of upstream's stuff there | 18:09 |
| seb_kuzminsky | but now when i diff between the bzr branches, it doesnt seem to think the identical files are identical... | 18:10 |
| seb_kuzminsky | it seems to (correctly) think that the upstream and local branches don't share history | 18:10 |
| seb_kuzminsky | so my question (finally!) is: can i fool or bribe bzr into thinking that upstream and local are related now? | 18:10 |
| seb_kuzminsky | some kind of a fake merge perhaps? | 18:11 |
| jelmer | seb_kuzminsky, not afaik | 18:11 |
| seb_kuzminsky | :-( | 18:11 |
| jelmer | seb_kuzminsky, the only option you have is to recreate one of the two branches | 18:11 |
| seb_kuzminsky | what do you mean? | 18:11 |
| jelmer | and while recreating it using the same file ids the other branch is using | 18:11 |
| jfroy | morning | 18:14 |
| jfroy | I have a small patch to submit to bzr, is it as simple as using bzr send? | 18:15 |
| seb_kuzminsky | jelmer: i'd be happy to throw away the current broken bzr repo and re-create it in some new way, but i dont know how | 18:16 |
| jelmer | jfroy, yep | 18:21 |
| jfroy | Gotta provide an email now :p | 18:21 |
| jfroy | Send to bazaar@lists.canonical.com? | 18:21 |
| jelmer | yep | 18:22 |
| jelmer | seb_kuzminsky, Unfortunately, I don't think there's a way to do that yet | 18:22 |
| jfroy | well that's awesome | 18:22 |
| seb_kuzminsky | jelmer: ok thanks, i'll just do it by hand | 18:24 |
| seb_kuzminsky | luckily our history is pretty short ;-) | 18:24 |
| rocky | jelmer: heyo | 18:33 |
| jelmer | rocky, was wondering if you could three revision properties in the cluemapper repo | 18:38 |
| jelmer | would be set by older (broken) versions of bzr-svn 0.5 | 18:38 |
| jelmer | unsetting them would fix svn-import | 18:38 |
| jelmer | rocky, bzr:base-revision on r512 | 18:39 |
| rocky | oh | 18:41 |
| rocky | that should be doable | 18:41 |
| rocky | "if you could three revision properties" ... think you missed a word there | 18:41 |
| jelmer | sorry | 18:42 |
| jelmer | if you could remove three revprops | 18:42 |
| rocky | what would be the easiest way to remove them? | 18:44 |
| rocky | and on what paths? | 18:44 |
| ilia | hi all | 18:52 |
| ilia | I have a question | 18:52 |
| ilia | anybody knows, how can I edit branch history? I need to change commiter's e-mails only. | 18:53 |
| beuno | ilia, you can't | 18:54 |
| beuno | it's immutable | 18:54 |
| beuno | you may be able to use bzr-rebase plugin, but it will make the branch incompatible with all the rest | 18:54 |
| jelmer | beuno, rebase doesn't change that sort of thing | 18:56 |
| jelmer | rocky, revision properties are set on the revision not on a particular path | 18:56 |
| jelmer | rocky, svn propdel -r512 --revprop bzr:base-revision <url> should do it | 18:56 |
| ilia | I have last 13 commits in a branch, which are my own | 18:58 |
| ilia | and I did it with wrong e-mail | 18:58 |
| ilia | I can branch from 13 revisions ago and make all changes in a single commit with a right e-mail, but it's an ugly solution | 18:59 |
| beuno | jelmer, it doesn't? I thought it let you re-commit in a sense | 19:00 |
| rocky | jelmer: done | 19:01 |
| ilia | bueno, what do you mean by "incompatible"? | 19:01 |
| beuno | ilia, revision IDs change, so existing branches will be completely different and unmergeable | 19:03 |
| ilia | there were no new branches during last 13 revisions | 19:04 |
| rocky | jelmer: any part of Clue* you're most interested in ? | 19:05 |
| ilia | i.e. the revisions I want to edit are currently only in one branch | 19:05 |
| jelmer | rocky, just browsing | 19:06 |
| pfanelli | hey, i am trying to setup pqm and can't figure out what goes in the queue and how to get it in there | 19:07 |
| pfanelli | any ideas? | 19:07 |
| jelmer | rocky, seems to still be there | 19:09 |
| beuno | pfanelli, you have to send the location of a branch to PQM | 19:10 |
| beuno | which PQM should be able to access | 19:10 |
| beuno | you send those with the bzr-pqm plugin | 19:10 |
| beuno | which IIUC, it sends it in through RPC with a gpg signature | 19:10 |
| pfanelli | i am running bzr 1.12, i have the bzr-pqm and bzr-email plugins loaded, i setup the public and target branch settings in the .bazaar/locations.conf file... | 19:12 |
| pfanelli | i my 'work' branch, i am running 'bzr pqm-submit -m "pqm submit test"... | 19:13 |
| pfanelli | i also did the 'bzr pqm-submit with a dry-run - and i can see that the email that is going to be emailed to pqm is gpg'ed correctly | 19:14 |
| pfanelli | and the pqm user is getting the email | 19:14 |
| pfanelli | then i run the 'pqm -v -d --run' command, but i don't see anything in the queue | 19:14 |
| LarstiQ | pfanelli: pqm can be a bit difficult to setup | 19:14 |
| pfanelli | but i have to say that it is awesome | 19:15 |
| pfanelli | all of this sw is awesome :) | 19:15 |
| LarstiQ | thank you :) | 19:15 |
| pfanelli | you guys are fantastic (i have been trying to find a way to start helping you guys out) | 19:15 |
| === salgado-lunch is now known as salgado | ||
| pfanelli | started looking at bzr bugs, but not sure where to start | 19:17 |
| pfanelli | who would be the correct person to ask about setting up pqm? | 19:20 |
| rocky | jelmer: i issued your cmmand... .svn said property was deleted ... not sure what else | 19:21 |
| rocky | jelmer: is there a specific path i have to delete it from? | 19:22 |
| rocky | i'm just doing it at the root of the repo | 19:22 |
| LarstiQ | pfanelli: Odd_Bloke, lifeless and Kinnison have set up pqm before, but maybe I can try to help debug too | 19:22 |
| pfanelli | LarstiQ: cool/thx, i am sooooo close on this, just trying to figure out what to ask next :) | 19:23 |
| LarstiQ | pfanelli: does pqm need to pick the mail up and enter it in the queue maybe? | 19:24 |
| LarstiQ | pfanelli: the mail arrives for the pqm user, what happens next? | 19:24 |
| LarstiQ | pfanelli: is there a procmailrc involved? | 19:24 |
| jelmer | rocky, hmm, that's odd | 19:26 |
| pfanelli | i took a guess and thought maybe that when i would run 'pqm --run' that it would read the mail in /var/mail, but when i ran 'pqm -h' is said that --run would process the queue... | 19:27 |
| pfanelli | so that's what got me thinking that, there has to be something in the queue to process | 19:27 |
| jelmer | rocky, svn propget --revprop -r512 bzr:base-revision https://dev.serverzen.com/svn/cluemapper still works | 19:28 |
| pfanelli | i think i have a chicken-and-egg thing going on here 8) | 19:28 |
| LarstiQ | pfanelli: let me take a gander at the pqm source | 19:29 |
| rocky | jelmer: http://cluebin.appspot.com/pasted/89262 | 19:31 |
| jelmer | rocky, it's lying! | 19:31 |
| jelmer | rocky, :-) | 19:31 |
| rocky | lol | 19:31 |
| jelmer | rocky, do you allow changing of revision properties in hooks/pre-revprop-change-hook ? | 19:31 |
| jelmer | rocky, you may have to temporarily edit that in order to be able to remove revision properties | 19:32 |
| jelmer | although it should also be giving you an error rather than silently ignoring you | 19:32 |
| rocky | jelmer: i've never intentionally changed anything in hooks/pre-* | 19:32 |
| rocky | jelmer: there is no pre-revprop-change script ... just the .tmpl one | 19:34 |
| jelmer | rocky, For now, you should be able to just create one that jsut does "exit 0" | 19:34 |
| jelmer | rocky, and remove it afterwards | 19:34 |
| rocky | k | 19:35 |
| pfanelli | LarstiQ: man that's a good idea, i am gonna' look at the unit tests for pqm (man, why didn't i think of this earlier) | 19:36 |
| rocky | bah, having ssh issues | 19:38 |
| jsled | I've a branch ("trunk") at revno 6797, and another ("remote") at 6667, which was the last point at which I sent a mergedirective to a coworker. Why would `bzr send -o update ../trunk` report "Bundling 0 revision(s)."? | 19:41 |
| rocky | jelmer: ok, i think i've done it ;) | 19:48 |
| jelmer | rocky, thanks! :-) | 19:48 |
| jelmer | jsled, there are no revisions in remote that are not in trunk | 19:49 |
| jsled | Ah. Cause I'm exactly backwards. *ahem* Sorry. | 19:49 |
| jsled | jelmer: thanks. | 19:51 |
| jelmer | rocky, the second one is r589, for which bzr:base-revision should also be removed | 19:55 |
| rocky | jelmer: i just removed that file =P | 19:55 |
| jelmer | rocky, s/file/property ? | 19:55 |
| mwhudson | good morning | 19:56 |
| jelmer | hey mwhudson, abentley | 19:56 |
| abentley | jelmer: morning. | 19:56 |
| jelmer | abentley, could you give bundlebuggy a kick? | 19:56 |
| jelmer | it doesn't seem to be responding atm | 19:56 |
| rocky | jelmer: no, the pre hook file that allowed me to delete the rev properties =P | 19:56 |
| jelmer | rocky, ahh :-) | 19:57 |
| jelmer | rocky, sorry | 19:57 |
| jelmer | rocky, bzr check said there were 3 such revisions | 19:57 |
| rocky | ah ok | 19:57 |
| jelmer | rocky, so there should be another one after the one I just reported | 19:57 |
| rocky | jelmer: ok, that one's removed | 19:57 |
| abentley | jelmer: restarted | 19:57 |
| jelmer | abentley, thanks | 19:58 |
| jelmer | rocky, thanks | 19:58 |
| jelmer | rocky, the last one is r591 | 20:11 |
| rocky | jelmer: done | 20:12 |
| jelmer | rocky, merci | 20:18 |
| jelmer | jfroy, how are you using the netrc plugin? | 20:20 |
| === sdboyer-laptop_ is now known as sdboyer-laptop | ||
| === sdboyer-laptop is now known as Guest31946 | ||
| jfroy | jelmer: sorry back | 20:32 |
| jfroy | I'm using using netrc myself | 20:32 |
| jfroy | But the code is clear | 20:32 |
| * jfroy pasted http://pastie.textmate.org/408694 | 20:33 | |
| jfroy | it at minimum expects a 'host' key in the credentials dictionary | 20:33 |
| LarstiQ | oh, that sounds familiar | 20:33 |
| jfroy | and the netrc tests synthesize credential dictionaries with a 'host' key set. | 20:33 |
| LarstiQ | did I not report that bug? :( | 20:34 |
| jfroy | however AuthorizationConfig never did set that | 20:34 |
| jfroy | LarstiQ: maybe :p I honestly didn't check. | 20:34 |
| jfroy | My patch was written with my keychain credential store plug-in in mind, but also conforms to the expectations of the netrc plug-in. | 20:34 |
| LarstiQ | jfroy: it's entirely possible, bad larstiq has not been getting to many things on his todo list | 20:34 |
| fullermd | That keeps other things on the list from getting lonely. | 20:35 |
| LarstiQ | yes, but any time now they might petition the UN for recognition of their own nation. | 20:38 |
| fullermd | Hah! Fat chance. They're your vassals, totally dependant upon you for any sustenance or boon you might grant them! | 20:39 |
| fullermd | You're just demonstrating the point by starving them out, see. Clenching the iron fist. | 20:40 |
| pigmej | Hi everyone, | 20:47 |
| pigmej | How to get commit message from bzrlib ? | 20:47 |
| LarstiQ | pigmej: for a given revision? | 20:48 |
| pigmej | Yes | 20:48 |
| pigmej | I cannot find that in docs... | 20:48 |
| LarstiQ | pigmej: revision.message | 20:49 |
| pigmej | hmmm | 20:49 |
| LarstiQ | pigmej: say, 'from bzrlib.workingtree import WorkingTree; tree = WorkingTree.open('"."); print tree.branch.repository.get_revision(tree.last_revision()).message | 20:50 |
| pigmej | Hmm | 20:50 |
| pigmej | I'm going in other way... | 20:51 |
| pigmej | like | 20:51 |
| pigmej | my_branch=branch.Branch.open(....) | 20:51 |
| pigmej | repo=my_branch.repository | 20:51 |
| pigmej | repo.lock_write() | 20:51 |
| pigmej | and then revtree=repo.revision_tree(rev_id) | 20:52 |
| pigmej | rev_id is previously set to my_branch.last_revision() in that "example" | 20:53 |
| pigmej | is it better to go trough WorkingTree? | 20:53 |
| pigmej | i need branches "support" | 20:53 |
| LarstiQ | no, this is fine | 20:55 |
| LarstiQ | so then | 20:55 |
| LarstiQ | repo.get_revision(rev_id).message | 20:55 |
| pigmej | thanks ;) | 20:56 |
| pigmej | btw I think that the better api documentation is needed ;d | 20:56 |
| LarstiQ | pigmej: revision_tree() gets you the RevisionTree of that revision, not the Revision object itself | 20:56 |
| LarstiQ | pigmej: where did you look to find this information? | 20:57 |
| LarstiQ | pigmej: ie, what do we need to change to have better helped you? | 20:57 |
| LarstiQ | pigmej: patches welcome btw ;) | 20:57 |
| pigmej | http://starship.python.net/crew/mwh/bzrlibapi/ | 20:57 |
| pigmej | here for example ;d | 20:57 |
| pigmej | and there http://bazaar-vcs.org/BzrGivingBack | 20:57 |
| LarstiQ | ok, and then, at what pieces of that did you look? | 20:58 |
| pigmej | LarstiQ: Finally i fetch | 20:58 |
| pigmej | revison=revtree.inventory() | 20:58 |
| pigmej | LarstiQ: anyway what is the best way to fech binary files content ? | 21:04 |
| LarstiQ | pigmej: I don't know about "best", but I'd do "fileid = revtree.path2id('NEWS'); fileobj = revtree.get_file(fileid)" | 21:09 |
| pigmej | LarstiQ: so the same way that me :d | 21:09 |
| pigmej | I'm going to write some bzr_wiki ;-) | 21:09 |
| pigmej | web wiki engine managed via bzr ;) | 21:10 |
| pigmej | just for fun ;d | 21:10 |
| LarstiQ | pigmej: ah ok, cool :) | 21:10 |
| LarstiQ | pigmej: I don't know how up to date the ikiwiki bzr backend is, but you could look at that too | 21:10 |
| LarstiQ | pigmej: but keep us posted about your progress :) | 21:11 |
| pigmej | LarstiQ: mine "bzr_wiki" in final ver should have full web access to naturally | 21:11 |
| pigmej | I will see :) | 21:11 |
| LarstiQ | pigmej: are you aware of http://bazaar-vcs.org/Integrating_with_Bazaar btw? | 21:15 |
| pigmej | I have read this :) | 21:16 |
| pigmej | From that I have revtree ;-) | 21:17 |
| LarstiQ | ok :) | 21:17 |
| ferringb | curious, anyone seen failed locks w/ "Transport operation not possible: readonly transport" when doing bzr pull $URL -d $CHECKOUT , yet have it succeed fine when doing cd ${CHECKOUT} & bzr pull $URL # ? | 21:20 |
| poolie | ferringb: that is strange | 21:46 |
| * ferringb thought so | 21:46 | |
| ferringb | solution atm is to kill the checkout, which sucks a bit though | 21:47 |
| poolie | ferringb: does it tell you which transport is readonly? or does the traceback in ~/.bzr.log give any clues? | 21:47 |
| ferringb | forgot about ~/.bzr.log | 21:47 |
| poolie | is it a checkout bound to another branch? | 21:47 |
| ferringb | sec | 21:47 |
| jam | morning poolie | 21:49 |
| ferringb | poolie: remote, bzr server is chucking it | 21:54 |
| poolie | hello jam | 21:54 |
| ferringb | poolie: re: checkout bound to another branch, if by that you mean is the checkout w/in a repo... yes, tis. | 22:00 |
| ferringb | the branch it's pulling from, that side has a similar setup although I'd expect bzr server to handle that- the odd thing is that bzr-server does lack write perms to those directories (intentionally since commits aren't routed through it since when we deployed it bzr-server was raw and questionable), although those issues aren't seen for other ops | 22:01 |
| === montywi|food is now known as montywi | ||
| pfanelli | this stuff (bzr, pqm, cm, etc...) is fantastic! I have been working today trying to get pqm setup and working with bzr. I forgot the link in pqm over to the bzr code. I ran the pqm tests and it said I was using 1.13 but needed 1.12. So I ran 'bzr revert -r date:2009-02-13' on my bzr.dev and presto it works. That's the motto 'it just works'. Fantastic :) | 22:28 |
| ferringb | poolie: figured out an additional naggle actually. that co came from a different upstream branch, iow foon.com/repo1, the pull --overwrite fails when it attempts foon.com/repo2 over the same co | 23:01 |
| spiv | jam: btw, the numbers for time spent generating a stream for the network are 22% in fileids_altered_by_revision_ids, and 16% because _read_records_iter_raw is used rather than _read_records_iter_unchecked | 23:07 |
| pfanelli | another pqm ?...I have the 'mail_reply=1' set in my .pqm.conf file, but when I run 'pqm -v -d --run --report' i am not seeing any mail reply? Any ideas why? | 23:20 |
| === montywi is now known as montywi|zzz | ||
| pfanelli | any pqm guru's out there? Is this a bad time of the day/night/ | 23:54 |
| pfanelli | ? | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
