| thumper | how do I cat a file at a particular date in history | 00:20 |
|---|---|---|
| thumper | where that file may not be in the branch now | 00:21 |
| lifeless | bzr cat -r revspec filepath | 00:26 |
| lifeless | you can use bzr ls -r revspec to find files present there | 00:27 |
| lifeless | thumper: ^ | 00:28 |
| thumper | lifeless: thanks, I kinda figured that out on my own :) | 00:29 |
| spiv | Good morning. | 00:57 |
| poolie | thumper: cat -rdate:2010-01-01 file | 01:11 |
| poolie | i think so? | 01:11 |
| thumper | poolie: yeah, thansk got that | 01:11 |
| poolie | sorry, i didn't see the scrollback | 01:11 |
| poolie | thumper: export -r REV FILENAME may do it? | 01:12 |
| thumper | I just used cat | 01:12 |
| thumper | and ls to find the name of the file | 01:12 |
| thumper | that had been remvoed | 01:12 |
| meoblast001 | hi | 02:06 |
| meoblast001 | i'm having a problem | 02:06 |
| meoblast001 | i'm trying to get the contents of a file named src/renderer.cpp at revision 30 | 02:07 |
| meoblast001 | wait, hm, i think i just figured it out | 02:07 |
| meoblast001 | ah, nevermind, guess i was doing it right | 02:07 |
| rubbs | meoblast001: if you still need help I'm here. | 02:11 |
| meoblast001 | ah, i had the file name wrong :P | 02:11 |
| meoblast001 | it was crenderer.cpp | 02:11 |
| meoblast001 | bzr cat src/crenderer.cpp -r30 | 02:12 |
| rubbs | cool :D | 02:12 |
| poolie | lifeless: when you say "a rewrite rule for squid" | 02:24 |
| poolie | this is a rule that says when squid gets request X, it should actually serve and cache the URL f(X)? | 02:24 |
| lifeless | yes | 02:26 |
| lifeless | this can take two forms | 02:26 |
| lifeless | squid can return a 30x to the client, so the client makes a new request | 02:27 |
| lifeless | squid can make the new request itself, and returns the result of that request | 02:27 |
| lifeless | its the latter form I'm suggesting | 02:27 |
| poolie | how will squid know which revid to request? | 02:28 |
| lifeless | we'd write a small redirectory | 02:28 |
| lifeless | s/y// | 02:28 |
| lifeless | which would take urls in, and do the work to decide what url should be used instead | 02:29 |
| poolie | ok, so this would be a subprocess of squid that knows how to interpret bzr branches? | 02:29 |
| lifeless | yes | 02:30 |
| lifeless | squid would run a few of them up | 02:30 |
| poolie | hm | 02:30 |
| poolie | why not just use an etag to let loggerhead verify the revno page still shows what squid has got cached? | 02:30 |
| lifeless | because revno pages are less stable, by being revid keyed we can cache the output of diff/status etc operations for weeks or months with low risk | 02:31 |
| lifeless | we may well use an etag *too* | 02:31 |
| lifeless | but thats for a different problem | 02:31 |
| poolie | hm | 02:32 |
| poolie | this seems a bit duplicative | 02:32 |
| poolie | between the redirect helper and what loggerhead does | 02:32 |
| poolie | i think there is probably simpler fruit first | 02:32 |
| poolie | such as just getting a squid at all :) | 02:33 |
| lifeless | there is overlap | 02:35 |
| lifeless | the benefit is that once a revno->revid mapping is established, no further hits will reach loggerhead for that revno for [mapping cache time] | 02:36 |
| lifeless | and further, mapping and rendering are decoupled, so that we don't have expensive rendering logic happening much either | 02:37 |
| poolie | hm | 02:42 |
| poolie | if there's a cache time on this, isn't it just equivalent to saying that revno urls are simply cacheable for that period? | 02:42 |
| poolie | well, i guess in the case where it misses we'd be doing a lookup in the branch to see if the mapping is still true | 02:43 |
| lifeless | right | 02:43 |
| lifeless | and the cache time is in squid | 02:43 |
| lifeless | we can invalidate it by an api call when the branch has a revno change | 02:43 |
| lifeless | [in principle; that might not be as no-brainer as the basic stuff] | 02:43 |
| poolie | oh there's an external api to squid to say "drop X"? | 02:44 |
| lifeless | eys | 02:44 |
| poolie | ok | 02:44 |
| lifeless | several | 02:44 |
| poolie | i guess you need to determine all possible affected urls | 02:44 |
| lifeless | but possibly not for the particular mapping we're talking about | 02:44 |
| lifeless | theres also a lightweight 'is this still valid' api using a helper and rss stuff that yahoo built | 02:45 |
| lifeless | I don't know if we've integrated that upstream properly yet. | 02:45 |
| lifeless | the takeaway though is - some infrastructure in squid, policy in bzr, win. | 02:45 |
| lifeless | :P | 02:45 |
| lifeless | I'll reach st leonards on the 1:05 trani | 02:45 |
| poolie | hm | 02:46 |
| poolie | can you defer that | 02:46 |
| poolie | i need to do some errands for stephane before i leave | 02:46 |
| lifeless | the train? sure. or I can hack-in-sunshine if the deferral is minor. | 02:46 |
| lifeless | I'm coming from mount colah, so outside the high frequency train zone | 02:46 |
| lifeless | ok -> train | 03:13 |
| poolie | nice mail there | 03:21 |
| poolie | hi spiv? | 03:57 |
| spiv | Hi poolie. | 04:46 |
| parthm | I am thinking of landing the approved mp https://code.launchpad.net/~jbowtie/bzr/fix-515660/+merge/24290 using ./feed-pqm | 05:42 |
| parthm | is there anything i need to consider or is it simply a matter of running the ./feed-pqm command? | 05:43 |
| * parthm hasn't done this before. | 05:43 | |
| spiv | parthm: are you asking about how to use feed-pqm, or about our policies about what proposals are ready to land? | 05:47 |
| parthm | spiv: more about how to use feed-pqm. I am assuming that the proposals that show us as "ready to land" should be ok to land. | 05:48 |
| spiv | Yeah, they should be, although some may need conflicts resolved. | 05:49 |
| spiv | As far as using feed-pqm goes, run "./feed-pqm bzr" | 05:49 |
| parthm | spiv: so the suggested method is that i try the merge manually on my system before submit? | 05:49 |
| spiv | You can enter ? at the prompt to get help on the options | 05:50 |
| parthm | spiv: sounds good. | 05:50 |
| spiv | parthm: no, in fact if you look at the LP page for the proposal it'll mention if there are conflicts, and PQM will obviously fail to land conflicts anyway. | 05:51 |
| parthm | spiv: one more question. whats the policy in moving reviewed mps to "ready to land". 2+ approves? | 05:51 |
| spiv | So it's typically not worth the effort to do it locally. | 05:51 |
| parthm | spiv: ok. that sounds easy enough. i will give it a shot with the documentation proposals. | 05:52 |
| spiv | parthm: http://doc.bazaar.canonical.com/bzr.dev/developers/HACKING.html#the-code-review-process | 05:52 |
| spiv | "ormally changes by core contributors are reviewed by one other core developer, and changes from other people are reviewed by two core developers. Use intelligent discretion if the patch is trivial." | 05:53 |
| spiv | In case you're not already aware of it, you can see the PQM queue (and status of the current job) at http://pqm.bazaar-vcs.org/ | 05:54 |
| parthm | spiv: just curious. does the queue run tests on win, linunx and mac? or is it linux only? | 05:55 |
| spiv | Just on linux (with Python 2.4). vila has something that runs tests on some other platforms after landing, I don't have a URL for that handy though. | 05:57 |
| parthm | spiv: thanks for your help. i will try feed-pqm now. | 06:01 |
| lifeless | jelmer: is bug 551362 fixed ? | 06:51 |
| ubottu | Launchpad bug 551362 in bzr-builddeb "support upstream/VERSION tags" [Medium,Triaged] https://launchpad.net/bugs/551362 | 06:51 |
| lifeless | hey | 07:25 |
| lifeless | spiv: ping | 07:25 |
| lifeless | mtaylor: you might like https://code.edge.launchpad.net/~lifeless/bzr-builddeb/trunk/+merge/24578 too | 07:54 |
| lifeless | mtaylor: as I recall you struggling with pristine-tar transitions | 07:55 |
| mtaylor | lifeless: sweet | 07:56 |
| mtaylor | lifeless: I'm maintaining all of my packages using that process now, btw | 07:56 |
| lifeless | mtaylor: cool | 07:56 |
| lifeless | mtaylor: you should be able to just merge-upstream now; but if you find an old branch youhaven't fixed up yet - that should be much easier for you | 07:56 |
| mtaylor | sweet | 07:57 |
| mtaylor | lifeless: hey, you know things... any ideas on how I might actually sensibly use launchpadlib via jython in hudson? | 07:57 |
| mtaylor | lifeless: I poked at it some today and did not get very far | 07:58 |
| lifeless | mtaylor: offhand it should be compatible with jython; did the basics work ? | 07:58 |
| lifeless | mtaylor: if they didn't (just doing a repl loop in netbeans or whatever) - file a bug | 07:59 |
| mtaylor | lifeless: well, getting it going just basically was very hard | 07:59 |
| mtaylor | lifeless: lucid ships python2.6 and doesn't have a 2.5 package anymore | 07:59 |
| mtaylor | lifeless: also, lucid ships very old jython | 07:59 |
| mtaylor | I installed recent (2.5) jython from python.org, but it does not understand .pth files or any of the places debian puts python files | 08:00 |
| mtaylor | so really it's just one big giant mess | 08:00 |
| lifeless | file a bug | 08:00 |
| lifeless | its probably the mother of all bad ideas, setuptools, all over again. | 08:01 |
| mtaylor | I started trying to build a pythonpath so that jython could find everything, but then I got eaten by the fact that python system libs were 2.6, which meant jython couldn't read the site.py | 08:01 |
| mtaylor | yup | 08:01 |
| mtaylor | very much setuptools, combined with python-support let's add 7 more search directories | 08:01 |
| mtaylor | my next thought was building a virtualenv and installing stuff into that, which I'm doing on a different machine :( | 08:01 |
| lifeless | mtaylor: also #launchpad-dev | 08:03 |
| lifeless | spiv: https://bugs.edge.launchpad.net/bzr/+bug/574236 - sorry for the delay; yak shaved by filing a bug on malone ;) | 08:06 |
| ubottu | Launchpad bug 574236 in bzr "repository.refresh_data() cannot be called in a write group" [Wishlist,Confirmed] | 08:07 |
| spiv | lifeless: heh :) | 08:07 |
| poolie | hi there spiv | 08:14 |
| vila | hi all ! | 08:17 |
| * vila crosses fingers after the repeated crashes in the last hours | 08:18 | |
| lifeless | hai | 08:19 |
| * vila blesses its mail client for its autosave feature :-/ | 08:20 | |
| lifeless | vila: s/its/his/ | 08:20 |
| vila | grr, lifeless: thanks :) | 08:21 |
| lifeless | vila: its is for non gendered things ;) | 08:21 |
| vila | lifeless: I blame the crashes that directly attacked my sanity :) | 08:21 |
| parthm | hello. i am trying to feed-pqm proposal https://code.launchpad.net/~jbowtie/bzr/fix-515660/+merge/24290 | 08:24 |
| parthm | it doesn't seem to be working. this is what i did. http://pastebin.com/pG7K4amn | 08:25 |
| parthm | it doesn't show up in the queue and i didn't see any mails. should i be doing something differently? | 08:25 |
| spiv | parthm: that looks ok to me. PQM ought to send you a mail if it has rejected your request for some reason. | 08:26 |
| lifeless | parthm: you're not authorised to send via PQM email, are you ? | 08:26 |
| parthm | lifeless: i am not sure. i am just using feed-pqm. | 08:27 |
| lifeless | parthm: if you haven't given your GPG key to the losas to install on balleny, you can't submit things to land. | 08:27 |
| lifeless | parthm: this is something that the API based feed-bzr fixed, but we're disabling that. | 08:27 |
| poolie | i think i did add his key previously | 08:28 |
| poolie | perhaps not | 08:28 |
| spiv | Either way, PQM ought to send a reply saying what happened. | 08:28 |
| * spiv takes the opportunity to tweak the commit message on that merge proposal ;) | 08:28 | |
| poolie | according to my mail, that key is authorized to commit | 08:29 |
| lifeless | oh, ok | 08:29 |
| lifeless | parthm: have you configured outbound email on your machine ? | 08:29 |
| lifeless | is it perhaps stuck in a mail queue ? | 08:29 |
| parthm | i tried it earlier today but nothing happened. so i tried it again right now (after doing an "approve" of mp just in case). | 08:29 |
| lifeless | I don't see anything from the pqm cron server | 08:29 |
| parthm | lifeless: i don't remember explicitly configuring outbound email. let me see. | 08:30 |
| parthm | spiv: :) | 08:30 |
| parthm | lifeless: outgoing mail isn't configured on my system. would that cause a problem? | 08:36 |
| lifeless | feed-pqm is trying to send an email | 08:37 |
| lifeless | I'm surprised you're not gettnig an exception | 08:37 |
| parthm | lifeless: i will try to configure exim and try again. | 08:38 |
| lifeless | parthm: you can just configure your normal SMTP server using bazaar.conf | 08:39 |
| lifeless | parthm: see bzr help configuration | 08:39 |
| poolie | iow you can ask bzr to send direct to your company's or isp's smtp server | 08:42 |
| parthm | the patch seems to have gone to the queue http://pqm.bazaar-vcs.org/ but i haven't seen the mail yet. it will probably come. :) | 08:57 |
| * parthm just configured thunderbird as the default mail client. | 08:57 | |
| parthm | spiv, lifeless, poolie: thanks for your help. | 08:58 |
| lifeless | ok, EOD for me | 08:59 |
| poolie | parthm: ok, it's running, you should get mail when it either succeeds or fails | 09:01 |
| parthm | poolie: great. thanks. | 09:03 |
| jelmer | lifeless: hi | 09:09 |
| jelmer | lifeless: bug 551362 is fixed in bzr-builddbe trunk | 09:10 |
| ubottu | Launchpad bug 551362 in bzr-builddeb "support upstream/VERSION tags" [Medium,Triaged] https://launchpad.net/bugs/551362 | 09:10 |
| MvG | Hi! Wrt https://code.launchpad.net/~gagern/bzr/bug527878-directoryCommonOption/+merge/23970 I'm looking for a suitable name for a function that does Branch.open if --directory is given, BzrDir.open_containing_tree_or_branch otherwise. Preferrably not too long. Opinions? | 09:20 |
| bialix | heya | 09:21 |
| MvG | vila suggested "_open_containing_tree_or_branch_for_directory" but to me that implies that --directory would find containing bas well, which is not what I implemented, so I'm looking for better alternatives. Listed a few in a comment on that merge request. | 09:21 |
| MvG | hi bialix! | 09:23 |
| bialix | MvG: hi | 09:23 |
| bialix | MvG: I have a strange problem with my machine where trac and trac-bzr hosted | 09:24 |
| bialix | MvG: it could be unrelated to trac-bzr of course, I just don't know how to track it | 09:24 |
| bialix | every week I'm packing entire trac repo for archive reasons | 09:24 |
| bialix | last weeks every time I do this I'm get disk error from inside branch metadata (often branch.conf) | 09:25 |
| bialix | scandisk helps in those cases and fix the problem | 09:25 |
| MvG | disk error? Sounds very hardware-ish. | 09:25 |
| bialix | but I'm a bit worried of this | 09:26 |
| bialix | not really disk error | 09:26 |
| bialix | windows can't read the file, and then scandisk reports about fixing incorrect index entries (this is NTFS disk) | 09:26 |
| MvG | Only thing I can imagine would be kept locks or similar. | 09:26 |
| bialix | the disk itself is brand new, the other hardware is not | 09:27 |
| bialix | MvG: is there any dangling branch references left inside trac-bzr when doing timeline with repository checkins? | 09:28 |
| MvG | trac-bzr should perform read-only access to branch.conf at the most, I'd say. | 09:28 |
| bialix | so it could be bzr server, oh well | 09:28 |
| bialix | strange thing -- the errors often arised in the non-active branches | 09:28 |
| bialix | that's why I'm not sure it's bzr serve | 09:29 |
| MvG | bialix: You could enable the memory leak detection code in trac, see if that has anything to say about dangling references. | 09:29 |
| bialix | how? | 09:29 |
| MvG | bialix: http://trac.edgewall.org/browser/branches/0.11-stable/trac/web/main.py#L425 | 09:30 |
| bialix | 0.11 only? | 09:31 |
| MvG | bialix: Dunno, guess newer ones should have it as well. | 09:31 |
| poolie | MvG: open_directory_dwim? | 09:31 |
| poolie | open_dash_d? | 09:31 |
| bialix | MvG: thanks, I'll try to use it and see what it say | 09:32 |
| MvG | poolie: Maybe. Problem is that there are other similar open thingies that require working trees. | 09:32 |
| MvG | poolie: And that it does open even in cases where --directory wasn't given at all, in which cases it takes the argument into account. | 09:33 |
| MvG | vila: Currently discussing function name alternatives for https://code.launchpad.net/~gagern/bzr/bug527878-directoryCommonOption/+merge/23970 as I'm not perfectly happy with your suggestion. | 09:34 |
| MvG | poolie: So maybe open_branch_dash_d? | 09:35 |
| poolie | it's not great, just an idea | 09:35 |
| MvG | I tried _open_directory_or_containing_tree_or_branch and found that in that case I can keep to 80 cols with a single escaped line break. Anything lonmger maks the code really really ugly. | 09:36 |
| vila | MvG: (hoping to avoid crashes), from your names I think I'd prefer (2) (sorry I'm still recovering from crash and I don't remember it more precisely) | 09:45 |
| vila | MvG: But, I wonder if the issue is not a deeper one, | 09:46 |
| MAfifi | Is there a way to list the branches in a bazaar repository? | 09:46 |
| MvG | vila: I think I'm in favour of (2) as well. Thx. will push that and set state to needs-review. | 09:46 |
| vila | roughly, we don't *require* the directory because we deduce it from the path and to achieve --dir support we may want to change that, | 09:46 |
| vila | i.e. if the user tell us: here is my branch root, don't guess | 09:47 |
| vila | then instead of *adding* a new funtion/method, you may want to inspect the existing open_containing_* ones and see if you could address that at this lower level | 09:47 |
| vila | this would also means *less* tests since once you're happy with the tests in the open_containing_* methods, there is little point in testing all their call sites | 09:48 |
| vila | MvG: does that make sense ? | 09:49 |
| MvG | Doesn't feel right: the semantics here, with the --directory option, are specific to command line interface, while the underlying open methods are generic bzrlib, and clobbering them with command line special cases feels bad. So I'd prefer a function in builtins.py. | 09:49 |
| MvG | And there is still the chance of commands doing funky things with their arguments besides opening a branch, as I experienced in the case of the added builtin. | 09:50 |
| MvG | So the tests do make kind of sense, I fear. | 09:51 |
| vila | well, the tendency should be to *reduce* the specifics in builtins.py since that smells like lack of feature in bzrlib | 09:51 |
| MvG | vila: On the other hand, providing several different ways to achieve a goal is probably a good thing for a command line interface, where you want to support anything that users might naturally expect to work. For the API that kind of redundnancy would be bad design, I'd say. | 09:53 |
| vila | yes, some commands may do fancy things, I view your work on the --directory option as the perfect occasion to unify our behavior here (but that doesn't mean you have to address all of them in your proposal) | 09:53 |
| vila | MvG: Well, having an optional directory short-circuiting the branch root guess is not *that* bad, there are just different ways to find it | 09:54 |
| vila | there are other part of the API that already do that kind of thing | 09:54 |
| MvG | vila: OK, if you want it in the BzrDir.open_containing_tree_or_branch method, I can put it there. But in that case I guess I'd name it branch_location or similar, as the --directory option from the command line isn't exactly fitting, since remote URLs work just as well. | 09:55 |
| vila | my feeling is that there are already too many open_containing_tree_or_branch_or_repo_or_whatever variations that may be simplified there | 09:56 |
| vila | MvG: I don't have a strong feeling there, I'm thinking out loud (especially with the crashes I'm experimenting this morning, I haven't yet look at the code again) | 09:56 |
| MvG | OK. Maybe we should land my branch first, and see about unifying stuff afterwards. | 09:57 |
| vila | MvG: exactly what I was about to say | 09:57 |
| MvG | The method I introduced starts with an _, so it should be easy to drop it without a compatibility stub when we have a better solution. | 09:58 |
| MvG | s/method/function/ | 09:58 |
| * vila shudders with ease, yeah, leading '_' are *good* | 09:58 | |
| vila | it's far easier to drop one than to add one | 09:58 |
| MvG | vila: OK, I pushed a function rename and a NEWS item, and would like to see the thing merged soon. I assume you'll want to recover from your crash first. And it seems LP is taking some time to update stuff today as well. | 10:12 |
| vila | MvG: I'm reviewing right now | 10:13 |
| vila | MvG: out of curiosity, are you using jam's update_copyright plugin ? | 10:20 |
| MvG | vila: no, did that manually. | 10:20 |
| vila | MvG: ok, you may want to give it a try then :) | 10:20 |
| MvG | LP is taking really long today to update branches... :-( | 10:31 |
| poolie | hm, you could tell them | 10:31 |
| poolie | they changed something that's supposed to eliminated delays | 10:32 |
| poolie | there may be some fallout | 10:32 |
| MvG | poolie: OK, mentioned it in #launchpad. | 10:34 |
| vila | MvG: hmm, "the --directory option from the command line isn't exactly fitting, since remote URLs work just as well." | 10:34 |
| MvG | vila: Agreed. Do you think it should be renamed to --branch in these cases? | 10:35 |
| MvG | vila: In bug #559998 poolie suggested reuse of the --directory option. | 10:36 |
| ubottu | Launchpad bug 559998 in bzr "bzr cat should accept --directory" [Low,Confirmed] https://launchpad.net/bugs/559998 | 10:36 |
| vila | MvG: I think we had this kind of discussion in the past and 'location' has been used instead... | 10:36 |
| vila | but... | 10:36 |
| vila | sometimes it's used for tree so branch doesn't fit either, directory may be the best after all | 10:37 |
| vila | and '-d' also has an history in other tools so... | 10:38 |
| vila | --base c oming :( | 10:38 |
| MvG | vila: So we keep --directory/-d for now, knowing that it is somewhat inaccurate? | 10:46 |
| MvG | vila: Or do we introduce a location option, which has directory as an alias, and still uses -d for compatibility? | 10:47 |
| MvG | vila: except that Option doesn't allow for aliases... | 10:48 |
| * MvG just notices that vila has left the room... :-( | 10:50 | |
| vila | grr, add one more crash | 10:57 |
| vila | MvG: so --base may be considered, but --directory still sounds like the best choice | 10:57 |
| MvG | vila: I had addressed some lines to you while you were away. I'll repeat them below: | 10:59 |
| MvG | vila: So we keep --directory/-d for now, knowing that it is somewhat inaccurate? | 10:59 |
| MvG | vila: Or do we introduce a --location option, which has --directory as an alias, and still uses -d for compatibility? | 10:59 |
| MvG | vila: except that Option doesn't allow for aliases... | 10:59 |
| vila | MvG: my main hesitation comes from the compatibility issue, if we start with --directory we have to stick to that, | 11:01 |
| lifeless | jelmer: then the status needs updating ;) | 11:01 |
| MvG | vila: Yes, that has me somewhat worried as well. | 11:01 |
| vila | having aliases just because we're not sure about the best name is asking for trouble down the road and just exposes our doubts. | 11:01 |
| vila | Let me check where we use location | 11:02 |
| MvG | vila: afaik only for args, not as an option... | 11:02 |
| vila | MvG: and for config vars | 11:03 |
| vila | I think the rationale there was because directory sounds like a local thing as opposed to a remote thing | 11:03 |
| MvG | vila: There is a global --basis option registered, but it seems no command actually uses it. | 11:03 |
| vila | --basis is for merge purposes AFAIK | 11:03 |
| vila | MvG: So, I think --directory is fine, we may want to explain whether it applies to branch or tree for some commands but that should be all there is to it | 11:06 |
| * vila blesses *his* mail client again, the review is not lost | 11:07 | |
| MvG | vila: One problem is that one globally registered option has one global help string to go with it. | 11:07 |
| vila | MvG: the command help itself then ? | 11:07 |
| vila | MvG: *in* the command help itself then ? | 11:07 |
| MvG | vila: So if we had --base (-d) alongside --directory (-d), we could simply use different documentation for these as well, which is much more problematic with a single option. | 11:07 |
| vila | nah, forget --base, it's as abstract as --directory but without history | 11:08 |
| vila | MvG: Anyway, this is targeted at people who want to be explicit, it's not as if they didn't know what there are talking about | 11:09 |
| MvG | vila: One could use custom_help for individual commands, but that would introduce quite a lot of redundancy. | 11:09 |
| MvG | That's what http://bazaar.launchpad.net/~gagern/bzr/bug527878-directoryCommonOption/revision/5172 does to preserve current trunk behaviour. | 11:10 |
| MvG | vila: One good argument for using --directory in all cases is that there might be cases where we require a working tree now but find a sensible application to remote branches in the future. | 11:11 |
| vila | I'm sure we can find a way to describe the option intent around: paths given to command either deduce the branch/tree they are in or respect the --directory option | 11:12 |
| vila | and in that case are relative to it | 11:12 |
| vila | blah, in correct english :) | 11:13 |
| MvG | Where would you put that help description? | 11:13 |
| * vila reading revno 5172 | 11:13 | |
| MvG | And it doesn't help users figure if remote branches are allowed for a given command or not. | 11:13 |
| vila | MvG: I find revno 5172 very good, there may be a bit of duplication but I really don't care at that point, I don't have problems with duplication in doc, as long as it's kept consistant | 11:16 |
| vila | MvG: I.e. custom_help looks like the perfect solution | 11:17 |
| vila | so forget my remark about the generic definition or maybe just add a comment before the 'directory' definition in bzrlib.option explaining how it's intended to be customized | 11:18 |
| MvG | OK. Then we might fine-tune the documentation in the future to convey more information as to where branches are acceptable. | 11:19 |
| vila | MvG: yes. Keep in mind to check for cases where *two* --directory options may be needed (hopefully none) | 11:19 |
| === davidstrauss_ is now known as davidstrauss | ||
| vila | MvG: 'bzr diff' comes to mind but we already have --old --new there | 11:20 |
| vila | MvG: Approval sent, I'm ok with the actual submission (settling on --directory) most of the discussion above is for further work (and thanks again for working in on that ;) | 11:21 |
| MvG | vila: thx for the review! | 11:22 |
| vila | MvG: Will have a look to the bash completion one now | 11:22 |
| MvG | Great! | 11:22 |
| * MvG has got to go | 11:25 | |
| MvG | vila: in case there are questions about the bash completion merge request, please comment on the merge, and I'll deal with it in about two hours hopefully. | 11:25 |
| vila | MvG: sure, near lunch time here anyway | 11:26 |
| MvG | I guess we're the same time zone. :-) | 11:26 |
| parthm | lifeless: looking at the trunk looks like the merge went through. however i noticed that https://code.launchpad.net/~jbowtie/bzr/fix-515660/+merge/24290 still shows status as "approved". | 11:29 |
| vila | MvG: 12:30 here | 11:30 |
| parthm | lifeless: i also got an empty message from pqm with the subject "no valid commands given". | 11:30 |
| lifeless | parthm: thats a bug; the approved thing will depend on lp noticing | 11:44 |
| parthm | lifeless: so will it eventually turn to "merged"? just a matter of time? | 11:45 |
| lifeless | parthm: yes, a few days :) | 11:48 |
| lifeless | parthm: lp is busy right now dealing with maverick | 11:48 |
| === Viper7 is now known as Viper-7 | ||
| parthm | lifeless: cool :) ... whats maverick? | 11:49 |
| lifeless | the thing after lucid :) | 11:49 |
| thumper | parthm: after lucid | 11:50 |
| parthm | thumper: aah :) ... i just upgraded to lucid a few days back. look forward to it. thanks. | 11:50 |
| === oubiwann is now known as oubiwann_ | ||
| rodrigo_ | hi | 13:14 |
| rodrigo_ | I'm getting this message: | 13:14 |
| rodrigo_ | bzr: ERROR: KnitPackRepository('lp-67245712:///~vcs-imports/couchdb-glib/trunk/.bzr/repository') | 13:14 |
| rodrigo_ | is not compatible with | 13:14 |
| rodrigo_ | CHKInventoryRepository('lp-67245712:///~rodrigo-moya/couchdb-glib/optional-introspection/.bzr/repository') | 13:14 |
| rodrigo_ | different serializers | 13:14 |
| rodrigo_ | whenever I push a branch branched from a vcs import | 13:14 |
| rodrigo_ | bzr push again works, but it seems it pushes the whole branch, it takes much more time than when pushing other branches where I don't get those errors | 13:15 |
| maxb | Ugh, yes, this is known and annoying | 13:15 |
| rodrigo_ | maxb, any solution? | 13:16 |
| maxb | You can't stack a 2a format branch on a 1.x format branch, which is what's trying to happen here | 13:16 |
| === oubiwann_ is now known as oubiwann | ||
| rodrigo_ | ah, the vcs-import is 1.x, I guess? | 13:16 |
| maxb | Unfortunately, since bzr 2.x defaults to using 2a, the workflow of "bzr init-repo; bzr branch" tends to lead people to unwittingly create their local branches in 2a format even when the remote trunk is 1.x | 13:17 |
| rodrigo_ | maxb, so, maybe I should get the vcs-import to move to 2a? is that possible? and how is it done? | 13:17 |
| maxb | Ideally, yes, except that would break any existing branches stacked on it | 13:18 |
| rodrigo_ | you mean branches in active status? or all the previous branches that have already been merged? | 13:19 |
| maxb | all of them | 13:20 |
| maxb | Anyway, the solution for the moment is to not use 2a format for this project | 13:21 |
| maxb | As for the migration, you should probably ask on #launchpad about this problem during UK working hours, or file a Launchpad question | 13:21 |
| rodrigo_ | ok, not a big problem though, so I guess I can keep pushing twice for no | 13:26 |
| rodrigo_ | w | 13:26 |
| rodrigo_ | maxb, another question, about bzr-git | 13:26 |
| rodrigo_ | do you know anything about it? | 13:26 |
| Tiibiidii | hi, can someone help me? i'm trying to push to the same repository with 2 different users | 15:28 |
| Tiibiidii | but one of the 2 constantly keeps creating files | 15:28 |
| Tiibiidii | with its own permission | 15:29 |
| Tiibiidii | (thus making the repository unusable for the other) | 15:29 |
| Tiibiidii | (one of the culript files is .bzr/repository/pack-names ... but it isn't the only one) | 15:29 |
| Tiibiidii | (i've already tried googling the problem to no avail) | 15:30 |
| Tiibiidii | (in fact i've found that in this page: http://wiki.bazaar.canonical.com/SharedRepositoryTutorial it says that " When Bazaar writes to control files, it tries to make their permissions consistent with existing files." so this shouldn't be happening ) | 15:31 |
| Tiibiidii | (currently i don't have a shared repository... i'm using a normal repository and first tried with a lightweight checkout... thought that this may be the cause of the problem... then tried with a full branch...) | 15:32 |
| Tiibiidii | (but by pushing from the branch the problem still happens) | 15:33 |
| Tiibiidii | anyone? | 15:33 |
| GaryvdM | Tiibiidii: what os? | 15:33 |
| Tiibiidii | ubuntu | 15:34 |
| Tiibiidii | (wait while i'll check the version) | 15:34 |
| GaryvdM | thats odd | 15:34 |
| Tiibiidii | karmic | 15:34 |
| GaryvdM | What transport (file/ftp/sftp)? | 15:35 |
| Tiibiidii | currently i'm trying directly through file | 15:35 |
| Tiibiidii | (i'm connected via ssh with both users) | 15:35 |
| Tiibiidii | GaryvdM, how do you usually setup your repository? | 15:36 |
| Tiibiidii | i mean.... push, then ssh to the server, then chown .bzr to a common group between the users like i'm doing right now? | 15:37 |
| GaryvdM | Tiibiidii: Yes | 15:37 |
| Tiibiidii | ok | 15:38 |
| Tiibiidii | where do you usually put your branch? | 15:38 |
| Tiibiidii | could this make any difference? | 15:38 |
| GaryvdM | I don't think so | 15:38 |
| Tiibiidii | (i mean: external fs mounted somewhere... inside the home of some user) | 15:39 |
| Tiibiidii | mhn | 15:39 |
| GaryvdM | Tiibiidii: why only chown the .bzr. I would chown the whole branch. | 15:39 |
| Tiibiidii | uhm | 15:39 |
| GaryvdM | Tiibiidii: Normally just use sftp | 15:39 |
| Tiibiidii | it should be chowned... | 15:39 |
| Tiibiidii | i'll check if the whole branch is chowned ok | 15:40 |
| Tiibiidii | yes, it is... the folder and all of the direct subfolders are chowned by the common group (with write permissions for the group) | 15:41 |
| bialix | heya GaryvdM !!! | 15:44 |
| GaryvdM | Hi bialix | 15:48 |
| Tiibiidii | GaryvdM, | 15:48 |
| Tiibiidii | i tried again | 15:48 |
| Tiibiidii | pushed via sftp | 15:49 |
| Tiibiidii | then branched locally (unfortunately i don't have the password of the other user... i'm testing while it's logged on) | 15:49 |
| Tiibiidii | with the other user | 15:49 |
| Tiibiidii | then touched an empty file, added and commited it | 15:49 |
| Tiibiidii | but i can't push | 15:49 |
| Tiibiidii | now it laments about a .bzr/branch/lock/tmp-something file | 15:50 |
| GaryvdM | Tiibiidii: Please pastbin error. | 15:50 |
| Tiibiidii | (i haven't tried yet to chown it... but it seems strange to be regarding a lock file) | 15:50 |
| Tiibiidii | sure | 15:50 |
| GaryvdM | Tiibiidii: try chown first | 15:51 |
| GaryvdM | The lock file would be the first file it would try write to | 15:51 |
| Tiibiidii | mhn, but shouldn't a lock tmp file be erased at the end of every transaction? | 15:52 |
| Tiibiidii | (now i'll try to chown as before) | 15:52 |
| GaryvdM | Yes | 15:53 |
| GaryvdM | Tiibiidii: how is it going | 16:00 |
| GaryvdM | I'm going home soon | 16:00 |
| Tiibiidii | sorry | 16:06 |
| Tiibiidii | for the delay | 16:06 |
| Tiibiidii | you know: | 16:06 |
| Tiibiidii | the guy who choose the folder/setup for the server | 16:06 |
| Tiibiidii | chose to put everything in a /GeoIndex folder -_- | 16:06 |
| Tiibiidii | even if this folder has the correct ownership and permissions | 16:07 |
| Tiibiidii | it seems that this still causes some problems | 16:07 |
| Tiibiidii | i tried it again | 16:07 |
| Tiibiidii | by creating the repository on my home on the server (where i can liberally chmod and chown everything) | 16:07 |
| Tiibiidii | and now everything's seems fine | 16:07 |
| Tiibiidii | thanks anyhow | 16:07 |
| === salgado is now known as salgado-lunch | ||
| === IslandUsurper is now known as IslandUsurperAFK | ||
| mdmkolbe | Where is a good tutorial on the bzr API? (e.g. if I wanted to write a web based front end to bzr) | 17:35 |
| bialix | check this http://doc.bazaar.canonical.com/plugins/en/plugin-development.html#learning-more | 17:37 |
| TresEquis | mdmkolbe: and have a look at loggerhead: https://launchpad.net/loggerhead | 17:42 |
| Peng_ | TresEquis: Why are you trying to hurt him? :( | 17:43 |
| mdmkolbe | bialix: hmm, looks promising. (but it looks like I'll have to dig to find a way to commit to a branch without checking out a working directory to the filesystem) | 17:43 |
| bialix | mdmkolbe: there is preview tree and memory tree | 17:44 |
| bialix | try to ask abentley or lifeless for more details | 17:44 |
| * TresEquis quotes Santayana here | 17:45 | |
| TresEquis | "those who do not know history are condemned to repeat it" | 17:45 |
| Christoph^ | Hi! | 17:46 |
| mdmkolbe | TresEquis: I'm not actually trying to create a BZR viewer. I'm trying to use BZR as a light-weight, ACID, storage mechanism for my web app. | 17:47 |
| Peng_ | mdmkolbe: There's probably prior work in that area -- ikiwiki and such | 17:48 |
| abentley | mdmkolbe, you may also be interested in https://edge.launchpad.net/wikkid/ | 17:48 |
| === radoe_ is now known as radoe | ||
| TresEquis | mdmkolbe: OIC | 17:49 |
| Peng_ | Took me a minute to see the pun there. | 17:49 |
| Peng_ | abentley: Neat. Thanks for the link. :) | 17:50 |
| Christoph^ | When I want two people to push code to a launchpad project, does that mean I have to create a team for those two people? | 17:50 |
| Peng_ | Christoph^: If you want them to push to the same branch? Yes. | 17:50 |
| Christoph^ | And you can't seem to push code directly to a project, only to your own id? | 17:50 |
| Peng_ | Christoph^: Branches must belong to a user or team. | 17:51 |
| Christoph^ | ok, thanks | 17:51 |
| Christoph^ | What would be the advantage of having one branch per person for the same project? (Up to now its only two people.) | 17:52 |
| TresEquis | Christoph^: the "main line" branch can be shared, but each developer can push multiple feature / fix branches for the project | 17:53 |
| TresEquis | e.g., to let the others review / approve | 17:54 |
| TresEquis | for instance, the lp:zope.event branch is owned by ztk-steering-group | 17:54 |
| TresEquis | but I have another branch where I was improviing docs: lp:~tseaver/zope.event/new_style_docs | 17:55 |
| TresEquis | which wasn't merged until this weekend. | 17:55 |
| TresEquis | (the trunk there is actaully a mirror of the SVN trunk) | 17:56 |
| === IslandUsurperAFK is now known as IslandUsurper | ||
| === salgado-lunch is now known as salgado | ||
| Christoph^ | What is the difference between pull and checkout? | 19:28 |
| Peng_ | One creates a branch, one creates a checkout. | 19:28 |
| Peng_ | Err, wait. | 19:28 |
| Peng_ | pull is to branch as update is to checkout. | 19:28 |
| Christoph^ | And practically? I mean, both gets me a local copy of some foreign branch that can be updated? | 19:29 |
| Peng_ | Christoph^: If by "pull" you meant "branch", yes. | 19:30 |
| Christoph^ | no, I meant pull | 19:32 |
| Christoph^ | ah, pull is to branch as update is to checkout | 19:32 |
| Christoph^ | ok | 19:32 |
| Christoph^ | but then there is no real difference between doing a branch and then pulling changes to doing a checkout and then updating changes? | 19:32 |
| Peng_ | There are differences between a branch and a checkout -- and, um, I'm terrible at explaining things, but there should be some nice documentation somewhere. | 19:34 |
| Peng_ | But either is sufficient for the requirements you described. | 19:34 |
| fullermd | If you do a 'branch', you have two branches. If you do a 'checkout', you have one branch. | 19:40 |
| === salgado is now known as salgado-brb | ||
| === salgado-brb is now known as salgado | ||
| mdmkolbe | Does bzr handle non-overlapping merges at the server end or do those all have to be done at the client? | 20:44 |
| mdmkolbe | (Specifically I'm wondering if I use bzrlib to directly access a repo and two different copies of my program (running at the same time) change two different files, then am I going to have to put logic in my program to do the merge or is that automatic?) | 20:44 |
| lifeless | mdmkolbe: so the repo is just a cloud of data; if you change a tree stored in the repo, thats atomic; you'll need to use bzr's merge facilities to join your two changes together, or otherwise arrange them to end up on the same timeline | 21:23 |
| lifeless | mdmkolbe: if you're wanting to have your changes appear as changes to a branch, then bzr will force you to be serialised anyway, so you won't need merge logic in your code | 21:23 |
| mdmkolbe | lifeless: I'm not sure I understand you. Is Bzr like Git in that merging two branches is just creating a new tree that happens to point to the two parent nodes (it was probably created via a tree-way merge but Git doesn't know that)? Or is Bzr smarter about merges than that (the oposite extreme would be Darcs which is structured such that merges happen automatically)? | 21:35 |
| james_w | mdmkolbe: like git in that sense | 21:37 |
| james_w | the branch can only point to a single revision though | 21:38 |
| james_w | so you can happily create new revisions in parallel, subject to locking constraints | 21:38 |
| james_w | but if your application requires it then at some point there will have to be a new revisions that references the others if you want them to be tied in to the history of the branch | 21:39 |
| james_w | and if both instances will be expecting to update the branch pointer when they add new revisions they will have to serialise and the second will have to merge if your app expects that | 21:39 |
| mdmkolbe | james_w: thanks, that makes sense. two questions though. First, is there support in the bzrlib API for making doing that merge easy? Second is there a good quick reference out there for the bzrlib repo format/object model (It would make it easier for me to figure out these things if there were)? | 21:43 |
| james_w | mdmkolbe: you mean doing a three-way merge, or just creating a new tree with two parents? | 21:44 |
| mdmkolbe | tree-way merge | 21:44 |
| mdmkolbe | /tree/three/ | 21:44 |
| james_w | there are some helpers | 21:45 |
| james_w | there's WorkingTree.merge_from_branch() and similar at one level | 21:45 |
| james_w | then Merger.from_revision_ids or similar at a lower level | 21:45 |
| lifeless | mdmkolbe: theres some object stuff on the wiki | 21:46 |
| a212901390231901 | is launchpad having issues? | 21:47 |
| a212901390231901 | https://code.launchpad.net/~bzr-pqm/bzr/bzr.dev <- not updated | 21:47 |
| lifeless | a212901390231901: yes | 21:47 |
| lifeless | a212901390231901: we just made 20K branches | 21:47 |
| fullermd | Ah, spring, that wondrous time of year when every young man's fancy turns to reproduction... | 21:48 |
| fullermd | Though most aren't THAT prolific. | 21:48 |
| a212901390231901 | but it's okay to push new branches and suggest them for merging still? | 21:48 |
| lifeless | a212901390231901: yup | 21:49 |
| lifeless | james_w: what do you think is wrong with doing the fetch ? | 21:49 |
| james_w | lifeless: excuse me? | 21:50 |
| james_w | oh | 21:51 |
| lifeless | nvm, I see what you meant | 21:51 |
| james_w | it's not doing a fetch | 21:51 |
| lifeless | I was going to put it in one place and changed my mind. | 21:51 |
| lifeless | james_w: I'll get that additional test written today. | 21:54 |
| james_w | thanks | 21:55 |
| === salgado is now known as salgado-afk | ||
| ovnicraft | hi folks, i have symlinks to folders in my repo i added them | 22:36 |
| ovnicraft | bzr has any problem with this? | 22:36 |
| Peng_ | ovnicraft: If the OS supports symlinks, to. | 22:37 |
| Peng_ | Err, no* | 22:37 |
| Peng_ | ovnicraft: Checking the branch out on Windows will lead to pain unless you install a plugin to help. | 22:37 |
| Peng_ | That was a while ago. The situation may have improved. | 22:37 |
| jam | hi Peng_ | 22:39 |
| Peng_ | Hii | 22:39 |
| jam | I just posted a review changing the History class to use bzr-history-db as the storage | 22:39 |
| jam | some numbers, etc. | 22:40 |
| Peng_ | Ooh. I need to learn what bzr-history-db is. :D | 22:40 |
| jam | Peng_: essentially a way to partition history data so that you can share it between branches | 22:41 |
| jam | it takes more space initially | 22:41 |
| jam | but if you are browsing 20 branches, it is ~1+changes, rather than 20*N | 22:41 |
| jam | If I can get a chance, I'd like to discuss it with you, mwhudson, beuno, whoever would be interested. | 22:42 |
| jam | I'd like to get some of my patches moving, but I'm not really sure how to do that. | 22:42 |
| jam | On the plus side, you don't need to get rid of merge_points, since the db stores information to look it up reasonably efficiently | 22:42 |
| a212901390231901 | are you still doing a sqlite backend thing? | 22:42 |
| Peng_ | I'm good at the "bzr merge"ing, not so much at the discussing. | 22:42 |
| jam | a212901390231901: roughly, yes | 22:42 |
| a212901390231901 | I've read what you've posted to the list but not followed very closely | 22:43 |
| beuno | jam, I have them in my queue to review. I want to help you move them | 22:43 |
| beuno | time has been lacking due to Lucid | 22:43 |
| beuno | but should get better now | 22:43 |
| jam | So I'm officially switching back to bzr + annotation stuff, but I'm sure that if you need me to do stuff to land it, I'll be happy to work on it. | 22:43 |
| jam | just the primary push is done. | 22:44 |
| ovnicraft | Peng, so i need a plug to have not problems with symlinks? | 22:44 |
| ovnicraft | i need add them, dont want to replicate info in my disk | 22:44 |
| jam | what would be *really* nice, is if I could find a way to get a Staging deployment of it, and then replay the requests that go to the regular site | 22:44 |
| jam | and see what happens. | 22:44 |
| beuno | jam, thanks a lot for all the work, I haven't been very verbose about it, but I'm thrilled you picked it up | 22:44 |
| a212901390231901 | ovincraft: really, you need the branch you're working on to not contain symlinks at all | 22:45 |
| jam | stuff like "browsing 2 related branches" going from 13s down to <1s for the second branch is very nice, but I don't know how often that happens | 22:45 |
| a212901390231901 | the plugins have big problems, and doing everything through cygwin is a pain | 22:45 |
| a212901390231901 | symlinks just aren't a windows thing. | 22:45 |
| Peng_ | ovnicraft: This is only if you need to be able to check out the branch on OSes that don't support symlinks, of course. | 22:45 |
| Peng_ | Just reading the diff, not the code itself, is "self.get_revid_for_revno([revid])" in http://bazaar.launchpad.net/~jameinel/loggerhead/history_db/revision/415 right? | 22:46 |
| ovnicraft | Peng, i am linux user, but trying to add a file inside a folder@ i get this error http://dpaste.com/190495/ | 22:47 |
| jam | Peng_: well, there are several revisions there. But yes, that is the final implementation. | 22:49 |
| ovnicraft | as i see bzr has problems in linux adding symlinks folders | 22:54 |
| Peng_ | ovnicraft: What exactly are you trying to do? | 22:55 |
| ovnicraft | add a file inside folder@ | 22:55 |
| Peng_ | ovnicraft: Add a file inside a directory that is a symlink? | 22:56 |
| ovnicraft | yes | 22:56 |
| Peng_ | Wow. lp:~jameinel/loggerhead/history_db changes a lot of code that I don't think I've ever even read. | 22:56 |
| Peng_ | ovnicraft: Yes, that sounds problematic. | 22:56 |
| ovnicraft | yes but i need it, i want to know if bzr support that actions? | 22:56 |
| ovnicraft | Peng_, so i ask you if its supported and maybe i understood wrong but i read that is a OS issue | 22:59 |
| Peng_ | ovnicraft: You can version symlinks 'til the cows come home, but files inside symlinks? That's just bizarre. I don't know if it's supposed to be supported, but I'm not surprised it fails. | 23:00 |
| ovnicraft | i think must be, as example if you are django devel and you want to version an app in different projects that can help you :) BTW i'll fix it placing the info | 23:02 |
| Peng_ | jam: Hmm, your history_db branch used to have different revisions? "Bring back the small-cleanups branch and restore the removed changes.". What became of that? | 23:02 |
| * Peng_ dozes off | 23:04 | |
| ovnicraft | and as i see my bus is being fixed https://bugs.edge.launchpad.net/ubuntu/+source/bzr/+bug/264275 | 23:05 |
| ubottu | Launchpad bug 264275 in bzr "bazaar internal error if adding file in a linked directory" [Undecided,In progress] | 23:05 |
| jam | Peng_: I only see 4 revisions for lp:~jameinel/loggerhead/history_db, I'm not sure where you are getting that message | 23:05 |
| ovnicraft | bug* | 23:05 |
| jam | ah, I did do a push --overwrite | 23:06 |
| jam | the old stuff was a test | 23:06 |
| jam | I nuked it and started from scratch | 23:06 |
| Peng_ | Oh, good, I hadn't merged the old stuff anyway. | 23:07 |
| jam | basically, the old branch was a dogpile of stuff I was working on, I split it out into a bunch of new branches and merge requests, and redid how bzr-history-db integrated | 23:07 |
| jam | I'm pretty sure "small-cleanups" was proposed, and I think it was merged | 23:08 |
| jam | 408 Ian Clatworthy 2010-04-22 [merge] | 23:08 |
| jam | Merge John's minor cleanups | 23:08 |
| Peng_ | OK. :) | 23:08 |
| jam | anyway, end-of-day for me here, I'll see you all around tomorrow | 23:09 |
| jam | Peng_: you may want to look at lp:~jameinel/loggerhead/integration, which is where I put all my stuff together to make sure I'm tuning the right code. | 23:11 |
| Peng_ | jam: Ah, thanks, | 23:12 |
| a212901390231901 | what's the right way of spelling "this test needs pywin32" in a test method? | 23:13 |
| Peng_ | jam: I'm running a few bits of it, but none of the major ones. | 23:13 |
| a212901390231901 | I currently have the first line as: | 23:13 |
| a212901390231901 | self.requireFeature(ModuleAvailableFeature("pywintypes")) | 23:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!