[00:06] hey poolie [00:06] I'm contemplating getting tagged versions of pyqt and sip from their mercurial repo instea. [00:07] except of course they only have sip in the repo and not pyqt itself [00:07] /facepalm [00:21] thumper: just passing by, I may be around in about 3-4 hours, though [00:21] jam: can we chat tomorrow? [00:21] thumper: sure [00:21] jam: I'd like to talk about your thoughts on branch revisions :) [00:21] sure [00:21] jam: as in the LP table [00:21] though what time? [00:21] can you do 22:00 UTC? [00:21] or perhaps half an your earlier? [00:21] 5pm is usually when I stop, extra important tomorrow because my wife is out of town [00:22] 22:00 = 5pm [00:22] ah [00:22] 02:00 or so might be better [00:22] 21:30 would work [00:22] gotta go [00:22] ok [00:59] Good morning. [01:07] howdy spiv [01:21] Hey dOxxx, haven't noticed you around for a while. Probably you've just been awake in more sensible timezones ;) [01:21] spiv: I'm not normally on IRC :) [01:22] I'm doing the Mac installers right now and vila suggested we talk about them on IRC [01:22] but I guess his timezone is not compatible [01:36] He's in Europe, typically he'll be online in about 5.5 hours from now. [01:38] spiv: Hmmm... awkward. [01:52] hi spiv [03:25] When I'm about to try something I think might be a bad idea that could be hard to reverse, I tend to copy .bzr somewhere so I can restore it if I make a mess. Is it safe to do that for a branch under a shared repo, without also copying/restoring the shared repo itself? [03:26] I sorta have this 6 meg .bzr branch under a 3 gig shared repo. :) [03:28] It's safe to do that. [03:29] Really good news for this project! [03:34] dlee: but you can also use bzr revert and bzr uncommit :) [03:38] dash: well, assuming the operation being tried is a commit, or a pull that adds one new mainline revision (with the old tip as the lefthand parent). [03:48] Learning how to manage a multiperson bzr workflow at the far end of a large svn repo... lots of syncing that confuses me if I make a wrong step. === Ursinha is now known as Ursinha-afk [05:14] thanks for the ascii mode patch spiv [05:15] hi folks i am searching something like this http://bit.ly/aF2hqw anyone knows about? [05:15] plugin for diff with Ooo files [05:16] i think you want 'bzr diff --using "oodiff -u"' [05:16] then you might want to define a bzr command alias to run that [05:21] in another hand i want to know is tortoisebzr will be support on linux? [05:22] poolie, i dont know why initially linux is not supported [05:23] poolie, this is great https://edge.launchpad.net/bzr-oodif [05:39] ovnicraft: tbzr is very windows-specific [05:39] there's some bzr nautilus integration [05:39] i think in bzr-gtk [05:39] but 'bzr explorer' is a better option there [05:39] btw is not too important i can live with stdout [05:40] but i am really interested in bzr-oodiff [05:40] and great foudn it [05:40] found* === mnepton is now known as mneptok [05:50] We have file-specific merge hooks; do we not have file-specific diff hooks? [05:52] I'm thinking I might propose a blueprint for handling diff and merge of various free software "binary" formats. [05:53] good idea [05:55] +1 [05:56] Then you hire me so I actually have time to implement it, right? ;) [05:58] * jbowtie did not put subtlety on his CV [05:59] Subtlety? I think I heard of that once... [07:19] hi all ! [07:33] Again? Didn't you just say that yesterday? [07:34] yup, mummy told me I should do that every time I meet people, so they smile just a bit more everyday :-D [07:35] Remember, it takes more muscles to frown than it does to smile. But it doesn't take ANY muscles to just sit there with a dumb look on your face! [07:49] Yeah, but it doesn't make you richer whereas smiles are supposed to make everybody richer... The trick is to find a way to get some of *their* richness there... [08:06] hi there vila [08:07] poolie: hey ! [08:31] hi there [08:35] is there a way to uncommit a list of commit and reapply them at the end of the history ? [08:36] Uncommit only works on commits from the end of history. But perhaps you are looking for rebase, from the bzr-rewrite plugin? [08:37] Although, that'll only work if the list of commits is a side-chain in the revision graph [08:37] There's no way to splice commits out without rewriting everything that comes after the change [08:38] we've made a mistake: we have branch B1 and branch B2 - both were branched of V1 & V2 (different branches, corresponding to different versions of the codebase). B2 was merged into B1 and updates of V1 are merged through to B1 every now and then... [08:38] ouch [08:38] now that we want to merged B1 into something else we get a criss cross merge... [08:38] and it's a mess. [08:39] the thing is that the updates from V1 are in mutually exclusive directories to the rest of the commits. [08:39] you want rewrite then [08:40] what will that do? [08:40] that will let you hoist out the good bits of your history, leaving behind the stuff you shouldn't have merged [08:41] and what will happen with the bits of the history I take out? [08:42] bzr-rewrite produces a new branch, and in that branch they will never have been merged [08:48] spiv: here we are http://babune.ladeuil.net:24842/view/selftest-all-platforms/job/selftest-jaunty/lastFailedBuild/testReport/junit/bzrlib.tests.test_transport/TestSSHConnections/test_bzr_connect_to_bzr_ssh/ [08:48] how do I enable these plugins? [08:50] vila: huh, it wants me to login... [08:50] Is that new? [08:50] argh [08:52] GungaDin: if installing from source, typically by placing them into (or symlinking them into) ~/.bazaar/plugins/, or else by installing it as a system-wide Python package. [08:53] spiv: yes, new, I'm trying to allow some users to run jobs and ... that seems to have restricted anonymous access :-/ [08:53] vila: :( [08:53] spiv: since you will be part of these users, you may as well create a login until I fix the problem [08:54] Ok [08:54] vila: I don't suppose Hudson has OpenID support? ;) [08:54] I read that as "since you will be part of the problem, [...] until I fix these users" :p [08:54] spiv: hehe, I haven't see that (nor searched either ;) [08:55] spiv: fortunately I have all relevant config files under bzr as yesterday evening *I* couldn't login anymore at one point... [08:55] and I had to revert to a working config [08:56] one click and boom :-/ [08:56] installed bzrtools on my fedora.. but bzr rebase isn't accepted [08:56] Wow, apparently I got the first two captchas wrong. [08:56] vila: Doesn't that infringe some Amazon patent? :p [08:56] fullermd: you think I can sue Amazon for damages ? [08:56] GungaDin: It's not part of bzrtools... look for 'bzr-rewrite' [08:56] GungaDin: bzrtools is a different plugin. [08:56] GungaDin: the plugin you want is called 'bzr-rewrite' [08:57] vila: I think it's the other way around... they sue you for doing something with one click. [08:57] vila: "spiv is missing the Read permission" [08:57] vila: for the front page [08:57] (and the log in question) [08:59] try again ? [09:00] Ok, I can view them now. [09:00] and try again without login too, it seems to be fixed (I just love when I fix things without knowing why...) [09:00] vila: that's a really intruiging log [09:01] vila: bah, I don't want to have to re-enter my password :P [09:01] nvm, I tried from another host, seems good [09:02] It appears to allow anon read access. [09:02] that's the idea [09:12] spiv: a possible explanation can be: the client try to use the socket before the hand-shake with the server has been done [09:12] spiv: jam fixed a similar issue with the sftp test server [09:13] spiv: most of the time the hand-shake happens quickly enough but it sometimes takes a bit more time [09:13] spiv: did this match ? [09:14] is it possbile to find where a criss cross originates? [09:15] vila: the log implies otherwise, but of course in the presence of threads the impression of sequential events it gives is likely to be a lie.... [09:15] GungaDin: a visualisation tool like 'bzr qlog' or 'bzr viz' ('qbzr' or 'bzr-gtk' plugins, respectively), may help. [09:15] there are tons of commits... [09:15] I suppose there should be an option to get merge to report which revisions were involved. [09:16] * spiv -> dinner === ddaa1 is now known as ddaa === spike_ is now known as spikeWRK === zyga is now known as zyga-airport [11:02] vila: I have a thought for you about this coding style thing. [11:02] vila: Two thoughts. [11:03] lifeless: I'm sure about that and I'm happy you share them :) [11:03] vila: firstly, I think you may be proposing a *surrogate* metric. That is it itself doesn't indicate anything good or bad, but perhaps its often correlated with actual good/bad things. [11:03] lifeless: I don't want to start a holy war but I suspect there are more problems than it appears behind this subject and I'd rellay like to understand them [11:04] I don't like surrogate metrics because they are *follow* they don't *lead*. [11:04] Fixing the metric doesn't make things good. [11:05] it took me a while to understand this, (and when I did I did a big about face on my opinions in coding standards) [11:06] Secondly, I wonder if you've taken the time to deeply listen to what Andrew Martin and I are saying about how we find code more readable when done clearly on a case by case basis rather than being strongly-mandated. [11:06] I feel like you're brushing us off a bit. [11:07] ha, sorry about that, certainly not my intent [11:08] no worries [11:08] like I say, just a couple of thoughts. [11:08] The one about surrogates is the key one. [11:08] I came to this proposal mostly by applying it previously on the assumption that they were an agreement and specifically to address bugs in the first place [11:09] when you say coding standards, do you mean something like PEP8? [11:09] and I still feel there is a relative vagueness about how we handle the overall bzrlib namespace and I'm still not comfortable about that [11:09] yes; bzr builds its standards on pep8 [11:13] vila: I don't know quite what you mean there [11:13] as poolie commented, my intent was to *discuss* the policy and I expect to at least understand why people agree with it in certain cases but not others [11:13] vila: Well, do you understand why I don't agree with it *at all* ? [11:13] no [11:14] 'warning' for example, I never know which one we're calling [11:14] I think you're specifying something best left unspecified. [11:15] that won't help talk about it :) [11:15] names spaces are an important concept, how to use it is worth discussing no ? [11:16] vila: we already do. [11:16] 'from module import *' while allowed is not the best example of use [11:16] vila: we could a little more in terms of where we put htings. [11:17] vila: but you're not really talking about namespaces, more about scopes. [11:17] vila: I dunno, the rules you're proposing would drive me batty. [11:17] yes, name spaces are all about defining scopes to partition the global name space [11:18] lifeless: hehe, right, some aliasing related bugs indeed drove me nuts ;) [11:19] not to mention the spurious failures ending with illegal use of scope replacer... [11:20] lifeless: I realize the proposed rules put a small burden on the writer, but the write *knows* clearly when he use a symbol from which module it comes, and *this* information is not passed to the reader, I think that's the crux of my concern [11:21] vila: what concerns me is: [11:21] - the reduction in flexability [11:21] - the reduction in readability [11:21] - the reduction in performance [small but exists] [11:22] I don't understand how this reduce flexibility [11:22] ha ! Finally someone mentions the performance ;) [11:22] when you say 'do it X way', you exclude all 'non-X' ways [11:23] thats less flexible. [11:23] erm, i'm sorry to show my oar in, but could someone help me with a simple 'bzr init' ? [11:23] jean@klippie:~/tmp$ mkdir screnum ; cd screnum ; bzr init [11:23] bzr: ERROR: '/home/jean' is not a working copy [11:23] neaj: interesting [11:23] neaj: `which bzr` ? [11:24] looking in .bzr.log, the traceback dies on File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/format.py", line 196, in _open [11:24] neaj: oh [11:24] what's it messing about with svn for? [11:24] this is bzr on ubuntu 10.04 [11:24] you can do 'bzr --no-plugins init' to avoid that; please do file a bug on https://launchpad.net/bzr-svn [11:25] will do :-) [11:25] lifeless: well, one way or another you refer to a symbol. There are only two ways (excluding the ones we don't use and we don't use a lot of alias) [11:25] neaj: you have bzr-svn, the bzr svn integration layer installed. [11:25] hehe, that dies with bzr: ERROR: No repository present: "file:///home/jean/tmp/screnum/ [11:26] neaj: your previous failure left you with half-a-dir [11:26] yes, i want to make local branches of svn repos also [11:26] ah OK, i'll clean up and restart [11:26] vila: sure, but when you specify you're making a global assertion...globals are bad ;) [11:26] Created a standalone tree (format: 2a) <-- yay, thank you very much [11:26] neaj: my pleasure [11:28] lifeless: 'from module import symbol' is more global than 'module.symbol' at the module (the one doing the import ;) level [11:28] removing the authors choice is more global than that [11:28] so you need a very strong justification to do that. [11:29] lifeless: does it fly both ways ? Can *I* use module.symbol because I find it more readable ? [11:29] the rule you're suggesting is to disallow from module import symbol? [11:29] vila: I need to sleep; If its still going around tomorrow, I might ask you to argue my case, and see if that helps. [11:30] lifeless: ok [11:30] vila: If its clearer sure; mass patches forcing it one way or the other would just be noise and regarded as such, I think, reading martins comment ('flip flop..') [11:31] Glenjamin: yes, see https://code.edge.launchpad.net/~vila/bzr/imports/+merge/36324 comments welcome (whatever your opinion is of course) [11:31] I can see the justification, but knee-jerk is that its a bit restrictive [11:31] lifeless: sure [11:34] lifeless, Glenjamin : I thought I made this clear with: "Moving from the ``from import symbol`` style is a work in progress, submissions should avoid using it for new code but should not either includes huge cleanups that obscure the purpose of the proposal. When in doubt, use the ``.symbol`` without modifying the ``from import symbol`` part. [11:35] vila: you need consensus that it *is* a work in progress. [11:35] vila: that is sorely lacking. [11:35] * lifeless goes to bed. Gnight. [11:36] I;m unlikely to start doing any major hacking bzr, but my inclination would be that this is more guideline than rule territory. [11:37] Looks like it's a regression: https://bugs.launchpad.net/bzr-svn/+bug/182140 [11:37] Launchpad bug 182140 in Bazaar Subversion Plugin "bzr-svn interferes with bzr operation (affected: 1, heat: 10)" [Undecided,Fix released] [11:38] neaj, can you get the bzr and bzr-svn version from "bzr version" and "bzr plugins" [11:38] posted on the issue [11:39] if you try adding the bzr ppa, you can get newer versions of both. [11:39] which will probably let you use it, although not really fix the underlying problem [11:39] it was fixed on 0.4.9 but it's biting me on 1.0.2, so i don't think new-ness is the problem. [11:55] is it possible to bind a branch to two locations? [11:55] i'm using colo (which does lightweight checkouts), but I want the branches mirrored onto my central server [11:59] presumably a lightweight checkout of a bound branch doesn't propagate commits up [12:04] What is the scenario where I'd actually use bzr add --file-ids-from? [12:07] help provides an example, sounds pretty obscure [12:07] "This option is rarely needed but can be useful when adding the same logical file into two branches that will be merged later (without showing the two different adds as a conflict). It is also useful when merging another project into a subdirectory of this one." [12:10] It is obscure, I'm trying to find a more useful way to say that in order to fix #505086 [12:11] bug 505085 (making myself a link) [12:11] Launchpad bug 505085 in gnome-settings-daemon (Ubuntu) "gnome-settings-daemon extensive disk usage (affected: 11, heat: 62)" [Undecided,Confirmed] https://launchpad.net/bugs/505085 [12:11] No, bug 505086 [12:11] Launchpad bug 505086 in Bazaar "[doc] bzr add help mentions but doesn't explain file ids (affected: 1, heat: 0)" [Low,Confirmed] https://launchpad.net/bugs/505086 [12:11] oh, whoops [12:12] oh right, i see [12:13] something like --same-files-as=TREE [12:21] I need to sleep on it, I'll have another look at it in the morning. [12:28] what is the last number in a bzr file_id? [12:28] filename-timestamp-random-X [12:28] what's X? [12:29] looks like an incrementing number to me [12:30] Glenjamin: incrementing when? [12:30] at a guess, when the file changes. [12:30] knittl: technically, the whole fileid is an opaque string [12:30] and why? using those 16 byte randomness + timestamp make it pretty unique [12:31] Glenjamin: that would mean the file id changes all the time [12:31] maxb: yes, but that string has to be generated first [12:31] knittl: imagine committing 5 files called README.txt in the same commit [12:31] i was about to say that, looking at my inventory i have file_ids of an entirely different format [12:31] in different directories [12:32] it's probably just an enumerator per-commit then. [12:32] It's a guaranteed (within reasonable limits of probability) unique ID. [12:32] so start_bzr.bat in bzr.dev exists 9 times? [12:32] The exact way it is generated is unimportant for basically every use I can think of. [12:32] * maxb points to bzrlib.generate_ids.gen_file_id if you REALLY care [12:33] But you really shouldn't care [12:33] i do care, otherwise i wouldn't ask [12:33] It is implemented a) to meet that constraint, b) in a way that is reasonable performant and convenient to implement. [12:33] But design-wise the details don't matter. [12:33] maxb: ok, i.ll look at that function [12:33] knittl: why? [12:34] spiv: because i do. i'm not writing code to work with bzr file ids [12:34] for example, bzr-svn imported file_ids appear to be svn-revno@random:full_path [12:34] i simply need to know. is that so much to ask? [12:34] knittl: Not at all, but we want to make sure you don't mistakenly build semantics on top of something that has none [12:34] knittl: Well, it's just that it frankly sounds like a waste of your time [12:35] Glenjamin: s/random/svn-repository-uuid/ [12:35] yeah, i just got that :) [12:35] spiv: writing a thesis is not wasting my time [12:35] when i noticed they were all the same [12:35] knittl: ah! [12:35] knittl: what are you writing a thesis on, if you don't mind saying? [12:35] all week you've been asking obscure questions, you could have said why! [12:35] maxb: i don't … but i'm describing bzr's internals and defaults [12:35] spiv: dvcs [12:36] Glenjamin: well, the answers should be the same regardless of my reasons? [12:36] yes, but the willingness to provide answers is higher if the answerer understands the justification [12:36] … [12:36] nittl: Just DVCS in general? I wouldn't have thought the exact details of our default file-id generation in current versions of bzr aren't really very interesting for a thesis... [12:36] Also, the answerer can tailor the answer to the purpose being asked [12:37] But it's possible I'm missing some aspect of it that you find particularly interesting. [12:37] spiv: dvcs (bzr git hg), inner workings, storage model, object model, storage formats, performance [12:37] so it matters a lot how bzr generates ids [12:37] i'm intrigued as to what comparison metric you can apply to something like the file ids [12:38] Right: I'm saying these details aren't relevant to any of those things you just listed, unless "inner workings" encompasses arbitrary implementation details. [12:38] Glenjamin: nothing to compare with file ids, but it's good to know [12:38] Or at least, that I'd be surprised to find they are. [12:39] spiv: i simply do that, it's important for me and my paper. ok? [12:39] In terms of storage model, these are restrictions on what forms a valid ID (for files, and revisions). [12:39] s/these/there/ [12:39] knittl: if you haven't already seen it, http://video2010.scottishrubyconference.com/show_video/11/0 is an excellent presentation on git's workings [12:39] e.g. it's a valid UTF-8 string [12:40] Glenjamin: git and hg chapters have been finished a long time [12:40] It sounds to me like knittl is following the "Understand (almost) everything, then write about the interesting bits" approach [12:41] please don't tell me how to write _my_ paper [12:41] knittl: I don't mean to tell you how to write your paper [12:41] answer my questions that i have – and might sound weird to you – and everything will be fine [12:42] knittl: Easy there, we're just interested [12:42] knittl: I do hope I'm able to give you some guidance on what I, as one of the developers, consider to be the key design aspects vs. uninteresting implementation details, though. [12:42] maxb: the impression i have is different, i only get told what not to do with bzr and what is unimportant [12:43] knittl: which is not to say I'll be 100% right :) [12:43] i'm mostly interested in implementation details [12:43] knittl: also, you ought to be aware that you're the first person to be asking these questions for the sake of it. We're much more used to helping people *do* things with our tool and code [12:43] anyways. if the last number in a default file id is incrementing, why is it 9 for start_bzr.bat? [12:44] knittl: so naturally our reactions so far have been oriented towards that [12:44] spiv: i thought i was clear, everytime i asked something, that i'm interested in it, because i'm interested, and not because i want to build tools on top of bazaar or write extensions to it [12:44] knittl: When someone asks about details which are deliberately unspecified, there is a natural caution to make sure they are not attempting to interpret semantics that don't exist. Once you explain that your reasons, that caution is allayed. [12:45] ok [12:45] I'd expect it increments for every file added in a single 'bzr add' call (in the default implementation), because that is the simplest way to implement it to meet the constraints. [12:45] sounds better than the last weeks [12:45] knittl: so far everyone, even you, that has asked questions, has wanted to achieve *something*, not just asking to understand for the sake of it :) [12:46] knittl: I'm glad to know your goal, it will help me answer your questions better I think. [12:46] The design interesting bit about file-ids is simply: (something derived from file basename) + (something unique) [12:46] i want to achieve understanding [12:46] Actually, now I'm curious. Why do we put something derived from the file basename in there? [12:47] knittl: understanding in a specific context, though. [12:47] maxb: yes. filename in lowercase ascii, 20 chars, first period removed. timestamp in YYYYMMDDhhmmss. random 16 byte string. X [12:47] knittl: I can debate these semantics with your endlessly if you like, or you can trust me that I have much better idea of where your questions are coming from now. [12:47] knittl: just like you want us to trust you ;) [12:47] spiv: ok. bzr add file1 file2 file3. bzr commit will create: file1-time-random-1, file2-time-random-2, file3-time-random-3? [12:48] knittl: bzr add creates the file IDs, not commit. [12:48] knittl: probably. I don't care. Why do you? [12:48] spiv: ok. so bzr 'un-add' removes them again? or leaves them as stale ids? [12:48] maxb: I'd imagine because it's easy to grab, somewhat unique, and just-because-it's-opaque-doesn't-mean-it-can't-look-good. [12:49] knittl: How to put this? If they're never committed, then they're never committed. [12:49] spiv: yes, but they are created on add (at least the string) [12:49] fullermd: A debugging aid. That makes sense. I vaguely recall something about it helping sort like content into groupcompress blocks also? [12:49] knittl: and recorded in the working tree metadata [12:50] ok [12:50] Just like renames via 'bzr mv', or merge revisions from 'bzr merge', etc. [12:51] yeah. dirstate (same name as hg) [12:51] i'll write and come back [12:51] i hope you remember the reason for my questions :D [12:51] maxb: actually, IIRC the file-id being based on basename only isn't especially good for groupcompress, or something like that. [12:51] knittl: don't worry, you've been quite memorable :) [12:52] spiv: haha. [12:52] Happy writing! [12:52] spiv: on an unrelated note, what about my cat-signature branch? [12:52] still no tests [12:52] knittl: is there a merge proposal or bug for it? [12:53] couldn't wrapp my mind about it, because i need to access bzr.dev to have something to test regressing against [12:53] knittl: it seems like a reasonable addition (as a hidden command) [12:53] knittl: ah, no [12:53] the justification in the docstring for gen_file_id seems to be based on the assumption that the file_id will be used in the filesystem [12:53] no bug, and no proposal yet [12:53] knittl: tests shouldn't assume that bzr.dev exists, it's perfectly possible to create the test data you need in the test [12:54] Glenjamin: They were, in knit and earlier formats, where each file had its own [set of] file[s] in the repo. [12:54] spiv: well, the test would need to create a new revision, sign that revision (with a key which is then stored within the test), then cat it, then verify it [12:54] makes sense [12:54] knittl: that's more than necessary [12:55] knittl: you just need a test that shows cat-revision outputs the signature content for the specified revision [12:55] knittl: there's no need for the test to generate that signature on the fly first, it can be pre-canned [12:55] spiv: yes. but to get the contents i'm just calling my code [12:55] or what do you mean? [12:55] I'm sure the existing tests for signatures should already have examples [12:56] couldn't find any signature tests, maybe i was looking in the wrong places [12:56] you only need to prove that if you store some text as a signature, that cat-signature outputs it [12:56] knittl: I mean: use the bzrlib APIs to create a precise signature record in the database [12:56] knittl: and then assert that cat-signature emits exact output (with that content) [12:57] You don't need to generate the signature during the test execution, it can be a literal, predefined string in the test code. [12:57] Consider what you are trying to test: [12:57] hm, i'll look. brb [12:57] * not that bzr can generate signatures [12:57] * not that bzr can generate revisions [12:58] * but that cat-signature will retrieve and display whatever content it finds for a revision [12:59] (we do of course want those other things to be tested, but that's the job of other, already written, parts of the test suite) [13:00] (overly broad tests obscure intent and make tests slower than necessary, among other drawbacks) [13:01] * spiv -> zzz [13:06] what do the cool kids use for bzr / emacs integration these days? [13:13] how can i run a bzr command inside a test? [13:13] jml: I use a shell :-) [13:15] That doesn't count. [13:15] Bah [13:15] Although I'm sure you are one cool kid, that's not integration. [13:15] * Kinnison treats his entire desktop environment as the integration layer :-) [13:15] At least not for my purposes. [13:19] knittl: http://doc.bazaar.canonical.com/latest/developers/testing.html [13:19] spiv: go to bed :P [13:20] is there a standard way of selectively committing chunks from a file? [13:22] interactive shelve to first remove what you don't want to commit [13:22] there ought to be an interactive commit option though [13:22] particularly since there's an interactive merge [13:24] maxb: thanks! [13:25] Somebody wrote a 'record' plugin once that did that I think. Dunno if it really worked, or still does. [13:26] it ought to be in bzr if shelf is. [13:30] The term 'record' is woefully overused [13:30] I wish loom called its command record-loom at least [13:31] I imagine it was chosen to call out to 'darcs record' [13:31] (since that does the same interactive type stuff) [13:31] "bzr commit -i". There, I've solved the naming problem. === Ursinha-afk is now known as Ursinha [14:06] can someone help me write that blackbox test? [14:06] please :) [15:07] morning all [15:07] knittl: what test? [15:07] hi jam [15:07] tests for cat-signature [15:08] i can create one for cat-signature -r0 easily (no output xD) [15:08] is it useful for me to say i think it should be called show-signature ? [15:08] knittl: you can look for bzrlib/tests/blackbox/test_cat.py and copy that file to test_cat_signature.py [15:08] Glenjamin: hahaha [15:08] jam: i believe i copied cat_revision [15:09] knittl: same thing, sounds fine [15:09] do you have the code somewhere you want me to look at? [15:09] basically it would be something like: [15:09] just a sec [15:09] Glenjamin: https://code.launchpad.net/~knittl/bzr/cat-signature look at the history (r5432 and r5433) [15:09] jam: well, i need a signature to validate against [15:09] there would be two ways to do it, IMO, one is to use the "run_script" method [15:09] i think jam told me to name it "cat-signature" :] [15:09] knittl: you need a signature, but it doesn't have to be valid or gpg signed :) [15:10] knittl: you'll need to track down the commit code which signs, and see how it adds the signature to the revision [15:10] my best name would be print-signature, because it prints to the terminal [15:10] and just do the last bit [15:10]