[00:39] Night [00:47] how are bzr revision ids calculated/generated? i'm also happy with the file name (and line number/function name) [00:50] hey... is there a plugin for use with Qt Creator? === Ursinha is now known as Ursinha-afk [01:26] 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:27] jbowtie: yes i was. but i think i found it. email-timestamp-random [01:27] although i don't understand why random and not some kind of hash [01:29] knittl: Probably no reasonable criteria for what to hash. [01:31] knittl: Don't forget that revids can originate in other places. For example bzr-tfs uses path:changeset for its revids. [01:32] so in bzr there is no way to verify a revid is actually the revid of that particular revision? [01:32] revids themselves are not signatures [01:33] signature are signatures [01:34] also creating the exact same revision twice will generate a different revid? [01:37] knittl: If I understand the question, yes, you'll get two different revids; though I suspect they would merge cleanly in that case. [01:38] ok [03:05] hi all [03:05] i'm having some hardware problems, will be offline a bit [03:06] some web pages indicate it may be just the cable, which would be nice [03:08] poolie: almost more aggravating if it just a cable, though :) [03:09] :) [05:43] poolie_: the pad.lv root page doesn't list OOPS === poolie_ is now known as poolie [05:46] thanks [05:46] just a small thing :) [05:48] can you give me an example id? [05:55] fixed [06:03] ding ding ding, release day, hello all ! [06:03] poolie: I mean that the root page doesn't explain showing OOPS's [06:03] poolie: got that cable plugged now ? :-p [06:03] poolie: actually showing a specific oops works :P [06:03] lifeless: i understand; i've fixed it now [06:03] \o/ [06:03] i was just going to use a specific example [06:03] ah [06:03] but i guess since most people can't click them it's of limited use [06:04] and maybe they expire anyhow? [06:04] hi vila [06:04] eventually yes [06:04] i was hoping to get stale lock detection in for the beta, but i guess i won't now [06:04] and i believe in resisting the temptation to slip or rush [06:05] poolie: you're right, I was hoping for orphans myself :) [06:05] so, let's just do it [06:05] can release another later [06:05] vila, i'm just running gardener [06:05] which is nice [06:05] but it told me something was merged even though it has uncommitted changes [06:05] is that intended? [06:05] poolie: glad you like it [06:06] poolie: it's very rough so far, so it just spew out whatever if finds without dependencies [06:07] so that seems like a bug? do you want a report somewhere? [06:07] or for me to just tell you here [06:07] 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:08] poolie: bug please [06:08] poolie: that's why I released early :) [06:09] vila, so today shall we do 2.2.1 and 2.3b1? [06:09] poolie: no 2.1.2 ? Anyway, I think the most important is 2.2.1 so we can then merge up [06:10] and also that [06:10] i sent a merge up of 2.1 to 2.2 the other day [06:10] would be worth checking it succeeded [06:11] I think I saw it [06:13] 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:14] 2.2.1 will go into maverick right ? Somewhere else ? [06:14] 2.2.1 should go in to maverick updates [06:14] they've just today announced the final freeze [06:15] i don't know if it's possible to do an SRU before the thing even officially releases [06:15] we should check [06:15] ok, added to TODO [06:16] 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] We did have a page on the wiki once. It was very useful for seeing when anybody bothered updating it ;p [06:17] Didn't have such a page to track the installer builds ? Or was it done just by mail ? [06:18] That will be very helpful for me and my alzheimer... what's the name ? [06:18] also, we may want to get a specific clarification that the SRU policy and our policy agree [06:18] to avoid future confusion [06:19] I think we got such confirmation... or did I just dreamed it ? [06:19] https://bugs.edge.launchpad.net/bzr-gardener/+bug/641043 - your very first! [06:19] Launchpad bug 641043 in bzr-gardener "says 'merged' about trees with uncommitted changes (affected: 1, heat: 6)" [Undecided,New] [06:20] 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:21] poolie: we may as well start with 2.1.3 [06:21] yes, lets [06:21] *let's [06:21] how about if you do it and i'll copilot? [06:21] 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] (I was trying to merge 2.2 to lp:bzr so I could close off a couple of In Progress bugs) [06:22] just in case it is subtly broken in 2.2? [06:22] that makes sense to me, put it up for review? [06:22] Right, and the minimise the delta between 2.2 and trunk. [06:22] Will do. [06:22] on the whole that was perhaps not critical enough to put in 2.2 [06:22] otoh it should only affect selftest [06:23] spiv: if you're >90% sure about it , go, otherwise, revert please ;) [06:23] oh, only selftest ? make that >80% then :) [06:23] spiv: thanks for the heads-up anyway [06:25] 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:26] backports? [06:26] meaning merges from trunk to 2.3? [06:27] 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] IIRC the process was that 2.3 is released from trunk until the first rc... am I misremembering? [06:28] there was some discussion that having a branch makes the actual release process easier [06:28] spiv: yeah, that [06:28] in case any small fixes are needed [06:29] vila, poolie: https://code.edge.launchpad.net/~spiv/bzr/traceback-accumulation-2.2/+merge/35778 [06:30] thanks, +1 [06:39] poolie: wow, hold on, what about 2.0.6 ? [06:40] https://edge.launchpad.net/bzr/2.0 says: Released in September 2009; supported until at least September 2010. [06:41] There are several worthwhile fixes that would be in 2.0.6, especially #522637 [06:41] spiv: shameless plug :) [06:41] :) [06:42] let's do it [06:44] hm, what should i do now? still fix stale locks? [06:45] maybe add a note about requesting SRUs to the release guide, then go back to that [06:45] 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:49] i'll be here for at least 2-3 hours [06:50] meh, now what's new for 2.0, no wonder I couldn't find it :) [06:56] bzr lp-propose -m 'Release 2.0.6' --approve lp:bzr/2.0 [06:56] bzr: ERROR: bzr+ssh://bazaar.launchpad.net/%2Bbranch/bzr/2.0/ is not registered on Launchpad [06:56] ring any bell ? [06:57] it sounds a lot like what thumper just changed [07:03] grr, firefox can't start, close any existing window (none, double checked) or *restart your system*. WTF ? [07:07] ok, found the ghost, jinxed it [07:09] poolie: https://code.edge.launchpad.net/~vila/bzr/prepare-2.0.6/+merge/35779 sanity check please, while pqm is busy [07:23] poolie: ping [07:26] * vila plugs poolie's cable [07:29] poolie: hi [07:29] i mean, vila [07:29] :) [07:30] sure [07:31] vila re the branch for bug 32669 [07:31] 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:32] hm [07:33] 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] Launchpad bug 32669 in Bazaar "Adding a symlink to another branch fails (affected: 3, heat: 17)" [Medium,Fix released] [07:33] at any rate i wouldn't block 2.0.6 on it [07:33] poolie: me neither :) Just a heads-up for 2.0.7 [07:34] 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:35] hm [07:35] that makes sense [07:36] done [07:36] its host distribution may EOL before then? [07:37] you mean hardy ? [07:37] i guess so [07:37] actually no, isn't 2.0 in karmic? [07:38] 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] works for me [07:39] poolie: ok, sanity check on https://code.edge.launchpad.net/~vila/bzr/prepare-2.0.6/+merge/35779 ? [07:43] yes, it's fine [07:46] karmic is supported until april next year [07:46] so, it's probably not worth doing a 2.0.7 in march [07:46] but we can see how we go closer to the time [07:51] pff, two feed-pqm from two different setups, both errored out but both send the request :-/ [07:54] istm we want to get on to this page: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions [07:58] poolie: istm you're deadly right [08:00] i'll mail the board [08:00] poolie: great ! thanks ! [08:04] 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] heya vila, spiv [08:05] vila: hmm, I don't think I like that. [08:05] 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:06] Yeah :( [08:06] spiv: hehe, I don't like it much either, but I want a stop-gap fix [08:06] spiv: I hate to discover that *now* too [08:07] 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] does anyone know off hand if selftest runs during packaging? [08:07] i think it does not. [08:08] poolie: my guess is no, but I don't know either. [08:08] dunno, but it runs at each commit and at source release time [08:08] i know :) [08:08] releasing source is not part of packaging ? [08:09] hmm [08:09] poolie: IIRC pitti has said that our mandatory tests-run-before-landing might be considered as good [08:09] But I guess it's probably not too hard to make the packaging do a selftest run. [08:10] * bialix waves at poolie [08:10] bialix: hey ! [08:12] hi there spiv, bialix [08:12] vila: I'm actually trying to figure out why EPIPE is being treated specially there in the first place :) [08:12] 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] 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:13] spiv: ha cool, I'd like to have this fixed asap and preferably before cutting 2.3b1 [08:13] spiv: let me double check, I think it was [08:13] spiv: http://babune.ladeuil.net:24842/job/selftest-hardy/195/testReport/junit/bzrlib.tests.test_sftp_transport/SSHVendorBadConnection/test_bad_connection_ssh/ [08:14] Blah. [08:14] spiv: and I'm pretty sure the analysis was that it was a socket.error... [08:14] Yeah. [08:15] an alternative would be a more complex test with isinstance(socket) and e.args[0] or e.errno... but without tests... :-/ [08:16] s/complex test/complex if expression/ [08:16] spiv: thks for the merge 2.2 -> dev [08:17] vila: you're welcome, I already had it ready to go :) [08:20] ok sent [08:21] vila: I wonder if maybe http://paste.ubuntu.com/495134/ would do? [08:22] spiv: rationale ? [08:22] 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] (despite the comment and the fact that annotate blames me :) [08:23] vila: so I'm thinking "why not treat all of those as a regular connection error?", basically [08:24] spiv: and we have evidence that not handling a socket.error.EPIPE make the test fail... how does this relate ? [08:24] now we will raise a connection error in this case and ? [08:25] it will be handled above and... what ? [08:25] EPIPE there has always caused some sort of exception there [08:26] 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:27] 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:28] Well, it's not going to solve the intermittent failure. [08:28] It'll give a more appropriate error, we hope. [08:29] i need to reply to vila's config thing... [08:30] spiv: ok, let's try that [08:30] Hmm, I guess the test is about failure to connect, so a more appropriate error may be the fix... [08:30] poolie: the orphan related one ? [08:30] spiv: I understand [08:30] yeah [08:30] spiv: well, I *think* I understand :) [08:31] poolie: amanica raised a good point about ignoring bzr-orphans [08:31] * spiv experiments now [08:34] vila: manually hacking that try block to raise various socket.errors, just unconditionally doing self._raise... works. [08:34] vila: I'll put up a patch [08:34] spiv: thanks [08:35] vila: I'd love to know what the different treatment of EPIPE was intended to achieve, though :/ [08:35] spiv: yeah, me too, let's ask the praised one for this comment :) [08:37] spiv: just joking, trying to ease your pain for not remembering, I so know the feeling ;) [08:39] aw... 2.0 the [ascii] tests, double pain [08:40] plus the fact that I should add that back to babune some way or another ;-/ [08:42] 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] vila: https://code.edge.launchpad.net/~spiv/bzr/ssh-connect-socket-error/+merge/35784 [08:43] vila: yes, fixed in the upstream 2.7 branch, patch backported already to python2.6 in maverick [08:44] vila: it's triggered by trying to things with SSLSocket objects that aren't connected [08:44] vila: (http://bugs.python.org/issue9729 is the relevant report) [08:44] spiv: I know the root cause, ha cool [08:44] 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:45] spiv: it occurs only *before* the first connection ? [08:47] hmm, given the traceback... that's an idea worth checking... [08:47] 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:48] vila: except those code paths were untested and in some cases broken in two separate ways :) [08:48] spiv: so we get correct socket errors (EBADF especially) if we try to use a close socket right ? [08:48] closed [08:48] spiv: yeah, tell me about untested code ;-/ [08:49] http://svn.python.org/view?view=rev&revision=84806 is the patch that was committed. [08:50] vila: I know it's triggered by never-been-connected sockets wrapped with the SSLSocket class [08:51] vila: I haven't checked if was-connected-but-now-now-closed sockets would do the same thing [08:51] spiv: ok, good enough for me, I'm pretty sure the later is covered by tests [08:51] spiv: well, obviously the former is too ;) [08:52] spiv: but randomly :-D [08:52] I was a bit depressed by the test_socket and test_ssl tests in Python. [08:53] I'm used to nicer test infrastructure, and more comprehensive coverage. [08:56] spiv: right, I think I have rough idea on how to reproduce it in a test, but not now ;( [08:56] ;) I meant [08:57] spiv: so this patch will find its way upstream in the next 2.6 or only 2.7 ? [09:01] vila: only 2.7 [09:01] vila: IIRC upstream considers 2.6 to be security-fixes-only now [09:01] spiv: right, ssl is all about security isn't it ? :D [09:01] Hah. [09:02] vila: I'm about to log off for the night, anything else you need from me urgently? [09:03] 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] Ok :) [09:03] spiv: I'll land the fix for the EPIPE thing when needed [09:03] I'll try to keep an eye on it and if it fails put the failure somewhere visible. [09:04] spiv: ok, great, enjoy your week-end ! [09:04] vila: thanks, you too, when you get the chance :) [09:07] grr, bzr-2.0 knows nothing about BZR_PLUGIN_PATH damn alzheimer [09:12] * vila whistles while sudo mv /plugins /pluginsx , because... he can [09:14] vila, https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/35785 describes sru stuff [09:14] there may be more to add [09:14] i don't want to duplicate the wiki too much though [09:14] but please ask questions [09:15] * poolie trying to get the scripts branch through pqm [09:16] did we merge the patch to omit details from skipped tests? [09:18] 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:19] At least the workaround for duplicated tracebacks will help keep the details of skipped tests to something reasonable. [09:19] spiv: +1 [09:19] spiv: you did land this one right ? [09:20] 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] have fun spiv :) [09:32] poolie: appropriate Ubuntu release for 2.0 -> >= karmic ? [09:34] for 2.0 it would be karmci [09:34] 2.1 lucid [09:34] 2.2 mavericj [09:40] poolie: ok, and for ppas, I'll follow ppa.txt, but I'm not there yet [09:48] for those following from home: make check-dist-tarball for 2.0.6 : Ran 23384 tests in 1049.609s [09:48] OK (known_failures=39) [09:48] 2014 tests skipped [09:48] bzrlib.tests.blackbox.test_branch.TestBranchStacked.test_branch_stacked_from_smart_server is leaking threads among 2523 leaking tests. [09:48] now running with no locale [09:50] Spooky. [10:12] pass with no locale: [ascii] Ran 23384 tests in 994.671s [10:12] [ascii] OK (known_failures=39) [10:12] [ascii] 2260 tests skipped [10:12] [ascii] bzrlib.tests.blackbox.test_branch.TestBranchStacked.test_branch_stacked_from_smart_server is leaking threads among 2476 leaking tests. [10:12] Finally, I've got some reference point about the number of leaks [10:13] vila: which reminds me: https://bugs.edge.launchpad.net/subunit/+bug/637674 [10:13] Launchpad bug 637674 in subunit "RemotedTestCase.addCleanup exists but fails under Python 2.7 (affected: 1, heat: 6)" [Undecided,New] [10:14] spiv: hmm, should ping mgz about it [10:15] Oh, I see the 2.2->dev branch landed. Good. [10:23] Is there any software I can exploit to rapidly illustrate branch revision graphs? [10:24] qlog [10:24] Esp. something that produces "management grade" graphics? [10:24] Hmmph. [10:24] bzr-gtk adds a graph command iirc [10:24] bzrtools has something that uses graphviz. [10:24] ^^ thats the one i mean [10:25] it does not work well on big graphs [10:25] Heh, I was kinda hoping for something that does hypothetical ones, but I suppose that's just as much work :-) [10:25] graph-ancestry [10:25] Oh, well, for hypothetical ones you use ASCII-art 8-} [10:25] jam is very good on that [10:25] oh i see [10:25] fullermd, I'm talking about _management grade_ visualization :-) [10:25] you can search the examples in his mails [10:26] 4-color glossy ASCII art, then :p [10:26] I heard Gary wasn't bad at generating them too ;-) [10:26] Heheheheh :-) [10:26] You could bang up fake stuff to feed into dot just like graph-ancestry does. [10:26] visio / omingraffle / dia i guess [10:26] I'd probably fiddle with xfig if I had to do it. [10:26] inkscape [10:27] we'll I [10:27] (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] well I'd just draw by hand and scan it later [10:27] Yeah, I've been using Inkscape up till now [10:28] awilkins: what is "management grade"? [10:29] bialix: simple :) [10:29] I presume it defines the revenue contribution of each revision. [10:29] rotfl [10:29] Also there need to be little clipart cartoon men pointing at them and smiling. [10:30] (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] do it in ascii, then apply a 3D filter to it so its at an angle [10:31] awilkins: look http://doc.bazaar.canonical.com/migration/en/foreign/bzr-on-svn-projects.html [10:31] there is a lot of sexy pictures [10:31] bialix, Yes, I always liked those [10:32] What are those, inkscape? [10:32] no, some MacOS tool [10:33] Bah. [10:33] I know [10:33] Ought to write something that takes ASCII-art graphs and transforms them into SVG [10:34] Which you can then stylesheet and export to PNG [10:34] The people who can do things like that are too busy writing converters that go the other way, making ASCII movies :p [10:34] I always find whenever i try and use a diagramming tool [10:34] that i wish i'd just used paper [10:35] A tool that generated Hollywood movies from ASCII art would be much more impressive [10:35] Isn't that what Avatar did? [10:35] its not something you generally do often enough to be able to do something that looks good quickly [10:36] xfig works well for me once I jerk back into the mental mode to handle the UI. [10:36] it has a horrible website [10:37] I didn't even know it had a website, actually... [10:37] Woo, the recursive SVG file on the SVG page for Wikipedia is really impressive [10:37] whenever i see a site like this i instantly imagine it hasn't been maintained for a decade [10:37] I don't think it's had a release in something like that, no. But it still works fine. [10:37] 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:38] awilkins: where's the recursive one? [10:39] 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:40] Ok, it's a MITE more complex inside :-( [10:41] oh, i thought there was an SVG which included itself and rendered an infinite picture [10:42] 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:45] Ideally also prettyprinting the XSLT :p [10:46] 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:48] 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] jade? [10:48] DSSSL processor. [10:52] fullermd: Digital Super Slow Subscriber Line ? [10:52] fullermd: A ZX80 should do no ? [10:52] Pbbt :p [10:53] Poor BroadBand Type ? [10:53] I believe he meant "pttthpt" [10:54] awilkins: no no http not thpt [10:54] * fullermd hires Bill The Cat to do his IRC'ing for him. [10:56] hm. i still don't fully understand a testament [10:57] 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] so where do file contents come into play? [10:59] because obviously, having the same pathnames does not mean it's the exact same file contents [11:01] http://blogs.gnome.org/jamesh/2007/10/04/signed-revisions-with-bazaar/ [11:02] this says that "bzr testament --long" includes hashes of file contents [11:03] ok. difficult to find bzr docs on gnome sites [11:03] i googled "bzr testament" [11:03] its the top result. [11:04] still, it's a third party observation [11:04] http://wiki.bazaar.canonical.com/Testament [11:04] i expect the bazaar wiki to contain a little more information [11:04] there are a lot of third parties involved in the bzr community, that's the point of a community me thinks... [11:05] knittl: it's a wiki ! Your contributions will be gladly welcome [11:05] Well, that's a near-standing page from a glossary jblack was working up way back in the mists of history. [11:05] (near-standin that is) [11:05] vila: my contributions? i really don't grokk bazaar [11:05] and i don't want to confuse others [11:05] Even asking questions is a contribution ; gives people an idea of what's important for people [11:06] But, why ask about testaments in the first place? They're pretty specific use items. [11:06] because they come after files, ineventories and revisions [11:06] 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:07] (I think that wiki page is incorrect too; a testament isn't a type of revision) [11:07] only if you write a list "files, inventories, revisions, testaments" [11:07] fullermd: well, that does not help _me_ in any way [11:07] Glenjamin: i am [11:07] Well, it's like a crypto signature [11:07] Sort of [11:07] Ish [11:07] Yes, but why? A testament is basically just a representation of a revision. [11:07] seems an odd list of evaluation criteria [11:08] awilkins: i know what they *basically* are, but that's nearly not enough information [11:08] 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] it's like saying 'a revision is a specific version of the project' [11:08] knittl: as I understand it a testament is a format-independent mechanism for verifying the contents of a revision [11:08] great, that's 1 thing a revision is made of [11:09] does that mean you can lookup a revision using a testament's checksum [11:09] git just has this property because of the way it works - you can just say "revisions " where blah is the SHA-1 value and be almost totally certain that you are talking about the same thing [11:09] awilkins: git uses annotated tags to sign revisions [11:09] Glenjamin: in theory, sure. I'm not sure what the use of that would be though [11:10] knittl, because of the way git processes data, the signature is only required to certify the SOURCE of a revision [11:10] on an unrelated topic: how does bzr map from revids to revisions? using an index/dictionary file? [11:10] awilkins: ehm. i know. i think i really know git well [11:10] knittl, The SHA-1 hash identifies any revision + it's history + it's content with certitude. [11:11] hashes dependent on all contents and ancestor content [11:11] Apologies if I'm teaching you to suck eggs [11:11]