| GaryvdM | Night | 00:39 |
|---|---|---|
| knittl | how are bzr revision ids calculated/generated? i'm also happy with the file name (and line number/function name) | 00:47 |
| nsh22 | hey... is there a plugin for use with Qt Creator? | 00:50 |
| === Ursinha is now known as Ursinha-afk | ||
| jbowtie | knittl: I assume you're asking about native revids? Because the plugins that talk to other VCS code can generate their own revids. (meaning bzr-svn, bzr-tfs, etc...) | 01:26 |
| knittl | jbowtie: yes i was. but i think i found it. email-timestamp-random | 01:27 |
| knittl | although i don't understand why random and not some kind of hash | 01:27 |
| jbowtie | knittl: Probably no reasonable criteria for what to hash. | 01:29 |
| jbowtie | knittl: Don't forget that revids can originate in other places. For example bzr-tfs uses path:changeset for its revids. | 01:31 |
| knittl | so in bzr there is no way to verify a revid is actually the revid of that particular revision? | 01:32 |
| lifeless | revids themselves are not signatures | 01:32 |
| lifeless | signature are signatures | 01:33 |
| knittl | also creating the exact same revision twice will generate a different revid? | 01:34 |
| jbowtie | knittl: If I understand the question, yes, you'll get two different revids; though I suspect they would merge cleanly in that case. | 01:37 |
| knittl | ok | 01:38 |
| poolie | hi all | 03:05 |
| poolie | i'm having some hardware problems, will be offline a bit | 03:05 |
| poolie | some web pages indicate it may be just the cable, which would be nice | 03:06 |
| spiv | poolie: almost more aggravating if it just a cable, though :) | 03:08 |
| poolie | :) | 03:09 |
| lifeless | poolie_: the pad.lv root page doesn't list OOPS | 05:43 |
| === poolie_ is now known as poolie | ||
| poolie | thanks | 05:46 |
| lifeless | just a small thing :) | 05:46 |
| poolie | can you give me an example id? | 05:48 |
| poolie | fixed | 05:55 |
| vila | ding ding ding, release day, hello all ! | 06:03 |
| lifeless | poolie: I mean that the root page doesn't explain showing OOPS's | 06:03 |
| vila | poolie: got that cable plugged now ? :-p | 06:03 |
| lifeless | poolie: actually showing a specific oops works :P | 06:03 |
| poolie | lifeless: i understand; i've fixed it now | 06:03 |
| lifeless | \o/ | 06:03 |
| poolie | i was just going to use a specific example | 06:03 |
| lifeless | ah | 06:03 |
| poolie | but i guess since most people can't click them it's of limited use | 06:03 |
| poolie | and maybe they expire anyhow? | 06:04 |
| poolie | hi vila | 06:04 |
| lifeless | eventually yes | 06:04 |
| poolie | i was hoping to get stale lock detection in for the beta, but i guess i won't now | 06:04 |
| poolie | and i believe in resisting the temptation to slip or rush | 06:04 |
| vila | poolie: you're right, I was hoping for orphans myself :) | 06:05 |
| poolie | so, let's just do it | 06:05 |
| poolie | can release another later | 06:05 |
| poolie | vila, i'm just running gardener | 06:05 |
| poolie | which is nice | 06:05 |
| poolie | but it told me something was merged even though it has uncommitted changes | 06:05 |
| poolie | is that intended? | 06:05 |
| vila | poolie: glad you like it | 06:05 |
| vila | poolie: it's very rough so far, so it just spew out whatever if finds without dependencies | 06:06 |
| poolie | so that seems like a bug? do you want a report somewhere? | 06:07 |
| poolie | or for me to just tell you here | 06:07 |
| vila | the rules can be refined, but I'm not clear yet about all edge cases, after all, you may modify a tree after it has been merged, you can forget to commit, etc, so upfront, I can't say if your case is valid | 06:07 |
| vila | poolie: bug please | 06:08 |
| vila | poolie: that's why I released early :) | 06:08 |
| poolie | vila, so today shall we do 2.2.1 and 2.3b1? | 06:09 |
| vila | poolie: no 2.1.2 ? Anyway, I think the most important is 2.2.1 so we can then merge up | 06:09 |
| poolie | and also that | 06:10 |
| poolie | i sent a merge up of 2.1 to 2.2 the other day | 06:10 |
| poolie | would be worth checking it succeeded | 06:10 |
| vila | I think I saw it | 06:11 |
| vila | poolie: Can you just remind me the intended audience for 2.1.3 and 2.2.1 (2.3b1 is for everyone willing to try, but not stable yet) | 06:13 |
| vila | 2.2.1 will go into maverick right ? Somewhere else ? | 06:14 |
| poolie | 2.2.1 should go in to maverick updates | 06:14 |
| poolie | they've just today announced the final freeze | 06:14 |
| poolie | i don't know if it's possible to do an SRU before the thing even officially releases | 06:15 |
| poolie | we should check | 06:15 |
| vila | ok, added to TODO | 06:15 |
| vila | hmm, we don't have a place where we track which distro carry which bzr version right ? | 06:16 |
| * fullermd will be updating ports... | 06:16 | |
| fullermd | We did have a page on the wiki once. It was very useful for seeing when anybody bothered updating it ;p | 06:16 |
| vila | Didn't have such a page to track the installer builds ? Or was it done just by mail ? | 06:17 |
| vila | That will be very helpful for me and my alzheimer... what's the name ? | 06:18 |
| poolie | also, we may want to get a specific clarification that the SRU policy and our policy agree | 06:18 |
| poolie | to avoid future confusion | 06:18 |
| vila | I think we got such confirmation... or did I just dreamed it ? | 06:19 |
| poolie | https://bugs.edge.launchpad.net/bzr-gardener/+bug/641043 - your very first! | 06:19 |
| ubot5 | Launchpad bug 641043 in bzr-gardener "says 'merged' about trees with uncommitted changes (affected: 1, heat: 6)" [Undecided,New] | 06:19 |
| vila | poolie: anyway, yesterday mthaddon was kind enough to create a pqm 2.3 branch so I think everything is in place for whatever release we want to do | 06:20 |
| vila | poolie: we may as well start with 2.1.3 | 06:21 |
| poolie | yes, lets | 06:21 |
| poolie | *let's | 06:21 |
| poolie | how about if you do it and i'll copilot? | 06:21 |
| spiv | vila, poolie: for some reason my __copy__ hack is failing on lp:bzr but not lp:bzr/2.2. I've thought of a shorter, more conservative workaround for traceback duplication to use to replace the __copy__ hack, it might be good to land that to 2.2 before we make a release of 2.2.1? | 06:21 |
| spiv | (I was trying to merge 2.2 to lp:bzr so I could close off a couple of In Progress bugs) | 06:21 |
| poolie | just in case it is subtly broken in 2.2? | 06:22 |
| poolie | that makes sense to me, put it up for review? | 06:22 |
| spiv | Right, and the minimise the delta between 2.2 and trunk. | 06:22 |
| spiv | Will do. | 06:22 |
| poolie | on the whole that was perhaps not critical enough to put in 2.2 | 06:22 |
| poolie | otoh it should only affect selftest | 06:22 |
| vila | spiv: if you're >90% sure about it , go, otherwise, revert please ;) | 06:23 |
| vila | oh, only selftest ? make that >80% then :) | 06:23 |
| vila | spiv: thanks for the heads-up anyway | 06:23 |
| vila | poolie: also, for 2.3, do we allow only backports from now on or will 2.3b2 be just a pull of bzr.dev ? | 06:25 |
| poolie | backports? | 06:26 |
| poolie | meaning merges from trunk to 2.3? | 06:26 |
| vila | poolie: I mean, what will be the policy for merging changes to 2.3. The same as 2.2 as of today, or everything from bzr.dev at 2.3b2 release time ? | 06:27 |
| spiv | IIRC the process was that 2.3 is released from trunk until the first rc... am I misremembering? | 06:27 |
| poolie | there was some discussion that having a branch makes the actual release process easier | 06:28 |
| vila | spiv: yeah, that | 06:28 |
| poolie | in case any small fixes are needed | 06:28 |
| spiv | vila, poolie: https://code.edge.launchpad.net/~spiv/bzr/traceback-accumulation-2.2/+merge/35778 | 06:29 |
| poolie | thanks, +1 | 06:30 |
| vila | poolie: wow, hold on, what about 2.0.6 ? | 06:39 |
| vila | https://edge.launchpad.net/bzr/2.0 says: Released in September 2009; supported until at least September 2010. | 06:40 |
| spiv | There are several worthwhile fixes that would be in 2.0.6, especially #522637 | 06:41 |
| vila | spiv: shameless plug :) | 06:41 |
| spiv | :) | 06:41 |
| poolie | let's do it | 06:42 |
| poolie | hm, what should i do now? still fix stale locks? | 06:44 |
| poolie | maybe add a note about requesting SRUs to the release guide, then go back to that | 06:45 |
| vila | poolie: whatever you want as long as I can interrupt you :) But if you want to summarize our policies regarding 2.0, 2.1, 2.2, 2.3, that would be good too :) | 06:45 |
| poolie | i'll be here for at least 2-3 hours | 06:49 |
| vila | meh, now what's new for 2.0, no wonder I couldn't find it :) | 06:50 |
| vila | bzr lp-propose -m 'Release 2.0.6' --approve lp:bzr/2.0 | 06:56 |
| vila | bzr: ERROR: bzr+ssh://bazaar.launchpad.net/%2Bbranch/bzr/2.0/ is not registered on Launchpad | 06:56 |
| vila | ring any bell ? | 06:56 |
| poolie | it sounds a lot like what thumper just changed | 06:57 |
| vila | grr, firefox can't start, close any existing window (none, double checked) or *restart your system*. WTF ? | 07:03 |
| vila | ok, found the ghost, jinxed it | 07:07 |
| vila | poolie: https://code.edge.launchpad.net/~vila/bzr/prepare-2.0.6/+merge/35779 sanity check please, while pqm is busy | 07:09 |
| vila | poolie: ping | 07:23 |
| * vila plugs poolie's cable | 07:26 | |
| poolie | poolie: hi | 07:29 |
| poolie | i mean, vila | 07:29 |
| vila | :) | 07:29 |
| poolie | sure | 07:30 |
| poolie | vila re the branch for bug 32669 | 07:31 |
| ubot5 | Launchpad bug 32669 in Bazaar "Adding a symlink to another branch fails (affected: 3, heat: 17)" [Medium,Fix released] https://launchpad.net/bugs/32669 | 07:31 |
| poolie | hm | 07:32 |
| poolie | i have a comment https://bugs.edge.launchpad.net/bzr/+bug/32669/comments/14 saying "fixed in trunk after 2.2" but i don't see it in trunk's news file | 07:33 |
| ubot5 | Launchpad bug 32669 in Bazaar "Adding a symlink to another branch fails (affected: 3, heat: 17)" [Medium,Fix released] | 07:33 |
| poolie | at any rate i wouldn't block 2.0.6 on it | 07:33 |
| vila | poolie: me neither :) Just a heads-up for 2.0.7 | 07:33 |
| vila | poolie: Given http://paste.ubuntu.com/495121/, I'll create a 2.0.7 milestone with a 2011-03-10 targeted date (in six months, a thursday) | 07:34 |
| poolie | hm | 07:35 |
| poolie | that makes sense | 07:35 |
| vila | done | 07:36 |
| poolie | its host distribution may EOL before then? | 07:36 |
| vila | you mean hardy ? | 07:37 |
| poolie | i guess so | 07:37 |
| poolie | actually no, isn't 2.0 in karmic? | 07:37 |
| vila | anyway, that's why I asked for a policy for 2.0, 2.1, 2.2, 2.3. The milestone is there, we can always says: and this is the last 2.0 release | 07:38 |
| poolie | works for me | 07:38 |
| vila | poolie: ok, sanity check on https://code.edge.launchpad.net/~vila/bzr/prepare-2.0.6/+merge/35779 ? | 07:39 |
| poolie | yes, it's fine | 07:43 |
| poolie | karmic is supported until april next year | 07:46 |
| poolie | so, it's probably not worth doing a 2.0.7 in march | 07:46 |
| poolie | but we can see how we go closer to the time | 07:46 |
| vila | pff, two feed-pqm from two different setups, both errored out but both send the request :-/ | 07:51 |
| poolie | istm we want to get on to this page: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions | 07:54 |
| vila | poolie: istm you're deadly right | 07:58 |
| poolie | i'll mail the board | 08:00 |
| vila | poolie: great ! thanks ! | 08:00 |
| vila | spiv: http://babune.ladeuil.net:24842/job/selftest-hardy/lastFailedBuild/testReport/junit/bzrlib.tests.test_sftp_transport/SSHVendorBadConnection/test_bad_connection_ssh/ :-( how about http://paste.ubuntu.com/495128/ | 08:04 |
| bialix | heya vila, spiv | 08:04 |
| spiv | vila: hmm, I don't think I like that. | 08:05 |
| vila | spiv: e.errno and e.args seem to be a mess that we don't handle consistently in other parts (see also bzrlib.smart.medium line 930 ) | 08:05 |
| spiv | Yeah :( | 08:06 |
| vila | spiv: hehe, I don't like it much either, but I want a stop-gap fix | 08:06 |
| vila | spiv: I hate to discover that *now* too | 08:06 |
| vila | spiv: and the comment in bs.medium is even more worrying because many other places don't even take it into account (grep socket.error) | 08:07 |
| poolie | does anyone know off hand if selftest runs during packaging? | 08:07 |
| poolie | i think it does not. | 08:07 |
| spiv | poolie: my guess is no, but I don't know either. | 08:08 |
| vila | dunno, but it runs at each commit and at source release time | 08:08 |
| poolie | i know :) | 08:08 |
| vila | releasing source is not part of packaging ? | 08:08 |
| vila | hmm | 08:09 |
| spiv | poolie: IIRC pitti has said that our mandatory tests-run-before-landing might be considered as good | 08:09 |
| spiv | But I guess it's probably not too hard to make the packaging do a selftest run. | 08:09 |
| * bialix waves at poolie | 08:10 | |
| vila | bialix: hey ! | 08:10 |
| poolie | hi there spiv, bialix | 08:12 |
| spiv | vila: I'm actually trying to figure out why EPIPE is being treated specially there in the first place :) | 08:12 |
| vila | spiv: do you have a better idea for http://paste.ubuntu.com/495128/ that could be landed soon ? Will a huge red blinking FIXME be enough to wait for a better fix ? | 08:12 |
| spiv | vila: as a stopgap, socket.error isn't going to be EPIPE is it? So it could be handled in a separate except block. | 08:12 |
| vila | spiv: ha cool, I'd like to have this fixed asap and preferably before cutting 2.3b1 | 08:13 |
| vila | spiv: let me double check, I think it was | 08:13 |
| vila | spiv: http://babune.ladeuil.net:24842/job/selftest-hardy/195/testReport/junit/bzrlib.tests.test_sftp_transport/SSHVendorBadConnection/test_bad_connection_ssh/ | 08:13 |
| spiv | Blah. | 08:14 |
| vila | spiv: and I'm pretty sure the analysis was that it was a socket.error... | 08:14 |
| spiv | Yeah. | 08:14 |
| vila | an alternative would be a more complex test with isinstance(socket) and e.args[0] or e.errno... but without tests... :-/ | 08:15 |
| vila | s/complex test/complex if expression/ | 08:16 |
| vila | spiv: thks for the merge 2.2 -> dev | 08:16 |
| spiv | vila: you're welcome, I already had it ready to go :) | 08:17 |
| poolie | ok sent | 08:20 |
| spiv | vila: I wonder if maybe http://paste.ubuntu.com/495134/ would do? | 08:21 |
| vila | spiv: rationale ? | 08:22 |
| spiv | vila: I don't really understand why that code is treating errno==EPIPE and EOFError as a connection error, but anything else that occurs during connection as not a connection error... | 08:22 |
| spiv | (despite the comment and the fact that annotate blames me :) | 08:22 |
| spiv | vila: so I'm thinking "why not treat all of those as a regular connection error?", basically | 08:23 |
| vila | spiv: and we have evidence that not handling a socket.error.EPIPE make the test fail... how does this relate ? | 08:24 |
| vila | now we will raise a connection error in this case and ? | 08:24 |
| vila | it will be handled above and... what ? | 08:25 |
| spiv | EPIPE there has always caused some sort of exception there | 08:25 |
| spiv | So if the test needs the connection to somehow succeed in that case, we're barking up the wrong tree with tweaking which exception it raises. | 08:26 |
| vila | Given that the comment is referring to some untested condition, I'm glad enough to get rid of it, worth a try at least | 08:27 |
| spiv | Well, it's not going to solve the intermittent failure. | 08:28 |
| spiv | It'll give a more appropriate error, we hope. | 08:28 |
| poolie | i need to reply to vila's config thing... | 08:29 |
| vila | spiv: ok, let's try that | 08:30 |
| spiv | Hmm, I guess the test is about failure to connect, so a more appropriate error may be the fix... | 08:30 |
| vila | poolie: the orphan related one ? | 08:30 |
| vila | spiv: I understand | 08:30 |
| poolie | yeah | 08:30 |
| vila | spiv: well, I *think* I understand :) | 08:30 |
| vila | poolie: amanica raised a good point about ignoring bzr-orphans | 08:31 |
| * spiv experiments now | 08:31 | |
| spiv | vila: manually hacking that try block to raise various socket.errors, just unconditionally doing self._raise... works. | 08:34 |
| spiv | vila: I'll put up a patch | 08:34 |
| vila | spiv: thanks | 08:34 |
| spiv | vila: I'd love to know what the different treatment of EPIPE was intended to achieve, though :/ | 08:35 |
| vila | spiv: yeah, me too, let's ask the praised one for this comment :) | 08:35 |
| vila | spiv: just joking, trying to ease your pain for not remembering, I so know the feeling ;) | 08:37 |
| vila | aw... 2.0 the [ascii] tests, double pain | 08:39 |
| vila | plus the fact that I should add that back to babune some way or another ;-/ | 08:40 |
| vila | spiv: by the way, IIUC you have a patch for python addressing http://babune.ladeuil.net:24842/job/selftest-jaunty/lastFailedBuild/testReport/junit/bzrlib.tests.per_transport/TransportTests/test_readv_with_adjust_for_latency_HttpTransport_urllib_HTTPSServer_urllib_/ ? | 08:42 |
| spiv | vila: https://code.edge.launchpad.net/~spiv/bzr/ssh-connect-socket-error/+merge/35784 | 08:42 |
| spiv | vila: yes, fixed in the upstream 2.7 branch, patch backported already to python2.6 in maverick | 08:43 |
| spiv | vila: it's triggered by trying to things with SSLSocket objects that aren't connected | 08:44 |
| spiv | vila: (http://bugs.python.org/issue9729 is the relevant report) | 08:44 |
| vila | spiv: I know the root cause, ha cool | 08:44 |
| spiv | vila: so if we want to avoid it in unfixed python perhaps we can find a way to avoid trying to use SSL sockets there before they are actually connected? | 08:44 |
| vila | spiv: it occurs only *before* the first connection ? | 08:45 |
| vila | hmm, given the traceback... that's an idea worth checking... | 08:47 |
| spiv | vila: if the SSLSocket._sslobj is not set, then various methods (including send and recv) just try to delegate to the back socket object implementation, presumably so that you'll get appropriate socket.errors | 08:47 |
| spiv | vila: except those code paths were untested and in some cases broken in two separate ways :) | 08:48 |
| vila | spiv: so we get correct socket errors (EBADF especially) if we try to use a close socket right ? | 08:48 |
| vila | closed | 08:48 |
| vila | spiv: yeah, tell me about untested code ;-/ | 08:48 |
| spiv | http://svn.python.org/view?view=rev&revision=84806 is the patch that was committed. | 08:49 |
| spiv | vila: I know it's triggered by never-been-connected sockets wrapped with the SSLSocket class | 08:50 |
| spiv | vila: I haven't checked if was-connected-but-now-now-closed sockets would do the same thing | 08:51 |
| vila | spiv: ok, good enough for me, I'm pretty sure the later is covered by tests | 08:51 |
| vila | spiv: well, obviously the former is too ;) | 08:51 |
| vila | spiv: but randomly :-D | 08:52 |
| spiv | I was a bit depressed by the test_socket and test_ssl tests in Python. | 08:52 |
| spiv | I'm used to nicer test infrastructure, and more comprehensive coverage. | 08:53 |
| vila | spiv: right, I think I have rough idea on how to reproduce it in a test, but not now ;( | 08:56 |
| vila | ;) I meant | 08:56 |
| vila | spiv: so this patch will find its way upstream in the next 2.6 or only 2.7 ? | 08:57 |
| spiv | vila: only 2.7 | 09:01 |
| spiv | vila: IIRC upstream considers 2.6 to be security-fixes-only now | 09:01 |
| vila | spiv: right, ssl is all about security isn't it ? :D | 09:01 |
| spiv | Hah. | 09:01 |
| spiv | vila: I'm about to log off for the night, anything else you need from me urgently? | 09:02 |
| vila | spiv: I don't think so, unless your current pqm submission fails in which case, I'll came personally talk to you on the beach | 09:03 |
| spiv | Ok :) | 09:03 |
| vila | spiv: I'll land the fix for the EPIPE thing when needed | 09:03 |
| spiv | I'll try to keep an eye on it and if it fails put the failure somewhere visible. | 09:03 |
| vila | spiv: ok, great, enjoy your week-end ! | 09:04 |
| spiv | vila: thanks, you too, when you get the chance :) | 09:04 |
| vila | grr, bzr-2.0 knows nothing about BZR_PLUGIN_PATH damn alzheimer | 09:07 |
| * vila whistles while sudo mv <censored>/plugins <censored>/pluginsx , because... he can | 09:12 | |
| poolie | vila, https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/35785 describes sru stuff | 09:14 |
| poolie | there may be more to add | 09:14 |
| poolie | i don't want to duplicate the wiki too much though | 09:14 |
| poolie | but please ask questions | 09:14 |
| * poolie trying to get the scripts branch through pqm | 09:15 | |
| poolie | did we merge the patch to omit details from skipped tests? | 09:16 |
| vila | poolie: I don't know, but my understanding is that jam and mgz are shaving this yak differently so they should agree on the better way (I've ping them both) | 09:18 |
| spiv | At least the workaround for duplicated tracebacks will help keep the details of skipped tests to something reasonable. | 09:19 |
| vila | spiv: +1 | 09:19 |
| vila | spiv: you did land this one right ? | 09:19 |
| spiv | On 2.2 (which is being merged to bzr.dev as we speak) | 09:20 |
| * vila drools about spiv wifi access from the beach 8-) | 09:20 | |
| poolie | have fun spiv :) | 09:20 |
| vila | poolie: appropriate Ubuntu release for 2.0 -> >= karmic ? | 09:32 |
| poolie | for 2.0 it would be karmci | 09:34 |
| poolie | 2.1 lucid | 09:34 |
| poolie | 2.2 mavericj | 09:34 |
| vila | poolie: ok, and for ppas, I'll follow ppa.txt, but I'm not there yet | 09:40 |
| vila | for those following from home: make check-dist-tarball for 2.0.6 : Ran 23384 tests in 1049.609s | 09:48 |
| vila | OK (known_failures=39) | 09:48 |
| vila | 2014 tests skipped | 09:48 |
| vila | bzrlib.tests.blackbox.test_branch.TestBranchStacked.test_branch_stacked_from_smart_server is leaking threads among 2523 leaking tests. | 09:48 |
| vila | now running with no locale | 09:48 |
| fullermd | Spooky. | 09:50 |
| vila | pass with no locale: [ascii] Ran 23384 tests in 994.671s | 10:12 |
| vila | [ascii] OK (known_failures=39) | 10:12 |
| vila | [ascii] 2260 tests skipped | 10:12 |
| vila | [ascii] bzrlib.tests.blackbox.test_branch.TestBranchStacked.test_branch_stacked_from_smart_server is leaking threads among 2476 leaking tests. | 10:12 |
| vila | Finally, I've got some reference point about the number of leaks | 10:12 |
| spiv | vila: which reminds me: https://bugs.edge.launchpad.net/subunit/+bug/637674 | 10:13 |
| ubot5 | Launchpad bug 637674 in subunit "RemotedTestCase.addCleanup exists but fails under Python 2.7 (affected: 1, heat: 6)" [Undecided,New] | 10:13 |
| vila | spiv: hmm, should ping mgz about it | 10:14 |
| spiv | Oh, I see the 2.2->dev branch landed. Good. | 10:15 |
| awilkins | Is there any software I can exploit to rapidly illustrate branch revision graphs? | 10:23 |
| bialix | qlog | 10:24 |
| awilkins | Esp. something that produces "management grade" graphics? | 10:24 |
| awilkins | Hmmph. | 10:24 |
| Glenjamin | bzr-gtk adds a graph command iirc | 10:24 |
| fullermd | bzrtools has something that uses graphviz. | 10:24 |
| Glenjamin | ^^ thats the one i mean | 10:24 |
| bialix | it does not work well on big graphs | 10:25 |
| awilkins | Heh, I was kinda hoping for something that does hypothetical ones, but I suppose that's just as much work :-) | 10:25 |
| Glenjamin | graph-ancestry | 10:25 |
| fullermd | Oh, well, for hypothetical ones you use ASCII-art 8-} | 10:25 |
| bialix | jam is very good on that | 10:25 |
| Glenjamin | oh i see | 10:25 |
| awilkins | fullermd, I'm talking about _management grade_ visualization :-) | 10:25 |
| bialix | you can search the examples in his mails | 10:25 |
| fullermd | 4-color glossy ASCII art, then :p | 10:26 |
| vila | I heard Gary wasn't bad at generating them too ;-) | 10:26 |
| awilkins | Heheheheh :-) | 10:26 |
| fullermd | You could bang up fake stuff to feed into dot just like graph-ancestry does. | 10:26 |
| Glenjamin | visio / omingraffle / dia i guess | 10:26 |
| fullermd | I'd probably fiddle with xfig if I had to do it. | 10:26 |
| bialix | inkscape | 10:26 |
| bialix | we'll I | 10:27 |
| fullermd | (I love xfig. The UI is so bizarre by modern standards that it always makes me crosseyed for the first 10 minutes I use it, but then it snaps right into focus) | 10:27 |
| bialix | well I'd just draw by hand and scan it later | 10:27 |
| awilkins | Yeah, I've been using Inkscape up till now | 10:27 |
| bialix | awilkins: what is "management grade"? | 10:28 |
| lifeless | bialix: simple :) | 10:29 |
| fullermd | I presume it defines the revenue contribution of each revision. | 10:29 |
| bialix | rotfl | 10:29 |
| fullermd | Also there need to be little clipart cartoon men pointing at them and smiling. | 10:29 |
| fullermd | (for bonus points, they all spontaneously burst out singing _It's A Small World_ partway through the presentation. Come to think of it, I'd kinda dig seeing that myself.) | 10:30 |
| Glenjamin | do it in ascii, then apply a 3D filter to it so its at an angle | 10:30 |
| bialix | awilkins: look http://doc.bazaar.canonical.com/migration/en/foreign/bzr-on-svn-projects.html | 10:31 |
| bialix | there is a lot of sexy pictures | 10:31 |
| awilkins | bialix, Yes, I always liked those | 10:31 |
| awilkins | What are those, inkscape? | 10:32 |
| bialix | no, some MacOS tool | 10:32 |
| awilkins | Bah. | 10:33 |
| bialix | I know | 10:33 |
| awilkins | Ought to write something that takes ASCII-art graphs and transforms them into SVG | 10:33 |
| awilkins | Which you can then stylesheet and export to PNG | 10:34 |
| fullermd | The people who can do things like that are too busy writing converters that go the other way, making ASCII movies :p | 10:34 |
| Glenjamin | I always find whenever i try and use a diagramming tool | 10:34 |
| Glenjamin | that i wish i'd just used paper | 10:34 |
| awilkins | A tool that generated Hollywood movies from ASCII art would be much more impressive | 10:35 |
| fullermd | Isn't that what Avatar did? | 10:35 |
| Glenjamin | its not something you generally do often enough to be able to do something that looks good quickly | 10:35 |
| fullermd | xfig works well for me once I jerk back into the mental mode to handle the UI. | 10:36 |
| Glenjamin | it has a horrible website | 10:36 |
| fullermd | I didn't even know it had a website, actually... | 10:37 |
| awilkins | Woo, the recursive SVG file on the SVG page for Wikipedia is really impressive | 10:37 |
| Glenjamin | whenever i see a site like this i instantly imagine it hasn't been maintained for a decade | 10:37 |
| fullermd | I don't think it's had a release in something like that, no. But it still works fine. | 10:37 |
| fullermd | Heck, xv hasn't had a release in, what, almost 2 decades? But I still use it every day. | 10:37 |
| * fullermd wonders when the last time xbiff was touched was... | 10:37 | |
| Glenjamin | awilkins: where's the recursive one? | 10:38 |
| awilkins | Glenjamin, I figured that the one that shows an SVG file overlaid with the SVG logo was actually describing itself | 10:39 |
| * awilkins opens the file | 10:39 | |
| awilkins | Ok, it's a MITE more complex inside :-( | 10:40 |
| Glenjamin | oh, i thought there was an SVG which included itself and rendered an infinite picture | 10:41 |
| awilkins | That would be cool ; on a related note I have a hankering to produce an XSLT stylesheet that renders an annotated schema as a specification document, which includes a pretty-printed copy of the schema within it as an appendix | 10:42 |
| fullermd | Ideally also prettyprinting the XSLT :p | 10:45 |
| awilkins | Heh, just have one XML file that is the schema but has the XSLT inline so you can open it in a browser to get a "management grade" spec but also use it for implementation :-) | 10:46 |
| fullermd | Better, XSL could fall into a hole somewhere for a while 'till people get around to finishing jade... I mean, not that I'm bitter or annoyed or anything... | 10:48 |
| Glenjamin | jade? | 10:48 |
| fullermd | DSSSL processor. | 10:48 |
| vila | fullermd: Digital Super Slow Subscriber Line ? | 10:52 |
| vila | fullermd: A ZX80 should do no ? | 10:52 |
| fullermd | Pbbt :p | 10:52 |
| vila | Poor BroadBand Type ? | 10:53 |
| awilkins | I believe he meant "pttthpt" | 10:53 |
| vila | awilkins: no no http not thpt | 10:54 |
| * fullermd hires Bill The Cat to do his IRC'ing for him. | 10:54 | |
| knittl | hm. i still don't fully understand a testament | 10:56 |
| knittl | it stores timestamp, parent revs, some text (it says indented, human-readable; but i have no idea what it is used for), and file paths in canonical form | 10:57 |
| knittl | so where do file contents come into play? | 10:57 |
| knittl | because obviously, having the same pathnames does not mean it's the exact same file contents | 10:59 |
| Glenjamin | http://blogs.gnome.org/jamesh/2007/10/04/signed-revisions-with-bazaar/ | 11:01 |
| Glenjamin | this says that "bzr testament --long" includes hashes of file contents | 11:02 |
| knittl | ok. difficult to find bzr docs on gnome sites | 11:03 |
| Glenjamin | i googled "bzr testament" | 11:03 |
| Glenjamin | its the top result. | 11:03 |
| knittl | still, it's a third party observation | 11:04 |
| knittl | http://wiki.bazaar.canonical.com/Testament | 11:04 |
| knittl | i expect the bazaar wiki to contain a little more information | 11:04 |
| vila | there are a lot of third parties involved in the bzr community, that's the point of a community me thinks... | 11:04 |
| vila | knittl: it's a wiki ! Your contributions will be gladly welcome | 11:05 |
| fullermd | Well, that's a near-standing page from a glossary jblack was working up way back in the mists of history. | 11:05 |
| fullermd | (near-standin that is) | 11:05 |
| knittl | vila: my contributions? i really don't grokk bazaar | 11:05 |
| knittl | and i don't want to confuse others | 11:05 |
| awilkins | Even asking questions is a contribution ; gives people an idea of what's important for people | 11:05 |
| fullermd | But, why ask about testaments in the first place? They're pretty specific use items. | 11:06 |
| knittl | because they come after files, ineventories and revisions | 11:06 |
| fullermd | Last time I heard or thought about them was when I was looking through the command list and said "hey, what's 'testament'?" ;p | 11:06 |
| fullermd | (I think that wiki page is incorrect too; a testament isn't a type of revision) | 11:07 |
| Glenjamin | only if you write a list "files, inventories, revisions, testaments" | 11:07 |
| knittl | fullermd: well, that does not help _me_ in any way | 11:07 |
| knittl | Glenjamin: i am | 11:07 |
| awilkins | Well, it's like a crypto signature | 11:07 |
| awilkins | Sort of | 11:07 |
| awilkins | Ish | 11:07 |
| fullermd | Yes, but why? A testament is basically just a representation of a revision. | 11:07 |
| Glenjamin | seems an odd list of evaluation criteria | 11:07 |
| knittl | awilkins: i know what they *basically* are, but that's nearly not enough information | 11:08 |
| awilkins | So you can say things like "this software was compiled from this revision" and know that you are talking about an exactly particular state, I suppose | 11:08 |
| knittl | it's like saying 'a revision is a specific version of the project' | 11:08 |
| jelmer | knittl: as I understand it a testament is a format-independent mechanism for verifying the contents of a revision | 11:08 |
| knittl | great, that's 1 thing a revision is made of | 11:08 |
| Glenjamin | does that mean you can lookup a revision using a testament's checksum | 11:09 |
| awilkins | git just has this property because of the way it works - you can just say "revisions <blah>" where blah is the SHA-1 value and be almost totally certain that you are talking about the same thing | 11:09 |
| knittl | awilkins: git uses annotated tags to sign revisions | 11:09 |
| jelmer | Glenjamin: in theory, sure. I'm not sure what the use of that would be though | 11:09 |
| awilkins | knittl, because of the way git processes data, the signature is only required to certify the SOURCE of a revision | 11:10 |
| knittl | on an unrelated topic: how does bzr map from revids to revisions? using an index/dictionary file? | 11:10 |
| knittl | awilkins: ehm. i know. i think i really know git well | 11:10 |
| awilkins | knittl, The SHA-1 hash identifies any revision + it's history + it's content with certitude. | 11:10 |
| knittl | hashes dependent on all contents and ancestor content | 11:11 |
| awilkins | Apologies if I'm teaching you to suck eggs | 11:11 |
| Glenjamin | what happens when you have 2^40+1 commits? | 11:11 |
| fullermd | Linus comes to your house and beats you up. | 11:11 |
| knittl | why 40? sha1 is 160 bits | 11:11 |
| jbowtie | I see some of my documentation patches have been merged, but the bug status is still "Confirmed" (example: lp:401605) | 11:12 |
| Glenjamin | hrm, dunno why i had 40 in my head | 11:12 |
| Glenjamin | oh, its 40 chars in hex | 11:12 |
| jbowtie | What needs to happen before those get bumped to "Fix Committed" status? | 11:12 |
| awilkins | One hex char is a nibble | 11:12 |
| knittl | 40 could be relevant to collision attacks, but 40 sounds like an awfull small number | 11:12 |
| fullermd | Well, all you REALLY need for a collision is two. Finding them is the trick... | 11:13 |
| Glenjamin | 2^51 is the collision attack number for sha1 according to wikipedia | 11:13 |
| knittl | my wikipedia tells me 2⁶³ | 11:14 |
| fullermd | Of course, most VCS exploits you'd want to do call for preimage attacks rather than just collisions... | 11:14 |
| awilkins | And you'd have to find collisions that were both valid git trees also | 11:14 |
| knittl | yes. but why are we having a conversation about collision attacks on sha1? | 11:14 |
| fullermd | It's more fun than discussing snails. | 11:14 |
| vila | jbowtie: where did they land ? | 11:15 |
| knittl | i'm looking forward to sha3 | 11:15 |
| knittl | grøstl ftw | 11:15 |
| knittl | :] | 11:15 |
| vila | jbowtie: I'm releasing today and I'm reviewing all of them, but if they landed recently you can mark them 'Fix Released' with a 2.3b1 milestone | 11:16 |
| jbowtie | vila: 401605 was merged into lp:bzr, revision 5202 back in May. | 11:17 |
| vila | jbowtie: we don't use 'Fix Committed' anymore | 11:17 |
| jbowtie | vila: Well that would explain it. | 11:17 |
| vila | jbowtie: Are they mentioned in NEWS ? If yes, the milestone where they appear applies | 11:18 |
| spiv | jbowtie: http://doc.bazaar.canonical.com/latest/developers/bug-handling.html | 11:18 |
| Glenjamin | oh, while people are around | 11:18 |
| Glenjamin | can anyone suggest a single letter shortcut for revert --no-backup | 11:19 |
| bialix | bzr alias "myrevert"="revert --no-backup" | 11:20 |
| bialix | bzr myrevert | 11:20 |
| bialix | sorry, it's 2 leters | 11:20 |
| Glenjamin | good point | 11:20 |
| bialix | make up your own! | 11:20 |
| spiv | bialix: I'd use 'bzr alias rnb="revert --no-backup"' ;) | 11:20 |
| bialix | cool! I like what spiv said | 11:20 |
| fullermd | Rig up a foot petal! | 11:20 |
| Glenjamin | yeah, i have aliases for most things - dunno why that didn't occur to me | 11:20 |
| vila | Glenjamin: nope, that's the only case where bzr can lose your data, you have to type it, I will even prefer --no-backup-I-know-it-will-kill-my-cat :D | 11:20 |
| bialix | hehe | 11:21 |
| Glenjamin | i do a lot of "merge --uncommitted" followed by revert on the merge source | 11:21 |
| jbowtie | OK, so I've basically been ignoring bugs once a merge proposal is accepted. But they're still sitting there as open - so what do I do about it? | 11:21 |
| jbowtie | Because otherwise my bug queue is not going to get shorter. | 11:21 |
| spiv | jbowtie: mark it as Fix Released, targetted to the milestone of the next release (the one that will include your fix) | 11:22 |
| spiv | jbowtie: although I think if the merge proposal includes a NEWS entry with a bug number then around the time release is made the RM will probably notice if the bug status is out of date. | 11:23 |
| jbowtie | spiv: So I should be touching NEWS when I fix bugs; did not realise that. | 11:23 |
| spiv | jbowtie: we often ask for NEWS entries when reviewing patches, but we also often just add them for you if that's all that's missing. | 11:25 |
| spiv | (And sometimes we don't have them at all, for sufficiently minor changes or due to forgetfulness) | 11:25 |
| jbowtie | spiv: Hmm, I can't seem to set milestone field. #401605 needs to be updated to target the milestone. | 11:28 |
| jbowtie | vila: Sorry - that should be for you - Launchpad is not letting me set the milestone field. | 11:29 |
| vila | jbowtie: that's weird... not in the right team, but which team ? | 11:31 |
| vila | ha, bzr-qa | 11:32 |
| jbowtie | vila: You will forgive me if I have no clue... | 11:32 |
| spiv | jbowtie: which milestone? | 11:32 |
| spiv | (we can add you to the relevant team as soon as we figure out which one that is, but in the meantime I can set this one for you) | 11:33 |
| jbowtie | spiv: Based on the revision number I would assume whatever's being released next | 11:33 |
| vila | jbowtie: adde you to bzr-qa, try with another bug | 11:34 |
| vila | added | 11:34 |
| spiv | jbowtie: ok, set to 2.3b1 | 11:34 |
| jbowtie | vila: That seems to have worked, will review my merged bugs and try to figure out which ones made 2.2 and/or 2.3b1 | 11:35 |
| vila | jbowtie: don't forget to assign the bug to yourself so we can blame you in the future :) | 11:35 |
| vila | jbowtie: thanks for that ! Let me know when you're done or if you need help | 11:36 |
| jbowtie | vila: No worries; will tell you bug numbers when I finish so you can check my work. | 11:37 |
| vila | jbowtie: I'll get mail for that, don't worry | 11:39 |
| jbowtie | vila: Done, wasn't as many as I thought. Only odd one was #146780 since it was fixed on wiki rather than in codebase. | 11:43 |
| vila | jbowtie: great. So yeas, wiki is instant-fix-released ;) | 11:44 |
| knittl | how can i get a list of stored testaments for a repository/branch? | 11:44 |
| jbowtie | Great, only 53 documentation bugs left to fix! | 11:46 |
| knittl | i thought revnos do not change inside a branch? | 11:49 |
| Glenjamin | they don't | 11:50 |
| Glenjamin | but they can be different for the same revision in a different branch | 11:50 |
| knittl | then why are my commits now 5410.1.x instead of 5411-5413? | 11:50 |
| knittl | i did bzr pull | 11:50 |
| bialix | revnos can be changed with pull/push --overwrite | 11:50 |
| knittl | i did not use overwrite | 11:50 |
| bialix | you pulled from the branch where is your local branch was merged | 11:51 |
| knittl | WHAT? | 11:51 |
| bialix | so pull makes your local branch the identical to the remote one | 11:51 |
| Glenjamin | pull doesn't just update your branch, it makes your branch a mirror of the remote one | 11:51 |
| bialix | knittl: perhaps you want to look at append_revisions_only settings for branch; it prevented to mainline revno changes | 11:52 |
| knittl | so you tell me revnos do not change in a branch? and then you tell me they do? | 11:53 |
| Glenjamin | no, your branch changed | 11:53 |
| bialix | yes | 11:53 |
| knittl | what now‽! | 11:54 |
| bialix | it depends on what you need | 11:54 |
| Glenjamin | bzr help pull | 11:55 |
| Glenjamin | Purpose: Turn this branch into a mirror of another branch. | 11:55 |
| knittl | i have my branch. i do a pull (which should not succeed, because i have different revisions) | 11:55 |
| Glenjamin | you have different revision numbers, or different revisions? | 11:55 |
| knittl | i made 3 revisions in my branch | 11:55 |
| knittl | they got merged | 11:55 |
| bialix | either you have alias for pull or your local branch was fully merged into another branch | 11:55 |
| Glenjamin | so it has all the revisions | 11:56 |
| bialix | ok, the latter | 11:56 |
| knittl | it was. but then, why do my revnos change? | 11:56 |
| bialix | because you branch was merged | 11:56 |
| Glenjamin | therefore no data is lost, and your branch is no longer your branch, its a fresh version of the pull location | 11:56 |
| bialix | your branch | 11:56 |
| knittl | i understand that nothing was lost | 11:56 |
| * bialix shut up for a while | 11:56 | |
| Glenjamin | if you want revnos to stay the same in your local branch, use merge - not pull | 11:57 |
| knittl | Glenjamin: it cannot just change my branch to something different? – even if all revisions are there | 11:57 |
| bialix | why not? | 11:57 |
| Glenjamin | it can, it does, it even says it will | 11:57 |
| Glenjamin | because that is what pull does | 11:57 |
| knittl | what happens if i merged? conflicts because revs are in both branches? | 11:58 |
| bialix | no | 11:58 |
| knittl | all revisions from upstream collapsed into a single merge commit? | 11:58 |
| Glenjamin | the latter | 11:58 |
| Glenjamin | but its expandable in the log | 11:58 |
| Glenjamin | and even looks pretty in bzr qlog | 11:59 |
| knittl | unknown command qlog | 11:59 |
| knittl | still, this behavior is – in my eyes – stupid | 11:59 |
| knittl | s/stupid/unintuitive/ | 11:59 |
| Glenjamin | install bzr-qt for qlog | 11:59 |
| bialix | it's not bzr-qt | 12:00 |
| knittl | no, i don't need another qt app | 12:00 |
| bialix | it is QBzr | 12:00 |
| Glenjamin | ah yes, it seemed wrong as i was typing it but couldn't remember what it was called | 12:00 |
| Glenjamin | its only unintuitive because you used git first, and its pull command means something different | 12:00 |
| Glenjamin | in git, pull just means fetch then merge | 12:00 |
| bialix | in bzr pull means fast-forward merge | 12:01 |
| knittl | it's unintuitive in every imaginable way | 12:01 |
| knittl | fast-forward does not change revnos | 12:02 |
| Glenjamin | your confusing unintuitive with "different from this other tool" | 12:02 |
| bialix | git does not have revnos | 12:02 |
| Glenjamin | you wanna talk about unintuitive, try git checkout == svn revert | 12:02 |
| knittl | they both do what you'd expect neven if ythey are named differently) | 12:04 |
| knittl | and i'm not even complaining that bzr is different from git | 12:04 |
| Glenjamin | anyway, revnos are not as important as you'd think | 12:04 |
| knittl | but i expect my revnos to stay the same | 12:04 |
| Glenjamin | then don't use pull | 12:04 |
| knittl | so i can see: bzr log -rXXX # my revision | 12:04 |
| jbowtie | knittl: The revids are stable in bzr - however the revnos are just a friendly representation. | 12:05 |
| knittl | even after i do git pull | 12:05 |
| Glenjamin | basically, "bzr pull" takes the remote branch, and puts it at your local location | 12:05 |
| knittl | so it's bzr clone? | 12:06 |
| Glenjamin | and in this case the remote branch's history differed from yours | 12:06 |
| knittl | bzr clone --resume | 12:06 |
| Glenjamin | yeah, i guess so | 12:06 |
| knittl | bzr clone --update-and-overwrite-local-branch | 12:06 |
| Glenjamin | well, only if the actual revisions are not going to be lost | 12:06 |
| fullermd | bzr update-my-out-of-date-mirror-of-that-branch | 12:07 |
| Glenjamin | what's do these two branches you have represent? | 12:07 |
| knittl | grml. i have to accept it. still find it unintuitive | 12:07 |
| Glenjamin | ie. which is the mainine, which is a feature branch | 12:08 |
| knittl | what's do WHAT? | 12:08 |
| Glenjamin | you merged your local branch into your remote branch, so that implies that the remote one is the mainline | 12:08 |
| knittl | i didn't merge anything. upstream merged | 12:08 |
| Glenjamin | well somehow the revisions you made in local got into remote | 12:09 |
| knittl | yes, upstream merged them | 12:09 |
| Glenjamin | right, so then upstream has the mainline list of revision numbers | 12:10 |
| Glenjamin | which as far as the world-at-large is concerned, is the right revnos | 12:10 |
| bialix | knittl: set append_revisions_only = True in your branch.conf | 12:10 |
| bialix | mgz: ping | 12:10 |
| mgz | boing. | 12:10 |
| Glenjamin | bialix: that would have just stopped him from pulling, no? | 12:11 |
| bialix | just discovered: python -c "print None <= 0" prints True; is it good? | 12:11 |
| bialix | Glenjamin: yes, stopped from pulling and compalining maybe | 12:11 |
| fullermd | bialix: I imagine you expect that from any duck typing language... | 12:11 |
| bialix | qwa | 12:11 |
| mgz | that's going away in Python 3. | 12:12 |
| Glenjamin | >>> None == 0 #> False | 12:12 |
| knittl | ok, no sense talking against you, for me it stays unintuitive. period. | 12:12 |
| Glenjamin | >>> None >= 0 #> False | 12:12 |
| bialix | heh | 12:12 |
| Glenjamin | >>> None <= 0 #> True | 12:12 |
| Glenjamin | thats odd. | 12:12 |
| mgz | Python 3: TypeError: unorderable types: NoneType() <= int() | 12:13 |
| mgz | it's the way it is in Python 2 so you can have a list of arbitrary objects and sort it without fuss | 12:13 |
| bialix | hmm | 12:13 |
| bialix | ok, I see | 12:14 |
| knittl | how can i display the saved testament of a revision? | 12:14 |
| spiv | knittl: there's been some discussion of making append_revisions_only = True the default | 12:15 |
| fullermd | Testaments aren't saved. They're generated. | 12:15 |
| knittl | so where is the signature stored? | 12:15 |
| fullermd | A testament isn't a thing, it's just a way of displaying a revision, not immorally unequivalent to 'log'. | 12:15 |
| knittl | which can be signed | 12:15 |
| fullermd | Well, any text can be signed. Testaments are just what bzr created as "use this text to sign". | 12:16 |
| fullermd | Signatures were a separate file in knits, AIR. I imagine they're just another data record in packs. | 12:16 |
| knittl | ok | 12:16 |
| spiv | I'm not sure if there's an easy way to see the signature via the command line; I can give you the Python incantation if you like. | 12:17 |
| knittl | i'm afk now. need to smash something :D | 12:17 |
| knittl | spiv: no way via commandline? oh my… | 12:17 |
| Glenjamin | if it makes you feel any better, i found git really unintuitive cos i was used to bzr/svn semantics for the commands | 12:17 |
| spiv | There just hasn't been much demand to work on UI around signatures, basically. Relatively few people care about them. | 12:19 |
| knittl | nobody cares about integrity? | 12:20 |
| bialix | what is integrity? | 12:20 |
| fullermd | A line of servers from HP, I think. | 12:20 |
| spiv | Apparently not, from the questions I've seen users ask. | 12:22 |
| spiv | At least, not in that form. | 12:22 |
| knittl | nobody cares about verifying history of a revision? | 12:22 |
| Glenjamin | not really, i just care that the code in that revision works | 12:22 |
| spiv | Well, obviously the bzr team cares, because we implemented the feature to have signatures :) | 12:22 |
| Glenjamin | how it got there is bonus information for me | 12:22 |
| knittl | spiv: but it cannot be verified from the command line? | 12:23 |
| Glenjamin | on the matter of integrity, i do have some missing revisions with cause some history operations to fail on a bzr repo that used to be an svn repo (and spent a year or so being an svn repo accessed by bzr clients) | 12:23 |
| spiv | I vaguely recall a plugin that did that. | 12:23 |
| fullermd | Shoot. Almost nobody even cares enough to run ECC memory; cryptographic signatures are so many steps beyond that... | 12:23 |
| fullermd | Yeah, jam wrote a plugin AIR. | 12:23 |
| Glenjamin | bottom of this page http://blogs.gnome.org/jamesh/2007/10/04/signed-revisions-with-bazaar/ | 12:24 |
| vila | fullermd: not mentioning running systems without RAID... | 12:24 |
| knittl | what if i wanted to display a signature for a revsion(testament) | 12:24 |
| fullermd | vila: Well, then you get into systems with (or without) RAID, but without a FS with hierarchial checksums too... but I stray. | 12:24 |
| vila | fullermd: hierachical file systems !!! Who needs that ??? | 12:25 |
| fullermd | vila: Well, nobody cares about hierarchial namespaces anyway. I mean, look at DNS. | 12:26 |
| vila | fullermd: pff IP addresses, real men use MACs ;) | 12:26 |
| knittl | you're confusing two transport layers here | 12:27 |
| bialix | knittl: `bzr testament` -- is not it what you're looking for? | 12:27 |
| fullermd | Macs? I thought you were using Ubuntu ;p | 12:27 |
| knittl | bialix: that does not display the signature, only the text form of a testament | 12:27 |
| fullermd | bialix: Testament doesn't display any signatures. It just gens a testament for the rev. | 12:27 |
| Glenjamin | knittl: there's some code halfway down that page i linked that shows how to display a signature | 12:27 |
| Glenjamin | which could be trivially wrapped in a command | 12:27 |
| bialix | are you talking about gpg-signatures? | 12:28 |
| bialix | because I don't know what else exists in bzf | 12:28 |
| knittl | Glenjamin: i find it a pity there's no command for that | 12:28 |
| vila | fullermd: you're mixing hardware and software now ;-P | 12:28 |
| knittl | i think i'll write a patch for that … | 12:28 |
| knittl | so i can again complain about rev 5432 being 5431.1.1 after pull | 12:28 |
| fullermd | vila: Heck, just wait'll I get warmed up! | 12:29 |
| bialix | knittl: `bzr pull -r5431.1.x . --overwrite` will restore your previous history | 12:29 |
| knittl | bialix: but will kill upstream revs? | 12:30 |
| bialix | what it means "kill"? | 12:30 |
| knittl | they are gone, aren't they? | 12:30 |
| bialix | you want your precious revisions back -- you'll get them | 12:30 |
| Glenjamin | if you do that, then merge from upstream | 12:31 |
| bialix | then merge from upstream, yes | 12:31 |
| knittl | Glenjamin: so, after pull --overwrite upstream revisions are gone and i have to merge (download) them again | 12:31 |
| bialix | knittl: no | 12:31 |
| knittl | that topic was closed btw | 12:31 |
| Glenjamin | they're probably cached in the repo | 12:31 |
| bialix | you don't need to download them | 12:31 |
| bialix | they're in the repo | 12:31 |
| spiv | knittl: the repository won't forget the revisions | 12:31 |
| bialix | run `bzr heads --dead` after pull | 12:31 |
| spiv | knittl: the bzr pull with simply change which revision the branch considers to be its tip | 12:32 |
| knittl | whatever. got work to do now | 12:33 |
| spiv | If you do another operation later that needs those revisions, they won't be refetched. | 12:33 |
| mgz | looking at the diff of one of spiv's changes, I see I mispelt my own name in the NEWS file | 12:49 |
| * maxb puzzles at getting "Repository with UUID 283d02a7-25f6-0310-bc7c-ecb5cbfe19da at svn://anonsvn.kde.org/home/kde contains fewer revisions than cache." from bzr-svn | 13:18 | |
| maxb | (non-reproducible) | 13:18 |
| === oubiwann is now known as oubiwann-away | ||
| === oubiwann-away is now known as oubiwann | ||
| === Ursinha-afk is now known as Ursinha | ||
| maxb | lifeless: Is there a debian packaging branch for testtools in sid? | 14:26 |
| knittl | raise errors.NoSuchRevision(self, revision_id) | 14:45 |
| knittl | bzrlib.errors.NoSuchRevision: CHKInventoryRepository('file:///home/knittl/bzr/bzr/.bzr/repository/') has no revision pqm@pqm.ubuntu.com-20100917091211-1e9h9nf6bsdjr6bd | 14:45 |
| knittl | $ bzr log -rrevid:pqm@pqm.ubuntu.com-20100917091211-1e9h9nf6bsdjr6bd | 14:45 |
| knittl | ------------------------------------------------------------ | 14:45 |
| knittl | revno: 5431 [merge] | 14:45 |
| knittl | so, what's wrong? | 14:46 |
| Glenjamin | knittl: are you trying to output the signature? | 15:01 |
| Glenjamin | i wrote a quick command to do that, and got the same nosuchrevision error | 15:02 |
| Glenjamin | if there's no signature, thats the exception that gets thrown | 15:04 |
| knittl | Glenjamin: yes | 15:05 |
| Glenjamin | knittl: https://code.launchpad.net/~glenjamin/+junk/bzr-signature is as far as i got | 15:10 |
| Glenjamin | but i have no repos with signed revisions | 15:11 |
| dobey | if i sprout() a branch from an existing bzr branch, and commit to the new branch, why would basis_branch().get_revision_id() on the new branch, return the last revision committed to the new branch, rather than the last revision of the basis branch? | 15:15 |
| GaryvdM | dobey: Maybe you need to unlock, and relock | 15:19 |
| GaryvdM | dobey: Oh sorry - I miss read the question. Please ignore my answer. | 15:20 |
| dobey | hmm | 15:40 |
| === zyga is now known as zyga-food | ||
| GaryvdM | Hi vila. How is it going? | 16:48 |
| vila | GaryvdM: at pqm pace... | 16:49 |
| GaryvdM | vila: Ah | 16:49 |
| vila | GaryvdM: 2.0 requests are twice as slow and I didn't order them as I should have | 16:50 |
| Glenjamin | is anyone familiar with the inner workings of QBzr? I was trying to see how to add --diff-options into qdiff the other day and couldn't for the life of me see how it worked | 16:51 |
| GaryvdM | Glenjamin: I can help you in a sec. | 16:51 |
| === zyga-food is now known as zyga | ||
| Glenjamin | my actual goal is just to be able to say "ignore whitespace" | 16:51 |
| GaryvdM | Glenjamin: so it would be cool if you could specify that from both the command line, and the ui. We are planing to make the qdiff ui simillar to new qannotate ui. | 16:53 |
| GaryvdM | then we can have all the view options in a menu. | 16:54 |
| Glenjamin | i see | 16:54 |
| GaryvdM | Glenjamin: but to start from the command line would be easier. | 16:54 |
| Glenjamin | is there a way to change the qannotate colours? | 16:54 |
| GaryvdM | Glenjamin: The colours are chosen from a hash of the committers name. | 16:55 |
| Glenjamin | heh, my boss gets hot pink | 16:55 |
| GaryvdM | Glenjamin: you would need to change the code to do this. | 16:55 |
| Glenjamin | clever approach to colour selection though | 16:55 |
| GaryvdM | Glenjamin: As the commit gets older, it changes towards white. | 16:55 |
| Glenjamin | is that pretty new? I'm sure i've used qannotate before and its been pastel colours like qdiff | 16:56 |
| GaryvdM | Glenjamin: Those must have been older commits. | 16:57 |
| GaryvdM | Glenjamin: so to add a commandline option to qdiff, you need to start in lib/commands.py | 17:00 |
| Glenjamin | that bit I can do, but i couldn't see how diffwindow gets its content | 17:00 |
| Glenjamin | or can i just assume it does, and pass the flag through to _get_ext_diff_args | 17:01 |
| GaryvdM | get_ext_diff_args is used when launching a external diff program. You need to change get_diff_window_args. | 17:02 |
| Glenjamin | does the external diff button only appear if its configured then? | 17:03 |
| GaryvdM | Yes | 17:03 |
| GaryvdM | Glenjamin: but you will need to change every get_diff_window_args, as you will need to change what is expected from that method. | 17:03 |
| GaryvdM | Glenjamin: there are 2 in commands.py, and 3 in diff_args.py | 17:04 |
| knittl | wouldn't it make more sense to default to the current revision instead of the last one? | 17:04 |
| Glenjamin | would it make sense to have it return a dict instead of a tuple? | 17:05 |
| Glenjamin | knittl: the current revision is the last one, i assumed | 17:05 |
| knittl | e.g. in cmd_testament -> if revision is None: revision = b.last_revision() | 17:05 |
| knittl | Glenjamin: not if you do bzr update -r old_revision | 17:05 |
| knittl | but i'm not really knowledgeable of bzr internals, so i could be mistaken | 17:05 |
| Glenjamin | i didn't dig into the branch/revision API, i just used an example that worked | 17:05 |
| Glenjamin | if you want to extend it so -r actually works, please do :) | 17:06 |
| GaryvdM | Glenjamin: Yes, a dict makes more sense. | 17:06 |
| knittl | unhashable type list. i think i'm getting closer | 17:06 |
| knittl | hm. that's not my code that's crashing :-/ | 17:07 |
| knittl | woohoo | 17:07 |
| Glenjamin | GaryvdM: so once i've sorted out the arguments, where abouts can i plug in and tell the diff bit to ignore whitespace? | 17:10 |
| === beuno is now known as beuno-lunch | ||
| === deryck is now known as deryck[lunch] | ||
| GaryvdM | Glenjamin: I'm not sure what is the best way to implement this. One way is to modify the text that you pass to the diff, so that all white space is removed. You will need to keep track of what white space you removed, so that you can translate the ranges of the hunks returned for positions with out whitespace to positions with whitespace. | 17:13 |
| Glenjamin | i wonder if it almost makes sense to allow the internal diff algorithm to ignore whitespace | 17:13 |
| Glenjamin | i was kind of hoping qdiff was a thinner wrapper around diff than it actually is | 17:14 |
| GaryvdM | Glenjamin: It does this at line 377 of diffwindow.py | 17:14 |
| GaryvdM | Glenjamin: yhea - sorry about that. The only thing we use is a SequenceMatcher. | 17:15 |
| Glenjamin | oh i see, this is the actual differencing | 17:16 |
| GaryvdM | Yes | 17:17 |
| Glenjamin | ok, i follow your suggestion now | 17:21 |
| Glenjamin | sounds fiddly, but doable | 17:21 |
| Glenjamin | i might give it a shot this weekend | 17:21 |
| GaryvdM | Goodluck | 17:21 |
| nprasath002 | hi i,m just starting to use bazaar. how can a get gui interface for bazaar. what plugin will do that? | 17:40 |
| dash | nprasath002: 'bzr explore' should do it in most recent versions | 17:40 |
| dash | how did you install it? | 17:41 |
| nprasath002 | i use via synaptic package manager | 17:41 |
| dash | ok, then that should work. | 17:41 |
| nprasath002 | thanks | 17:41 |
| knittl | where should i put show-signature and how can i inform bzr of the new command? i thought @display_command would be enough | 18:02 |
| dobey | anybody can help with my previous question? | 18:03 |
| dobey | if i sprout() a branch from an existing bzr branch, and commit to the new branch, why would basis_branch().get_revision_id() on the new branch, return the last revision committed to the new branch, rather than the last revision of the basis branch? | 18:03 |
| GaryvdM | dobey: on what object are you calling basis_branch()? I grep bzr.dev for that method, and could not find it. | 18:04 |
| knittl | why aren't there utility functions like 'openBranch' or 'getRevisionId'? | 18:05 |
| knittl | seems like if rev is None: rev_id = b.last_revision() else: rev_id = revision[0].as_revision_id(b) is used quite a lot | 18:05 |
| knittl | as is if branch == '.': b = Branch.open_containing(…)… | 18:05 |
| GaryvdM | knittl: are you writing a plugin? if so, put this in the plugins __init__.py: | 18:07 |
| ddaa | knittl: they are static methods, like Branch.open | 18:07 |
| GaryvdM | from bzrlib.commands import plugin_cmds | 18:07 |
| GaryvdM | plugin_cmds.register_lazy(name, aliases, module) | 18:08 |
| knittl | GaryvdM: i don't know if it's a plugin | 18:08 |
| knittl | show-signature | 18:08 |
| knittl | ddaa: so? what prevents utility methods? even better suited for calling static methods? | 18:08 |
| GaryvdM | knittl: Are you going to have this command live in bzrlib, or a plugin? | 18:09 |
| ddaa | Because: python -c 'import this' | grep Namespaces | 18:09 |
| knittl | GaryvdM: right now it is in bzrlib | 18:09 |
| ddaa | also, it makes it obvious what these functions return | 18:09 |
| ddaa | Branch.open returns a Branch... | 18:09 |
| GaryvdM | knittl: Look at bzrlib/builtins.py | 18:09 |
| knittl | ddaa: i don't understand? if rev is None: "default" else: "get id" is used a lot | 18:10 |
| knittl | GaryvdM: i've put it there already | 18:10 |
| dobey | GaryvdM: a bzr Branch | 18:10 |
| ddaa | knittl: because: python -c 'import this' | grep ambiguity | 18:11 |
| dobey | GaryvdM: sorry, typo. basis_tree(), not basis_branch() | 18:11 |
| knittl | In the face of ambiguity, refuse the temptation to guess. | 18:11 |
| knittl | what does that tell me? :-/ | 18:12 |
| ddaa | maybe I don't understand your problem | 18:12 |
| knittl | i think so | 18:12 |
| knittl | my question is: the code »if branch == '.': b = branch.open_containing(branch)[0] else: b = Branch.open(branch)« is used over and over | 18:13 |
| === beuno-lunch is now known as beuno | ||
| knittl | why isn't there a single function which returns the correct »b«? | 18:13 |
| knittl | same goes for »if revision is None: rev_id = b.last_revision() else: rev_id = revision[0].as_revision_id(b)« | 18:13 |
| GaryvdM | dobey: The basis_tree for a working tree is the tree which the wt is based on. It will be the parent of the revision for the next tree. | 18:14 |
| knittl | GaryvdM: my command class is in builtin.py | 18:15 |
| knittl | how do i register it for autocompletion? | 18:15 |
| GaryvdM | dobey: It has no relation to the parents branch tip, or common ancestor. | 18:15 |
| knittl | i cannot find register_something for the other classes in that file | 18:15 |
| dobey | GaryvdM: how do i get the last revision from the parent tree that a branch is based on, then? | 18:15 |
| dobey | i need the revision id or revno of the last revision from the parent tree | 18:16 |
| knittl | and should i use sys.stdout.write or self.outf.write? | 18:16 |
| knittl | different (existing) commands use one or the other form | 18:16 |
| GaryvdM | dobey: I'm not sure exactly offhand, but you are looking for how to get the common ancestor | 18:17 |
| knittl | cmd_testament uses sys.… and cmd_plugins uses self.… | 18:17 |
| GaryvdM | dobey: From the command line, you could do bzr diff -r ancestor:../trunk/ | 18:17 |
| dobey | GaryvdM: but how do i do that with bzrlib? i don't want a diff, i just want a reference, so i can iter over the revisions since that revision | 18:19 |
| dobey | GaryvdM: ie, i need to get all authors for all revisions, after the branch from the ancestor | 18:20 |
| GaryvdM | dobey: ok - take a look at the code for bzr missing --mine-only. that will do what you need | 18:21 |
| knittl | should i use self.outf.write or sys.stdout.write? | 18:22 |
| knittl | and how do i register the command for autocompletion? | 18:22 |
| dobey | GaryvdM: do you know where that code is? i'm having trouble finding it. if it's find_missing() in bzrlib.missing, then i can't really go that route :( | 18:25 |
| pickscrape | Is anyone aware of a workaround for bug 389674? | 18:30 |
| ubot5 | Launchpad bug 389674 in Bazaar "NotImplementedError(_PreviewTree.inventory) when unshelving must create the parent directory (affected: 3, heat: 3)" [Medium,Confirmed] https://launchpad.net/bugs/389674 | 18:30 |
| GaryvdM | dobey: why not? If you look in find_missing, you will see that it opens the revision dags of both branches, and finds the revision unique to each branch, but you only need to get the revisions unique to one of the branches. | 18:35 |
| dobey | GaryvdM: because how do i point at the remote branch if i've only got the local one to look at? | 18:36 |
| GaryvdM | dobey: if you don't have access to the remote branch, you will need to record what it's tip was when you branch it. Bzr does not currently store this. | 18:38 |
| dobey | fail :( | 18:39 |
| === frakturfreak_ is now known as frakturfreak | ||
| GaryvdM | dobey: What are you trying to do? | 18:39 |
| dobey | GaryvdM: get all the authors of all revisions in a branch, since it was branched from its ancestor | 18:40 |
| ovnicraft | hi folks i want to configure bzr with my user for pull/push but my laptop user is different from my lp user? | 18:40 |
| GaryvdM | dobey: And it has to work with no connection to the ancestor? | 18:41 |
| ovnicraft | how i can do this? | 18:42 |
| GaryvdM | ovnicraft: You can create a ~/.bazaar/authentication.conf | 18:43 |
| dobey | GaryvdM: preferably, yes. i might be able to hack it to pass in the other branch, but that makes things amazingly complex, since it might have changes since the child branch was made | 18:43 |
| GaryvdM | knittl: It seem that commands.py scans the builtins module for classes whos names start with "cmd_". Is your command named accordingly? | 18:45 |
| ovnicraft | GaryvdM, can i add th user here: parent_location= bzr+ssh://myuser@bazaar.launchpad.net/%7Eopenerp/openobject-server/trunk/ ? | 18:46 |
| ovnicraft | and get it done | 18:46 |
| GaryvdM | ovnicraft: Yes | 18:46 |
| GaryvdM | Night all. | 18:47 |
| knittl | hm, gary is offline | 18:50 |
| knittl | yes, my command is named cmd_show_signature | 18:50 |
| knittl | https://code.launchpad.net/~knittl/bzr/show-signature who wants to test? | 19:07 |
| dobey | abently, jam: ^^ is that true? do i need both branches to be able to determine the revno/revid of the ancestor from which a branch was created? | 19:12 |
| jam | dobey: I'm not sure what you are ^^ at, but if you want to run "ancestor:" you need a branch | 19:13 |
| === Ursinha is now known as Ursinha-lunch | ||
| jam | note that you can pretty trivially create a branch with "bzr branch --no-tree -r x.y.z . ../ancestor-branch", etc. | 19:14 |
| jam | with --no-tree and a shared repo, it is rather lightweight. | 19:14 |
| jam | Certaintly the bzrlib internals support more | 19:14 |
| jam | just hasn't been needed from the commandline | 19:15 |
| dobey | jam: previous converation with garyvdm. can i do it with just the child, or do i need both branches? i'm doing it from bzrlib, inside tarmac | 19:15 |
| jam | dobey: how do you know what the "ancestor" is? | 19:16 |
| jam | without having its branch | 19:16 |
| jam | if you mean "I need the tip pointer of the branch I branched from", no bzr does not store that | 19:16 |
| jam | also, it is not accurate once you have merged from the ancestor branch | 19:16 |
| dobey | that's what i'm trying to figure out | 19:17 |
| jam | if I do "bzr branch foo bar; bzr commit -m "foo" foo ; "bzr commit -m "bar" bar; cd bar; bzr merge ../foo; bzr commit -m "both" | 19:17 |
| jam | then what is the actual answer? | 19:17 |
| jam | what happens if foo merges bar 1 time, etc, etc | 19:17 |
| jam | you really want something like "Graph.find_unique_ancestors()" but you need to have the current tip of the branch you are comparing against | 19:18 |
| jam | IMO | 19:18 |
| jam | dobey: I said that pretty fast, but I can spell it out if you would prefer | 19:18 |
| dobey | well, if i could get the info from the merge proposal in launchpad, i'd be just as happy. | 19:18 |
| dobey | since launchpad seems to understand all this just fine, in terms of the merge proposal, though it doesn't seem to exactly expose all the information in the API | 19:19 |
| jam | dobey: well, there are probably 2 things to consider | 19:20 |
| jam | 1 the branch you are merging into | 19:20 |
| jam | 2 any prerequisite branches | 19:20 |
| jam | I don't know what lpapi exposes | 19:20 |
| dobey | well let's ignore the prerequisite branches issue for now, as i don't think tarmac handles them currently, anyway | 19:21 |
| jam | dobey: https://code.edge.launchpad.net/~abentley/bzr/annotate-revspec/+merge/34681 | 19:21 |
| jam | It has a "Merge into: <BRANCH_URL>" | 19:21 |
| jam | and a "Prerequisite: <BRANCH_URL>" | 19:21 |
| pickscrape | Anyone know if it's possible to so something like convert a shelf-* file into a diff so I can apply it by hand? | 19:21 |
| jam | if you grab that branch_url, you can open the branch and use "Branch.last_revision()" to get its tip | 19:21 |
| knittl | jam: how can i make a command default to the current checked out revision? | 19:22 |
| knittl | using last as default is unintuitive | 19:22 |
| dobey | jam: right, but that assumes that it hasn't changed since the branch proposed for merger | 19:22 |
| jam | knittl: WT.last_revision() | 19:22 |
| jam | vs Branch.last_revision(0 | 19:23 |
| jam | dobey: "Hasn't changed" ? | 19:23 |
| jam | what hasn't changed | 19:23 |
| jam | the branch? Isn't the point that you should handle if it *does* change? | 19:23 |
| jam | certainly the Merge Proposal page uses the current tips for those things. | 19:23 |
| dobey | jam: relying on that has to assume that there are no revisiions in the target branch, that aren't in the source branch | 19:23 |
| jam | dobey: MPs don't assume that | 19:23 |
| jam | why are you? | 19:23 |
| jam | If I have put up a branch for review with 10 changes, and I land 5 of them, what do you want the system to do? | 19:24 |
| jam | Still report all 10? | 19:24 |
| dobey | i'm not, but i can't get the last revision of the target and then use that as a reference in the source, if that revision isn't in the source | 19:24 |
| jam | dobey: graph = Repository.get_graph(other_repository) | 19:25 |
| jam | will use "other_repository" as a fall back for revisions it doesn't know about | 19:25 |
| dobey | what i would like is for proposal.preview_diff.prerequisite_revision_id to actually give me a value other than 'None' but it doesn't seem to do that | 19:25 |
| jam | dobey: abentley or maybe rockstar are more knowledgeable about the Launchpad side of things (even thumper if he's around) | 19:25 |
| rockstar | dobey, don't use Launchpad at all. Do it all in bzr. | 19:26 |
| dobey | rockstar: it doesn't seem possible. | 19:26 |
| rockstar | jam, dobey needs to get the LCA between two branches, and then get all the revisions from that LCA to tip in one of the branches. | 19:27 |
| lifeless | maxb: yes | 19:28 |
| abentley | dobey, is this for a merge proposal that has a prerequisite branch? | 19:28 |
| maxb | where? :-) | 19:28 |
| jam | rockstar: certainly. But he wants to get the information about what revisions, etc *from launchpad* | 19:28 |
| jam | (what branch, and what revision in the branch, etc) | 19:29 |
| dobey | abentley: no, not other than the target | 19:29 |
| jam | pickscrape: I'll poke at it for a second, but offhand I don't know of a way to do it | 19:29 |
| dobey | jam: well i'd like to get the information from bzr, but from what you're all are saying, it isn't stored in bzr | 19:29 |
| jam | the old shelves stored actually patches, but the new one does not | 19:29 |
| dobey | for what it's worth, i don't care about what tip is at all | 19:29 |
| dobey | what i want is the revision id at the point when the child branch was created from the parent. | 19:29 |
| dobey | that is the only piece of information i want/need | 19:30 |
| pickscrape | jam: thanks! | 19:30 |
| dash | yeah the new shelve is nice when it works, and it works more often now | 19:30 |
| dobey | or perhaps i am oversimplyfing things at the moment, because this seems like it is getting overly complex very easily | 19:30 |
| dash | but when it breaks it's really broken. :) | 19:30 |
| abentley | dobey, the prerequisite revision_id is the revision_id of the prerequisite branch that was used to generate the diff. If there was no prerequisite branch, it cannot have a revision_id. | 19:31 |
| jam | pickscrape: if you can use python apis, you can look into bzrlib.shelf.Unshelver.from_tree_and_shelf(), or even Unshelver.from_args() | 19:31 |
| dobey | abentley: by that definition, if there is no prerequisite branch, it cannot have a merge proposal | 19:32 |
| jam | sorry, that would be bzrlib.shelf_ui.Unshelver.from_args | 19:32 |
| abentley | dobey, False. All that is needed for a merge proposal is a source branch and a target branch. Prerequisite branches are optional. | 19:32 |
| dobey | abentley: then the documentation is wrong. | 19:33 |
| jam | dobey: I think you are using "prerequisite" when you don't want it | 19:33 |
| jam | you want the revision of the merge proposal | 19:33 |
| abentley | dobey, which documentation? | 19:33 |
| jam | abentley: is that exposed from the api? | 19:33 |
| jam | it may just be the Branch, which you then open for Branch.last_revision()? | 19:33 |
| dobey | abentley: the launchpad api docs | 19:33 |
| abentley | jam, I don't know what you mean by "revision of the merge proposal". | 19:33 |
| jam | abentley: the revision that is being proposed to be merged into another branch | 19:34 |
| dobey | hrmm | 19:34 |
| abentley | jam, we don't propose revisions, we propose branches. | 19:34 |
| jam | abentley: well there is a specific revision that is being shown | 19:34 |
| knittl | who wants to test: https://code.launchpad.net/~knittl/bzr/show-signature ? | 19:34 |
| abentley | jam, yes, the source branch last_revision. It will be updated (for active proposals) if you push the source branch. | 19:35 |
| jam | abentley: dobey basically wants to know what revisions are being proposed to be merged, and it sounds like he needs to open the source and target branches, and then use Graph.find_unique_ancestors(source.last_revision(), [target.last_revision()]) | 19:35 |
| jam | pickscrape: that will let you open up the shelf, and as long as you don't call .run() it won't try to apply it, and I think you can then query it for the data you want to pull out manually | 19:35 |
| abentley | jam, (well, if you just want to know which are proposed to be merged, you don't need an LCA) | 19:36 |
| pickscrape | jam: thanks, I'm having a play with that now. | 19:36 |
| jam | abentley: he wants all the authors that have contributed to the current code | 19:36 |
| jam | how would you determine that ? | 19:36 |
| abentley | jam, I'd do a set difference of the two tips. | 19:37 |
| jam | abentley: that is what find_unique_ancestors does, only without having to get the full ancestry | 19:37 |
| jam | and to do so, you ... have to walk back to the LCAs :) | 19:37 |
| abentley | jam, yes, I know. | 19:38 |
| === frakturfreak_ is now known as frakturfreak | ||
| jam | anyway, I don't think I've stated a strict need for an LCA, just to get the tips and use find_unique_ancestors() | 19:38 |
| jam | which I think is also what you are saying | 19:39 |
| jam | dobey: does that make sense? | 19:39 |
| dobey | maybe | 19:39 |
| dobey | my brain hurts :) | 19:39 |
| dobey | i guess i just need to have both branches, and do find_unmerged() | 19:40 |
| abentley | jam, when you said "what revisions are being merged", I thought you meant which tip revisions are being merged, not the ancestry of those tips. | 19:40 |
| jam | dobey: http://paste.ubuntu.com/495461/ | 19:41 |
| jam | some basic overview of what I would do | 19:42 |
| abentley | If you meant "which revisions will become part of the ancestry", not "which two revisions are participating in the merge", I get it now. | 19:42 |
| pickscrape | jam: any idea what type the "merger" parameter passed to either write_diff() or show_changes() need to be? | 19:43 |
| jam | abentley: correct | 19:44 |
| jam | pickscrape: I would look at the shelf_ui.Unshelver.run() method | 19:45 |
| abentley | dobey, the API documentation doesn't say that the prerequisite branch is non-optional. In fact, it says there are circumstances where it should be left blank. | 19:45 |
| jam | merger = self.manager.get_unshelver(self.shelf_id).make_merger(None) | 19:45 |
| jam | pickscrape: what about "bzr unshelve --preview" ? | 19:45 |
| jam | that should show the diff for you, right? | 19:46 |
| jam | does that also fail? | 19:46 |
| pickscrape | jam: --preview results in the same execption unfortunately | 19:46 |
| dobey | abentley: yes. but it implies that if left blank, the target is considered the prerequisite, and i would therefore expect the prerequisite_revision_id to be from the target | 19:46 |
| dobey | which doesn't seem to be the case | 19:46 |
| abentley | dobey, I didn't mean to imply that the target was the prerequisite in that case. | 19:46 |
| jam | dobey: and if you take my example slightly further, it can handle prerequisite branches by just passing more revision_ids to the find_unique_ancestors() method. | 19:47 |
| dobey | abentley: perhaps clarify that prerequisite_revision_id will NEVER point to a revid of the target, and is only there if there is a prerequisite other than the target | 19:48 |
| abentley | dobey, the prerequisite is a branch that should be merged into target before you merge the source branch. | 19:48 |
| jam | (I don't think find_unmerged supports that) | 19:48 |
| pickscrape | jam: write_diff and show_changes also result in the same exception being thrown. | 19:48 |
| abentley | dobey, for example if you have two branches, A and B, and you branched B from A. | 19:48 |
| jam | pickscrape: so the specific failure is that PreviewTree is not a 100% reproduction of a real tree. But I don't really know what it is trying to do that is failing | 19:49 |
| jam | (I haven't looked closely at the bug) | 19:49 |
| abentley | dobey, You want A's changes to be considered separately from B's changes, so you set A as a prerequisite branch when you propose B for merging. | 19:49 |
| pickscrape | jam: I posted a small reproduction recipe on the bug a while back which could be handy for you. | 19:49 |
| dobey | abentley: i know what the prerequisite branch feature means. i'm just stating that the api documentation i just looked at, is somewhat unclear and implied there was more of a connection between what target and prerequisite are, in the backend, than there apparently is in actuality | 19:50 |
| abentley | dobey, this is text that was written for the web interface, so it's written with Launchpad users as a target audience rather than API client devs. | 19:52 |
| dobey | abentley: even if not your intent, the wording tends to denote the possibility that the target can be a prerequisite, and while that field should be left blank in such a case, it does not state that all the other related fields will also be blank | 19:52 |
| pickscrape | jam: I just realised that I've been trying to unshelve while my lightweight checkout was pointing at a different branch to the shelf's original source. | 20:01 |
| pickscrape | So in this instance I was actually being silly. However, the last time this happened it was a bit more subtle than that. | 20:01 |
| jam | pickscrape: well, shelved content has a required revision_id that it is based upon. It sounds like we don't give a clear error when that revision is not available | 20:02 |
| jam | that would be a separate bug from the sound of it | 20:02 |
| knittl | anybody wants to test printing signatures? | 20:03 |
| knittl | https://code.edge.launchpad.net/~knittl/bzr/show-signature | 20:03 |
| pickscrape | jam: wouldn't attempting to unshelve to a branch with that revision_id not present be roughly similar to merge --uncommitted? | 20:05 |
| jam | knittl: I'll give it a look | 20:05 |
| jam | pickscrape: if we can't find the revision *at all* is different than if it just isn't in the ancestry | 20:05 |
| jam | (if your branches have separate repositories) | 20:05 |
| jam | otherwise yes, it should be 'merge --uncommitted' | 20:05 |
| knittl | jam: great, thanks | 20:05 |
| pickscrape | jam: ah, well in this case the revision in question will definitely have been in the shared repository. | 20:06 |
| jam | pickscrape: then that makes less sense, and my guess is just a bug in an edge case handling | 20:07 |
| pickscrape | jam: should I raise that as a separate bug then, and attempt to write something remotely sensible? :) | 20:07 |
| pickscrape | (as a description) | 20:07 |
| jam | pickscrape: if the revision is available, then it is probably the same bug | 20:09 |
| jam | but you're welcome to update the description and summary if you can make it clear what is going on | 20:09 |
| pickscrape | jam: OK, I'll leave it then | 20:09 |
| dobey | jam: ok, with your pastebin, i think i finally got something that works, using the graph. | 20:10 |
| === Ursinha-lunch is now known as Ursinha | ||
| dobey | jam: it seems to work! thanks! :) | 20:27 |
| jam | dobey: happy to hep | 20:28 |
| jam | help | 20:28 |
| jam | (not that I don't like hepping, though :) | 20:28 |
| dobey | heh | 20:28 |
| === frakturfreak_ is now known as frakturfreak | ||
| nekohayo | hey there, bzr is quite slow for branching from launchpad (time bzr branch lp:arista = 20 seconds). Is there any way to make it go faster, by using bzr:// or something? | 20:41 |
| nekohayo | when I want to "sell" launchpad to someone, I obviously get the git comparison (5 seconds to git clone http://github.com/danielgtaylor/arista.git) | 20:42 |
| nekohayo | I would really prefer my project to use bzr | 20:42 |
| knittl | nekohayo: do you know if there is a hg clone as well? | 20:42 |
| nekohayo | knittl, ? | 20:42 |
| nekohayo | a mercurial repo of arista? | 20:43 |
| knittl | nekohayo: nothing to do with your problem, i'm simply interested | 20:43 |
| knittl | yes | 20:43 |
| nekohayo | not that I know of | 20:43 |
| knittl | so bzr and git? | 20:43 |
| nekohayo | yeah, the bzr one is a mirror of the git repo | 20:44 |
| knittl | i see. thank you :) | 20:44 |
| nekohayo | so, anyhow, I've never seen bzr branch faster than 20 seconds from launchpad | 20:45 |
| knittl | don't ask me, i don't use bzr :> | 20:45 |
| glyph | nekohayo: 'bzr lp-login' | 20:45 |
| glyph | that might not make it go faster, but things will certainly be different! | 20:45 |
| nekohayo | I'm alreaddy logged in | 20:46 |
| nekohayo | (or is that command supposed to do something else than just return my login username?) | 20:46 |
| glyph | nekohayo: oh, nevermind then. | 20:47 |
| === frakturfreak_ is now known as frakturfreak | ||
| glyph | nekohayo: without being logged in, it's http://, if you are logged in, it's bzr+ssh | 20:48 |
| glyph | FWIW, it takes 15 seconds for me to get the branch. | 20:48 |
| * nekohayo is scared to imagine the performance without being logged it, must be about 30-40 secs | 20:48 | |
| glyph | maybe it's better! who knows. | 20:49 |
| nekohayo | from my tests here, over HTTP = 20 secs, over bzr+ssh = 9 secs | 20:49 |
| nekohayo | so I'm wondering why LP is still slow | 20:49 |
| nekohayo | hmm, lifeless might know something | 20:55 |
| hallyn | i did a 'bzr branch lp:qa-regression-testing', made a chance, committed it, and now want to push it to lp:~serge-hallyn/qa-regression-testing/foo. It's a huge tree, so i want it to just base lp:~serge-hallyn/qa-regression-testing on the main one and upload only the one diff. Is that possible? | 21:15 |
| knittl | afaik bzr/lb does that automatically | 21:17 |
| knittl | * lp | 21:17 |
| knittl | but don't take my word for it | 21:18 |
| hallyn | knittl: doesn't appear to :) i gave up after 30 mins of very heavy net traffic | 21:18 |
| jam | hallyn: just pushing to a branch should auto base on the old one, as long as a development focus is set | 21:18 |
| hallyn | how do i set a development focus? | 21:19 |
| jam | knittl: bzr show-signature works for me. 'bzr show-signature -r 4011.1.1 | gpg --verify' works | 21:20 |
| jam | (in your brancH) | 21:20 |
| jam | though I'm guessing you don't actually validate the testament sha1, which may be a next step | 21:21 |
| knittl | jam: awesome :D | 21:21 |
| knittl | no, it's only called 'show-…' | 21:21 |
| jam | knittl: you may want to call it "cat-signature" | 21:21 |
| jam | I think we have cat-revision, etc | 21:21 |
| knittl | i think cat is a bad name for that | 21:21 |
| jam | which does a similar "dump the text that is stored in the repo" | 21:21 |
| knittl | because it's for concat, not for output | 21:21 |
| jam | knittl: while true, we don't use "show-text" or "show-revision" | 21:22 |
| knittl | yes, i understand that | 21:23 |
| GaryvdM | hallyn: Ihttps://help.launchpad.net/Code/QuickStart#line-61 but if lp:project works, it suggests that the dev focus is set. | 21:32 |
| GaryvdM | hallyn: When you push a new branch, it should tell you that it stacked the branch against the dev focus. | 21:33 |
| knittl | but only after pushing | 21:34 |
| GaryvdM | yes | 21:34 |
| niemeyer | Hi there! | 21:35 |
| niemeyer | We're getting a connection timeout issue when trying to checkout a bazaar branch out of Launchpad in an EC2 cloud-init script | 21:35 |
| niemeyer | Would anyone have any vague guesses on what could possibly be going on? | 21:36 |
| niemeyer | We're a bit puzzled at the moment because sshing into the machine and run it, it works | 21:37 |
| niemeyer | s/run/running | 21:37 |
| niemeyer | apt-get is running right before the bzr switch command, so it's not an actual network error | 21:38 |
| knittl | jam: best name would probably be print-signature | 21:39 |
| knittl | also for all the other cat-*-commands | 21:39 |
| jam | niemeyer: do you have the traceback? | 21:40 |
| jam | if you are checking out an "lp:" thing | 21:40 |
| jam | sometimes that fails because of the xmlrpc request | 21:40 |
| jam | especially if proxies are involved | 21:40 |
| niemeyer | jam: Yes, we're using lp: | 21:41 |
| jam | niemeyer: some versions of bzr did not handle xmlrpc requests and http proxies (because python itself does not trivially handle it) | 21:41 |
| niemeyer | hazmat has the error message | 21:41 |
| hazmat | bzr: ERROR: Connection error: failed to connect to bazaar.launchpad.net:4155: Connection timed out | 21:41 |
| jam | hazmat: that is trying to connect directly to a "bzr://" url | 21:42 |
| jam | you need to connect to a "bzr+ssh://" url | 21:42 |
| niemeyer | jam: We're not behing an http proxy though.. it's an EC2 instance | 21:42 |
| jam | 4155 is the bzr port | 21:42 |
| niemeyer | Uh | 21:42 |
| hazmat | jam, hmm. thanks i'll double check that now | 21:42 |
| niemeyer | hazmat: Aren't we using lp:? | 21:42 |
| niemeyer | jam: Does lp: resolve to bzr: in some cases? | 21:42 |
| hazmat | niemeyer, we are using lp: | 21:42 |
| knittl | jam: why should the testament hash verified? that's not the job of a signature | 21:42 |
| hazmat | probably since we're not authenticated to bzr (no keys) on the ec2 instance | 21:42 |
| knittl | if it's wrong, well, you signed a faulty testament :P | 21:43 |
| jam | niemeyer: lp: should never resolved to bzr:// because Launchpad doesn't expose bzr:// | 21:43 |
| jam | if it does, that is a bug in launchpad-code (aka thumper) | 21:43 |
| niemeyer | What the heck then :) | 21:43 |
| niemeyer | jam: Yeah, no "bzr:" in our code base, at least | 21:44 |
| niemeyer | If that's a bug in Launchpad, though, should be easy to fix by using http: explicitly | 21:45 |
| jam | I don't really know why it would be trying to connect directly. | 21:45 |
| jam | I do know that thumper recently landed code to allow "lp:" urls to be resolved inside of ssh | 21:45 |
| jam | so that it can handle private projects, etc | 21:45 |
| jam | so "lp:foo" actually resolves to "bzr+ssh://bazaar.launchpad.net/+branch/foo" | 21:45 |
| jam | rather than ~/foo-group/foo/trunk, etc | 21:46 |
| niemeyer | Hmm | 21:46 |
| jam | I don't know if it broke something of yours | 21:46 |
| niemeyer | Ok.. we'll try with http:.. let's see | 21:46 |
| hallyn | GaryvdM: it did say it was trying stacked, but i don't remember against what, and it certainly wasn't pushing only the diff. | 21:46 |
| hallyn | alas, that has to wait, more urgent question: | 21:47 |
| hallyn | what is the recommended bzr equivalent to 'git rebase -i'? | 21:47 |
| hallyn | in other words, remote developer makes 5 commits while offline, meanwhile upstream advances by 10 commits, | 21:47 |
| knittl | why not use git in the first place? :> | 21:47 |
| hallyn | now remote developer wants to squash his patches 2-4, and rebase those 3 on top of the upstream branch? | 21:47 |
| * hallyn facepalms | 21:48 | |
| knittl | that was no sarcasm, that was a real question :) | 21:48 |
| knittl | but i'd be also interested in the answer to rebasing in bzr | 21:48 |
| hallyn | "we can't", basically | 21:48 |
| nDuff | there's a 3rd-party rebase plugin | 21:49 |
| nDuff | but using it is not necessarily a good practice | 21:49 |
| knittl | amending a revision is so uncomfortable right now | 21:49 |
| niemeyer | jam: Yes, http: solved the problem | 21:49 |
| niemeyer | jam: So it looks like some kind of resolution problem with lp: indeed | 21:49 |
| jam | niemeyer: I don't *know* that it is resolving lp:foo => bzr://bazaar.launchpad.net/foo" but it certainly looks like something like that happened | 21:50 |
| hazmat | jam, what's odd is that when we logged into the instance by hand and used bzr switch lp: it did the right thing.. but somehow it didn't do the right thing eraly on | 21:50 |
| hallyn | nDuff: so what is good practice? | 21:50 |
| jam | maybe thumper changed something and forgot to have the +ssh | 21:50 |
| niemeyer | jam: Yeah, I have no idea either | 21:50 |
| niemeyer | Glad it's now working, though :-) | 21:50 |
| hazmat | indeed | 21:50 |
| niemeyer | jam: Thanks! | 21:50 |
| jam | hazmat: if you were logged in, maybe it was using different credentials? | 21:50 |
| hazmat | +1 | 21:50 |
| niemeyer | It was indeed | 21:50 |
| hallyn | nDuff: i would guess: do a local branch into different working dir, work there, and do bzr merge revision-by-revision into the other after a fresh pull? | 21:50 |
| hazmat | jam, its all anonymous work | 21:50 |
| niemeyer | hazmat: I don't think so | 21:51 |
| niemeyer | hazmat: cloud-init must execute as root | 21:51 |
| niemeyer | hazmat: and we executed with sudo | 21:51 |
| hazmat | niemeyer, but that has no bzr/launchpad credentials | 21:51 |
| niemeyer | hazmat: Yeah, just saying it's a different env | 21:51 |
| niemeyer | jkakar: Hi! | 21:51 |
| hazmat | true | 21:51 |
| nDuff | hallyn, ...to use a workflow that avoids _needing_ rebase-like functionality? | 21:51 |
| hazmat | niemeyer, hmm.. actually executing by hand i was using sudo.. because of file perms | 21:51 |
| nDuff | hallyn, ...if you're not coming from git, that's not so hard :) | 21:52 |
| hallyn | nDuff: well really i'm trying to figure out how to tell someone else, not employed by my employer, how they should proceed with their workflow... | 21:53 |
| hallyn | (in a bzr tree shared with us) | 21:53 |
| hallyn | nDuff: so the most basic question: if he has made 2 commits, and now wants to push, but there are conflicting changes in the upstream, how can he stash his changes away, pull, and then (gotta use the word) rebase his revisions? | 21:54 |
| nDuff | why do that at all? | 21:55 |
| hallyn | nDuff: alternative? | 21:55 |
| nDuff | why not just merge upstream and fix the conflicts? | 21:55 |
| hallyn | well, i think tha'ts what h'es doing now. it removes the previous commits from upstream and replaces it with one called 'merge' | 21:55 |
| hallyn | if i didn't want meaningful revision history, i wouldn't need this at all | 21:55 |
| nDuff | they're still there | 21:55 |
| hallyn | how do i see them? | 21:55 |
| * nDuff looks at help for bzr log | 21:56 | |
| nDuff | ahh, --levels / -n | 21:56 |
| hallyn | jinkeys | 21:56 |
| nDuff | so -- you're actually getting _more_ history this way | 21:58 |
| hallyn | but, if the 'merge' wasn't conflicting anyway, why bother 'hiding' this way instead of just picking an order? | 21:58 |
| nDuff | rather than throwing away the info about the context something was originally written in (and disguising bugs introduced during the rebase/merge process), you're keeping it all | 21:58 |
| nDuff | it's a win | 21:58 |
| hallyn | hm | 21:58 |
| hallyn | nDuff: it definately solves my problem, thanks a bunch | 21:59 |
| nDuff | there's textual conflicts, and there's logical conflicts | 21:59 |
| nDuff | only the former can be detected automatically | 21:59 |
| nDuff | so doing an automatic flatten on merge is dangerous | 21:59 |
| nDuff | well | 21:59 |
| nDuff | that's not quite true -- the cases where git does an automatic fast-forward are safe | 21:59 |
| nDuff | but they lose history about when things were actually merged | 21:59 |
| knittl | why? history is still the same | 22:00 |
| knittl | and dummy-merge commits only clutter history | 22:00 |
| nDuff | not from the perspective of "what did the shared tree look like at this point in time/" | 22:00 |
| * hallyn quietly sneaks away from the ensuing battle | 22:00 | |
| knittl | then use git pull --no-ff | 22:00 |
| knittl | or merge --no-ff | 22:00 |
| nDuff | knittl, yes, I'm not saying there aren't workarounds -- it's just something that I've been historically a little wary of as a default behavior. | 22:01 |
| nDuff | knittl, ...I use git for my day job, far more than I use bzr, but that doesn't mean I like every single design choice and default Linus made. | 22:01 |
| thumper | jam: the resolve_lp_path xmlprc call that bzrlib calls to resolve lp: branches ONLY returns http or bzr+ssh, no bare bzr to be found there | 22:02 |
| knittl | i still think --no-ff is (most of the times) unnecessery | 22:02 |
| thumper | no idea what was causing the problem | 22:02 |
| knittl | * …ary | 22:02 |
| nDuff | knittl, I don't think you're wrong -- but I do think throwing away information just because it's unnecessary 99% of the time is something to be wary of in the context of a tool whose principal and primary purpose is storing and tracking mission-critical content. At least, I do when I'm playing devil's advocate. :) | 22:04 |
| jam | thumper: I would have assumed so, but something weird is going on, and I new you had touched it a bit recently | 22:04 |
| thumper | jam: yeah :) | 22:04 |
| knittl | nDuff: if nothing changed in my version of the DAG why should i introduce i new node? that's my point of view ^^ | 22:05 |
| jam | knittl: if you look at bzr log --short bzr.dev, that is an example of where --no-ff works very well | 22:05 |
| jam | which is: features are developed on non-mainline commits, and committed and summarized at merge time | 22:05 |
| knittl | i don't care | 22:05 |
| jam | so instead of seeing 100 revisions every time you implemented a feautre | 22:05 |
| jam | you see a single summary rev | 22:05 |
| jam | with logical step | 22:06 |
| jam | stepts | 22:06 |
| jam | somewhat akin to rebasing to clean up your history | 22:06 |
| knittl | no, it only hides the turd | 22:06 |
| jam | anyway, we do support "bzr merge --pull" which you can alias to be the default | 22:08 |
| jam | (bzr merge --pull = ff if you can) | 22:09 |
| knittl | whatever, i'm not interested in ff vs. non-ff merges | 22:09 |
| knittl | jam: why should verification of testament hash happen in cat-signature? | 22:10 |
| knittl | cat-signature should only print the signature (so, print-signature …) | 22:10 |
| jam | knittl: it certainly doesn't have to, but if you actually want to verify that the revision is correct and signed, then I would recommend closing the loop (potentially only as a flag) | 22:11 |
| knittl | if the testament hash is wrong there's another thing wrong | 22:11 |
| jam | certainly it is "separate but related" | 22:12 |
| knittl | should happen on testament level | 22:15 |
| knittl | does an inventory store the executable bit? | 22:36 |
| knittl | i guess so, but then why isn't it printed when using bzr inventory -v? | 22:36 |
| kirkland | what's the bzr command do bind your local checkout to the network one, so that you don't get out of sync? | 22:44 |
| dash | 'bzr bind <url>' | 22:45 |
| * kirkland just butchered the vocabulary, he's sure | 22:45 | |
| dash | apparently not ;) | 22:45 |
| kirkland | dash: hmm, man and bzr help don't seem to know about "bind" | 22:45 |
| * kirkland did at least look for it | 22:45 | |
| dash | 'bzr help bind' | 22:46 |
| dash | also listed under 'bzr help commands' | 22:46 |
| === Ursinha is now known as Ursinha-afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!