| lifeless | oh, igcs updated loom, right | 00:00 |
|---|---|---|
| abentley | Yes, the patches igc submitted recently. | 00:00 |
| igc | abentley: what was the bug? | 00:00 |
| lifeless | didn't jml have a patch for clone already? | 00:00 |
| jml | I did | 00:00 |
| jml | it got merged into abentley's branch too. | 00:01 |
| abentley | lifeless: yes, and it was my modification of that patch which exposed the bad behavior. | 00:01 |
| abentley | lifeless: Anyhow, when I thought it was about all_revision_ids, I thought I should confirm that it should work across fallbacks. | 00:01 |
| abentley | The bug is that we open a repository before opening a branch, and we attempt to use that repository even if we find a branch later. | 00:02 |
| lifeless | oh yes, references won't like that | 00:03 |
| abentley | Exactly. | 00:03 |
| abentley | It doesn't follow branch references and it also doesn't set fallback repositories. | 00:03 |
| abentley | Anyhow, I've got a fix now. I only pinged because I misdiagnosed the problem at first. | 00:06 |
| lifeless | abentley: sweet | 00:06 |
| nosecow | another newbie question. just tried my first commit, and got this error: bzr: ERROR: Cannot lock LockDir | 00:22 |
| beuno | nosecow, is this on a checkout? | 00:23 |
| nosecow | beuno: no, the checkout was successful. created a test directory with one file, then tried to commit, and got that error | 00:24 |
| beuno | nosecow, this was using a lp:~yadayada type for URL? As in, from Launchpad? | 00:24 |
| nosecow | beuno: no. bzr co ftp://myhost/var/www/mysite c:\apache\htdocs\mysite | 00:25 |
| beuno | that's odd then. Can you paste in the full error? | 00:26 |
| nosecow | yes | 00:26 |
| nosecow | bzr: ERROR: Cannot lock LockDir(ftp://linuxdev01/var/www/propertypartner/.bzr/re / pository/lock): File exists: '/var/www/propertypartner/.bzr/repository/lock/un7w / nlmbyp.tmp': 550 Create directory operation failed. | 00:26 |
| beuno | nosecow, what version of bzr are you using? | 00:27 |
| bob2 | ms windows ftp server? | 00:27 |
| lifeless | nosecow: thats strange. Can you use 'sftp' instead of 'ftp' - it is a much nicer protocol and less problematic | 00:27 |
| nosecow | bueno: 1.5, just downloaded | 00:27 |
| nosecow | lifeless: had trouble with setting up sftp; will go edit my conf file...can i just checkout again once i change? | 00:28 |
| lifeless | nosecow: yes | 00:28 |
| === mw is now known as mw|out | ||
| nosecow | lifeless: changed default scheme in authentication.conf to sftp; but bzr does not seem to be picking up the proper username - is still using it's 'guess' | 00:32 |
| lifeless | nosecow: put the username before the url like: | 00:33 |
| lifeless | sftp://USERNAME@hostname/..... | 00:33 |
| nosecow | okeydokey | 00:33 |
| nosecow | sigh: bzr: ERROR: File exists: u'C:/apache/htdocs/propertypartner/.bzr': [Error 183] C / annot create a file when that file already exists: u'C:/apache/htdocs/propertypa / rtner/.bzr' | 00:34 |
| * igc back in a few hours | 00:34 | |
| nosecow | should i just delete it? | 00:34 |
| nosecow | and, i really appreciate this help... | 00:35 |
| lifeless | yes, you can just delete that if its where you want to checkout to | 00:36 |
| lifeless | back in a little bit : food | 00:36 |
| nosecow | Okay, sftp protocol used, checkout from linux server to windows machine works fine, adding a directory and attempting to commit yields: | 00:40 |
| nosecow | bzr: ERROR: Cannot lock LockDir(sftp://nosecow@linuxdev01/var/www/project/.bzr/repository/lock): Permission denied: "/var/www/project/.bzr/repository/lock/ctb89f5sh3.tmp": [Errno 13] Permission denied | 00:40 |
| Peng | nosecow: Does your sftp user have read/write access to the repo? | 00:41 |
| nosecow | ooh good question. can you tell it's been a long time since I used unix? :) | 00:41 |
| === mwhudson__ is now known as mwhudson | ||
| nosecow | peng: excellent advice, thank you | 00:47 |
| nosecow | yesssssssssssss | 00:48 |
| nosecow | peng,bob2,lifeless: thank you all for the help. i have the basics working now. I appreciate all of your help! | 00:48 |
| Peng | :) | 00:48 |
| nosecow | bye | 01:01 |
| poolie | spiv: were you going to come down here today? | 01:11 |
| spiv | poolie: yeah. I'm just about to head out the door. I slept badly, and was just trying to figure out if I was sick or just tired before I came down and possibly spread contagion :) | 01:19 |
| spiv | poolie: it seems I was just tired, which is good (relatively speaking...) | 01:19 |
| lifeless | beuno: what do you think of the new loggerhead bugs? | 01:20 |
| mwhudson | lifeless: https://bugs.edge.launchpad.net/loggerhead/+bug/240504 is a bit interesting | 01:23 |
| ubottu | Launchpad bug 240504 in loggerhead "Should not generate revisioned URLs unless specifically needed" [Undecided,Confirmed] | 01:23 |
| mwhudson | because if you want to generate a link to "file X in rev Y" i think you need to load the inventory for rev Y | 01:24 |
| mwhudson | which is a pain, probably | 01:24 |
| lifeless | mwhudson: well | 01:24 |
| poolie | spiv, oh np, just wondered | 01:25 |
| poolie | glad you're not ill | 01:25 |
| lifeless | mwhudson: first approximation: load the inventory for .tip. If the modification revision is the same as in .tip, then you don't need to specify a revision | 01:25 |
| lifeless | mwhudson: anyhow, this is why bzr search has phrase searches for (file_id, revision_id) -> 'p', '', PATH | 01:26 |
| mwhudson | ah interesting | 01:26 |
| mwhudson | so if we demanded bzr-search, we could do this more quickly? | 01:27 |
| lifeless | mwhudson: its how 'bzr search foo' can return README as a path | 01:27 |
| mwhudson | (not sure this is sane, of course) | 01:27 |
| lifeless | mwhudson: well, there are multiple answers. In particular I wanted to say to Olav that we agree its not friendly | 01:27 |
| mwhudson | sure | 01:27 |
| lifeless | right now I'd do the low hanging fruit | 01:28 |
| lifeless | jam: spiv: I've mailed a sample of how to do it easily | 01:28 |
| mwhudson | well, i think the priority with loggerhead is to get some of the branches floating around merged | 01:28 |
| lifeless | jam: spiv: feedback + things that would make it easier appreciated | 01:28 |
| lifeless | using tango stuff would be cute; cuter still if it was just an optional theme | 01:29 |
| mwhudson | i don't think the visual stuff is going to be ready for merging for a while | 01:31 |
| mwhudson | (well, a week or so, let's say) | 01:31 |
| lifeless | mwhudson: :P | 01:31 |
| * mwhudson is running on internet time | 01:31 | |
| lifeless | blog aggregators must die | 01:34 |
| lifeless | http://www.asofterworld.com/oq-display.php?id=58 | 01:34 |
| lifeless | http://datacharmer.blogspot.com/2008/06/mysql-sandbox-122-and-joys-of.html | 02:13 |
| mwhudson | lifeless: nice | 02:14 |
| poolie | sweet | 02:28 |
| poolie | lifeless: assertRaises where? | 02:32 |
| lifeless | in the test | 02:33 |
| lifeless | you raise a specific exception | 02:33 |
| lifeless | and fail if its not raised | 02:33 |
| lifeless | that fits assertRaises doesn't it ? | 02:33 |
| poolie | hum | 02:33 |
| poolie | i want to generate an ImportError | 02:34 |
| lifeless | if it doesn't thats fine - but its close enough people will get confused IMO so a note to that effect would help clarity | 02:34 |
| poolie | i don't see how assertRaises can do that for me | 02:34 |
| poolie | possibly i should remove the 'else' clause; if for some reason that module is loaded it will fail in a different way | 02:34 |
| poolie | the raise is just to generate the input for the real test | 02:35 |
| poolie | which is the call to format_exception | 02:35 |
| lifeless | right | 02:35 |
| poolie | i guess i could pass a lambda to assertRaises but i don't see the point | 02:35 |
| lifeless | there is a bit of action at a distance happening I think. Specifically - are the args to ImportError well defined across python versions? If they are why don't you just 'raise ImportError' | 02:35 |
| poolie | i do... | 02:36 |
| lifeless | if they are not well defined then presumably the code is fragile, or we need python version based conditional logic | 02:36 |
| poolie | oh in the other test | 02:36 |
| lifeless | + try: | 02:36 |
| lifeless | + import ImaginaryModule | 02:36 |
| poolie | it seems like this is more realistic and no harder than just raising ImportError | 02:37 |
| lifeless | so I guess I'm saying I'd have done a test that 'import MissingModule' resulted in an ImportError with a specific value in the args, to catch python variations, and then all the other tests as 'raise ImportError(...)' | 02:37 |
| lifeless | which is close to what you've done ;) | 02:37 |
| poolie | ok | 02:38 |
| poolie | that would also work | 02:38 |
| poolie | that would be a bit more precise, i don't think it's needed here | 02:38 |
| poolie | thanks for the prompt review | 02:38 |
| lifeless | anyhow, its bb:approve'd | 02:38 |
| lifeless | the rest is sugar | 02:38 |
| poolie | can you also read my comment on https://bugs.edge.launchpad.net/bzr/+bug/205230 | 02:38 |
| ubottu | Launchpad bug 205230 in bzr "error message recommending incorrect setting of PYTHONPATH" [Low,Confirmed] | 02:38 |
| poolie | at the end | 02:38 |
| poolie | want to trivilaly fix that too | 02:39 |
| lifeless | thats an improvement | 02:40 |
| lifeless | a note though - folk with .zips (e.g. windows) may need 'bzr.zip' on the path. | 02:41 |
| lifeless | 205230 is good as is | 02:41 |
| lifeless | just speculating about potential further tweaks | 02:41 |
| lifeless | time to pkill firefox | 03:09 |
| lifeless | ah look, 20% cpu back just like that | 03:10 |
| fullermd | That must be nice. I get 100% (well, 100% of one CPU) back when I SIGSTOP it while not actively using it :| | 03:34 |
| * beuno looks at new LH bugs | 04:43 | |
| beuno | ah, fun | 04:45 |
| beuno | mwhudson, I was thinking, it shouldn't be too hard for us to be able to optionally serve branches over http | 04:46 |
| Verterok | beuno: you have a few to look ;) | 04:46 |
| beuno | would be a nice feature to have | 04:46 |
| * mwhudson loves how fast bzr log --short | less starts up now | 04:46 | |
| beuno | hey Verterok | 04:46 |
| mwhudson | beuno: um, true i guess | 04:46 |
| mwhudson | beuno: broadly speaking, i would tend to leave serving static files to apache... but i guess it wouldn't be hard | 04:47 |
| beuno | mwhudson, we could even provide URLs to branch ay any given point in time, for your copy'n'paste comfort | 04:47 |
| * mwhudson hmms | 04:47 | |
| beuno | I agree, although as a plugin for bzr that would rock :) | 04:47 |
| mwhudson | yeah, interesting idea | 04:47 |
| mwhudson | file a bug on that too :) | 04:48 |
| beuno | heheh | 04:48 |
| beuno | more bugs? :p | 04:48 |
| mwhudson | beuno: there's more stuff in my wsgi-ify branch now | 04:48 |
| mwhudson | beuno: bugs are great | 04:48 |
| beuno | absolutely, makes it clearer what to do! | 04:48 |
| * beuno looks at the whisky branch | 04:48 | |
| beuno | also, we should have export on there. "Download tar.gz for this revision" | 04:49 |
| mwhudson | that sounds resource intensive | 04:49 |
| mwhudson | but, well, sure :) | 04:49 |
| mwhudson | so long as we can turn it off for lp... | 04:50 |
| beuno | probably, but, well, generate it once, keep it forever :) | 04:50 |
| mwhudson | well, that just consumes a different resource | 04:51 |
| beuno | storage is cheaper, but yes, all these things should be optional | 04:52 |
| lifeless | getting a tar is not expensive | 04:56 |
| lifeless | compressing it is somewhat | 04:56 |
| beuno | mwhudson, what do you think about setting a milestone for 1.3 in LP, and filing bugs on what we absolutely want for it, and target them. That way it should be easier to focus | 05:00 |
| mwhudson | beuno: i think that's a good idea | 05:00 |
| beuno | mwhudson, cool, because only you can do that :p | 05:01 |
| mwhudson | beuno: i've just made you a 'driver', does that let you do it? :) | 05:02 |
| beuno | mwhudson, heh, no :) | 05:03 |
| mwhudson | darn | 05:03 |
| beuno | I wonder what that does anyway, I don't see anything new I can do | 05:04 |
| mwhudson | maybe it means you can target bugs to milestones? | 05:04 |
| beuno | not even | 05:05 |
| mwhudson | beuno: do you think i should create a new productseries? | 05:05 |
| mwhudson | beuno: you should apply to join the loggerhead-team, btw | 05:05 |
| mwhudson | i'll poke robey to make me an admin | 05:06 |
| poolie | jml: "i'd love to" cute :) | 05:06 |
| poolie | like Robert's thing that "the code will do X" meaning "will after it's written" :) | 05:06 |
| beuno | mwhudson, requested. I'm not sure about the series thing, that always confuses me. I think you *have* to | 05:06 |
| * beuno applies | 05:07 | |
| mwhudson | i guess that it confuses me too points to a problem in launchpad... | 05:07 |
| mwhudson | beuno: do we call it 1.3 or 2.0 do you think? :) | 05:07 |
| jml | poolie: well, the first email was sent *before* I consulted my calendar :) | 05:07 |
| beuno | mwhudson, 2.0 sounds cooler :p Maybe we can try releasing the same as bzr versions, to me it less confusing and obvious with what version it works with | 05:08 |
| mwhudson | beuno: that's probably a good idea | 05:09 |
| mwhudson | i guess that means 1.6 then as we'll probably release between 1.6 and 1.7 | 05:09 |
| beuno | yeap, sounds good | 05:09 |
| beuno | I love how versioning is so flexible :) | 05:09 |
| poolie | hello beuno, mwh | 05:12 |
| beuno | howdy poolie | 05:13 |
| mwhudson | beuno: i think maybe you can "nominate a bug for the 1.6 release" | 05:13 |
| beuno | mwhudson, nope, I can for bzr, not for LH | 05:14 |
| mwhudson | beuno: how strange | 05:14 |
| mwhudson | https://bugs.edge.launchpad.net/loggerhead/+bug/236702/+nominate says "The loggerhead release manager is Martin Albisetti. " :) | 05:15 |
| ubottu | Launchpad bug 236702 in loggerhead "No permalink to "latest revision of file" in Loggerhead" [Undecided,Confirmed] | 05:15 |
| beuno | oh, I can access that link :/ | 05:15 |
| mwhudson | releases, productseries and milestones do not have entirely obvious interactions in launchpad | 05:16 |
| * mwhudson adjusts his understatement settings | 05:16 | |
| beuno | I can't find anywhere in the UI to do it... | 05:16 |
| mwhudson | beuno: "nominate for release" in the actions portlet? | 05:16 |
| beuno | ah, target to release | 05:17 |
| beuno | and bzr uses "milestones" | 05:17 |
| mwhudson | well, i can add a milestone to the 1.6 series | 05:18 |
| mwhudson | i'm not quite sure if i want to though | 05:18 |
| beuno | don't worry about it, I'll use that | 05:19 |
| beuno | it's odd, in bzr it *does* say Nominate for... | 05:19 |
| mwhudson | oh, maybe all i can do is nominate for a release | 05:20 |
| mwhudson | but because you're the driver you can actually target it? | 05:20 |
| beuno | but you're part of the group and I'm not | 05:20 |
| beuno | but it makes sense | 05:20 |
| beuno | sort of | 05:20 |
| mwhudson | :) | 05:21 |
| mwhudson | i could actually read the code to figure this out, but it feels rather like cheating | 05:21 |
| beuno | right. " Bug nominations are evaluated by release managers and accepted or declined for fixing in a release. " | 05:21 |
| beuno | hahaha, and, from the looks of it, you may get lost for a while :p | 05:21 |
| mwhudson | oh, https://help.launchpad.net/Projects/SeriesMilestonesReleases seems relevant | 05:22 |
| beuno | mwhudson, bug #156453 probably should go away with the release of the zpt branch, right? | 05:25 |
| ubottu | Launchpad bug 156453 in loggerhead "production loggerhead branch leaks memory" [Critical,Fix committed] https://launchpad.net/bugs/156453 | 05:25 |
| mwhudson | beuno: hope so, let's see | 05:25 |
| poolie | lifeless: is it ok with you if i disable test_35_wait_lock_changing (patch for this on the list) | 05:29 |
| lifeless | poolie: if you must; I thought we'd discussed a simple way using a closure to test it with being timing dependent or threading | 05:29 |
| poolie | not as simple as this :) | 05:30 |
| poolie | i do want to finish that but i don't want to detour into it too much | 05:30 |
| lifeless | let me rephrase - no, I don't think its a good idea to disable it. Its (I estimate) < 2 hours to fix properly. If we disable it, just delete it because noone will ever fix it.. | 05:30 |
| poolie | hm | 05:31 |
| poolie | should i fix it now or read the VF patch? | 05:31 |
| lifeless | lets ask spiv where is review is up to | 05:31 |
| poolie | (biab) | 05:31 |
| lifeless | spiv: where is your review up to | 05:31 |
| poolie | lifeless: he was working on his hpss version handling patch | 05:51 |
| poolie | we are both going back to that now | 05:51 |
| lifeless | poolie: so, I don't know the answer to 'should i fix it now or read the VF patch?' | 05:54 |
| spiv | lifeless: fwiw, I'm reading your knit.py changes atm | 05:55 |
| lifeless | beuno: :) | 06:06 |
| lifeless | ok, sending an incremental diff with the stuff I've improved so far | 06:06 |
| poolie | spiv/lifeless, i'm reading log.py | 06:08 |
| poolie | lifeless: i'll read it now and do this | 06:08 |
| poolie | will try to fix it properly later | 06:08 |
| poolie | if its timeslice expires i will just disable the test though | 06:09 |
| igc | poolie: can I help with the VF review? | 06:09 |
| igc | otherwise, I'll review jam's annotate patch | 06:09 |
| poolie | merge.py | 06:11 |
| poolie | igc, hi! | 06:11 |
| poolie | i think it's ok with spiv and me | 06:11 |
| igc | hi poolie! | 06:11 |
| mwhudson | time to stop for me today | 06:11 |
| mwhudson | beuno: another day without reviewing your urls branch, sorry about that :( | 06:12 |
| lifeless | poolie: I'd like a chat with an intelligent teddy bear | 06:12 |
| beuno | mwhudson, no problem. wsgi thing is more important. I still have a few tweaks to add to it. I'll try and get those done tomorrow so you can review all if it in one batch | 06:13 |
| mwhudson | ok | 06:13 |
| lifeless | poolie: so I'm going to ring you :) | 06:13 |
| spiv | lifeless: be careful with intelligent teddy bears | 06:14 |
| spiv | lifeless: they can talk back! | 06:14 |
| beuno | mwhudson, I reorganized the bugs a bit, but feel free to change around anything you'd like. I targeted more or less what we've been discussing. I assume we're going to release with the new theme, right? | 06:14 |
| mwhudson | beuno: i think we should | 06:15 |
| mwhudson | so new templating engine, new look, new http front end, ... | 06:15 |
| mwhudson | anything left for us to change? :) | 06:15 |
| beuno | tests :p | 06:15 |
| mwhudson | most of history.py isn't changing i guess | 06:15 |
| mwhudson | ah yes, good point :) | 06:15 |
| beuno | no, but I saw you have a blueprint to replace that with something more sensible | 06:16 |
| beuno | maybe we can discuss that after this release, and work out a plan for that | 06:16 |
| mwhudson | oh, er, that blueprint is way out of date | 06:17 |
| mwhudson | the idea behind it is still good perhaps | 06:17 |
| beuno | it's worth looking in to. I get the impression we should change it too, so we should have a talk about it after we get this release out, and see if it still makes sense | 06:18 |
| beuno | and, well, tests. Which can be the main focus of the next release, apart from maybe bug fixing :) | 06:18 |
| poolie | (back) | 06:34 |
| igc | poolie: jam asked this morning if you'd send an email to the list at the close of your day explaining where you and spiv were up to in reviewing the VFs stuff. That way, he can pick it up overnight. He'd also said it was fine if you completed the review before then. :-) | 06:47 |
| poolie | heh thanks :) | 06:47 |
| poolie | ok | 06:47 |
| poolie | i think we can probably finish it today | 06:47 |
| poolie | i should send an update mail anyhow | 06:47 |
| * beuno is off to bed. Night all | 06:48 | |
| poolie | lifeless: in so many places the key list is the mapping of a function over some other list it kind of seems like there should be a more direct idiom | 06:53 |
| poolie | like that you should pass in a closure that does the mapping | 06:54 |
| poolie | however i suppose this would not actually make it any cleaner | 06:54 |
| lifeless | I think it would make it less clean | 06:59 |
| lifeless | because it would pollute the interface | 06:59 |
| poolie | mm | 07:06 |
| poolie | it was not a suggestion, just a thought | 07:06 |
| lifeless | yah | 07:06 |
| poolie | merge.py done, looking at your incremental patch | 07:06 |
| lifeless | I was just saying what I thought of the thought :) | 07:07 |
| * lifeless eats lunch | 07:07 | |
| poolie | > + Tuple based apis below, string based, and key based apis above | 07:08 |
| poolie | i don't understand that sentence | 07:08 |
| lifeless | oh hmm | 07:08 |
| lifeless | so I'm trying to say that below the line the code deals only with tuples | 07:09 |
| lifeless | and above you have either plain strings | 07:09 |
| lifeless | or for some apis (existing ones!) tuples that are types in that tuple[0] means 'fileid', tuple[1] means 'revisionid' (for that specific interface) | 07:09 |
| poolie | lifeless: ok, some feedback sent; if you want me to take a stab at rephrasing it i can | 07:22 |
| poolie | um | 07:22 |
| poolie | there is the risk that by the time we get there i will just understand it and not need the docs | 07:22 |
| poolie | but i think the initial review experience shows its worthwhile | 07:22 |
| spiv | + if content._lines and content._lines[-1][1][-1] != '\n': | 07:24 |
| spiv | Ow :) | 07:24 |
| === timchen1` is now known as nasloc__ | ||
| lifeless | poolie: I think there is value in that yes | 07:25 |
| lifeless | spiv: yes, but thats already in mainline :P | 07:25 |
| lifeless | spiv: I think. | 07:25 |
| spiv | lifeless: Not that my quick search of the diff finds :P | 07:26 |
| spiv | lifeless: I blame AnnotatedKnitContent rather than you, though ;) | 07:26 |
| lifeless | spiv: hmm, must have been pulled out with poolies other fix; I do recall not liking that line | 07:26 |
| lifeless | spiv: I think we can delete it | 07:26 |
| spiv | lifeless: awesome :) | 07:26 |
| lifeless | oh, that reminds me | 07:27 |
| lifeless | that bug is indeed fixed | 07:27 |
| poolie | lifeless, spiv, some comments sent | 07:35 |
| lifeless | thanks | 07:35 |
| spiv | + suffix_parents = self._kndx_cache[prefix][0][key[-1]][4] | 07:41 |
| spiv | That's perhaps even more impressive ;) | 07:41 |
| poolie | doing reconcile.py | 07:43 |
| poolie | spiv, i guess you did all of remote.py etc | 08:03 |
| spiv | poolie: My notes say I've done remote.py, smart/repository.py, branch.py, bundle/serializer/v4.py, bzrdir.py, check.py and fetch.py. And just sent knit.py | 08:05 |
| poolie | yay way to go | 08:06 |
| spiv | poolie: oh, and annotate.py, builtins.py and inventory.py (which are all pretty trivial) | 08:16 |
| poolie | ok will do revisiontree | 08:35 |
| lifeless | poolie: asking now to avoid latency... | 08:42 |
| lifeless | iter_topo_keys - why is it a good time now to fix a bug in existing code ?:P | 08:42 |
| poolie | lifeless: in that it accepts keys=None? | 09:01 |
| poolie | let's not add a new api that propagates problems | 09:02 |
| spiv | Done knitrepo.py | 09:02 |
| poolie | i suspect you can just delete those lines/words and it will work | 09:02 |
| poolie | if not it's ok to leave it | 09:02 |
| poolie | still on revisiontree | 09:05 |
| poolie | ok reading store/__init__.py | 09:07 |
| lifeless | poolie: I'm fairly sure I can't :P | 09:08 |
| poolie | ok well don't then | 09:18 |
| poolie | at least i'm sure it's never given one parameter | 09:19 |
| poolie | you could do that | 09:19 |
| poolie | it's possible it's sometimes indirectly given None | 09:19 |
| * spiv starts reading tests/* | 09:19 | |
| poolie | lifeless: it's a new function and there's only a handful of callers that do seem to pass a value | 09:20 |
| poolie | if it fals with that removed i guess it's not worth debugging | 09:21 |
| poolie | at the moment | 09:21 |
| poolie | lifeless: about the changes in store/__init__.py, changing _iter_files_recursive | 09:21 |
| poolie | you changed the way escaping is done there | 09:21 |
| poolie | ah, np | 09:22 |
| poolie | the diff context is a bit misleading | 09:22 |
| === RAOF_ is now known as RAOF | ||
| poolie | good night | 09:49 |
| lifeless | gnight poolie | 09:58 |
| james_w | In python if I create a variable holding a value and don't use it I assume it takes up memory until the next gc, is that correct? | 10:26 |
| james_w | and if I immediately create another variable with the same value then that takes up the same amount of memory again? | 10:27 |
| Leonidas | why does bzr blame display the email adresses instread of the names on the lines? | 10:30 |
| Leonidas | I'd prefer to see the names there instead and maybe the initial would be even better | 10:31 |
| Leonidas | (displaying the initials if the initials on a project do not clash) | 10:31 |
| james_w | hi Leonidas, I'm not sure, you could file a bug requesting the change. | 10:36 |
| Leonidas | james_w: on launchpad? | 10:37 |
| james_w | Leonidas: yuppers | 10:37 |
| james_w | https;//bugs.launchpad.net/bzr/+filebug | 10:38 |
| james_w | almost | 10:38 |
| james_w | https://bugs.launchpad.net/bzr/+filebug | 10:38 |
| Leonidas | james_w: yeah, ok. It's not that important, though :) | 10:38 |
| james_w | Leonidas: still nice to record these things. | 10:38 |
| Leonidas | james_w: ok, writing it now. | 10:39 |
| james_w | hanks | 10:39 |
| james_w | thanks | 10:39 |
| james_w | man, I should get off my ass and go to the shop to get some milk so I can have breakfast | 10:40 |
| lifeless | james_w: when you do 'foo = bar' | 10:50 |
| lifeless | james_w: 'foo' is bound to the result of evaluating 'bar' | 10:50 |
| Leonidas | there it is: https://bugs.launchpad.net/bzr/+bug/240633 (lp does not allow me to set 'enhancement' on this) | 10:50 |
| ubottu | Launchpad bug 240633 in bzr "Display names in bzr blame" [Undecided,New] | 10:50 |
| Leonidas | breakfast sounds like a great idea. | 10:50 |
| lifeless | james_w: if foo goes out of scope, then in CPython the ref count for whatever foo what bound to is decremented | 10:51 |
| james_w | Leonidas: done, thanks. | 10:51 |
| james_w | hi lifeless | 10:51 |
| lifeless | james_w: if there are no cycles this results in it being freed immediately | 10:51 |
| lifeless | james_w: if there are cycles then yes, a gc run is needed to free it | 10:51 |
| lifeless | james_w: if you rebind foo, by doing 'foo = bar2' | 10:51 |
| lifeless | then the old thing referenced by foo has its refcount decremented, see above | 10:52 |
| james_w | thanks | 10:52 |
| james_w | so a = foo; b = foo; would increase the chances of a MemoryError? | 10:52 |
| lifeless | this is a long winded way of saying: yes|no to the first question and yes|no to the second | 10:53 |
| james_w | this is for the patch I just sent if you didn't guess. | 10:53 |
| james_w | :-) | 10:53 |
| james_w | lifeless: if you're not heading off then I have a question about the package work. | 10:55 |
| lifeless | shoot | 10:55 |
| lifeless | i"m playing games | 10:55 |
| james_w | I'm adding handling of native packages. The simple case is just that. | 10:56 |
| james_w | the difficulty is when a package moves between native and non-native. | 10:56 |
| lifeless | so I'm biased here | 10:56 |
| james_w | I think non-native -> native should just import the native package as a merge of the packaging and upstream branches. | 10:56 |
| lifeless | I think native packages are a premature optimisation and a bug in dpgs | 10:56 |
| lifeless | *dpkg* | 10:56 |
| lifeless | non-native->native should do a merge commit yes | 10:57 |
| lifeless | and the reverse seems clear to me | 10:57 |
| lifeless | to move from native to non-native there are two branches made, both which derive from the last commit on the native one | 10:58 |
| james_w | I was leaning that way, I just wanted confirmation that it was sensible, thanks. | 10:58 |
| lifeless | in the new upstream branch the packaging data is deleted | 10:59 |
| lifeless | in the new packaging branch a merge from the new upstream is recorded, and the version metadata is changed | 10:59 |
| lifeless | jam: hi | 10:59 |
| james_w | yep, that sounds fine, I've just got to think about how to figure out what should happen from the history we have available, it shouldn't be too hard. | 11:00 |
| lifeless | upstream content == tarball | 11:00 |
| lifeless | upstream parent == last native | 11:01 |
| lifeless | packaging content == tarball + diff | 11:01 |
| james_w | the other question is how, and indeed whether, we should indicate that the package is native at that point. | 11:01 |
| lifeless | packaging parents = [last native, upstream] | 11:01 |
| lifeless | or perhaps the other way around | 11:01 |
| lifeless | well, its not native now, its now non-native :P | 11:01 |
| james_w | I think that's the right way round. | 11:02 |
| lifeless | I dunno, I'd need to think :P | 11:02 |
| james_w | yeah, sorry, indicate that the package is native when it is. | 11:02 |
| lifeless | I think just the version number :P | 11:02 |
| james_w | there's two things that impacts, one is when importing the next version so that we know to use the packaging branch as the upstream branch as well, and the other is when building. | 11:02 |
| lifeless | there should always be a packaging branch, thats the one people get | 11:03 |
| james_w | if only :-) | 11:03 |
| lifeless | seriously, the version number is the only way to detect a native package AIU | 11:03 |
| james_w | nope, a native package is a native package, i.e. the .dsc just describes a tarball, not a tarball and diff. | 11:04 |
| james_w | this can happen at any moment, with any version number. | 11:04 |
| james_w | e.g. lvm2 just goes native at something.something-1ubuntu4, and then back to non-native at the next revision | 11:04 |
| lifeless | argh | 11:05 |
| lifeless | see, native is a bug | 11:05 |
| james_w | I think it's a bug in dpkg that you get a native just because you didn't have a correctly named tarball/directory in the parent directory. | 11:05 |
| lifeless | native's _existence_ is a bug | 11:05 |
| lifeless | so totally convinced of this | 11:05 |
| james_w | well, trying to deal with this makes me dislike any variation, so I'd agree at this point. | 11:06 |
| lifeless | ok | 11:06 |
| james_w | what builddeb currently does is versions a file in the tree which just says "native = True" | 11:06 |
| lifeless | so detecting native. hmm - think on it during your day, mail me if you don't have a good answer at the end :P | 11:06 |
| james_w | I can detect native fine. | 11:06 |
| lifeless | 20:01 < james_w> the other question is how, and indeed whether, we should indicate that the package is native at that point. | 11:07 |
| lifeless | so, whatever you mean by ^^^ | 11:07 |
| james_w | ah, I meant indicate in the branch. | 11:07 |
| james_w | the .dsc tells you fine, but we don't version that. | 11:07 |
| lifeless | right | 11:07 |
| lifeless | so the dsc represents a 'commit' to the 'debian vcs' | 11:08 |
| lifeless | why don't we preserve it | 11:08 |
| james_w | sounds reasonable, do you have any suggestions where? | 11:09 |
| lifeless | revision properties perhaps | 11:09 |
| lifeless | only need some of the dsc | 11:09 |
| james_w | yeah, I was thinking of adding some from this information. | 11:09 |
| james_w | this works fine for imports, so I'm happy to do that for now. | 11:10 |
| james_w | however, what's not great about it is when you are building a new version of the package, the native property would be set on the last imported revision, but do we build the current package native? | 11:11 |
| lifeless | well | 11:11 |
| lifeless | I think that this is arguably something debian/control should answer | 11:11 |
| lifeless | it would solve the bug of sometimes getting native when you don't want, etc | 11:12 |
| james_w | I wouldn't mind enforcing the rule from the version number, but I wouldn't be surpised if there were packages out there that intentionally break the rule. | 11:12 |
| james_w | yes, debian/control would be great. | 11:12 |
| james_w | I think format 3.0 may actually do this. | 11:13 |
| james_w | yeah, you specify "3.0 (native)" | 11:15 |
| james_w | I don't think we could block on having 3.0 by default though. | 11:15 |
| lifeless | indeed | 11:15 |
| james_w | Am I right in thinking that bzr doesn't provide a mechanism that allows you to associate something with the branch rather than a revision? | 11:17 |
| james_w | i.e. branch.conf isn't copied on "branch" is it? Or at least not all of it? | 11:17 |
| lifeless | that correct | 11:17 |
| james_w | and that wouldn't help too much, as we would want it to be versioned. | 11:18 |
| lifeless | ash keybuk how he solved this | 11:19 |
| james_w | hct? or Mom? | 11:19 |
| lifeless | hct | 11:19 |
| james_w | ok, thanks. | 11:19 |
| lifeless | and I can think more about it but not tonight :P | 11:20 |
| james_w | I've one last thing that I wanted to ask. | 11:20 |
| james_w | when we chatted with jml and everyone else about branch naming we only discussed packaging branches. | 11:20 |
| james_w | are we going to push the upstream branches to launchpad separately, or just extract them as needed from the packaging branches? | 11:20 |
| lifeless | well | 11:21 |
| lifeless | Mark wants to keep the two incompatible branch sets separate | 11:21 |
| lifeless | so lets keep them implicit in the branch as tags only for now | 11:21 |
| james_w | sure, easy enough. | 11:21 |
| james_w | thanks for you time. I don't need to block on the native thing, but we need to get it right before making the branches available, so if you have any thoughts I'd appreciate it. | 11:22 |
| lifeless | I suggest a mail on it when you've chatted with scott & perhaps colin | 11:22 |
| james_w | sure, I'll start that today, thanks. | 11:23 |
| james_w | you're going to be at the distro sprint again, is that right? | 11:23 |
| lifeless | yes | 11:23 |
| lifeless | guadec + london + wolverhampton | 11:23 |
| james_w | ah, I'm doing the last two. | 11:24 |
| Jc2k | lifeless: your at GUADEC? | 11:26 |
| lifeless | Jc2k: I will be yes | 11:27 |
| lifeless | Jc2k: the Gnome folk at UDS thought it would be good to be able to grill me with others at GUADEC :) | 11:27 |
| Jc2k | for the DVCS stuff? | 11:28 |
| * Jc2k hopes to get to wave his finger at the Git camp :) | 11:29 | |
| pygi | is there really a point in pointing fingers, instead of collaborating? | 11:31 |
| Jc2k | i was joking, obviously, but the last time GNOME debated DVCS one of the Git users threatened to take their ball in. | 11:32 |
| mwhudson | Jc2k: hi :) | 11:33 |
| * mwhudson is not really here | 11:33 | |
| Jc2k | lo mwhudson :) | 11:33 |
| Jc2k | oh dear.. | 11:33 |
| Jc2k | :) | 11:33 |
| mwhudson | got my email? | 11:33 |
| Jc2k | yes i did, and i've updated bzr-mirror with your latest :) | 11:34 |
| mwhudson | and the annotate links work now, good | 11:45 |
| mwhudson | olav filed a bunch of loggerhead bugs, so i guess you showed it to some of the gnome people :) | 11:46 |
| Jc2k | just a couple | 11:46 |
| asabil_ | Jc2k: btw, thanks for setting up the bzr gnome mirror :) | 11:48 |
| Jc2k | hehe, np asabil_ | 11:49 |
| Jc2k | asabil_: im working on making it easy to use from jhbuild, if thats of any use to you | 11:49 |
| asabil_ | Jc2k: that sounds very nice :) | 11:49 |
| asabil_ | I think what is still lacking is a branch hosting facility, similar to launchpad's branch hosting | 11:50 |
| Jc2k | indeed, mark phoned me to discuss bzr-mirror and we are looking meant to be looking into that | 11:51 |
| === kiko is now known as kiko-afk | ||
| Jc2k | asabil_: watch this if your interested :) http://bugzilla.gnome.org/show_bug.cgi?id=538507 | 11:51 |
| ubottu | Gnome bug 538507 in general "Jhbuild should be able to use bzr-mirror.gnome.org" [Normal,Unconfirmed] | 11:51 |
| asabil_ | oh thanks | 11:51 |
| asabil_ | I am *very* interested | 11:52 |
| Jc2k | :) | 11:52 |
| lifeless | I showed that to jamesh, no comment so far :P | 11:56 |
| lifeless | jam: ping | 11:56 |
| Jc2k | :P | 11:56 |
| mwhudson | Jc2k: do you have any loggerhead issues you'd want me to focus on particularly? | 11:57 |
| mwhudson | (other than the reasonably obvious one of "get what you're running into trunk") | 11:57 |
| Jc2k | mwhudson: anything that olav wants, nicer urls would be lovely (so i can guess a url if i know the layout of my project, for example) and some way for me to start giving it the GNOME skin | 11:59 |
| mwhudson | ah yes, themable html | 11:59 |
| mwhudson | that's beuno's department :) | 11:59 |
| Jc2k | mwhudson, bueno: might be worth hanging out in #gnome-bzr on irc.gimp.org? | 12:00 |
| mwhudson | you can supply your own css now of course, it's just a static file | 12:00 |
| Jc2k | you too asabil_ | 12:00 |
| asabil_ | oh oki | 12:00 |
| mwhudson | but you'll probably want to hurt yourself before you got anywhere | 12:00 |
| mwhudson | Jc2k: oh right | 12:00 |
| asabil_ | btw Jc2k, you are the conduit author right ? | 12:01 |
| Jc2k | im one of the core devs, aye | 12:01 |
| asabil_ | we need to talk :D | 12:01 |
| Jc2k | ace | 12:01 |
| Jc2k | #conduit on gimpnet then ;D | 12:01 |
| asabil_ | :) | 12:01 |
| lifeless | mwhudson: I did mention #gnome-bzr on gimpnet right ? | 12:02 |
| mwhudson | lifeless: you did | 12:02 |
| lifeless | :P | 12:03 |
| mwhudson | i had some reason for not joining at the time you mentioned it, i forget what it was :) | 12:04 |
| Jc2k | :P | 12:05 |
| jelmer | :-( dak migrated to git | 12:57 |
| lifeless | garh | 12:58 |
| lifeless | who maintains dak? | 12:59 |
| james_w | ftpmasters I believe | 13:08 |
| james_w | http://blog.ganneff.de/blog/2008/06/16/byebye-bzr-hello-git.html | 13:08 |
| lifeless | erm no browser | 13:12 |
| lifeless | whats the summar ? | 13:12 |
| james_w | As the title says - the Ftpmaster dak repository is now using git instead of bzr. | 13:14 |
| james_w | I never did like bzr, so I recently asked what the rest of the team thinks of switching to git. Luckily I got no objections, so here we are, with a VCS thats not dead-slow. | 13:14 |
| dato | lifeless: that the person doing most of the works nowadays just dislikes bzr, and no other member of the team opposed to moving to git | 13:14 |
| dato | s/works/work/ | 13:14 |
| james_w | hi dato | 13:15 |
| dato | hello james_w | 13:16 |
| james_w | dato, jelmer: any thoughts on https://bugs.edge.launchpad.net/bzr/+bug/228298 ? | 13:24 |
| ubottu | Launchpad bug 228298 in bzr ""common-post-build-indep" target in debian/rules became obsolete when bzr became arch-specific" [Undecided,New] | 13:24 |
| lifeless | ok | 13:25 |
| lifeless | search suggestions done | 13:25 |
| lifeless | by done, I mean 'unit tested and works to the ui', not 'performant' or 'cleanly coded' | 13:26 |
| jelmer | james_w: Looks like a genuine bug in the debian bits | 13:27 |
| jelmer | james_w: The submitters suggestion looks reasonable | 13:27 |
| lifeless | hi dato | 13:27 |
| dato | james_w: yeah, I think as Jelmer | 13:27 |
| dato | hello lifeless | 13:27 |
| james_w | jelmer: cool, shall I file it in Debian as well to keep track of it, or just do it? | 13:27 |
| jelmer | james_w: Should be trivial enough to just fix, but whatever works best for you is fine with me | 13:28 |
| james_w | sure, I'm just doing some triage, I'll get to it after. Thanks. | 13:28 |
| jelmer | james_w: thanks for your triaging work, btw, bzr itself is way behind on that :-( | 13:30 |
| james_w | no problem. I noticed we were close to 1000 open bugs | 13:30 |
| lifeless | gnight all | 13:31 |
| Jc2k | night lifeless | 13:31 |
| jelmer | gutenacht lifeless | 13:31 |
| james_w | night lifeless | 13:31 |
| lifeless | Jc2k: I've just mailed beuno a suggestion (and the necessary code in bzr-search) for some bling; if he does it - and he is attracted to shiny things - then the search will be seriously sexy | 13:31 |
| Jc2k | orly? | 13:32 |
| * Jc2k wraps bzr-mirror.gnome.org in glitter and throws it to beuno | 13:32 | |
| mtaylor | lifeless: if I have a revid, how do a get a revno from a branch? | 14:02 |
| mtaylor | lifeless: (in the code, not in the command line) | 14:03 |
| mtaylor | oh. damn. he's gone to bed | 14:03 |
| mtaylor | anybody else? ^^ | 14:03 |
| bob2 | branch.get_revision_id_to_revno_map()[revid]? | 14:08 |
| mtaylor | bob2: is that better than branch revision_id_to_revno() ? (which I just noticed...) | 14:10 |
| bob2 | ah, I would say no :) | 14:11 |
| mtaylor | uh... | 14:24 |
| mtaylor | help? | 14:24 |
| mtaylor | Two plugins defined the same command: 'cmd_parent' | 14:24 |
| mtaylor | Not loading the one in <module 'bzrlib.plugins.mysql.parent' from '/home/mtaylor/.bazaar/plugins/mysql/parent.py'> | 14:24 |
| mtaylor | Previously this command was registered from <module 'bzrlib.plugins.mysql.parent' from '/home/mtaylor/.bazaar/plugins/mysql/parent.py'> | 14:24 |
| mtaylor | those look like the same place to me | 14:24 |
| Jc2k | buggy plugin? can you not just move it out of the way? | 14:25 |
| awilkins | I'm trying to ignore all files with the extension .txvClassDiagram20 *except* default.txvClassDiagram20 - the RE I think it should be is RE:.*(?!default)\.txvClassDiagram20 .. but this doesn't seem to work.. any pointers? | 14:26 |
| mtaylor | Jc2k: yes. and I finally see the problem ... but WOW, what a weird error message | 14:28 |
| Jc2k | mtaylor: i've seen python get the path wrong if you move *.pyc files around | 14:28 |
| Jc2k | awilkins: if you bzr add a file, then it doesnt matter that its in .bzrignore *i think* | 14:29 |
| awilkins | Jc2k: Yup, agreed, but these files are not already added. | 14:29 |
| Jc2k | so add them? :) | 14:29 |
| awilkins | Jc2k: It's the other way round, I want to PREVENT automatic adds of all txvClassDiagram20 files EXCEPT default.<blah> | 14:30 |
| awilkins | So I want to ignore them apart from default... | 14:30 |
| mtaylor | Jc2k: in this case, it was a "foo: %s" foo | 14:30 |
| mtaylor | Jc2k: without a % between the string and the var :( | 14:30 |
| Jc2k | mtaylor: eep | 14:31 |
| Jc2k | awilkins: ahh ok, i figured there wouldnt be any new default.foo files to add | 14:32 |
| awilkins | I think the .* is being too greedy | 14:32 |
| awilkins | Bingo, I wanted .*\b(?<!default>\.txvClassDiagram20$ | 14:39 |
| awilkins | Don't you just love regular expressions ..... | 14:39 |
| Jc2k | write-only language :) | 14:46 |
| awilkins | My old colleagues used to joke about some of mine achieving sentience and taking over the world. | 14:46 |
| awilkins | They were'nt even very complicated as Regex go.... | 14:47 |
| abentley | awilkins: .bzrignore supports regexes. | 15:56 |
| abentley | awilkins: Just prefix them with RE: | 15:56 |
| Jc2k | abentley: he solved the problem with regexes just a few lines up :) | 15:56 |
| Jc2k | 14:39 < awilkins> Bingo, I wanted .*\b(?<!default>\.txvClassDiagram20$ | 15:56 |
| abentley | awilkins: I didn't see that he knew he could use that regex. | 15:57 |
| abentley | Or Jc2k, actually... | 15:57 |
| Jc2k | :) | 15:57 |
| === kiko-afk is now known as kiko | ||
| catlee | Hello | 16:32 |
| catlee | I've been trying to use bzr to work on a local branch of a svn repository | 16:32 |
| catlee | But I've noticed when I push changes back to the svn repo, all of my intermediate merges from the svn repo are included in my commit. Is there a better way to work with a svn repo than bzr merge / commit / push? | 16:34 |
| awilkins | jam: There's a bug on lp that says you use bzr/cygwin, have you ever used a bzr/cygwin sshd to serve bzr+ssh:// ? | 16:35 |
| jelmer | catlee: You can use rebase instead | 16:36 |
| jelmer | catlee, (instead of merge) | 16:36 |
| catlee | jelmer, ok I'll give that a try, thanks | 16:36 |
| jam | awilkins: I use bzr/win32, I just run a cygwin shell | 16:36 |
| catlee | got an AssertionError when I tried to rebase with no arguments | 16:37 |
| jam | I've never run openssh server on cygwin | 16:37 |
| jelmer | catlee, what version are you using? | 16:37 |
| catlee | 1.5 | 16:37 |
| awilkins | jam: I think I just thought of a solution anyway... let me try it | 16:37 |
| jelmer | catlee, sorry, what version of rebase ? | 16:37 |
| catlee | jelmer, how do I tell? | 16:37 |
| catlee | 0.3.0 | 16:38 |
| awilkins | jam: Problem I'm having is that the shell script is #!-ing a path to Python that Cygwin doesn't grok | 16:38 |
| jelmer | catlee: If you specify a location explicitly, it probably works better | 16:38 |
| jelmer | I think this issue as also been fixed in bzr-rebase, just isn't in 0.3.0 yet | 16:38 |
| jam | awilkins: you could have a different bzr in your cygwin path, which it *does* understand | 16:47 |
| jam | you just need it for the shell script | 16:47 |
| jam | I use this: | 16:48 |
| jam | #!/bin/ash | 16:48 |
| jam | # Simple 'ash' script to thunk over to the real python | 16:48 |
| jam | export BZR_PLUGIN_PATH='C:\Users\jameinel\dev\bzr\plugins' | 16:48 |
| jam | exec /cygdrive/C/Python25/python.exe 'C:\Users\jameinel\dev\bzr\bzr.dev\bzr' "$@" | 16:48 |
| catlee | jelmer, not sure if I've really messed up my branch now...bzr rebase errors out saying there are no common revisions | 16:48 |
| jelmer | catlee: You really want the trunk version of bzr-rebase in that case | 16:48 |
| catlee | jelmer, where is it? the branch link from the Rebase wiki page is empty | 16:49 |
| jelmer | catlee, That link should work, you can run "bzr branch <link> ~/.bazaar/plugins/rebase" | 16:49 |
| catlee | http://people.samba.org/bzr/jelmer/bzr-rebase/trunk/ | 16:50 |
| jelmer | catlee, yes | 16:50 |
| catlee | ah, I guess apache is hiding the .bzr directory | 16:50 |
| catlee | I'll give it a try, thanks | 16:51 |
| awilkins | jam: That works a lot better ; do bzr+ssh URIs understand "~" ? | 16:53 |
| Peng | awilkins: No. | 16:53 |
| jam | awilkins: not yet | 16:53 |
| jam | but you can use the "contrib/bzr_access" script to change the meaning of / | 16:54 |
| awilkins | Would using Cygwin Python be any easier, DYT? | 16:55 |
| awilkins | How do you specify the path, I'm now guessing you can't use <URI_ROOT>/home/branch ? | 16:56 |
| awilkins | I got SFTP working nicely, but the completist in me wants to see bzr_ssh work | 16:56 |
| awilkins | Aha, you just use the drive letter :-) | 16:58 |
| awilkins | Blech, that's horrible | 16:58 |
| awilkins | right ,time to go | 17:00 |
| === thekorn_ is now known as thekorn | ||
| beuno | lifeless, is it expected I get this when pulling bzr.dev: http://paste.ubuntu.com/20914/ | 17:44 |
| awilkins | jam: How do you get the smart server to serve branches that are not on the same drive as Python on windows? | 19:18 |
| jam | awilkins: add a "cd ???" before starting the interpreter? | 19:19 |
| jam | I would have thought bzr+ssh://host/D:/aoueaoeu would work | 19:19 |
| jam | but if you are finding that it does not | 19:19 |
| awilkins | jam: It doesn't... f you leave off the drive letter it can serve branches on the same drive (ie c:) | 19:21 |
| awilkins | jam: But the chroot stuff is trying to read a path c:\c:\home\branch even if the drive letter is on the same drive | 19:21 |
| uws | I'd like to | 19:22 |
| uws | import a bzr branch to a newly created SVN repo | 19:22 |
| awilkins | I think it needs a bit of a patch in request.py : translate_client_path | 19:22 |
| uws | bzr push svn+ssh://..../trunk doesn't work since there are no common revisions (branches have diverged, but the svn repo is new, doh) | 19:22 |
| uws | any clue how to do this? | 19:22 |
| uws | And no, I'm not moving away from bzr. Actually I'm importing to Gnome SVN for i18n reasons, development will still be in bzr :) | 19:23 |
| === mw is now known as mw|food | ||
| bkor | uws: you mean http://live.gnome.org/BzrForGnomeDevelopers | 19:23 |
| bkor | ? | 19:23 |
| jam | awilkins: is that using bzr_access or just plain bzr+ssh? | 19:23 |
| jam | uws: 'bzr svn-push' to create a new branch | 19:23 |
| awilkins | jam: that's bzr+ssh//, bzr:// (although different paths, same problem) | 19:24 |
| uws | jam: trunk/ dir is already there... | 19:24 |
| uws | bkor: that's the other way around | 19:24 |
| uws | bkor: I already have a bzr history | 19:24 |
| awilkins | jam: bzr+ssh:// is over local cygwin sshd ; sftp to the same branch works | 19:24 |
| awilkins | (as long as you use the /cygdrive/ root to get to other drives) | 19:25 |
| schierbeck | ahoy | 19:25 |
| uws | bkor, jam: I tried removing trunk/, but gnome svn won't let me because it wants a MAINTAINERS file | 19:28 |
| jam | uws: can you try pushing to another location (svn-push) and then something like copy them over? | 19:29 |
| bkor | ehr, you shouldn't remove trunk | 19:29 |
| jam | you might want to try on a local repo first | 19:29 |
| jam | uws: another option | 19:29 |
| jam | if there is only 1 revision in trunk | 19:29 |
| jam | you can use | 19:29 |
| jam | bzr merge -r 0..-1 .../trunk | 19:29 |
| awilkins | jam: push-and-copy isn't going to work, alas, SVN repos being what they are. | 19:29 |
| jam | bzr commit | 19:29 |
| jam | bzr push trunk | 19:29 |
| jam | I'm not sure what bzr-svn has to say about that | 19:30 |
| jam | but it would work for bzr branches with diverged histories | 19:30 |
| awilkins | I've done it for empty branches, I think | 19:30 |
| uws | jam: first create a svn checkout and merge that from the to-be-imported-into-svn-bzr-branch? | 19:30 |
| jelmer | uws: Hmm | 19:32 |
| jelmer | uws: You may be able to merge the current trunk and then push | 19:32 |
| uws | bzr merge -r0..-1 ../svn/trunk | 19:32 |
| uws | That's what I just did in my bzr branch | 19:32 |
| uws | the svn/ dir is a svn checkout (empty repo) | 19:33 |
| uws | jelmer: ^ | 19:33 |
| jelmer | uws: If you commi that, can you then push? | 19:34 |
| uws | jelmer: no | 19:34 |
| jelmer | uws: What error, diverged branches? | 19:36 |
| uws | elin:~/Computing/Projects/gnome-specimen/development > bzr merge -r0..-1 ../gnome-specimen.bzr-svn/ | 19:36 |
| uws | All changes applied successfully. | 19:36 |
| uws | elin:~/Computing/Projects/gnome-specimen/development > bzr ci -m 'Merged Gnome SVN trunk' | 19:36 |
| uws | Committing to: /home/uws/Computing/Projects/gnome-specimen/development/ | 19:36 |
| uws | Committed revision 205. | 19:36 |
| uws | elin:~/Computing/Projects/gnome-specimen/development > bzr push svn+ssh://svn.gnome.org/svn/gnome-specimen/trunk/ | 19:36 |
| uws | bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified. | 19:36 |
| uws | Oops, too many lines. sorry | 19:36 |
| uws | jelmer: ../gnome-specimen.bzr-svn/ is a trunk checkout made using bzr-svn | 19:37 |
| jelmer | Probably because it's not a lhs ancestor :-/ | 19:38 |
| uws | the common use case is to branch from svn, and commit back to svn | 19:38 |
| uws | i want to import a bzr branch into svn :) | 19:39 |
| uws | jelmer: fwiw, my bzr branch is linear (no merges) | 19:39 |
| jelmer | yeah, the unfortunate bit here is that bzr-svn is a bit strict about where it can push to | 19:39 |
| jelmer | I was planning to fix this in 0.5, but we're not there yet.. | 19:40 |
| jelmer | trying to think of workarounds.. | 19:40 |
| uws | jelmer: I'm now trying svn-push to a trunk-from-bzr dir | 19:41 |
| uws | jelmer: That seems to work | 19:41 |
| uws | (after committing a MAINTAINERS file to the completley empty just created real trunk/) | 19:41 |
| uws | it's now pushing | 19:42 |
| uws | I'll try to move trunk-from-bzr to trunk/ afterwards | 19:42 |
| uws | http://svn.gnome.org/viewvc/gnome-specimen/ | 19:42 |
| jelmer | Ah, that's a nice idea | 19:42 |
| uws | if you refresh you see it going :) | 19:42 |
| uws | heh, "age: very little time" | 19:42 |
| Jc2k | uws: oooh | 19:42 |
| uws | it's halfway done now. | 19:42 |
| uws | Jc2k: ? | 19:42 |
| Jc2k | this should be interesting, i wonder if bzr-mirror.gnome.org will pick it up automatically | 19:43 |
| * Jc2k goes to watch the log unfold | 19:43 | |
| uws | Jc2k: I've done the regular "ssh svn.gnome.org new-svn-repos gnome-specimen" so it should be no different from another new svn repo | 19:43 |
| awilkins | They have websites for that kind of thing | 19:44 |
| uws | when this is done, I'll discard the original bzr branch in favor of a bzr-svn clone of the new trunk/ | 19:44 |
| uws | awilkins? | 19:44 |
| jelmer | uws: There shouldn't be a need for that | 19:44 |
| jelmer | uws: Since cloning the new trunk/ will create an exact copy of what you already have locally | 19:44 |
| awilkins | ^^ watching the lgo unfold (a poor scat joke) | 19:44 |
| uws | jelmer: I can keep pushing from the original bzr branch to turnk/ | 19:44 |
| uws | jelmer: even if it wasn't a svn checkout in the first plae? | 19:44 |
| Jc2k | uws: i've never watched a new module be born, though :) | 19:45 |
| uws | anyway, http://svn.gnome.org/viewvc/gnome-specimen/trunk-from-bzr/ seems to be ok now | 19:45 |
| uws | let's try to move it | 19:45 |
| jelmer | uws: Yes, since it was created with svn-push. | 19:45 |
| jelmer | In hindsight, it may be useful to start out by pushing to branches/from-bzr rather than trunk-from-bzr | 19:46 |
| jelmer | To avoid trouble with bzr-svn picking up the branching scheme | 19:46 |
| jelmer | If it's easy to strart over, you may want to do that | 19:47 |
| uws | hmm ok | 19:47 |
| uws | bkor: still here? | 19:47 |
| bkor | uws: sort of | 19:47 |
| uws | jelmer, bkor: jullie houden net zo veel van voetbal als ik zeker? :) | 19:47 |
| uws | bkor: can you rm -fr the gnome-specimen repos from svn.gnome.org now? | 19:47 |
| jelmer | uws: idd (-: | 19:47 |
| uws | bkor: I've just created it so there's no need to backup | 19:48 |
| uws | bkor: I'll recreate and try the svn import in a correct way, like jelmer suggests | 19:48 |
| bkor | uws: GOAL! | 19:48 |
| bkor | uws: I mean.. done! | 19:49 |
| * uws loves "direct lines" to people in OSS projects. bzr-svn trouble? ask the maintainer. Gnome SVN issues? ask bkor | 19:49 | |
| Jc2k | :) | 19:49 |
| uws | bkor: I would've heard a sound coming from the people on the street ;) | 19:49 |
| uws | http://svn.gnome.org/viewvc/gnome-specimen/ | 19:49 |
| uws | and there is is agai n:) | 19:49 |
| awilkins | Ben Collins-Sussman once very kindly uploaded a build of SVN to my SFTP server | 19:49 |
| awilkins | IRC is great | 19:50 |
| awilkins | Freenode in particular | 19:50 |
| uws | awilkins: Colleagues make fun of me because I don't do the msn thingy. i know better though :) | 19:50 |
| awilkins | IM networks are too fragmented | 19:50 |
| awilkins | They won't be any use until it all does XMPP | 19:51 |
| uws | awilkins: irc.gnome.org is even better than freenode for my particular case :) | 19:52 |
| uws | bkor, jelmer: http://svn.gnome.org/viewvc/gnome-specimen/branches/import-from-bzr/ incoming! :) | 19:52 |
| Jc2k | uws: can bkor and i lure you into #gnome-bzr on irc.gimp.org? | 19:52 |
| Jc2k | :) | 19:52 |
| uws | jelmer, bkor: ok, import in branches/import-from-bzr almost done | 19:55 |
| uws | now how do I get this as trunk/ ? | 19:55 |
| uws | I had to commit a MAINTAINERS file to trunk/ first btw otherwise the push commits would fail | 19:55 |
| jelmer | uws: What's the exact post-commit script that's used in gnome svn? | 19:56 |
| uws | jelmer: dunno, ask bkor | 19:56 |
| jelmer | bkor: Still there? | 19:56 |
| Jc2k | i can take a look | 19:56 |
| Jc2k | i think | 19:56 |
| Jc2k | if its in the rysncs | 19:56 |
| uws | jelmer: msgfmt checks for .po files, and MAINTAINERS file in trunk/ methinks | 19:56 |
| uws | Jc2k: Why do you use rsyncs? | 19:56 |
| uws | jelmer: but apart from the commit hook (if it's a real problem we can ask bkor to disable it for like 2 minutes), how would I get this branch as trunk? | 19:57 |
| bkor | jelmer: post-commit? why does it matter? | 19:57 |
| jelmer | uws: it's probably easiest to just do a checkout of the repository root and then do a "svn rm trunk" followed by "svn mv branches/import-from-bzr trunk" | 19:57 |
| Jc2k | uws: i had rsyncs of svn.gnome.org for the initial bzr-mirror conversions | 19:57 |
| jelmer | bkor: I was mainly interested in how it checks for MAINTAINERS - does it make sure the MAINTAINERS file is there after the commit or does it actually look at the delta of the commit? | 19:58 |
| bkor | jelmer: that is a pre-commit | 19:58 |
| uws | bkor, jelmer: eh, pre-commit methinks | 19:58 |
| uws | exactly | 19:58 |
| uws | jelmer: Ok, but I have to commit after removing the trunk/, and before moving the branch into its place | 19:58 |
| uws | but commiting the "svn rm trunk/" fails because of the pre-commit hook | 19:59 |
| bkor | jelmer: http://pastebin.mozilla.org/462388 | 19:59 |
| bkor | it is on purpose | 19:59 |
| uws | I like the "`whoami`" != "ovitters" part | 19:59 |
| uws | bkor: could you type this for me: | 20:00 |
| Jc2k | oh so its not just bzr-mirror that needs a workaround for gnomemm :) | 20:00 |
| jelmer | uws: ahh, ok. It is possible to do such a change when using the svn API, guess it's just the UI that forbids it. | 20:00 |
| uws | svn checkout svn+ssh://ovitters@svn.gnome.org/svn/gnome-specimen | 20:00 |
| uws | cd gnome-specimen/ | 20:00 |
| uws | rm -fr trunk | 20:00 |
| jelmer | uws,bkor: Disabling the hook and then doing the move would be easiest | 20:00 |
| uws | svn commit -m "Removed trunk/ so bzr import branch can be moved into its place" | 20:00 |
| jelmer | otherwise, I can come up with a python script that does it for you | 20:00 |
| uws | jelmer: according to http://pastebin.mozilla.org/462388 bkor can avoid the checks | 20:01 |
| uws | so if he removes trunk/ for me | 20:01 |
| uws | I can move the branch back | 20:01 |
| uws | methinks | 20:01 |
| bkor | uws: svn rm svn+ssh://svn.gnome.org/svn/gnome-specimen/trunk is easier, and done | 20:01 |
| uws | bkor: ah, didn't know that works as well | 20:01 |
| Jc2k | its probably worth trying the replay idea, the next time this crops up | 20:02 |
| jelmer | Jc2k: replay breaks all copies of the bzr branch you're pushing though | 20:02 |
| jelmer | Jc2k: what we're doing right now doesn't | 20:02 |
| Jc2k | ah | 20:02 |
| uws | Yay | 20:03 |
| uws | http://svn.gnome.org/viewvc/gnome-specimen/ | 20:03 |
| uws | it seems to have worked | 20:03 |
| uws | jelmer, bkor: it seems ok to me. | 20:04 |
| uws | jelmer: now bzr push svn+ssh://svn.gnome.org/svn/gnome-specimen/trunk/ from my original bzr branch ought to work, right? | 20:04 |
| jelmer | yep | 20:04 |
| jelmer | or, actually - you have to pull first | 20:05 |
| uws | yeah, pulled the "move" commit | 20:05 |
| uws | which doesn't seem to change anything locally | 20:05 |
| uws | jelmer: at least the output "bzr diff --verbose -r204..205" is empty | 20:05 |
| === mw|food is now known as mw | ||
| uws | (r205 is the "Moved branches/import-from-bzr to trunk to (hopefully) complete the import." commit) | 20:06 |
| jelmer | uws: Yep, that all looks fine | 20:06 |
| LarstiQ | uws: btw, I still have books of yours | 20:06 |
| uws | LarstiQ: Hmm. that's right. which ones? | 20:07 |
| uws | LarstiQ: alphabet + brown, right? | 20:07 |
| uws | LarstiQ: coming to guadec by any chance? | 20:07 |
| uws | (that would be a ridiculous place to hand those back, btw ;>) | 20:07 |
| * jelmer will most likely be at Guadec, btw | 20:07 | |
| uws | jelmer: You will? great. Chime in on #gnome-nl! | 20:08 |
| LarstiQ | uws: yes, what/where? | 20:08 |
| uws | LarstiQ: also coming to guadec? | 20:08 |
| * LarstiQ rephrases more clearly | 20:08 | |
| LarstiQ | uws: Those two books indeed. I'm familiar with guadec, but I don't know when or where it is this time around? | 20:09 |
| uws | LarstiQ: istanbul, July 6--13 | 20:14 |
| uws | anyway, dutch oss hackers should probably team up for a beer/other drink sometime | 20:15 |
| uws | gnome and bzr ppl, for instance | 20:15 |
| LarstiQ | no Guadec for me | 20:16 |
| LarstiQ | uws: but totally agreed about drinking ;) | 20:16 |
| Verterok | moin | 20:40 |
| beuno | howdy Verterok | 20:41 |
| Verterok | beuno: hi (I'm suffering a bit of lag :P) | 20:52 |
| beuno | Verterok, ah, 11 minutes lag is going to be interesting :) | 20:53 |
| Verterok | beuno: hehe | 20:54 |
| === dpm_ is now known as dpm | ||
| grantgm | does bundlebuggy actually perform requested merges, or does it just track them for code reviews? | 21:58 |
| mwhudson | it tracks them | 21:59 |
| mwhudson | pqm is what performs them | 21:59 |
| grantgm | ok, thanks. Is pqm documented anywhere? the description at https://launchpad.net/pqm sounds pretty awesome, and I'd like to push for bzr (incl. bundlebuggy and pqm) to be used for our department | 22:05 |
| grantgm | there seems to have been some discussion here: https://lists.ubuntu.com/archives/bazaar/2007q4/032572.html | 22:06 |
| grantgm | does anyone know if there's been any progress towards packaging or documenting it since then? | 22:07 |
| thumper | grantgm: I don't think so | 22:07 |
| thumper | grantgm: but I'm actively fixing a few pqm bugs | 22:07 |
| grantgm | good to hear that its still being actively developed. is it in a state where I should be pushing for our department to use it, or is it still really only used within bzr? | 22:11 |
| tca | I originally reported https://bugs.launchpad.net/bzr/+bug/205564, and this bug seems to be fixed in latest bzr.dev. Should I just close the bug myself? | 22:14 |
| ubottu | Launchpad bug 205564 in bzr "bzr log fails with KeyError: 'null:'" [Medium,Triaged] | 22:14 |
| Peng | I'm pretty sure you can, so it wouldn't hurt to. | 22:15 |
| Peng | If you're sure it's fixed. | 22:15 |
| nslater | how would i check the latest revision of a remote repository? | 22:46 |
| beuno | nslater, bzr revno LOCATION | 22:46 |
| nslater | thanks beuno :) | 22:47 |
| beuno | :) | 22:47 |
| awilkins | Hmm, there appear to be some DNS issues | 22:56 |
| Peng | oh? | 22:58 |
| awilkins | I'm getting problems resolving my newshost, but it seems to resolve OK from a host in the states | 22:59 |
| awilkins | http://just-ping.com/index.php?vh=news20.forteinc.com&s=ping! | 22:59 |
| niran | the bzr-svn page says that merged revisions show up as ghosts in svn. what does that mean? | 23:10 |
| jelmer | niran: They show up as ghosts in bzr | 23:11 |
| jelmer | niran: In other words, right hand side revisions (in other words, revisions show indented by "bzr log") are not pushed into subversion themselve but a pointer to them is | 23:12 |
| niran | oh... so the actual changesets shown NOT as ghosts in bzr are the same ones that will end up in svn? | 23:12 |
| jelmer | niran: If you push a branch into Subversion and then run "bzr branch" on the Subversion URL somewhere else | 23:12 |
| jelmer | it will only be able to copy the left hand side (not indented in "bzr log") revisions | 23:12 |
| niran | jelmer: ok i think that makes sense | 23:13 |
| niran | one more question | 23:13 |
| niran | when pushing multiple changesets to svn, do they each get a separate commit, or do they all show up at once? | 23:13 |
| jelmer | each left hand side revisions gets a separate commit | 23:14 |
| niran | ok, thanks for your help | 23:14 |
| lifeless | beuno: hi | 23:30 |
| beuno | mornin' lifeless | 23:30 |
| lifeless | beuno: you have an old index | 23:36 |
| lifeless | beuno: that was before I added reporting of paths, just delete the index | 23:37 |
| lifeless | beuno: also, completion, whaddya think :) :) :) | 23:37 |
| beuno | lifeless, good, Still bugless then :p | 23:38 |
| beuno | completion? | 23:38 |
| lifeless | check your gmail | 23:38 |
| lifeless | sorry, suggestions | 23:38 |
| lifeless | search completion/suggestions same thing | 23:39 |
| jml | lifeless: are you off to the vibe today? | 23:39 |
| beuno | lifeless, odd, I somehow missed that email completely :/ | 23:39 |
| lifeless | jml: I think so | 23:39 |
| * beuno checks gmail filters | 23:40 | |
| beuno | oh, VERY cool | 23:40 |
| jml | lifeless: cool. I'll pack some books. | 23:40 |
| * jml will head off in a few minutes. | 23:40 | |
| lifeless | beuno: so I guessed right that that is bling you'd find interesting :P | 23:42 |
| beuno | lifeless, replied back. You rock :) | 23:43 |
| beuno | I still don't understand how that email got marked as read | 23:44 |
| beuno | lifeless, can you send a test email my way? | 23:44 |
| lifeless | done | 23:44 |
| beuno | hrm, works fine. Odd. | 23:45 |
| lifeless | bundle in a sec | 23:45 |
| beuno | thanks :) | 23:45 |
| beuno | I've got a dinner, but I already know how to do the ajax bit for that, so it should be just a couple of hours work | 23:46 |
| lifeless | sweet | 23:46 |
| lifeless | after work tonight I'll do the refactoring and partial-read work required to make it faster | 23:46 |
| beuno | LH will look *very* web 2.0 in a month's time | 23:46 |
| mwhudson | :) | 23:47 |
| beuno | lifeless, I get: beuno@beuno-laptop:~/bzr_devel/bzr-search$ bzr pull ~/Desktop/trunk-38.patch | 23:48 |
| beuno | bzr: ERROR: Revision {('robertc@robertcollins.net-20080617122537-eyv8tt7s1dki5dyw',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x894f7ec>". | 23:48 |
| lifeless | you probably don't have 37 | 23:49 |
| lifeless | oh, or my hacking send glitched cause there is no public branch | 23:49 |
| beuno | beuno@beuno-laptop:~/bzr_devel/bzr-search$ bzr revno | 23:49 |
| beuno | 37 | 23:49 |
| lifeless | abentley: how can I force bundle to include data for a revision | 23:52 |
| lifeless | (bundle/send/whatever) | 23:52 |
| beuno | lifeless, maybe just send me the whole branch? should be small enough | 23:52 |
| lifeless | beuno: I have :P | 23:54 |
| lifeless | 401K including its own index :P | 23:54 |
| beuno | lifeless, very very very cool :) | 23:57 |
| beuno | and, fast as hell compared to other apps to doing this | 23:57 |
| abentley | lifeless: create a branch that lacks that revision and use it as the submit branch | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!