| === poolie is now known as pooliex | ||
| jml | is this the one causing all the oopses? | 00:12 |
|---|---|---|
| mwhudson | no | 00:14 |
| edencane | Hi. | 00:17 |
| edencane | someone sent me a diff file to apply to my tree... | 00:17 |
| edencane | they said use the 'patch' command, however there is no patch command in 1.6 | 00:18 |
| wgrant | edencane: The patch command is part of bzrtools. | 00:18 |
| lifeless | pooliex: sorry, was in the zonr | 00:19 |
| edencane | ok... (-: | 00:19 |
| edencane | thanks wgrant | 00:19 |
| pooliex | mwhudson, i'm going to look at #261315 today | 00:32 |
| pooliex | lifeless, np | 00:32 |
| mwhudson | pooliex: cool | 00:36 |
| jelmer | hah, pushing the exact same branch from scratch over both bzr+ssh and svn+ssh to the same server is faster over svn+ssh now >-) | 00:38 |
| jelmer | the difference is not very big, and the bzr server side is running bzr 1.0 (bzr.dev on the client) | 00:39 |
| lifeless | spiv: how did you go with streams? | 00:43 |
| * jml submits a patch | 00:50 | |
| lifeless | classic - http://steve-yegge.blogspot.com/2008/08/business-requirements-are-bullshit.html?showComment=1218561660000#c5713392683478153083 | 00:55 |
| warren | hmmm, does bzr have anything like git where you can export checkins as diff files with metadata? | 00:58 |
| poolie | warren, 'bzr help send' | 00:58 |
| jml | poolie: hello | 00:59 |
| abentley | poolie: wb | 00:59 |
| poolie | we had it first i think | 00:59 |
| warren | thx | 00:59 |
| jml | poolie: welcome back. | 00:59 |
| poolie | thanks, both of you | 00:59 |
| warren | thx | 01:03 |
| poolie | lifeless: hi | 01:07 |
| poolie | nice rant if somewhat longwinded | 01:07 |
| lifeless | ho | 01:07 |
| poolie | is the comment directed at me though? | 01:07 |
| lifeless | poolie: no | 01:07 |
| lifeless | poolie: but it did make me smile | 01:07 |
| poolie | i would say the main article is somewhat in the category of 'intentionally misconstruing the question' | 01:08 |
| teratorn | anyone know of a way to interactively tweak where 'bzr shelve' decides to place hunk boundaries? | 01:15 |
| teratorn | quite often I need to break up the changeset differently :/ | 01:15 |
| jml | teratorn: I think shelve gets it from diff. | 01:16 |
| teratorn | you're probably right | 01:18 |
| teratorn | one day when I'm rich I'm gonna hire someone to follow me around on IRC and implement all the stuff I complain about | 01:18 |
| Hydrogen | you jus gotta complain to the right people! | 01:21 |
| teratorn | complaining is hard work | 01:21 |
| lifeless | abentley: ping | 01:21 |
| lifeless | abentley: I want hunk-editing and stuff in bzr core | 01:22 |
| lifeless | abentley: what do you think of the shelf editor code - is it lovely, and what you'd build for bzr core, or should I take the concepts and write something new? | 01:22 |
| abentley | lifeless: I've never had much need to look at the shelf editor code. So it must be good. | 01:23 |
| teratorn | what is this shelf editor code of which you speak? | 01:24 |
| abentley | (Originally written Michael Ellerman. I just maintain it.) | 01:24 |
| lifeless | abentley: I poked at it, I found it a little obstruse, but not terribly so; I don't know if it will scale to hunk splitting and so on, which I do want us to get to. | 01:24 |
| lifeless | teratorn: its the hunk selector in 'bzr shelve' | 01:24 |
| lifeless | teratorn: bzr shelve's hunks are those output by 'bzr diff' | 01:25 |
| teratorn | *nod* | 01:26 |
| teratorn | yeah that would be way cool | 01:26 |
| abentley | lifeless: I've always figured that sub-hunk territory was best handled in an editor. | 01:26 |
| lifeless | abentley: so fire up an editor with some markers, perhaps the basis & current text seperate, let them edit till it has what they want,then use that to do a new diff and shuffle stuff ? | 01:28 |
| teratorn | basically all you need to do is to be able to split the hunks | 01:28 |
| teratorn | a simple line editor that lets you add some "<<<<<" markers, or something | 01:28 |
| teratorn | and move them around.. up or down | 01:28 |
| abentley | lifeless: Currently, for that purpose, I stop using shelve, and start using bzr vimdiff | 01:28 |
| jam | poolie, spiv: Good to have you guys back. Today is "Labor Day" in the US. | 01:30 |
| lifeless | abentley: I'm sneaking up on tree marks. I want something that doesn't need specific things like vimdiff that may not be readily available for some users, or which will not bind well for IDE's and GUI's. | 01:30 |
| abentley | poolie, spiv, jam: In Canada, today is "Labour Day" ;-) | 01:35 |
| jam | abentley: I guess that means u work harder | 01:36 |
| abentley | jam: lol | 01:36 |
| lifeless | abentley: I guess I'll send a mail to the list about hunk editing/selection. Using a callback may be the right interface. | 01:37 |
| jam | it seems like you could evolve the "shelve" interface if you really wanted to go that route | 01:38 |
| jam | just have a "split hunk" option | 01:38 |
| jam | though I agree, vimdiff (or an editor) is probably a more comfortable ui for it | 01:39 |
| jam | anyway, I'm only just walking by, back to family time | 01:39 |
| jam | oh, and poolie, spiv, igc, lifeless, abentley, vila, beuno, jelmer, LarstiQ, fullermd, etc, etc.... Feature freeze is tomorrow, so I encourage you to do some reviewing | 01:40 |
| poolie | jam, oh, right | 01:41 |
| poolie | re Labo[u]r Day | 01:41 |
| lifeless | abentley: the other thing we should discuss - rich-root; *I* thought it was waiting on a patch from you, you're saying its blocked on me. Lets sync | 01:43 |
| lifeless | oh damn | 01:43 |
| fullermd | Reviewing? You must have me confused with somebody who knows what they're doing :p | 01:46 |
| rocky | jelmer: best version of bzr to use with TracBzr is 1.5 ? | 01:56 |
| jelmer | rocky, probably | 01:56 |
| rocky | jelmer: does TracBzr support trac 0.11 ? | 01:56 |
| jelmer | rocky, yeah | 01:57 |
| rocky | latest release of TracBzr or do i need to grab a branch? | 01:57 |
| jelmer | rocky, there are no releases, you'll have to grab a branch | 02:09 |
| rocky | just grabbed trunk | 02:09 |
| lifeless | jam: why does branch.get_revno_map use the old graph abstraction? | 02:12 |
| rocky | jelmer: any particular reason you haven't merged over the trac0.11 branch into trunk? | 02:14 |
| jelmer | rocky, it is merged into trunk | 02:15 |
| rocky | oh... sorry i'm still getting familiar with launchpad's very very complicated interface | 02:15 |
| rocky | seemed to indicate it hadn't been merged | 02:15 |
| rocky | https://code.launchpad.net/~trac-bzr-team/trac-bzr/trunk/+merges seems to show it hasn't been merged | 02:16 |
| jelmer | rocky: I'm not the maintainer of trac-bzr btw, I do the occasional merge when I need it myself though | 02:16 |
| rocky | oh gotcha | 02:16 |
| jelmer | rocky, since nobody appears to be particularly looking after it these days | 02:16 |
| rocky | i might be interested in helping ... particularly if i integrate it with cluemapper | 02:16 |
| jelmer | ah, cool | 02:16 |
| === mw is now known as mw|out | ||
| === Snaury__ is now known as Snaury | ||
| jam | lifeless: because merge_sort doesn't allow ghosts | 02:33 |
| poolie | lifeless: please use more contentful subject lines than 'review feedback' thx | 02:34 |
| Hydrogen | yes | 02:35 |
| Hydrogen | like | 02:35 |
| lifeless | poolie: please patch bzr send to give me more contentful subject lines! | 02:36 |
| Hydrogen | du du du | 02:36 |
| poolie | lifeless: is this the bug about not being able to override the subject line if you use the builtin mail-sender? | 02:37 |
| lifeless | poolie: actually, I didn't look at the subject at all | 02:37 |
| lifeless | poolie: and as there is one, evo didn't bitch at me | 02:37 |
| poolie | if you're sending through evo i think you can override it and i'm asking that you do | 02:38 |
| lifeless | besides which, BB knows its a follow on patch, it can give extra content. | 02:38 |
| lifeless | poolie: I normally do. I forgot, once. | 02:38 |
| lifeless | and got jumped on. | 02:38 |
| poolie | oh np | 02:38 |
| poolie | no stomping was intended | 02:39 |
| jelmer | lifeless, when you have time, any chance you can reply to the "[MERGE] Move install_revision(s) onto the Repository object." thread? | 02:55 |
| jelmer | (http://news.gmane.org/find-root.php?message_id=%3C20080804032617.GA19075%40vernstok.nl%3E) | 02:55 |
| lifeless | poolie: ok | 02:55 |
| lifeless | jelmer: is it stuck? | 02:56 |
| jelmer | lifeless: Sortof - you voted resubmit but I wasn't entirely sure what I had to change | 02:56 |
| lifeless | jelmer: right found it. | 02:57 |
| lifeless | jelmer: what was unclear? | 02:57 |
| jelmer | lifeless: The tests for install_revisions() were already inside repository_implementations | 02:57 |
| jelmer | even though install_revisions() didn't live on Repository but was generic | 02:57 |
| lifeless | ah | 02:57 |
| lifeless | wow | 02:58 |
| lifeless | we have 1 test | 02:58 |
| lifeless | and its bare bones | 02:58 |
| lifeless | uhm | 02:59 |
| lifeless | it really needs to obey the full protocol on per-file graph support etc | 02:59 |
| lifeless | I hesistate to ask you to extend it to be sure of that, but I can think of so many ways it could be broken and pass the current test. | 02:59 |
| lifeless | poolie: I've dropped you a mail, there is a little bit of administrivia needed fairly urgently | 03:00 |
| jelmer | lifeless: Ok, so it just needs more tests? | 03:00 |
| lifeless | jelmer: yeah, I think so | 03:01 |
| * poolie chases indirections | 03:01 | |
| lifeless | jelmer: I think I'd structure them self-referentially - thusly | 03:01 |
| poolie | lifeless: is this at google again? | 03:01 |
| lifeless | jelmer: use the default format to build a branch with a file, dir, symlink (only where symlinks are present), that have the following occur to them | 03:01 |
| lifeless | created | 03:01 |
| lifeless | modified | 03:01 |
| lifeless | modified in two branches and merged | 03:02 |
| lifeless | modified in one branch merged to the other branch | 03:02 |
| lifeless | these are the basic corner cases for last-modified revision assignment | 03:02 |
| lifeless | then copy those revisions over to the repository format that is being tested | 03:02 |
| lifeless | they should end up identical | 03:03 |
| jelmer | thanks | 03:04 |
| jelmer | I'll leave it alone for now though, it seems like too much trouble to avoid 20 lines of code duplication in bzr-svn | 03:07 |
| lifeless | I'll note that the bugs in bzr-svn recently about last-changed etc will be avoided if you do this | 03:08 |
| lifeless | its not a good idea to leave it alone and hope :( | 03:09 |
| jelmer | lifeless, last-changed? | 03:09 |
| jelmer | you mean the text revids? That would be the bit I would override in bzr-svn | 03:09 |
| lifeless | its the bit you need to make sure the rules are absolutely in sync with bzr | 03:09 |
| jelmer | Sure, but this is just code sharing, it's not test sharing | 03:10 |
| lifeless | right | 03:10 |
| lifeless | I'm looking for a review on http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1219204485.31549.89.camel%40lifeless-64%3E | 03:12 |
| jelmer | So I don't see how that would help here; I would override install_revisions() for bzr-svn anyway, but that would allow using an existing InterRepository implementation that uses install_revisions() rather than writing my own. | 03:12 |
| lifeless | jelmer: so, I guess I'm thinking about test sharing more | 03:13 |
| lifeless | I'm hesitant about install_revisions as it stands, there are still #XXX's in it | 03:13 |
| lifeless | last I checked | 03:13 |
| jelmer | sure, but it's already being used at the moment. I'm just moving it. | 03:14 |
| lifeless | so my comment was, that by moving it we're making it be at higher risk - bugs in it will be more exposed | 03:15 |
| lifeless | and anyone implementing Repository will be expected to implement it, so test coverage matters substantially more | 03:15 |
| spiv | lifeless: I can review that | 03:16 |
| spiv | lifeless: as a general comment, I'm in favour of bringing things in incrementally though, so don't share jam's concern there. | 03:17 |
| jelmer | lifeless, ah, ok | 03:32 |
| spiv | lifeless: review sent. | 03:32 |
| lifeless | spiv: thanks | 03:33 |
| * beuno -> sleep | 03:36 | |
| lifeless | spiv: replied | 03:36 |
| beuno | g'night all | 03:36 |
| lifeless | spiv: I'm not sure where the 'if in tests is a bad smell' meme is coming from, but its either too simplistically phrased, or wrong. | 03:37 |
| lifeless | I've seen it a couple of times recently, I think its new. | 03:37 |
| spiv | lifeless: well, I can elaborate why I think this particular if is bad; I agree they can be ok. But by default treating with some suspicion is justified. | 03:39 |
| lifeless | why is it justified? | 03:39 |
| spiv | lifeless: as to the source of the meme, the xUnit Test Patterns book lists it ("Conditional Test Logic") | 03:39 |
| lifeless | or, whats the justification | 03:39 |
| spiv | In this case I think it's basically just that you're using the if statement to squeeze multiple tests into one test method. | 03:42 |
| lifeless | you've seen my reply? | 03:42 |
| spiv | Which isn't as clear at communicating intent as it would be as two separate tests. | 03:42 |
| spiv | Not yet; I'll do that now. | 03:42 |
| lifeless | because I'm not doing that | 03:42 |
| lifeless | I'm testing the single behaviour of an interface with optional output | 03:43 |
| spiv | Ok. | 03:43 |
| lifeless | the first column must be either all None, or not None at all | 03:43 |
| spiv | So I think you can express that intent more clearly. | 03:43 |
| lifeless | as I've defined it | 03:43 |
| spiv | (And without an if statement in the test method) | 03:43 |
| spiv | By: | 03:44 |
| spiv | names = sorted([result[1] for result in read_result]) | 03:44 |
| spiv | self.assertEqual(expected_names, names) | 03:44 |
| spiv | # (so far, same as before) | 03:44 |
| spiv | self.assertAllNoneOrAllNotNone([result[0] for result in read_result]) | 03:44 |
| lifeless | ugh | 03:45 |
| spiv | There would be an if statement in the assertion method, obviously. | 03:45 |
| lifeless | Thats less clear | 03:45 |
| spiv | (The xUnit book points out that this is a good thing because you can write tests for your test helpers, whereas writing tests for test methods leads to madness) | 03:46 |
| lifeless | I'll change the test around a bit, see if you like it | 03:46 |
| spiv | I'll be interested to see what it looks like. | 03:46 |
| lifeless | well, the xUnit book, frankly, should smoke less camel toenails. Its equally untested even with a helper test, because you may simply fail to call the right helper, or pass incorrect parameters in | 03:47 |
| lifeless | at a certain point you have to assess the code in front of you on its own merits | 03:47 |
| spiv | :) | 03:47 |
| lifeless | I do write helper tests, for helpers that deserve it | 03:48 |
| spiv | Right, I agree. | 03:48 |
| lifeless | so its not a critique of doing that. Its a critique of using that facility to support an argument that 'if' is bad in test methods | 03:48 |
| spiv | I nearly said so originally, but I felt like I was already waffling :) | 03:48 |
| lifeless | bet you the authors don't like 'goto' either. | 03:48 |
| spiv | Perhaps, but the index gives no clue either way :) | 03:49 |
| lifeless | :> | 03:49 |
| lifeless | (goto is very good practice in C for function cleanups) | 03:49 |
| spiv | (agreed) | 03:50 |
| spiv | Skimming the Conditional Test Logic section of the book, it is a touch vague but boils down to "conditional logic == complex code == harder to understand/trust == less confidence". | 03:52 |
| lifeless | sounds like an indictment of both 'if' and 'objects' all at once | 03:54 |
| spiv | Which I think is right. It's a mild smell for me; it can be a sign that the test could be better, but I don't consider it to be a 100% reliable indicator of trouble. Sometimes the test is clear enough even though it has conditional. | 03:55 |
| spiv | Well, complexity sucks. :) | 03:55 |
| lifeless | see, this is the bit where I think its process insanity | 03:55 |
| lifeless | thats the sort of thing thats so inane, I'd never put it in a talk | 03:55 |
| spiv | One of the neat thing about tests is that you can often write several simple tests that you individually trust to gain confidence in a larger, complex system. | 03:56 |
| lifeless | "I find your test hard to read" >>>> "your test has if in it" | 03:56 |
| lifeless | spiv: that ignores the potential for skew | 03:56 |
| spiv | (Keeping in mind that you may have gaps between your simple bits...) | 03:56 |
| lifeless | you have to be sure they are aligned right, and thats hard to test | 03:57 |
| spiv | Right. | 03:57 |
| spiv | I said it's a "neat thing", not a "magic bullet" :) | 03:57 |
| spiv | Anyway, back to the case in hand... I *did* find the purpose of the test a little confusing. | 03:58 |
| lifeless | which is fine, fixing. | 03:58 |
| spiv | Partly because I worry a little that a casual reader might not pick up on the fact that that test is parameterised, which is helpful in figuring out why the "if" might matter. I wonder if we should have some convention to flag parameterised tests that are outside the per_* and *_implementations directories? | 04:02 |
| spiv | Perhaps the answer is just that a casual reader that gets confused should just read more closely :) | 04:03 |
| lifeless | well, the test, when it runs, shows the parameters | 04:03 |
| lifeless | spiv: mail sent to the list | 04:04 |
| spiv | Yeah. So people reading the test because of test failures will know. | 04:04 |
| spiv | Which is probably most casual readers. | 04:04 |
| spiv | lifeless: that tweak is better, thanks. | 04:08 |
| lifeless | the difference from a helper function is that this is clearer | 04:08 |
| lifeless | a non-reused helper is just a new function to remember, and the name would signal what it does, not why it does it | 04:09 |
| lifeless | why is what matters | 04:09 |
| spiv | Sure. | 04:09 |
| spiv | I wasn't wedded to using a new function, but it was a lot easier to type into IRC :) | 04:10 |
| poolie | wow | 04:10 |
| poolie | i got sucked in too | 04:10 |
| lifeless | poolie: ? | 04:12 |
| poolie | to the 'if in tests' thing | 04:12 |
| lifeless | hehe | 04:12 |
| poolie | smell doesn't mean 'never do this' | 04:12 |
| mwhudson | poolie: not sucked into wow, i hope | 04:13 |
| poolie | i guess overall, why not hide the sorting by inodes inside the function you're testing | 04:13 |
| poolie | nup | 04:13 |
| lifeless | poolie: performance | 04:13 |
| poolie | heh | 04:13 |
| poolie | care to expand on that? | 04:13 |
| lifeless | sure | 04:13 |
| lifeless | sorting costs, its cheaper not to sort unless you need to | 04:14 |
| poolie | so if a caller wants the directory without caring about sorting by inode, surely they'd like to also avoid consing and then removing all the tuples? | 04:15 |
| lifeless | poolie: I'll be a second, buffer overflow | 04:16 |
| lifeless | poolie: so, I think the thing about smells, is that if you bring them up in a comment, it muddies the actual discussion that should take place. | 04:22 |
| poolie | the reviewer should keep inside their head the fact that it's a smell and just either give a concrete reason or say nothing? | 04:23 |
| lifeless | yes | 04:23 |
| lifeless | unless they want to just say 'it smelt to me, if it smells to you too please fix it' | 04:23 |
| spiv | So I mentioned it as a shorthand way of explaining what I thought was problematic. | 04:24 |
| spiv | Clearly this failed as a way to explain myself concisely :) | 04:24 |
| lifeless | like pattern languages, unless its shared, it fails | 04:24 |
| poolie | it may bifurcate the conversation into a discussion of whether it's a general problem or not, and what to do in this case | 04:24 |
| poolie | as has happened here | 04:24 |
| poolie | they may go in different directions | 04:25 |
| poolie | anyhow, coming back to the specific thing here | 04:26 |
| poolie | it seems to me that callers want either a directory listing in random order, or a listing sorted for optimal access to the files (if possible) | 04:27 |
| lifeless | just waiting for a push to finish then I'll have the code up in front of me again | 04:27 |
| poolie | dear lazyspiv: getattr won't be called if the attribute is defined in a base class? | 04:29 |
| spiv | Heh. | 04:30 |
| spiv | The __getattr__ hook? Right. | 04:30 |
| mwhudson | poolie: you mean __getattr__ right? and yes, pretty sure | 04:30 |
| poolie | i do | 04:30 |
| poolie | thanks | 04:31 |
| poolie | that was my reading of the docs, it just contradicts something jam said so i was checking | 04:31 |
| poolie | lifeless: the other thing here, which is kind of mission creep, is that i think you can actually return the file file kind from readdir, which your comment waves towards | 04:32 |
| lifeless | poolie: its not a win today | 04:32 |
| lifeless | poolie: I ripped that code out | 04:32 |
| poolie | but it might take a bit of code change to use it, and it probably isn't enough to avoid stat | 04:32 |
| * spiv -> lunch | 04:32 | |
| lifeless | poolie: so, sometimes we want to sort, sometimes we don't care. Having multiple interfaces is less appealing than a single if its cheap | 04:34 |
| === lamont` is now known as lamont | ||
| lifeless | poolie: we would allocate inode, string tables to sort anyway, so there isn't <much> of a saving in hiding that | 04:34 |
| poolie | my point is that if you care about avoiding the sort when the client doesn't care, shouldn't you want to avoid allocating all the data structures needed to sort too? | 04:38 |
| lifeless | poolie: yes, I didn't disagree with your point | 04:39 |
| lifeless | poolie: but we'll need another tested interface to implement it, and that has its own cost; I don't really want to duplicate the C code unnecessarily | 04:40 |
| poolie | i think it would be clearest to have list_dir(..., sort_hint=None) or something | 04:42 |
| lifeless | that will be quite tricky to test | 04:44 |
| === mario_ is now known as pygi | ||
| lifeless | poolie: so, spiv has given bb:approve, i'm blocked on a little clearer messaging from you | 04:58 |
| === abentley1 is now known as abentley | ||
| === abentley1 is now known as abentley | ||
| === abentley1 is now known as abentley | ||
| poolie | lifeless: ok | 05:05 |
| poolie | in what way is that trickier to test? | 05:05 |
| poolie | at the moment you're not testing that it is sorted in any way at all | 05:06 |
| poolie | i think if you do this it will address john's just-posted concern that this is not a good api for pyrex | 05:06 |
| lifeless | he doesn't say its not a good api for pyrex; hes saying its not all-thats-needed-to-be-really-fast | 05:13 |
| lifeless | because we need to fix the overhead of stat | 05:13 |
| lifeless | and we may actually want a full pyrexed walkdirs implementation | 05:13 |
| poolie | so is that clear or not? | 05:16 |
| jml | so, I'm having a problem with this bzrdir patch. | 05:17 |
| lifeless | so the change you propose is really unrelated to John's concern about pyrex, which I've replied to | 05:18 |
| jml | If I add another BzrDirMetaFormat1 to the tested formats, I get this error: http://pastebin.ubuntu.com/42594/ | 05:18 |
| lifeless | jml: you shouldn't add another BzrDirMetaFormat1 to the tests | 05:19 |
| lifeless | jml: as its already tested | 05:19 |
| jml | lifeless: ok. | 05:19 |
| lifeless | jml: like I said yesterday, just change the formats it tests with to be the latest ones, rather than the defaults | 05:19 |
| jml | lifeless: changing the existing format to use stackable branches and repositories makes the 'does default work' tests fail | 05:19 |
| * jml looks for the right shelf to get the test output | 05:20 | |
| lifeless | jml: give me a diff somewhere | 05:20 |
| lifeless | poolie: so, I can do it, but I think we're polishing the knob a little early | 05:20 |
| jml | http://pastebin.ubuntu.com/42595/ | 05:20 |
| jml | lifeless: ^^ | 05:20 |
| lifeless | poolie: what I have is the shrunken version of 'get the file kind from C's readdir()' | 05:21 |
| lifeless | jml: what for are you fiddling around in there | 05:22 |
| lifeless | jml: BzrDirFormat.known_formats() is the function to change | 05:22 |
| lifeless | poolie: no its not really clear; I can't tell if you are voting comment: or tweak: | 05:23 |
| jml | lifeless: I'm sorry, but I have no idea how to change that in a sane way | 05:23 |
| jml | lifeless: what's a control format? | 05:23 |
| lifeless | jml: BzrDir4/5/6/7/BzrDirMetaDir/RemoteBzrDir/SvnDir | 05:24 |
| lifeless | HgDir | 05:24 |
| lifeless | GitDir | 05:24 |
| lifeless | etc | 05:24 |
| jml | ok. I still don't get how to change known_formats. | 05:25 |
| lifeless | so | 05:25 |
| lifeless | I can paraphrase the problem differently I think. | 05:25 |
| lifeless | the reason your tests did not fail after you wrote them is that the BzrDirMeta1 type supports stacking, even though the bzr 'default' format does not | 05:26 |
| * jml nods | 05:28 | |
| lifeless | I am saying, change the default, for all these tests | 05:28 |
| poolie | ok, i reviewed the new one | 05:28 |
| jml | lifeless: how do I change the default for the tests without changing the default for bzr? | 05:30 |
| lifeless | so, known_formats is only used for testing | 05:31 |
| lifeless | if you look at the loop | 05:31 |
| lifeless | its returning all the specific types known by each control type | 05:32 |
| lifeless | so, all the flavours of BzrDir, all the Flavours of GitDir etc | 05:32 |
| lifeless | you want the BzrDirMeta1 flavour returned to be parameterised with a branch and repo type | 05:33 |
| lifeless | basically, I think you change | 05:33 |
| lifeless | __default_format = BzrDirMetaFormat1 | 05:34 |
| lifeless | way down in the file | 05:34 |
| jml | ok. | 05:34 |
| lifeless | and check 'bzr init' doesn't break surprisingly. (I don't think it will) | 05:34 |
| lifeless | oh, or upgrade | 05:34 |
| lifeless | it shouldn't actually change the default, due to various things | 05:34 |
| lifeless | poolie: where did you see the copyright thing? | 05:36 |
| poolie | readdir.h | 05:36 |
| lifeless | and whats wrong with it (other than it saying Bazaar-NG, which I've fixed) | 05:37 |
| poolie | it's also 2008 now :) | 05:39 |
| lifeless | that file has not changed since 2006 | 05:39 |
| poolie | ok | 05:40 |
| poolie | it's newly added so i thought it was new | 05:40 |
| lifeless | Am I misunderstanding (C) rules? | 05:40 |
| poolie | but maybe it's been sitting on your disk since then | 05:40 |
| poolie | in which case it's fine | 05:40 |
| jml | import sucks | 05:41 |
| lifeless | jml: ? | 05:45 |
| jml | lifeless: would you expect http://pastebin.ubuntu.com/42600/ to cause http://pastebin.ubuntu.com/42601/ | 05:47 |
| jamesh | lifeless: usually copyright relates to publication date rather than creation date | 05:48 |
| jamesh | so a 2008 copyright might be appropriate if that's when it first gets published | 05:48 |
| lifeless | its been on the interwebs since london 2006 | 05:49 |
| lifeless | why is something so simple such a long process | 05:50 |
| lifeless | 1/2 a day on one patch | 05:50 |
| lifeless | jml: yes, I would | 05:50 |
| jml | lifeless: for my part, it's because of a lack of familiarity :) | 05:50 |
| lifeless | jml: I wasn't referring to your patch | 05:50 |
| lifeless | this readdir one of mine | 05:51 |
| lifeless | EFRUSTRATION | 05:51 |
| jml | :) | 05:51 |
| lifeless | I feel like saying, meh, I'll come back to it in another 2 years | 05:51 |
| lifeless | (This patch was the reason I wrote the pyrex stuff for setup.py in the first place, way way way back - it was to enable bringing in such extensions) | 05:51 |
| lifeless | jml: anyhow, your patch. bzrlib.branch is probably lazy importing bzrdir | 05:52 |
| lifeless | and those default setting lines are too high up | 05:52 |
| poolie | lifeless: i feel like that sometimes too | 05:52 |
| lifeless | jml: try changing bzrlib.branch.BranchFormat.default | 05:53 |
| lifeless | jml: instead, I think it delegates by default | 05:53 |
| poolie | lifeless: want to talk? any ideas about what to do differently? | 05:55 |
| lifeless | poolie: I'm feeling a tad time pressured. The idea of a process chat right now is not appealing | 05:55 |
| poolie | lifeless: take 3 is ok with me if you really don't want to change it | 06:10 |
| poolie | i guess i'd be more relaxed if it were marked private | 06:10 |
| lifeless | poolie: it is now, its _read_dir | 06:11 |
| poolie | am i one patch behind? | 06:12 |
| lifeless | no | 06:12 |
| lifeless | you're probably confused by the modules | 06:12 |
| lifeless | _readdir_pyx.pyx -> thats a private module | 06:12 |
| lifeless | it has read_dir() in it | 06:12 |
| poolie | oh, you mean _readdir | 06:12 |
| lifeless | bzrlib.osutils._readdir | 06:12 |
| * jml looks into changing the repository default | 06:12 | |
| poolie | fairy nuf | 06:12 |
| lifeless | is where it is exposed, and its exposed _ prefixed. | 06:12 |
| poolie | http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1219204485.31549.89.camel%40lifeless-64%3E has osutils republishing it as read_dir | 06:13 |
| lifeless | try: | 06:13 |
| lifeless | from bzrlib._readdir_pyx import read_dir as _read_dir | 06:13 |
| lifeless | except ImportError: | 06:13 |
| lifeless | from bzrlib._readdir_py import read_dir as _read_dir | 06:13 |
| poolie | ok | 06:14 |
| poolie | wrong tab | 06:14 |
| lifeless | so my view is - there is one user; it obvious that it is doing a sort, so the costs are visible to readers | 06:15 |
| lifeless | we can triangulate when there are multiple users of the interface | 06:15 |
| lifeless | jam: bug 262565 | 06:22 |
| ubottu | Launchpad bug 262565 in bzr "Old resolved conflicts resurrected" [Undecided,New] https://launchpad.net/bugs/262565 | 06:23 |
| lifeless | jam: I suspect you've spent the most time looking at that set of problems.. | 06:23 |
| lifeless | poolie: for squid patches, in the web ui you can retarget them rather then rejecting them | 06:24 |
| lifeless | poolie: it would be nice if you could change your vote to comment | 06:24 |
| lifeless | http://bundlebuggy.aaronbentley.com/project/squid/request/<1220137897.6703.4.camel%40henriknordstrom.net> | 06:24 |
| poolie | sure | 06:25 |
| lifeless | thanks | 06:28 |
| poolie | out to the shops, biab | 07:00 |
| lifeless | jonnydee: sorry that your patch wasn't merged. It was approved, just not sent to the gatekeeper | 07:06 |
| philn | hi | 08:16 |
| philn | i can't manage to checkout a bzr:// branch via a ssh tunnel.. is there something specific needed to setup that? | 08:17 |
| philn | to setup the tunnel i do: ssh -nNL 4155:bling:4155 sshhost | 08:17 |
| poolie | philn, hi, do you want to tunnel ssh over ssh, or have bzr listening on a tcp port on the other side of the tunnel | 08:18 |
| spiv | I wouldn't think anything special would be needed. | 08:18 |
| philn | i have bzr serve listening on the remote side | 08:18 |
| poolie | try adding -v to ssh and see if it tries to connect? | 08:18 |
| philn | when i do telnet localhost 4155 it wors | 08:18 |
| poolie | potentially silly question, why not just use bzr+ssh? | 08:18 |
| philn | ok | 08:18 |
| lifeless | jonnydee: your bugfix has landed in bzr.dev | 08:19 |
| philn | err, dunno ;) i should try that maybe ;) | 08:19 |
| spiv | philn: and so you're trying to checkout using "bzr co bzr://localhost/..."? | 08:19 |
| philn | yes | 08:19 |
| spiv | philn: well, if telnet localhost 4155 works, then there's no reason why bzr://localhost shouldn't work. | 08:20 |
| philn | debug1: Connection to port 4155 forwarding to bling port 4155 requested. | 08:20 |
| philn | debug1: channel 2: new [direct-tcpip] | 08:20 |
| spiv | (at least, no reason related to SSH tunnelling) | 08:20 |
| philn | i'll try bzr+ssh | 08:20 |
| philn | bzr+ssh works, fair enough.. | 08:21 |
| spiv | What error were you getting? | 08:22 |
| philn | for bzr:// ? well bzr was just hanging, nothing displayed, even with -v option | 08:22 |
| spiv | You could try adding the -Dhpss option and then looking in ~/.bzr.log | 08:24 |
| spiv | Or you could try | 08:24 |
| spiv | echo 'hello' | nc localhost 4155 | 08:24 |
| spiv | (Which should get a reply) | 08:25 |
| lifeless | spiv: did you see my query about streaming this morning ? | 08:26 |
| philn | it displayed ok2 | 08:26 |
| spiv | philn: ok, then the SSH tunnelling is definitely working as intended, so if you wanted to know more, then -Dhpss & ~/.bzr.log option would be the next step. | 08:27 |
| philn | i see no error in that file | 08:27 |
| spiv | lifeless: oh right. Slowly, but that's due to sinus congestion rather than code :) | 08:27 |
| spiv | philn: pastebin the last 10 lines? | 08:27 |
| spiv | It should indicate what part of the network conversation it is hanging on. | 08:28 |
| philn | http://pastebin.com/m6c724273 | 08:28 |
| philn | if i interrupt i get a traceback in the file | 08:29 |
| philn | http://pastebin.com/m26331e2d | 08:30 |
| philn | this is bzr 1.6 from your ppa | 08:30 |
| spiv | Huh, that is weird. | 08:30 |
| poolie | lifeless: do you want to go to both uds and fosscamp? | 08:31 |
| lifeless | poolie: yup | 08:31 |
| spiv | philn: FWIW, random testing over an SSH tunnel works ok for me here. | 08:32 |
| lifeless | calling it a day folk. | 08:33 |
| lifeless | later | 08:33 |
| spiv | philn: At this point, I'd probably start resorting to tcpdump :/ | 08:34 |
| spiv | philn: or, more pragmatically, use bzr+ssh://, seeing as that works already... | 08:34 |
| philn | i'll just use bzr+ssh and work done ;) | 08:35 |
| philn | have a good day | 08:35 |
| Peng_ | Shouldn't osutils.pump_string_file use xrange instead of range? It could potentially be a large range, right? | 08:38 |
| poolie | Peng_: i can't find a method of that name... | 08:46 |
| lifeless | poolie: pydoc xrange | 08:47 |
| poolie | :) | 08:47 |
| poolie | very funny | 08:47 |
| poolie | i meant pump_string_file | 08:47 |
| lifeless | Peng_: possibly, OTOH 5MB chunks from a string -> if its GB's in size, it will be a problem for other reasons | 08:47 |
| lifeless | poolie: oh, pull bzr.dev then | 08:47 |
| poolie | oh, merged since this morning? | 08:48 |
| lifeless | yes | 08:48 |
| lifeless | quite a few patches landed today | 08:49 |
| poolie | spiv, are you still here? | 09:27 |
| poolie | vila, hi/ | 09:31 |
| poolie | are you online? | 09:31 |
| vila | poolie: Hi ! | 09:31 |
| poolie | could we talk in a bit? | 09:31 |
| vila | sure | 09:31 |
| poolie | need to go and pick up stephane at the moment | 09:32 |
| vila | poolie: when you want | 09:32 |
| stianse | Hi all. When I use "bzr branch", how should i configure the branches so that configuration (like the one you find in branch.conf) is copied to the new branch? | 09:48 |
| stianse | Right now I'm using bzr-shell-hooks plugin and have a section of [hooks] in my branch.conf of which scripts to run. It would be nice if there was a way to copy such information. Or probably specify it somewhere else? | 09:49 |
| Odd_Bloke | stianse: I think the accepted way to do that would be to have a plugin which installed the hooks that you would install wherever you wanted that stuff setup. | 09:50 |
| Odd_Bloke | Though I don't know a great deal about shell hooks. | 09:50 |
| stianse | Odd_Bloke, but using a plugin would affect all my bazaar branches, right? I only want these hooks on a few branches. | 09:52 |
| Odd_Bloke | stianse: Yeah, I'm not sure how we handle this case. | 09:53 |
| Odd_Bloke | I've never run into needing it, so have never looked at it. | 09:53 |
| stianse | Odd_Bloke, ok no problem. Thanks anyway. | 09:55 |
| hmeland | Would moving the [hooks] section from .bzr/branch/branch.conf into ~/.bazaar/locations.conf work? | 09:56 |
| hmeland | Probably not, if the README of bzr-shell-hooks is accurate. | 09:57 |
| === jelmer is now known as Guest12522 | ||
| === Guest12522 is now known as jelmer | ||
| poolie | vila, hi, still here? | 10:34 |
| vila | sure | 10:34 |
| vila | but if it's late for you we can talk tomorrow, your call | 10:35 |
| === acuster is now known as avc_work | ||
| loxs[] | folks, I'm having a problem... first I made a branch, then I checkout the branch... then I add some files to my checkout and then bzr add, bzr commit... it says everything is fine... then I go to the parent branch and the files are not there.... then I do a bzr log in the parent branch and surprise... the log is ok, as if the commit was successful. Do you have any idea what's going on? | 10:58 |
| loxs[] | probably the problem is that the files are binary? they are doc files | 10:58 |
| james_w | ; | 10:59 |
| james_w | loxs[]: could you try running "bzr update" in the parent branch? | 10:59 |
| loxs[] | ghm, strange james_w, now it adds the files there o_O | 11:01 |
| loxs[] | can't it be done automatically? | 11:02 |
| james_w | loxs[]: not really | 11:02 |
| james_w | it's not easy to do that remotely, and really bad for performance | 11:02 |
| loxs[] | it's not that remotely... it's inside a novell environment... I mean, both places are part of the filesystem | 11:03 |
| james_w | hmm, maybe it doesn't do it locally either | 11:04 |
| james_w | I'm more used to "push" than checkouts | 11:04 |
| loxs[] | what is going to happen if someone edits something in the 'central' repo? without doing a bzr up before that? | 11:04 |
| === Bambi_BOFH is now known as Kamping_Kaiser | ||
| loxs[] | yeah, I must start thinking in bzr ways :)... the 'parent' and the 'child' are of equal priority... even the 'parent' can be 'out of date' | 11:31 |
| uws | loxs[]: you can also use checkouts, in which case you can use the "centralized workflow" (a la svn, cvs) | 11:44 |
| uws | loxs[]: then your "parent" cannot be out of date, only the "child" | 11:44 |
| uws | loxs[]: since all commits are automatically pushed "upstream" to the parent | 11:44 |
| uws | loxs[]: See "bzr help checkout" and "bzr help update" | 11:45 |
| uws | loxs[]: and "bzr help bind" | 11:45 |
| loxs[] | well, that was the problem.... see above :) | 11:45 |
| loxs[] | the parent doesn't get automatically updated upon commits | 11:45 |
| uws | loxs[]: it will if you use a checkout | 11:46 |
| loxs[] | it doesn't | 11:46 |
| uws | loxs[]: it should, and it does everywhere I use it. | 11:46 |
| loxs[] | first I made a branch, then I checkout the branch... then I add some files to my checkout and then bzr add, bzr commit... it says everything is fine... then I go to the parent branch and the files are not there.... then I do a bzr log in the parent branch and surprise... the log is ok, as if the commit was successful. Do you have any idea what's going on? | 11:46 |
| uws | loxs[]: So it's likely something in your setup is not right | 11:46 |
| uws | loxs[]: You need to "bzr update" the parent branch | 11:47 |
| loxs[] | yeah, that's the thing :) | 11:47 |
| uws | loxs[]: But usually you don't need a working tree in the parent branch (e.g. it's on a central, backed up server) | 11:47 |
| loxs[] | in this case I need a working tree there | 11:47 |
| uws | loxs[]: you can use "bzr remove-tree" if you don't need it. | 11:47 |
| uws | loxs[]: Ok, then "bzr update" | 11:47 |
| loxs[] | the problem is that i can't be sure that every developer will bzr update the parent every time | 11:48 |
| uws | loxs[]: is this a website perhaps? | 11:48 |
| loxs[] | and sometimes some of us make changes on the parent... and then we have a problem | 11:48 |
| uws | there's a "bzr upload" plugin i think | 11:48 |
| loxs[] | bzr automirror... I'm looking at it now | 11:49 |
| uws | loxs[]: make changes on the parent branch, or on the parent working tree? | 11:49 |
| loxs[] | I'm not very sure what's the difference | 11:49 |
| loxs[] | working tree I suppose | 11:50 |
| LarstiQ | loxs[]: the crux of the problem should be answered by finding out why you need the central branch to have a working tree? | 11:50 |
| loxs[] | well, speaking strictly we don't... | 11:50 |
| LarstiQ | ok, so why not nuke it then? | 11:53 |
| loxs[] | because my colleagues will wonder what's happening :) | 11:53 |
| LarstiQ | for publishing revisions you only need the branch part, not the working tree. | 11:53 |
| LarstiQ | loxs[]: happenening in what case? | 11:54 |
| LarstiQ | loxs[]: you can certainly have a workingtree present on your central branch, but it makes things more complex. | 11:54 |
| LarstiQ | so unless you really really need it, I advise against doing that. | 11:54 |
| loxs[] | well, if I get it right, the central repository will not contain the actual files, only the .bzr and the history... | 11:54 |
| LarstiQ | loxs[]: right | 11:54 |
| loxs[] | some of my colleagues, especially my boss, don't care much about bzr... they expect to be able to see what's going on by visiting the central directory (it's a Novell environment) | 11:55 |
| loxs[] | it's central and it's being backuped and so on | 11:56 |
| LarstiQ | so this is more of an education/workflow thing. | 11:57 |
| LarstiQ | loxs[]: you could use a 'central' working tree that is in a different location than the 'central' branch, and have the former autoupdated. | 11:58 |
| uws | loxs[]: You shuold setup something like Trac or Loggerhead | 11:58 |
| loxs[] | yes, that exactly am I asking... how to do the autoupdating :) | 11:58 |
| LarstiQ | loxs[]: cron :) | 11:58 |
| uws | loxs[]: that is MUCH more useful for browsing the files and history | 11:58 |
| loxs[] | cron... it's windows :( | 11:59 |
| uws | loxs[]: how do you push to it? sftp? | 11:59 |
| LarstiQ | loxs[]: other options are bzr push-and-update and bzr upload, but again probably not on windows. | 11:59 |
| loxs[] | no uws, the central repo is part of the filesystem (it's Novell environment)... just simple directory path | 12:01 |
| loxs[] | yeah, LarstiQ, these two commands are not present | 12:04 |
| LarstiQ | loxs[]: they are plugins, but afaik both require ssh. | 12:05 |
| loxs[] | yes, automirror also required ssh :/ | 12:06 |
| LarstiQ | loxs[]: see http://bazaar-vcs.org/BzrPlugins | 12:06 |
| loxs[] | looking at ti | 12:06 |
| loxs[] | *it | 12:06 |
| LarstiQ | loxs[]: so, if you decide to keep your central working tree, when people make changes to it but don't commit, they will be merged when you run bzr update | 12:06 |
| loxs[] | when I run bzr update on my checkout copy you mean? | 12:07 |
| LarstiQ | loxs[]: if they try to commit when the working tree is out of date, bzr will tell you so and you have to update first. | 12:07 |
| LarstiQ | loxs[]: no, this is all speaking about the central one | 12:07 |
| loxs[] | yes, I tried it, I know... and its fair thing as far as I see | 12:08 |
| LarstiQ | loxs[]: if people make uncommited changes to the central one, there is no new revision, and hence update on a different checkout will do nothing. | 12:08 |
| loxs[] | I'll resolve the issues when they emerge | 12:08 |
| LarstiQ | loxs[]: you will still have to run update on the central copy to bring it up to date. | 12:08 |
| loxs[] | yes, there is probably no other way | 12:08 |
| loxs[] | thanks | 12:09 |
| LarstiQ | really, I do think you're best off without it. | 12:09 |
| uws | yeah, loggerhead or trac will give much better information | 12:09 |
| LarstiQ | and as uws said, loggerhead is a much better solution for seeing what the status is | 12:09 |
| LarstiQ | loxs[]: and I would try to teach people how things might be different from what they expect. | 12:10 |
| loxs[] | I will try that, for sure :) | 12:10 |
| uws | just not having a central working tree means there can't be any confusion | 12:10 |
| loxs[] | yeah, if everyone is familiar with bazaar :) | 12:11 |
| LarstiQ | loxs[]: if they are not familiar with bazaar, they see an 'empty' directory, or one with just a .bzr/ dir beneath it. | 12:12 |
| LarstiQ | loxs[]: I hope your colleagues aren't in the habit of randomly deleting things that look like empty directories to them. | 12:12 |
| loxs[] | yeah, and they start to recover from the backups :) | 12:12 |
| loxs[] | it happened today :) | 12:13 |
| LarstiQ | doh. | 12:13 |
| LarstiQ | loxs[]: but even if they do, you have a branch of your own and can easily recreate the central branch, there is nothing special about it perse. | 12:13 |
| loxs[] | how, LarstiQ ? | 12:14 |
| LarstiQ | loxs[]: if it so happens that they delete the central branch, from your copy just 'bzr push location/to/central' | 12:15 |
| loxs[] | hmm... I start to understand how much Bazaar rocks :) | 12:16 |
| LarstiQ | loxs[]: that will put the .bzr/ back in place. Won't give you a working tree (but since in this scenario the dir got deleted because your colleagues didn't see a working tree anyway, no problem) | 12:16 |
| * LarstiQ heads off to visit his dentist. | 12:18 | |
| loxs[] | one more question.... let's say I checkout a branch.... then I checkout from the checkout.... What happens if I try to commit in the 'grandchild'? | 12:30 |
| LarstiQ | loxs[]: bzr will complain that what you're trying to commit to is bound to something else in turn. | 12:33 |
| jelmer | LarstiQ, your dentist has IRC ? :-P | 12:34 |
| jelmer | james_w, do you think it would be possible to get bzr-svn 0.4.12 into Intrepid? | 12:37 |
| uws | LarstiQ, loxs[]: what I do with branches on shared storage with empty directories (i.e. no working tree), is putting a README file in there explaining that ppl shouldn't removed the directory | 12:38 |
| loxs[] | that's exactly what I'm doing at the moment uws :) | 12:38 |
| uws | something like "This is a Bazaar branch without a working tree. All files are in the .bzr/ directory. Please do not delete it." | 12:38 |
| LarstiQ | jelmer: it seems I failed at getting away. | 12:42 |
| james_w | jelmer: possible yes, you'd have to ask | 12:58 |
| vila | damn, is there a way to cancel a pqm-submission ? | 12:58 |
| beuno | vila, move the submitted branch? :p | 12:59 |
| beuno | hi :) | 12:59 |
| jelmer | vila, get some canonical sysadmin to knock over the pqm machine? :-P | 12:59 |
| vila | I just reviewed http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20080712104527.GA16321%40mutt.xyzz.org%3E and after sending the submission I realized there was a related bug and in the comments it was decided to wait for other fixes | 13:00 |
| vila | beuno, jelmer: yeah thanks for the support :) | 13:00 |
| LarstiQ | hmm, iirc in the past I had the queue edited | 13:01 |
| LarstiQ | vila: I don't recall any other support for it | 13:02 |
| vila | I just commited on that branch some sabotage that should make the submission fail, hopefully | 13:02 |
| vila | LarstiQ: Hi ! | 13:02 |
| vila | I know a lot of work has occurred on pqm but I think we still use an old version | 13:03 |
| vila | but I'm not sure the queue handling has been developed anyway | 13:03 |
| * LarstiQ nods | 13:03 | |
| LarstiQ | vila: hey :) | 13:03 |
| vila | damn, pqm catch my branch to soon :-( | 13:07 |
| vila | s/catch/merged from/ | 13:07 |
| vila | jam: any advice ? | 13:07 |
| vila | me/ reads 'LarstiQ heads off to visit his dentist.' and wonders what the point is to visit a dentist without its head... | 13:09 |
| vila | s/its/his/ | 13:09 |
| uws | vila: ever heard of handheld devices with an internet connection? ;) | 13:11 |
| vila | uws: you mean Larstiq's head is hand held ? | 13:13 |
| LarstiQ | vila: 'heads off (to)' is an idiom for going away/somewhere. | 13:14 |
| LarstiQ | uws: nah, I'm still at home. | 13:14 |
| LarstiQ | vila: earlier today a jawsurgeon removed two wisdomteeth, now I'd like to bring the OPG photos back to my dentist. | 13:15 |
| uws | LarstiQ: dus je pwaat een beetje mwoeilijk? | 13:15 |
| LarstiQ | uws: it's not that bad, it's surprisingly easy to talk through clenched teeth. | 13:16 |
| vila | especially on IRC... | 13:17 |
| LarstiQ | :) | 13:17 |
| uws | only bad thing is that you only have half of your wisdom left. | 13:17 |
| LarstiQ | they'll be gone the 8th of october. | 13:20 |
| quicksilver | vila: I believe LarstiQ removed his head and sent *only* that to the doctor. | 13:21 |
| quicksilver | vila: cheaper. | 13:21 |
| quicksilver | dentist. | 13:21 |
| quicksilver | whatevr. | 13:21 |
| vila | quicksilver: aaah, I thought the dentist connected via internet or something | 13:22 |
| vila | jam: should I re-submit with a reversed patch ? | 13:24 |
| lifeless | vila: what happened ? | 13:24 |
| vila | I just reviewed http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20080712104527.GA16321%40mutt.xyzz.org%3E and after sending the submission I realized there was a related bug and in the comments it was decided to wait for other fixes | 13:25 |
| vila | :-/ | 13:25 |
| lifeless | did you munge the branch ? | 13:26 |
| lifeless | or has pqm landed it ? | 13:26 |
| vila | pqm is currently running the tests, I tried modifying my branch but it was too late | 13:26 |
| lifeless | ok | 13:26 |
| vila | rats, pqm has already finished :-( | 13:27 |
| lifeless | its not running anything :P | 13:27 |
| lifeless | reset | 13:28 |
| vila | lifeless: merged on http://bazaar-vcs.org/bzr/bzr.dev, I just received the 'success' mail from pqm | 13:31 |
| lifeless | yes | 13:32 |
| lifeless | I just uncommitted | 13:32 |
| vila | lifeless: thanks ! problem closed ? | 13:32 |
| lifeless | should be :P | 13:32 |
| vila | pfew | 13:33 |
| vila | sorry for that :-/ | 13:33 |
| === mw|out is now known as mw | ||
| lifeless | jam: bug 262565 - I think its falling between us right now, please let me know if you need me to dive into it (though its a little daunting) | 14:24 |
| ubottu | Launchpad bug 262565 in bzr "Old resolved conflicts resurrected" [Undecided,New] https://launchpad.net/bugs/262565 | 14:24 |
| alsuren | I have a project in bzr, and I would like to add 2 levels of directories above my current top level directory (for buildsystem and python namespace package support) | 14:57 |
| alsuren | what's the best way to do this? | 14:58 |
| sabdfl | alsuren: make the directory, then bzr add it | 15:02 |
| alsuren | and then just move everything from my tree into that directory? | 15:03 |
| alsuren | will that fuck up my bzr ignore rules? | 15:03 |
| Peng_ | alsuren: Sure, but you can edit .bzrignore. | 15:06 |
| Peng_ | If subtrees weren't all experimental, you could create a new branch and use "bzr join". Hm. | 15:07 |
| alsuren | when are subtrees going to become mainstream? | 15:09 |
| alsuren | I think I might just just keep the namespace package hierarchy out of version control for now | 15:10 |
| Peng_ | It's normal to have "build" and "mypackage" dirs in your source control. | 15:11 |
| alsuren | I know. I will put them in once I have it working outside of version control. Right now, I'm adding a testing framework | 15:13 |
| === mark1 is now known as markh | ||
| === kiko is now known as kiko-phone | ||
| === AnMaster_ is now known as AnMaster | ||
| techtonik | Hmm.. Is it possible to change commit message in bazaar history without reverting and recommiting all changes? | 16:42 |
| techtonik | Also, how can I delete one revision from repository in a convenient way? | 16:47 |
| Jc2k | techtonik: bzr uncommit? | 16:48 |
| Jc2k | uncommit deletes a revision | 16:48 |
| Jc2k | uncommit is probably also the easiest way to chage a commit message, but does mean you are effectively reverting and recommitting.. | 16:49 |
| techtonik | df | 16:50 |
| techtonik | I need to change log message deep in history | 16:50 |
| SteveA | hi | 16:51 |
| techtonik | uncommit reverts only last revision | 16:51 |
| SteveA | I have a branch, and I want to make a bundle of the last 2 committed revisions | 16:51 |
| xif | Hi. | 16:51 |
| SteveA | I tried to use bzr send and bzr bundle, with -r-2.. | 16:51 |
| SteveA | but, it gives me an error "bzr: ERROR: No submit branch known or specified" | 16:52 |
| xif | Is there a way to set a bzr branch, so that `bzr st` would always imply `bzr st -V`? | 16:52 |
| ajaksu | çç | 16:53 |
| ajaksu | oops | 16:53 |
| techtonik | xif: to hide unversioned files branchwide use "bzr ignore" | 16:54 |
| xif | techtonik: hm, but then I'd need to `bzr ignore` any new file added to the branch, right? | 16:55 |
| jam | SteveA: generally with send, you just want to keep 2 branches | 16:57 |
| techtonik | xif: you need to ignore only files that you do not want to be added to branch, but still present in your working copy | 16:57 |
| jam | one as a mirror of theirs | 16:57 |
| jam | and the other as your working branch | 16:57 |
| SteveA | jam: is 'send' the same as 'bundle' ? | 16:57 |
| jam | SteveA: not entirely | 16:57 |
| jam | they create the same kind of objects | 16:57 |
| techtonik | xif: and you may use file masks | 16:57 |
| jam | but have a slightly different ui | 16:57 |
| jam | and "bzr bundle" itself is mostly deprecated | 16:57 |
| SteveA | all I want really is a command which means "create a bundle out of revisions 9 and 10 of this branch" | 16:57 |
| jam | SteveA: so unfortunately that is | 16:58 |
| techtonik | me too. | 16:58 |
| jam | bzr branch -r 8 . ../other_tip | 16:58 |
| jam | bzr send ../other_tip -o ../outputfile.patch | 16:58 |
| SteveA | why do I need ../other_tip? | 16:58 |
| jam | SteveA: because abentley wants to make sure you include the right revisions in the request | 16:58 |
| jam | he felt it was too easy to send the wrong ones | 16:58 |
| SteveA | that's kinda confusing | 16:58 |
| jam | so he requires another branch to reference | 16:58 |
| jam | SteveA: If you try "bzr send -r 8..10 ." | 16:59 |
| SteveA | I feel like I just made these revisions, and now I want to send them :-) | 16:59 |
| jam | it would see that all revisions are in the branch | 16:59 |
| jam | and send an empty bundle | 16:59 |
| techtonik | confusing a lot | 16:59 |
| SteveA | hmm, trailing dot | 16:59 |
| SteveA | ok | 16:59 |
| xif | techtonik: OK, is there a simple way to tell bzr to ignore everything except foo.py and bar.py? | 16:59 |
| jam | SteveA: abentley basically feels that people make mistakes, so he wants you to use an explicit branch for reference | 16:59 |
| SteveA | I think this is a UI mistake | 16:59 |
| jam | SteveA: we've had a lot of discussions on it, I'm hoping to invoke him now :) | 17:00 |
| SteveA | because I'm trying to explain to someone a really simple workflow of "you make revisions, then you send them to me" | 17:00 |
| abentley | SteveA: Not requiring a branch was a bigger UI mistake. | 17:00 |
| SteveA | and now I need to say "you track my branch and you do other stuff" | 17:00 |
| jam | One suggestion was that a bundle should always include the explicitly referenced revisions | 17:00 |
| * LarstiQ does agree with abentley that it's very easy to make bundles that won't apply | 17:00 | |
| abentley | Because people kept submitting bundles that were unusable. | 17:00 |
| SteveA | I don't really mind if the bundles won't apply | 17:00 |
| SteveA | I can just ask for more revisions | 17:00 |
| SteveA | not a problem in my case | 17:00 |
| SteveA | I can see it being a problem in the "a community of loosely collaborating people" case | 17:01 |
| abentley | SteveA: The whole point of bundles is to be mergeable. Perhaps you want patches instead. | 17:01 |
| xif | techtonik: OK, looking at the bzr ignore docs, looks like there should be. thanks. | 17:01 |
| SteveA | I don't think I want a normal patch | 17:01 |
| SteveA | I want to be able to re-merge the other way too | 17:01 |
| SteveA | so, I'm now confused as to what I need to do | 17:02 |
| jam | SteveA: so Aaron's point is that if you don't mirror their branch | 17:02 |
| jam | then you'll sometimes guess wrong | 17:02 |
| abentley | SteveA: "bzr bundle" is a strict subset of "bzr send". They use the same implementation. | 17:02 |
| jam | and you'll actually need 7-9 | 17:02 |
| jam | rather than just 8-9 | 17:02 |
| techtonik | xif: only with regexps - i.e. "RE:(?!foo.py|bar.py)" | 17:02 |
| jam | and the bundle won't actually be usable | 17:02 |
| xif | techtonik: yup :) thanks. | 17:02 |
| jam | until they request again | 17:02 |
| SteveA | if I've got the other branch, maybe I can just say "bundle what's missing" ? | 17:02 |
| jam | *I* feel like that is ok | 17:02 |
| jam | SteveA: If you do "bzr send ../other-branch" it will do the right thing | 17:02 |
| SteveA | that would make it worth tracking the other branch | 17:02 |
| jam | And once you've done a send | 17:03 |
| SteveA | ok | 17:03 |
| jam | I believe it will default to tracking the other branch | 17:03 |
| jam | so you can just do "bzr send" | 17:03 |
| SteveA | ok | 17:03 |
| jam | (no arguments) | 17:03 |
| jam | You need a shared repo, for efficiency at this point | 17:03 |
| jam | which is a level of complexity... | 17:03 |
| SteveA | oh, that means moving directory structures around | 17:03 |
| abentley | jam: Or stacking :-) | 17:03 |
| techtonik | abentley: I want patches. 10-15 patches - one for each revision to apply them carefully one by one. | 17:03 |
| SteveA | this is a small project | 17:04 |
| SteveA | so I think having 2 duplicated branches is okay | 17:04 |
| techtonik | abentley: ..after I change my log message | 17:04 |
| abentley | techtonik: Perhaps you should have a look at the "rebase" plugin. | 17:04 |
| SteveA | thanks jam and abentley | 17:05 |
| abentley | SteveA: np | 17:05 |
| abentley | SteveA: We do get occasional complaints like yours. My current plan is to add a "--base-revision" parameter. That revision and all its decendents which are ancestors of the tip revision would then be included in the bundle. If supplied, it would remove the need for a branch. | 17:08 |
| Snaury | Hello, can I replay changes in one branch on another branch without doing merge? (the branches are unrelated, it's just that the same project was started from the same sources again, i.e. it's as if the old .bzr directory was removed and a new bzr init was done, now I'm trying to merge those histories) | 17:08 |
| SteveA | abentley: ok. I tried -r | 17:08 |
| techtonik | abentley: sounds complicated.. and there is no windows version. I just need to fix one little revision (or better replace it with another revision) deep in history without reverting and recommiting all subsequent revisions manually. | 17:08 |
| SteveA | abentley: I wouldn't have thought to try --base-revision | 17:08 |
| xif | techtonik: looks like `bzr ignore 'RE:(?!foo.py|bar.py).*' works | 17:09 |
| xif | though I wonder why `bzr ignore 'RE:(?!foo.py|bar.py)$'` did not. | 17:10 |
| abentley | SteveA: Well, I agree that it should be *possible* to override the auto-determination of which branches to include. I don't think it's the right default. I'm open to other ideas of how to make it possible. | 17:11 |
| abentley | SteveA: s/branches/revisions | 17:13 |
| techtonik | xif: because former is assertion that says "ignore everything that does not have foo.py or bar.py at start" and latter says "ignore empty strings if they are not prepended by foo.py or bar.py" | 17:17 |
| abentley | techtonik: what you are asking for is exactly what rebase was designed to do. Are you sure that you need a windows-specific version? | 17:18 |
| SteveA | abentley: how will the other guy keep his copy of my branch up to date, when I'm also sending him bundles? | 17:18 |
| SteveA | abentley: does he have to know that he pulls every bundle I send him into his copy of my branch, and then merges my branch into his own branch? | 17:19 |
| abentley | SteveA: If there's no public copy of your branch, that would make sense. | 17:19 |
| SteveA | ok | 17:19 |
| techtonik | well, I am on windows 2000 and virtualbox ceased support for this platform, so I am pretty sure I do not have any other systems at hand right now | 17:19 |
| abentley | techtonik: Most bzr plugins work on all platforms. Are you sure that rebase does not? | 17:20 |
| techtonik | abentley: Oh, sorry. I've forgot the bzr is in Python. Usually windows stuff is not distributed in sources, so when I looked at page with variuos Linux packages I thought it is not there. Will check this tomorrow. Thanks. Unfortunately need to go. | 17:22 |
| xif | OK, is there anything one should do, beyond deleting the .bzr directory, to turn a Bazaar branch into a regular directory of files? | 17:25 |
| luks | `bzr export` can make a new directory | 17:26 |
| Jc2k | you could also just do bzr export | 17:26 |
| Jc2k | snap | 17:26 |
| jam | vila: on the "make init-repo take '.'" did you read the ML thread? | 17:27 |
| jam | I was pretty sure we decided *not* to merge it | 17:27 |
| jam | because of problems with accidentally creating a repo at the wrong location. | 17:27 |
| xif | right, but if I don't want to create a new copy of the directory, just stop versioning it, I should just remove .bzr, correct? | 17:27 |
| vila | jam: yup, but I read it too late, AFAIK lifeless uncommit it from bzr.dev | 17:28 |
| jam | vila: ok, I just saw it in the commit logs | 17:28 |
| jam | bazaar-commits@ | 17:28 |
| vila | I tried sabotaging my integration branch when I realized but too late too :) | 17:29 |
| SteveA | abentley: still having problems | 17:30 |
| SteveA | bzr: ERROR: Your branch does not have all of the revisions required in order to merge this merge directive and the target location specified in the merge directive is not a branch: ../steve_branch | 17:30 |
| vila | I also voted resubmit on the submission in to avoid further overzealous reviewers :-/ | 17:30 |
| SteveA | that was from trying this workflow where we both have a copy of each other's branch, and we pull bundles into that branch, then merge from our local copy of the other's branch | 17:31 |
| SteveA | it worked for 0.75 of a cycle | 17:31 |
| SteveA | then I got that error | 17:31 |
| SteveA | ../steve_branch is the name of the local copy of my branch on the other guy's machine | 17:32 |
| SteveA | so I don't know why I'm seeing that in the error message on my machine | 17:32 |
| jam | vila: I don't see it on "bzr log" though, so it sounds like he did uncommit it | 17:33 |
| jam | and yeah, thanks for doing resubmit | 17:33 |
| vila | jam: yup, same here | 17:33 |
| LarstiQ | SteveA: 'the target location specified in the merge directive is not a branch' looks a bit suspect. | 17:35 |
| SteveA | for some reason, when I do "bzr pull /tmp/bundle5.diff", it's looking at ../steve_branch as part of doing that | 17:36 |
| SteveA | and sure enough, in bundle5.diff, there is the line | 17:36 |
| SteveA | target_branch: ../steve_branch | 17:36 |
| SteveA | I don't understand what that means though | 17:37 |
| SteveA | that's a local branch of the guy who sent me the bundle | 17:37 |
| SteveA | and now I have the bundle, I obviously don't have that local branch | 17:37 |
| SteveA | if he was going to send me that branch anyway, then I wouldn't need the bundle at all | 17:37 |
| jam | LarstiQ, SteveA: That is the "fallback" code, which attempts to use a "public branch" to fill in any revisions you might be missing. | 17:38 |
| jam | I believe it uses: | 17:38 |
| jam | 1) Revisions in the target | 17:38 |
| jam | 2) revisions in the bundle | 17:38 |
| jam | 3) Revisions in the "public branch" of the submitted directive | 17:39 |
| vila | SteveA: I used that exact workflow on a previous project, setting things up was a bit painful, but once we had correct mirrors of each other, it worked flawlessly | 17:39 |
| jam | The idea being, if you've published your branch (as most people do *for bzr*) | 17:39 |
| jam | then even if the MD isn't complete | 17:39 |
| jam | we can still fill in the gaps | 17:39 |
| jam | In this particular case, I'm not sure if the error message is helpful or just confusing. | 17:39 |
| vila | The trick is to lie to bzr making it believe that one mirror is really the branch of the other guy | 17:40 |
| SteveA | jam: this is not public code | 17:40 |
| jam | SteveA: I understand that | 17:40 |
| jam | I'm giving you the logic that is used when merging a bundle | 17:41 |
| vila | May be I should have talked about it on the list so that *this* workflow is easier to setup, but I thought it was really an obsur edge case | 17:41 |
| SteveA | jam: and I thought using bundles would be an easy way for us to exchange revisions | 17:41 |
| jam | vila: It would be good to have it clearly documented | 17:41 |
| jam | SteveA: I think it should work | 17:41 |
| jam | we just need to figure out what steps you are doing | 17:41 |
| vila | I have it clearly documented :-) In french but easy enough to translate | 17:41 |
| abentley | jam: 3) is actually the target_branch in the directive. | 17:41 |
| SteveA | I started off doing a bzr branch http://hismachine/thebranch | 17:41 |
| SteveA | because we're in the same office | 17:41 |
| SteveA | and I can do that now | 17:41 |
| SteveA | from that point on, assume we're disconnected, and have only email | 17:42 |
| abentley | SteveA: It is only trying to use the target branch because the bundle was incomplete. It would otherwise just use the bundle. | 17:42 |
| SteveA | I need to go now, unfortunately. vila, if you get this online somewhere in english, please let me know, and I'll try it out | 17:44 |
| jam | abentley: right, I'm trying to figure out how an incomplete bundle was generated. | 17:44 |
| jam | My first guess is that the revisions are in "mybranch" but not in "mymirror" | 17:44 |
| jam | because he isn't using a shared repo | 17:44 |
| vila | jam: I didn't use a shared repo and it worked | 17:44 |
| jam | vila: did you ever fetch the revisions between the two branches? | 17:45 |
| jam | with a fake "bzr merge" | 17:45 |
| jam | etc | 17:45 |
| vila | No, but I had trouble at first because he didn't have an exact mirror of my branch | 17:45 |
| jam | I know how I would set it up and expect it to work | 17:45 |
| jam | but as I didn't actually test it | 17:45 |
| jam | I'm hesitant to give exact details | 17:45 |
| loxs | folks, I have a problem. I create a repo with bzr init-repo --no-tree sftp://bla. Then I push a branc: cd branch, bzr push sftp://bla/branch. After I checkout the branch from somewhere else with bzr co sftp://bla/branch I get the following structure /branch/branch/content instead of /brach/content | 17:48 |
| vila | jam: The trick is that since there is no public branch to share, each site needs to keep a mirror of the other one and work in its own branch. Then each site needs to name its mirror as the branch of the other site and use *relative* paths to trick bzr. | 17:49 |
| vila | then, the workflow is as SteveA said: pull in mirror, merge | 17:50 |
| jam | vila: sounds like a bug in our code | 17:51 |
| jam | if you have to do the naming trick | 17:51 |
| jam | I would be happy for you to document it | 17:52 |
| jam | write a bug | 17:52 |
| jam | and have us fix it | 17:52 |
| loxs | vila, jam, are you talking about my case? because I suppose so, but I am not very sure :) | 17:52 |
| jam | loxs: no | 17:52 |
| jam | I have the feeling you did your "init + add" incorrectly locally | 17:52 |
| jam | specifically you should do: | 17:52 |
| jam | mkdir local | 17:52 |
| jam | cd local | 17:52 |
| jam | copy content here | 17:53 |
| jam | bzr init | 17:53 |
| jam | bzr add content | 17:53 |
| jam | bzr commit -m "content" | 17:53 |
| jam | loxs: make sure that doing | 17:53 |
| vila | jam: bug ? Because we don't expand the relative path into a full one in the bundle header ? | 17:53 |
| jam | "bzr branch local_branch another_location" | 17:53 |
| jam | vila: because pulling bundles into a local mirror fails to get things that it really does want | 17:53 |
| jam | vila: you should be able to track someones branch | 17:53 |
| jam | without having to play tricks with your local branch names | 17:54 |
| jam | now, it *may* be that using a shared repo solves it well enough that we'll defer fixing the bug | 17:54 |
| jam | but if someone does "bzr send ../my-mirror-of-them" I would expect them to be able to do | 17:54 |
| jam | "cd the_real_other_branch; bzr pull the-patch" | 17:54 |
| jam | sorry, | 17:54 |
| jam | bad terminology | 17:55 |
| loxs | yeah, still wondering are you talking about my case or not :) | 17:55 |
| jam | User A has 2 branches: mirror-of-B, A | 17:55 |
| jam | loxs: I'm talking to 'vila', not your use case, I did mention one thing, but I'll come back to you in a bit | 17:55 |
| jam | User B has 2 branches: mirror-of-A, B | 17:55 |
| jam | They *should* be able to collaborate with only doing: | 17:56 |
| jam | cd B | 17:56 |
| jam | bzr send -o ../mirror-of-A | 17:56 |
| jam | and on the other side | 17:56 |
| jam | cd A | 17:56 |
| jam | sorry | 17:56 |
| loxs | ok, jam... but please be so kind to tell me "loxs, now I'm talking about your case" :) | 17:56 |
| jam | cd mirror-of-B | 17:56 |
| jam | bzr pull | 17:56 |
| jam | cd ../A | 17:56 |
| jam | bzr merge ../mirror-of-B | 17:56 |
| jam | bzr commit -m "merge in other user" | 17:56 |
| jam | loxs: ok, back to you.... | 17:57 |
| jam | loxs: step 1) do "bzr branch my_branch other_location" | 17:57 |
| jam | and see if that creates a subdirectory "branch" that you don't want | 17:57 |
| jam | if so, | 17:57 |
| jam | then you did your "init + add" in the wrong directories | 17:57 |
| loxs | I didn't do init+add.. I did a push | 17:57 |
| loxs | isn't it a good way to do it? | 17:58 |
| jam | loxs: When you *started* you did init + add | 17:58 |
| jam | or you would have *nothing* to push | 17:58 |
| jam | (you also did 'commit') | 17:58 |
| jam | I'm saying | 17:58 |
| jam | create a new branch from what you've already done | 17:59 |
| jam | *without* pushing to the remote machine | 17:59 |
| jam | I believe you accidentally included the branch directory | 17:59 |
| loxs | the thing is that I already have a nice repository that I was working with... and it is quite fine tuned... now I want to push it to a central server | 17:59 |
| vila | jam: I see, what I did was setting up things so that people could do: 'cd mirror; bzr pull <path-to-patch>; cd ../branch ; bzr merge' and then 'hack; hack; commit; bzr send' without any parameter to type for 'bzr merge' nor 'bzr send' kind of bzr for dummies, I was in a hurry :) | 17:59 |
| loxs | but yte, I'll inspect my repository | 17:59 |
| loxs | *yes | 17:59 |
| jam | vila: sure, and I want that to work without having to follow an exact formula with branch names. | 18:00 |
| jam | "bzr send" defaults to the "submit_location" | 18:00 |
| jam | which is used by "bzr merge" | 18:00 |
| jam | so it *should* remember everything just fine | 18:00 |
| jam | (after the first time) | 18:00 |
| jam | At least, the default changed recently, not sure if that was 1.5 or 1.6 | 18:01 |
| vila | I think I made them work with bzr-1.3, but *I* was working with bzr.dev | 18:02 |
| * vila coming from kitchen | 18:09 | |
| vila | jam: Isn't it possible for SteveA to use a private branch on lp ? | 18:10 |
| vila | We should support this alternate workflow but using a private branch can be easier no ? | 18:10 |
| * vila going back to kitchen | 18:11 | |
| jam | vila: well, using a semi-public (aka lp private) branch is certainly easier for this sort of thing | 18:11 |
| jam | but I *would* really like to have pure email | 18:11 |
| jam | as the transport between two branches | 18:11 |
| jam | and have it work | 18:11 |
| === kiko-phone is now known as kiko | ||
| === frej_ is now known as frej | ||
| luks | hmm, 1.7 has feature freeze today, who can I bribe to get my register_lazy_command reviewed? :) | 19:04 |
| abentley | luks: Do you think that the existing Registry.register_lazy wouldn't work, or did you just not want to do it? | 19:17 |
| luks | abentley: the main problem are aliases, it would need a subclasses which stores also aliases and allows to look them up | 19:19 |
| luks | as far as I can tell, registries are currently just key/value, key/lazy-value | 19:19 |
| luks | s/subclasses/subclass/ | 19:20 |
| loxs | folks, is there a way to specify a user when using bazaar over sftp? | 19:21 |
| abentley | luks: Registries are not just key/value, they are key/value + help + info | 19:22 |
| abentley | luks: info is meant to contain additional metadata, like aliases. | 19:22 |
| luks | oh | 19:22 |
| rocky | anyone here know of a web server component written that will serve loggerhead for browser access but serve actual smart server responses for direct bzr branch access? | 19:22 |
| luks | abentley: ok, I see how it could work. but still I'd really like if 1.7 could get at least some register_lazy_command | 19:24 |
| luks | it's probably too late for me to submit a patch that uses this approach | 19:25 |
| luks | the current patch just extends the API, doesn't change anything so can't introduce any regressions | 19:25 |
| abentley | luks: I have some sympathy, but on the other hand, I first suggested this approach on Aug 26, and there was lots of time then. | 19:31 |
| abentley | So I suggest keeping it in your plugin, and doing it right in 1.8 | 19:31 |
| luks | abentley: well, lifeless suggested the LazyObjectGetter approach, and you voted just comment, so I assumed it's not ideal, but good enough | 19:35 |
| luks | er, abstain | 19:35 |
| abentley | luks: Abstain means I don't want it in, but if other people think it's a good idea, I won't stand in their way. | 19:37 |
| luks | ah, I read it more like "I don't care enough about this" | 19:37 |
| abentley | luks: Well, since lifeless suggested this approach, perhaps he'll review it for you. He should be up in a couple hours. | 19:38 |
| loxs | is there a way to make bzr write some 'standard' data in the beginning of every file? things like licensing information, last commiter of the file etc.? | 19:53 |
| === thekorn_ is now known as thekorn | ||
| === emgent`NL is now known as emgent`nl | ||
| Odd_Bloke | jelmer: I'm getting http://paste.pocoo.org/show/84210/ when trying to pull bzr-svn trunk. | 20:45 |
| jelmer | Odd_Bloke, are you pulling into a subtree repository by any chance? | 20:45 |
| Odd_Bloke | Yes. | 20:46 |
| Odd_Bloke | jelmer: Should I do a fresh branch of it? | 20:46 |
| jelmer | Odd_Bloke, there was a bug open about this | 20:47 |
| jelmer | Odd_Bloke, try branching into a rich-root-pack repo | 20:47 |
| Odd_Bloke | jelmer: Cool, thanks. :) | 20:48 |
| jelmer | Odd_Bloke, I'm pushing a lot more changes you probably want | 20:59 |
| jelmer | hmm, this is getting ridiculous | 21:07 |
| jelmer | pushing a new tree into my remote bzr repository now spends about half its time pushing signatures | 21:07 |
| Jc2k | jelmer: is that a sign that bzr is getting faster at the vanilla pushing :P? | 21:13 |
| jelmer | Jc2k, could be (-: | 21:14 |
| Jc2k | :-) | 21:14 |
| jelmer | imo pushing is still way too slow compared to e.g. git | 21:14 |
| jelmer | with bzr, I find myself switching to a different terminal when I run bzr push | 21:14 |
| jelmer | with git push, I just wait for it to finish | 21:14 |
| Jc2k | i have a little bit of evolution weirdness | 21:16 |
| jelmer | Jc2k, ? | 21:16 |
| Jc2k | bzr info -v on the repository is shwoing 36889 revisions | 21:16 |
| Jc2k | http://bzr-mirror.gnome.org/bzr/evolution/.bzr.log shows 36246 revisions | 21:16 |
| jelmer | if a svn commit changes multiple branches in svn, it ends up being more than one revision in bzr | 21:18 |
| jelmer | e.g. if somebody changes both /trunk and /branches/foo in the same commit | 21:18 |
| Jc2k | i suppose 600 occurences of that isnt that often in evolution terms... | 21:19 |
| jelmer | some svn commits don't result in bzr commits at all | 21:19 |
| jelmer | e.g. if they change just the branches directory (nothing under it) | 21:19 |
| jelmer | or if they add a tag (since tags aren't versioned in bzr) | 21:20 |
| === sabdf1 is now known as sabdfl | ||
| radix | Odd_Bloke: hi, did you work on merge directives for PQM? | 22:04 |
| Odd_Bloke | radix: Yup. | 22:08 |
| radix | Odd_Bloke: does it require use of PGP/MIME? | 22:08 |
| radix | odd_bloke: the reason I ask is that I got this error: PQMException: 'Second part of multipart message must be application/pgp-signature' | 22:10 |
| Odd_Bloke | radix: Nope, inline is fine. | 22:11 |
| radix | hmm, then what's with the error? | 22:11 |
| Odd_Bloke | radix: You can only send multipart messages if the first part is the content and the second part is application/pgp-signature. | 22:11 |
| Odd_Bloke | And even that's not recommended. | 22:11 |
| radix | oh, so if my message happens to be multipart it will assume it's going to be PGP/MIME? | 22:11 |
| Odd_Bloke | Yeah, afraid so. | 22:11 |
| radix | Hmm, I don't think I *tried* to send a multipart message, but who knows what evolution does | 22:12 |
| radix | maybe thunderbird is less weird | 22:12 |
| jbalint | hey | 22:13 |
| Odd_Bloke | radix: Bug #264139. | 22:17 |
| ubottu | Launchpad bug 264139 in pqm "PQM doesn't deal with multi-part messages well" [Undecided,New] https://launchpad.net/bugs/264139 | 22:17 |
| radix | Odd_Bloke: cool, thanks. hopefully I won't need to wait for it to be resolved :) | 22:17 |
| Odd_Bloke | No. | 22:18 |
| Odd_Bloke | I've finished for the summer, so that could be a while. :p | 22:18 |
| radix | :) | 22:18 |
| LarstiQ | Odd_Bloke: move to the southern hemisphere! | 22:23 |
| Odd_Bloke | radix: It occurs to me that you need to make sure that the merge directive is in the body of the message, rather than attached. Which may be your problem... | 22:23 |
| Odd_Bloke | LarstiQ: Commuting to Rugby is bad enough from Coventry, let alone south of the equator. :p | 22:23 |
| radix | Odd_Bloke: the strange thing is that I tried using the "editor" email program and signed the message inline but got the same error | 22:24 |
| radix | Odd_Bloke: I'm going to try again | 22:24 |
| Odd_Bloke | radix: Try using 'bzr send -o <FILE>' and copying the contents of <FILE> directly into your email client. | 22:26 |
| radix | Odd_Bloke: hmmm | 22:31 |
| radix | Odd_Bloke: does it support base64-encoded data? | 22:31 |
| radix | apparently "gpg --sign --armor" will encode stuff in base64 automatically if it's got "weird" stuff in the body | 22:32 |
| Odd_Bloke | radix: What do you mean by 'base64-encoded data'? | 22:34 |
| Odd_Bloke | Bundles are base64-encoded, and it obviously supports those. :p | 22:34 |
| LarstiQ | Odd_Bloke: what does pqm do if the merge-directive is base64 encoded entirely? | 22:34 |
| radix | Odd_Bloke: like this: | 22:34 |
| radix | -----BEGIN PGP MESSAGE----- | 22:35 |
| radix | Version: GnuPG v1.4.6 (GNU/Linux) | 22:35 |
| radix | owGVUz1vFDEQPRIhoZUojoZ2EooApz28X3eblaIExAkKTgpJKpLo5LV9t0527Y3X | 22:35 |
| radix | etc. | 22:35 |
| Odd_Bloke | I expect it falls over. | 22:35 |
| radix | If you sign "hello world" it just adds the usual header/footer, but if you sign "====\n----" it base64s it | 22:36 |
| radix | presumably because that stuff could be misinterpreted as the header or footer for the pgp thing, so it's just encoding it to avoid misinterpretation | 22:37 |
| radix | Odd_Bloke: it looks like you're also working on the XMLRPC interface... I'd so much rather use that :) | 22:38 |
| Odd_Bloke | radix: I suggest passing '--no-patch' to 'bzr send'. | 22:38 |
| radix | ah, I'll try it | 22:38 |
| Odd_Bloke | Because PQM doesn't (or, at least, shouldn't) be using the patch. | 22:38 |
| radix | hmm, it seems to base64 it anyway. I guess it's really conservative. There are things like the "--- this line and the following will be ignored", not to mention all the headers etc | 22:39 |
| radix | well, I don't think I need to do it this way anyway | 22:40 |
| radix | I was just trying to get it working in editor | 22:40 |
| Odd_Bloke | radix: Isn't --armor _meant_ to base64 it? | 22:41 |
| radix | Odd_Bloke: not always | 22:41 |
| radix | --armor means "use ascii not binary", where binary output is the default | 22:41 |
| radix | i.e. stuff which will require you to type "reset" in your terminal | 22:42 |
| radix | oh, crap | 22:42 |
| radix | I think I am wrong about that | 22:42 |
| Odd_Bloke | 'echo "foo" | gpg --sign --armor' gives me base64 encoded stuff. | 22:42 |
| radix | ok, I am on crack, sorry | 22:42 |
| Odd_Bloke | radix: No worries. | 22:43 |
| radix | I wonder how to get gpg to give me normal ascii output without base64ing | 22:43 |
| Odd_Bloke | You probably want '--clearsign'. | 22:43 |
| radix | Odd_Bloke: yes! thanks | 22:47 |
| radix | Odd_Bloke: btw, does your XMLRPC/PQM support allow multi-line commit messages, or does it have the same problem that the usual email mechanism has? | 22:47 |
| Odd_Bloke | radix: At the moment, it doesn't. | 22:48 |
| Odd_Bloke | But it would be much easier to add than with email. | 22:49 |
| radix | Odd_Bloke: sweet. | 22:50 |
| radix | Odd_Bloke: ok, for future reference, it seems that using "bzr send" with mail_client set to "editor" can't work, because it sends the merge directive as an attachment | 22:56 |
| Odd_Bloke | radix: Yeah, that's an issue. | 22:58 |
| Odd_Bloke | radix: If you could mention that on Bug #264139 it'd be appreciated. | 22:58 |
| ubottu | Launchpad bug 264139 in pqm "PQM doesn't deal with multi-part messages well" [Medium,Confirmed] https://launchpad.net/bugs/264139 | 22:58 |
| radix | cool | 22:58 |
| jam | Odd_Bloke: I posted a bunch of response questions to the "bzr speed" question. | 23:02 |
| jam | radix: are you doing "gpg --clearsign" rather than "--sign" ? | 23:04 |
| jam | sorry, you already got there :) | 23:04 |
| radix | jam: I am now, odd_bloke suggested that to me already :) | 23:04 |
| radix | :) | 23:04 |
| jam | radix: well, you just need to teach pqm about attachments | 23:05 |
| jam | considering that 90% of how you would send it | 23:05 |
| jam | would be with an email program that would use an attachment, too | 23:05 |
| radix | yeah | 23:05 |
| radix | also, "bzr send" seems to totally not work with thunderbird, for what it's worth | 23:05 |
| jam | and, I guess, that is bug #264139 | 23:06 |
| radix | it doesn't include the merge directive at all, somehow | 23:06 |
| ubottu | Launchpad bug 264139 in pqm "PQM doesn't deal with multi-part messages well" [Medium,Confirmed] https://launchpad.net/bugs/264139 | 23:06 |
| jam | radix: bug in thunderbird when spawned via the debian "default mail client" scripts | 23:06 |
| jam | we have a workaround, let me dig it up | 23:06 |
| radix | ah | 23:06 |
| jam | (you have to set the mail client to t-bird instead of default) | 23:06 |
| radix | jam: I did that too, it still doesn't seem to work | 23:07 |
| jam | radix: in bazaar.conf add the line | 23:07 |
| jam | mail_client = thunderbird | 23:07 |
| Odd_Bloke | jam: 'bzr pqm-submit' probably has a fair share of submissions. | 23:07 |
| radix | ops wait | 23:07 |
| radix | my bad | 23:07 |
| jam | Odd_Bloke: "submissions" ? | 23:07 |
| * radix had it commented out | 23:07 | |
| radix | hmm, it adds it as an attachment in thunderbird as well | 23:07 |
| jam | Odd_Bloke: I'm not sure what you mean by that sentence | 23:07 |
| radix | I predict this will break | 23:07 |
| radix | hmm, unless I use PGP/MIME, and hope that thunderbird adds the signature as the second part. | 23:08 |
| jam | radix: Mail.app, thunderbird, editor, etc, etc all use an attachment | 23:08 |
| jam | radix: for T-bird you can select whether you want it to sign just the first part, or the whole thing | 23:08 |
| jam | though I've encountered bugs with enigmime and signing attachments | 23:08 |
| jam | where sending it to myself | 23:08 |
| jam | it ends up thinking the signature is invalid... :( | 23:09 |
| jam | So I only sign the text documents now | 23:09 |
| jam | (not the attachments) | 23:09 |
| Odd_Bloke | jam: Sorry, I meant to say that I guess a lot of submissions to PQM would be using 'bzr pqm-submit' rather than 'bzr send'. | 23:10 |
| radix | so how do people use the merge directive support at all? | 23:10 |
| radix | it seems there's no configuration which can possibly send stuff that it will accept | 23:10 |
| * lifeless pops up | 23:11 | |
| radix | morning lifeless | 23:11 |
| Odd_Bloke | radix: 'bzr send -o <FILE>' and copying the contents of <FILE> into the body of the email should work. | 23:12 |
| radix | Odd_Bloke: ok, I'll try that one | 23:12 |
| radix | Odd_Bloke: hmm, where do I put the commit message in that case? | 23:12 |
| Odd_Bloke | radix: Subject line. | 23:12 |
| radix | d'oh! | 23:13 |
| * Spaz storms in | 23:13 | |
| radix | that defeats my reason for using merge directives :) | 23:13 |
| jam | radix: I've never used it. AFAIK Odd_Bloke's changes didn't make it into PQM mainline | 23:13 |
| radix | I want to have a multi-line commit message | 23:13 |
| jam | hi Spaz | 23:13 |
| radix | jam: oh, yeah, that's true, we're using the branch specifically | 23:13 |
| Spaz | hello jam :) | 23:13 |
| Odd_Bloke | radix: Yeah, that's not easily possible via email. | 23:13 |
| radix | because we love odd_bloke's code | 23:13 |
| Odd_Bloke | s/easily/trivially/ | 23:13 |
| jam | Odd_Bloke: well, it is easy to create multi-line subjects that PQM accepts | 23:14 |
| jam | look at the bzr.dev mainline | 23:14 |
| jam | it just does so by accident | 23:14 |
| jam | more than by intention | 23:14 |
| jam | (Subject lines are automatically wrapped by mail clients, and pqm just accepts them "as is") | 23:14 |
| radix | jam: hmm | 23:14 |
| radix | maybe we will resort to that :) | 23:14 |
| radix | jam: and it actually maintains the newlines that the mail clients introduce in the header? | 23:15 |
| jam | radix: "bzr log --short http://bazaar-vcs.org/bzr/bzr.dev -r 3679" | 23:15 |
| jam | multi-line commit | 23:15 |
| radix | great | 23:15 |
| jam | radix: from what I can tell, it maintains the newlines *and* indentations | 23:15 |
| radix | oh, which is a bit crappy :) | 23:15 |
| Odd_Bloke | radix: Where would you have expected the commit message to go with a merge directive submission? | 23:15 |
| radix | Odd_Bloke: when you run "bzr send" you get an area for typing a commit message before a "-- everything after this line will be ignored" | 23:16 |
| jam | Odd_Bloke: well, *I* would have put it in the body, possibly with a custom header, and then had the MD as an attachment :) | 23:16 |
| Odd_Bloke | Well, if your mail client doesn't include the indentations, then you're probably fine. | 23:16 |
| jam | Odd_Bloke: email RFC requires the indentations | 23:16 |
| jam | or it is not part of the previous line | 23:16 |
| Odd_Bloke | Ah, OK. | 23:17 |
| jam | lines starting with spaces are meant to be wrapped back into the previous line | 23:17 |
| jam | PQM doesn't really follow a lot email RFC | 23:17 |
| Odd_Bloke | Yeah, that's what I was just thinking. :p | 23:17 |
| Odd_Bloke | Anyhow, I have to head to bed. | 23:18 |
| lifeless | well | 23:18 |
| radix | Odd_Bloke: thank you very much for the help | 23:18 |
| Odd_Bloke | What with having a job and all. :o | 23:18 |
| radix | even though it led to me giving up on PQM for a bit more :) | 23:18 |
| lifeless | Odd_Bloke: gnight | 23:18 |
| Odd_Bloke | radix: No worries, sorry I couldn't be of more help. | 23:18 |
| Odd_Bloke | Night all! | 23:18 |
| gigi-gigi | ciao | 23:19 |
| gigi-gigi | !list | 23:19 |
| ubottu | Hi! I'm #bzr's favorite infobot, you can search my brain yourself at http://tinyurl.com/5zfb6t - Usage info: http://wiki.ubuntu.com/UbuntuBots | 23:19 |
| pooliex | good morning | 23:49 |
| beuno | mornin' pooliex | 23:56 |
| beuno | how was your vacation? | 23:56 |
| pooliex | great, thanks | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!