| === abentley1 is now known as abentley | ||
| mwhudson | are all bzr+http accesses at the http level POSTs to $branch_url/.bzr/smart ? | 02:10 |
|---|---|---|
| spiv | mwhudson: some might be to higher directories I suppose, if bzr tries to look for shared repos and the like | 02:11 |
| mwhudson | spiv: for read-only launchpad i guess we can mostly ignore that? | 02:11 |
| spiv | mwhudson: IIRC bzr will try to prefer the first .bzr/smart that seems to work, though. | 02:11 |
| spiv | mwhudson: I think so. | 02:11 |
| mwhudson | spiv: cool | 02:12 |
| Peng | For me it accesses both repo/branch/.bzr/smart and repo/.bzr/smart. | 02:15 |
| Peng | That's if I use an "http" URL. If I use "bzr+http", it only uses repo/branch/.bzr/smart. | 02:16 |
| lifeless | mwhudson: what is the relevance of read-only lp to this? | 02:21 |
| mwhudson | lifeless: to what? | 02:21 |
| lifeless | bzr+http accesses | 02:21 |
| Peng | Well it'd be nice if LP supported it, no? :D | 02:22 |
| Peng | Why not straight bzr://? | 02:22 |
| lifeless | Peng: code.launchpad.net ? | 02:22 |
| mwhudson | lifeless: someone requested bzr+http specifically on the bazaar list | 02:22 |
| lifeless | Peng: or bazaar.launchpad.net ? | 02:22 |
| mwhudson | lifeless: just thinking about how hard it would be | 02:22 |
| lifeless | mwhudson: forward .smart to loggerhead? | 02:22 |
| lifeless | as loggerhead already does bzr+http doesn't it ? | 02:23 |
| mwhudson | lifeless: yeah maybe | 02:23 |
| Peng | Cuz what LP needs is Loggerhead using even more CPU and RAM! | 02:23 |
| mwhudson | well the one we have on launchpad doesn't do bzr+http cause of the way it's set up wsgi-wise | 02:23 |
| mwhudson | but that's strictly a detail | 02:23 |
| mwhudson | Peng: possibly not the same loggerhead as the code browsing one, i guess | 02:24 |
| lifeless | mwhudson: if we're adding loggerhead instance and haproxying between them, I'd make them all the same. | 02:26 |
| lifeless | mwhudson: and just add lots. | 02:26 |
| mwhudson | lifeless: yeah | 02:27 |
| Peng | Kinda silly to run Loggerhead *just* for .bzr/smart. | 02:28 |
| mwhudson | Peng: there's not much point following me on both twitter and identi.ca btw | 02:29 |
| Peng | mwhudson: Shrug. I usually do that anyway. Just in case one of them explodes or something, I guess. | 02:30 |
| mwhudson | fair enough | 02:31 |
| lifeless | Peng: but it wouldn't be just for it. | 02:35 |
| lifeless | Peng: we'd get more cpus working on code browsing at the same time. | 02:35 |
| Peng | Yeah, that sounds good. | 02:35 |
| Peng | Err, did that sound sarcastic? | 02:36 |
| lifeless | no. | 02:37 |
| lifeless | did you meant it to be? If so, FAIL. | 02:37 |
| Peng | Heh. I did not. | 02:38 |
| lifeless | http://robey.lag.net/2009/11/29/more-git.html is interesting | 02:58 |
| lifeless | just that the values and behaviours we recommend are still valuable to robey ;) | 02:59 |
| lifeless | Peng: as for why not straight bzr://, we could do that. But we have http open in the firewall, *and* loadbalancing software for it, already. | 03:22 |
| Peng | Ah. | 03:38 |
| Peng | Plus it's probably better for users behind firewalls, too. Though not those behind weird proxies. | 03:38 |
| lifeless | POST should be fine for them | 03:39 |
| lifeless | its non-smart http that really exercises the bug db of proxy vendors | 03:39 |
| Peng | Oh, good point. | 03:40 |
| poolie | afc, mwhudson, lifeless: so what i meant when i said anonymous ssh may be easiest is just that it may be easiest, not necessarily fastest | 04:00 |
| poolie | lifeless: want to send any mail about patch piloting? | 04:02 |
| lifeless | poolie: yes | 04:04 |
| lifeless | poolie: but its not work for me, so will happen later | 04:05 |
| lifeless | poolie: I have to do a sweep of the things I'm piloting anyhow | 04:05 |
| poolie | np | 04:09 |
| lifeless | poolie: bug 489993 - please consider landing that as-is; I agree we can overhaul the area, but fixing the logic inversion won't add debt or decrease test coverage. | 04:36 |
| ubottu | Launchpad bug 489993 in bzr "bzr 2.1.0b3 reports interpreter path on Mac OS X with a .dll extension" [Low,Confirmed] https://launchpad.net/bugs/489993 | 04:36 |
| poolie | yes | 04:38 |
| poolie | i didn't realize on the first reading that there was a logic inversion | 04:39 |
| poolie | thus the confugison | 04:39 |
| lifeless | cool | 04:41 |
| poolie | lifeless, i don't understand why you think handing over in-progress patches will cause rework | 04:42 |
| poolie | have you seen this happen? | 04:42 |
| poolie | i have seen other people want different things from a patch | 04:42 |
| poolie | but, that's life | 04:42 |
| poolie | we can resolve it | 04:42 |
| === jfroy is now known as jfroy|finishingd | ||
| === jfroy|finishingd is now known as jfroy|lvmealon | ||
| === jfroy|lvmealon is now known as jfroy|frackoff | ||
| dOxxx | hey poolie, just popping so we can sort out this 489993 thing quickly | 04:51 |
| poolie | bug 489993 | 05:00 |
| ubottu | Launchpad bug 489993 in bzr "bzr 2.1.0b3 reports interpreter path on Mac OS X with a .dll extension" [Low,Confirmed] https://launchpad.net/bugs/489993 | 05:00 |
| poolie | yep | 05:00 |
| poolie | i agree with your patch and i'll merge it | 05:00 |
| poolie | how's that? | 05:00 |
| dOxxx | ok :) | 05:00 |
| dOxxx | I was just a bit confused | 05:00 |
| dOxxx | there was some back and forth with lifeless about whether it should be changed to just remove that whole section | 05:00 |
| dOxxx | but if you're cool with it as is, that's fine by me. I pushed one more little change to add a comment referencing the doc url on the py2exe env like you suggested | 05:02 |
| poolie | i think that would be better but it's good to merge as it is | 05:02 |
| dOxxx | alrighty, minimal interference patch it is :) | 05:03 |
| dOxxx | I shall bid you good night then. Seeya later. | 05:04 |
| lifeless | poolie: because its going to cause new conversations | 05:11 |
| poolie | if there's been conversation about the patch not captured in the review? | 05:13 |
| lifeless | no, because the new pilot is likely not to have participated in the review so far | 05:14 |
| poolie | and... they may have questions that they'll ask now, but that would otherwise have gone unasked? | 05:15 |
| lifeless | I see this happen quite a lot - with experienced folk it doesn't matter, as you say we can address it. | 05:15 |
| lifeless | but if we really want to be helping these casual contributions get through, deliberately provoking that seems risky to me. | 05:16 |
| poolie | sorry what is "this" and "that"? | 05:16 |
| poolie | what i mean is | 05:17 |
| poolie | if changing from one reviewer to another requires the patch to be reworked | 05:17 |
| poolie | that seems like a pretty serious problem | 05:18 |
| poolie | like people are enforcing very different standards or something | 05:18 |
| lifeless | uhm | 05:18 |
| lifeless | I'm clearly not expressing the concern well. | 05:18 |
| poolie | iiuc the concern is | 05:19 |
| lifeless | I'm talking about things like scope expansion, 'taste' and so forth, not the actual standards or functional defects. | 05:19 |
| poolie | you've replied to a review last week saying "please do X and I'll merge it" | 05:19 |
| poolie | and then I come along this week and say "oh please do Y too" | 05:19 |
| poolie | ..? | 05:19 |
| lifeless | as a for instance, yes. | 05:19 |
| lifeless | if there is a pilot handoff I'm concerned that this will happen a lot more. | 05:20 |
| poolie | ok | 05:20 |
| poolie | so if it was you all the way through | 05:20 |
| poolie | you might sometimes do that, actually | 05:20 |
| poolie | saying "I've just realized we should do Y too" | 05:20 |
| poolie | but you'd probably at least notice you were doing it? | 05:20 |
| lifeless | right. Probably with 'sorry' in there too. | 05:20 |
| lifeless | :) | 05:20 |
| poolie | right:) | 05:20 |
| poolie | that seems like something we could in princple do across reviewers? | 05:21 |
| lifeless | yes, I'm not claiming exclusive ownership of these issues for patch pilot handoffs. | 05:21 |
| poolie | say that by default if one reviewer sets requirements for scope or cleanliness, we won't come back and raise them later? | 05:21 |
| lifeless | just a raised frequency. | 05:21 |
| lifeless | why do you want the handoff? | 05:22 |
| poolie | i want the pp process to be: | 05:22 |
| lifeless | I mean, you say the software doesn't model it, but I don't see why the software needs to, it already shows a submission date which is all you need. | 05:23 |
| poolie | while not active_reviews.empty(): active_reviews().pop().resolve() | 05:23 |
| lifeless | If there was a 'correct' actions_I_should_do list, I would be totally +1000 on that process. | 05:24 |
| lifeless | but we seem to be pretty far off that. | 05:24 |
| lifeless | I'd rather focus on giving a fantastic experience to new contributors that the pilot efficiency right now - particularly as the pilot efficiency is already quite high IME. | 05:24 |
| lifeless | s/that/than/ | 05:25 |
| poolie | so | 05:25 |
| poolie | i think having one person deal with them all the way through is a better experience than changing hands | 05:26 |
| poolie | however, i think having *somebody* follow up monday is better than having the original person follow up later | 05:26 |
| lifeless | poolie: why would the original person be following up any later than the new pilot? | 05:27 |
| poolie | i think they might be busy with other things or distracted when their week is over | 05:27 |
| lifeless | poolie: I mean, to be clear, I have no objection to more people helping out. But having the pilot stop on friday night seems wrong. | 05:27 |
| poolie | i would say their obligation to help finishes friday night | 05:28 |
| poolie | or their commitment | 05:28 |
| poolie | i want to make it easy enough on developers that they will do it | 05:29 |
| lifeless | what I find odd is that the two people that have done it so far haven't had an issue with this. | 05:29 |
| poolie | ok | 05:30 |
| poolie | i think this discussion is running dry | 05:30 |
| poolie | i'm not going to avoid touching reviews you've already commented on | 05:30 |
| lifeless | I am happy if you *want* to touch everything | 05:30 |
| poolie | i'm also not going to move the goalposts on the submitter without good reason | 05:30 |
| lifeless | I just want you to also pilot new things landed up to friday next week. Given that piloting only ever blocks on getting a second reviewer, this should be very easy for you. | 05:31 |
| lifeless | poolie: bah, my first sentence parses badly; please apply logic-checker on reading it :) | 05:31 |
| lifeless | I wasn't ever suggesting you should avoid reviewing stuff | 05:32 |
| lifeless | that would be nuts | 05:32 |
| poolie | you're saying you want me to promise to keep reviewing anything that lands this week, for as long as it takes? | 05:32 |
| lifeless | give me a minute pease, ringing tim to get bzr/+activereviews unbroken. | 05:33 |
| === abentley1 is now known as abentley | ||
| lifeless | poolie: yes | 05:37 |
| poolie | vila, hi, around? | 06:52 |
| poolie | want to talk about https://code.edge.launchpad.net/~vila/bzr/353370-notty-no-term-width/+merge/13832 | 06:54 |
| bialix | poolie: hi | 07:37 |
| bialix | are you here? | 07:37 |
| bialix | hello all | 07:37 |
| poolie | hi there | 07:37 |
| bialix | hi, can you say some ETA on next 2.1 release? (b4 or rc1)? | 07:38 |
| bialix | I need to plan next qbzr release accordingly | 07:38 |
| poolie | sure | 07:38 |
| bialix | the date is already known? | 07:38 |
| poolie | according to https://edge.launchpad.net/bzr/2.1 it's the 14th of december | 07:38 |
| poolie | and i don't see any reason to change that | 07:39 |
| bialix | thanks poolie, that's fine for me | 07:39 |
| poolie | we haven't been totally precise but we've been pretty close to those dates | 07:39 |
| bialix | poolie, I'm thinking about blogging on new cool features in qbzr 0.17, somrthing like LP guys wrote for their release announcements (with screenshots et al) | 07:40 |
| bialix | there is main bzr blog | 07:40 |
| bialix | or I can start special qbzr blog | 07:40 |
| bialix | because I have no access to main bzr blog, so I'm in doubts | 07:41 |
| poolie | i would like that a lot | 07:42 |
| bialix | poolie, do you think I should start dediacted blog? From other hand the chances that I'll blog in the future maybe not very high | 07:42 |
| poolie | i can certainly give you access | 07:42 |
| poolie | i think you should just put it there and tag it qbzr | 07:42 |
| bialix | can I do series of post, one for each separate feature? | 07:43 |
| poolie | sure | 07:43 |
| bialix | what you need from me to give me access? sign with blood ;-) | 07:43 |
| poolie | your prefered email address? | 07:45 |
| bialix | should be listed on my page: https://launchpad.net/~bialix | 07:45 |
| poolie | ok, sent | 07:48 |
| poolie | let me know if there's any problems | 07:48 |
| bialix | got your mail | 07:49 |
| bialix | hmmm | 07:50 |
| bialix | it said "bialix" username already exists | 07:50 |
| poolie | ! :) | 07:52 |
| bialix | ok, I've reset the password and now successfully login | 07:53 |
| bialix | don't see bazaarvcs blog though | 07:53 |
| bialix | poolie: on the page "My blogs" there is no bazaarvcs | 07:54 |
| bialix | I don't know what I'm doing wrong | 07:54 |
| * poolie looks | 07:54 | |
| poolie | try now? | 07:55 |
| bialix | poolie: works now, I'm in | 07:56 |
| poolie | great | 07:56 |
| poolie | i see gary already posted about some things | 07:56 |
| bialix | poolie: ok, found magic button "New Post". it seems I can write | 07:59 |
| bialix | thanks | 07:59 |
| * bialix don't use wordpress so will need some time to learn | 07:59 | |
| poolie | great | 08:05 |
| poolie | give it a try? | 08:07 |
| bialix | what do you mean? | 08:09 |
| bialix | I'll post tonight, after work | 08:09 |
| vila | hi all | 08:12 |
| poolie | hi vila | 08:15 |
| poolie | i just posted some things on bug 353370 in regard to your patch for that | 08:16 |
| ubottu | Launchpad bug 353370 in bzr "Lines cut off at 80 chars regardless of actual terminal size" [High,Fix committed] https://launchpad.net/bugs/353370 | 08:16 |
| * vila reading | 08:17 | |
| poolie | also i'm going to logoff soon | 08:18 |
| vila | poolie: ok, I'll comment there then | 08:19 |
| poolie | bialix: do you have any ideas how to debug bug 490228? | 08:19 |
| ubottu | Launchpad bug 490228 in bzr "Crash in groupcompress during commit operation" [Undecided,New] https://launchpad.net/bugs/490228 | 08:19 |
| vila | oh, you commented on the mp too | 08:19 |
| poolie | yeah | 08:22 |
| bialix | hi vila | 08:22 |
| poolie | then i thought that bugs were a better place | 08:22 |
| bialix | poolie: right now I can't say anything useful | 08:22 |
| poolie | so essentially i think we should fix the api somehow | 08:22 |
| poolie | bialix: ok, i just wondered if you knew a better way to get a good stacktrace? | 08:22 |
| bialix | no | 08:23 |
| bialix | maybe jam | 08:23 |
| poolie | vila: istm that "how wide is the terminal" should at the lowest level sometimes say "i don't know " or "i'm not sure" and then what happens with that depends on how you're going to use ti | 08:23 |
| poolie | it* | 08:23 |
| poolie | not sure though | 08:23 |
| vila | hmpf | 08:25 |
| vila | exactly what I was going to say :-) | 08:25 |
| poolie | :) | 08:25 |
| poolie | the good thing is there are only a few callers | 08:26 |
| vila | which means: 1) don't bother for log --line 2) progress bars are drawn only if the termiaal width is known | 08:26 |
| vila | i.e. don't outsmart the user and let it fix it's terminal width if things go wrong | 08:26 |
| vila | with the caveat that we don't want do *not* display progress bars too aggressively ? | 08:27 |
| vila | hi bialix | 08:27 |
| bialix | poolie: btw irclogs bots seems broken | 08:27 |
| bialix | bonjour vila | 08:27 |
| poolie | bialix: thanks | 08:27 |
| poolie | on irclogs.ubuntu.com? | 08:28 |
| bialix | yes | 08:28 |
| bialix | since Saturday no new logs | 08:28 |
| bialix | for all channels | 08:28 |
| poolie | mm i see | 08:28 |
| poolie | thanks | 08:28 |
| poolie | vila: so istm we should: let terminal_width return None and check the callers will cope | 08:29 |
| poolie | and also make it trust COLUMNS even if not on a tty | 08:29 |
| vila | that's sound pretty close, I have to check COLUMNS behavior a bit more since I discovered some strangeness there (at least the behavior is not as clear as I thought) | 08:30 |
| vila | but yeah, if COLUMNS can't be fully trusted, use BZR_COLUMNS | 08:31 |
| poolie | bialix: i filed a ticket for it; nobody's responding at the moment | 08:33 |
| poolie | good night all | 08:34 |
| vila | poolie: good night | 08:34 |
| bialix | fullermd: ping | 12:39 |
| === mrevell is now known as mrevell-lunch | ||
| thrope | hi - is it possible to copy a file with hisotry? | 13:01 |
| Peng | thrope: no | 13:01 |
| thrope | oh - thats a pain | 13:01 |
| Peng | Yeah. | 13:02 |
| Peng | Bazaar's design makes it a bit tricky, and nobody has done the work yet. | 13:02 |
| thrope | ok - thanks | 13:05 |
| === mrevell-lunch is now known as mrevell | ||
| vila | thrope: out of curiosity, why do you want to do that ? I generally needed that in CVS days because I couldn't rename a file, but now ? | 14:00 |
| thrope | vila: forking a file... working on a paper/report and had a script to produce figures for it.... but now changing the structure of report completely so I'm going to change it, but still want the old one around | 14:01 |
| thrope | I guess I could tag or something instead but I'd rather make a copy and have them both there so I can compare more easily | 14:01 |
| vila | thrope: how about creating a new branch while keeping the old one around ? | 14:02 |
| thrope | vila: yeah I could do that I guess... but I run the code on a number of difference machiens that are all bound so it would mean working out which one is bound to what etc | 14:02 |
| thrope | its ok just to loose the history in this cae... can always look back at the original file | 14:03 |
| bialix | vila: I have use case for you: split big file into 2 | 14:03 |
| thrope | bialix: thats a better one ;) | 14:03 |
| vila | bialix: I know there are valid use cases, I wanted some fresh input :) | 14:03 |
| bialix | vila: I'm just encounter this use case *today* | 14:05 |
| * bialix sighs and hides | 14:05 | |
| vila | bialix: And what are your expectations with regard to future merges ? | 14:05 |
| bialix | I'm happy to not have future merge, but like to preserve annotations | 14:07 |
| thrope | maybe merge to original with a warning that file has been copied and merge not applied to copied file | 14:07 |
| bialix | different file-ids today makes future merge after split the pain too | 14:07 |
| === kosipov is now known as kostja_osipov | ||
| kostja_osipov | hi | 14:40 |
| kostja_osipov | how do I retrieve per-file comments for a revision from the command line? | 14:41 |
| beuno | kostja_osipov, bzr log FILE -r REVISION? | 14:41 |
| kostja_osipov | hm... | 14:42 |
| kostja_osipov | is there a way to get all comments for all files at once? | 14:42 |
| beuno | bzr log FILE? | 14:42 |
| kostja_osipov | beuno: imagine I have a revision number: 2640.4.4 | 14:43 |
| kostja_osipov | I can do bzr diff -c 2640.4.4 | 14:43 |
| kostja_osipov | that gives me a diff that this revision introduced | 14:44 |
| kostja_osipov | I can do bzr log -c 2640.4.4 | 14:44 |
| kostja_osipov | that gives me the changeset comment for that revision | 14:44 |
| kostja_osipov | well, I could of course do bzr log <file1> -c 2640.4.4 | 14:44 |
| kostja_osipov | then bzr log <file2> -c 2640.4.4 | 14:44 |
| kostja_osipov | and so on | 14:44 |
| kostja_osipov | but that will take quite a while (the patch changes many files) | 14:44 |
| beuno | kostja_osipov, there ar eno per-file comments on commits | 14:44 |
| beuno | commits are atomic | 14:44 |
| kostja_osipov | beuno: it's a terminology issue I guess. when I commit, I can write per-file comments. | 14:45 |
| beuno | kostja_osipov, I am not aware of such thing with bzr | 14:46 |
| kostja_osipov | beuno: try bzr gcommit ;), click on a file, you can add a file-specific commit comment. | 14:47 |
| beuno | ah, right | 14:47 |
| beuno | I'm not sure how that gets stored though | 14:48 |
| beuno | jelmer may, if he's around :) | 14:48 |
| kostja_osipov | yeah, so now I'd like to get it back | 14:48 |
| bialix | kostja_osipov: I think you can't yet | 14:49 |
| bialix | I have ideas for adding such feature to qbzr though | 14:50 |
| beuno | bialix, it's stored as metadata, right? | 14:50 |
| bialix | as revision properties | 14:50 |
| bialix | something like ci --fixes | 14:50 |
| ChrisMorgan | I'm trying to log in to Launchpad Bazaar (on Windows) and it's not working at all. | 14:50 |
| ChrisMorgan | I'm getting: bzr: ERROR: Connection error: Unable to authenticate to SSH host as | chris.morgan@bazaar.launchpad.net | supported auth types: ['publickey'] | 14:50 |
| bialix | beuno: only bzr-gtk currently supports per-file commit messages (this is MySQL thingy) | 14:50 |
| bialix | ChrisMorgan: you have to use SSH keys | 14:51 |
| bialix | ChrisMorgan: hint: pageant, puttygen | 14:51 |
| bialix | there is nice tutorial on lp wiki | 14:51 |
| ChrisMorgan | How? I have an SSH key up there, but I can't work out how to feed the private key into Bazaar | 14:51 |
| bialix | ChrisMorgan: pageant? | 14:51 |
| beuno | kostja_osipov, that basiclly means that you can't get it from the command line, you will need to write a script | 14:51 |
| ChrisMorgan | pageant? | 14:52 |
| bialix | ChrisMorgan: what are your SSH client on Windows? How do you generate SSH key? | 14:52 |
| ChrisMorgan | I generated it with PuTTY | 14:52 |
| bialix | great | 14:53 |
| bialix | now run pageant -- this is part of Putty package | 14:53 |
| bialix | pageant.exe | 14:53 |
| ChrisMorgan | Is this to turn it into id_rsa.pub? | 14:53 |
| bialix | it will start small icon in system tray area | 14:53 |
| bialix | no | 14:53 |
| bialix | no | 14:53 |
| bialix | no | 14:53 |
| bialix | you should have *.ppk file | 14:53 |
| ChrisMorgan | OK; running. | 14:53 |
| ChrisMorgan | Yep | 14:54 |
| bialix | private key generated by puttygen | 14:54 |
| ChrisMorgan | Added ppk | 14:54 |
| bialix | double click on pageant icon and add key | 14:54 |
| bialix | now run bzr again | 14:54 |
| ChrisMorgan | Then? | 14:54 |
| bialix | then what? | 14:55 |
| bialix | run your bzr command again | 14:55 |
| ChrisMorgan | OK... so what did pageant do? :/ | 14:55 |
| ChrisMorgan | Thanks :-) | 14:55 |
| bialix | pageant is putty key agent | 14:55 |
| bialix | it provides bzr with your private key | 14:55 |
| ChrisMorgan | So it has to be running all the time when I use bzr? | 14:56 |
| bialix | you may want to put pageant into autostart entry | 14:56 |
| kostja_osipov | beuno: ok,I"m ready to write a script | 14:56 |
| bialix | yep | 14:56 |
| kostja_osipov | do you have some how-to or something? | 14:56 |
| kostja_osipov | I have over 200 changesets for which I need this stuff. | 14:56 |
| bialix | kostja_osipov: look at log code | 14:56 |
| ChrisMorgan | lifeless: #bazaar should redirect to here; #bazaar was my first guess (incidentally then, why is there a CIA bot sitting in there?) | 14:56 |
| kostja_osipov | bialix: i see | 14:57 |
| bialix | there is similar thing to per-file messages: branch nick | 14:57 |
| kostja_osipov | okay? | 14:57 |
| bialix | look how branch nick extracted from revision | 14:57 |
| bialix | it's basically access to properties dict | 14:58 |
| bialix | you may want to look into bzr-gtk code to see exact key values | 14:58 |
| bialix | kostja_osipov: I think actually bzr-gtk is your friend here | 14:59 |
| kostja_osipov | bialix: something like this: | 14:59 |
| kostja_osipov | # per-file messages | 14:59 |
| kostja_osipov | file_info = revision.rev.properties.get('file-info', None) | 14:59 |
| kostja_osipov | if file_info is not None: | 14:59 |
| kostja_osipov | if isinstance(file_info, unicode): | 14:59 |
| kostja_osipov | file_info = file_info.encode("utf-8") | 14:59 |
| kostja_osipov | file_info = bencode.bdecode(file_info) | 14:59 |
| kostja_osipov | if file_info: | 14:59 |
| kostja_osipov | for fi in file_info: | 14:59 |
| kostja_osipov | to_file.write('%s%s%s\n' % (indent, " @ ", fi['path'],)) | 14:59 |
| kostja_osipov | if fi['message']: | 14:59 |
| kostja_osipov | for line in fi['message'].rstrip().split("\n"): | 14:59 |
| bialix | pastebin please | 14:59 |
| kostja_osipov | to_file.write('%s%s%s\n' % (indent, " ", line,)) | 15:00 |
| kostja_osipov | heh ;) | 15:00 |
| bialix | yep, something like that | 15:00 |
| bialix | I don't have copy of MySQL branch to test it ;-) | 15:00 |
| kostja_osipov | bialix: ok, I think I can actually already access this functionality indirectly via: | 15:01 |
| kostja_osipov | bzr log --mysqlcommitemail -c 2630.4.3 | 15:02 |
| kostja_osipov | (this switch comes from mysql plugins) | 15:02 |
| kostja_osipov | pretty nice: | 15:02 |
| kostja_osipov | 2630.4.3 Dmitry Lenev2008-05-24 | 15:02 |
| kostja_osipov | WL#3726 "DDL locking for all metadata objects" | 15:02 |
| kostja_osipov | 15:02 | |
| kostja_osipov | Fixed failing Windows builds by adding mdl.cc to the lists | 15:02 |
| kostja_osipov | of files needed to build server/libmysqld on Windows. | 15:02 |
| kostja_osipov | @ libmysqld/CMakeLists.txt | 15:02 |
| kostja_osipov | Added mdl.cc to the list of files needed for building of libmysqld. | 15:02 |
| kostja_osipov | @ sql/CMakeLists.txt | 15:02 |
| kostja_osipov | Added mdl.cc to the list of files needed for building of server. | 15:02 |
| kostja_osipov | (sorry for flooding the channel -- is it not allowed here?) | 15:02 |
| bialix | there is plenty of ru people in your team? | 15:02 |
| kostja_osipov | some; what team do you have in mind? server runtime? | 15:03 |
| bialix | I dunno | 15:03 |
| bialix | I'm not sql hacker, just qbzr hacker | 15:04 |
| bialix | kostja_osipov: btw, I have evil plan to add support for per-file messages to qbzr; to qlog, qann and qci | 15:05 |
| kostja_osipov | we have multiple server teams, each works on an area. In runtime therea are 3 Russians, 3 Norwegians, 1 Swede, 1 Brazilian, 1 German, etc | 15:06 |
| kostja_osipov | bialix: I'm not using q* stuff | 15:06 |
| bialix | this is not to you personally | 15:09 |
| === beuno is now known as beuno-lunch | ||
| kostja_osipov | bialix: my #1 wish would be that cherry-picking (bzr merge -c) would automatically transfer all comments along with the patch. | 15:28 |
| bialix | kostja_osipov: you can replay revision and then merge it | 15:29 |
| bialix | or rebase if replay refuse because of conflicts | 15:29 |
| mthaddon | jam: RT#36031 is about configuring PQM to use python2.4, and the last comment in there is about asking you guys to let me know when you're ready for me to change the configs to use "make pqm-test" as the pre-commit hook - that sound familiar? | 15:46 |
| jam | mthaddon: indeed it does. I replied to your email | 16:02 |
| jam | vila: are you around? | 16:02 |
| mthaddon | jam: great, thx | 16:02 |
| vila | jam: hi ! Glad to see you back, I hope your son and you are going better | 16:03 |
| jam | yeah, a bit of a cough left, but no fever, etc. | 16:03 |
| jam | vila: just wondering how babune, et al are holding up | 16:03 |
| jam | freebsd seems to have failed again? | 16:04 |
| vila | yeah, lots of trouble :-/ | 16:04 |
| vila | the combined upgrade of karmic/vbox made many slaves unstable or losing connections, I'm upgrading the gentoo one right now hoping to get it stable :-/ | 16:05 |
| vila | I'm torn between migrating to hudson or waiting to have more stability back :-/ | 16:06 |
| vila | In fact I'm suspecting some change in buildbot itself (brought by the karmic upgrade_ | 16:07 |
| vila | ) | 16:07 |
| bialix | hi jam, glad you're back | 16:08 |
| vila | jam: in summary, I have the Ubuntu slaves up and running, I'm trying to fix the others while manually running the test suite when I can | 16:09 |
| jam | hi bialix | 16:09 |
| bialix | jam: without you even there is no announce for latest releases | 16:15 |
| bialix | btw, jam, maybe it's just me so paranoid, but I think latest regression on windows custom globber with replacing all \ with / is serious enough to not put it into wild | 16:18 |
| kostja_osipov | vila: btw, I've finally gotten to the file-id | 16:22 |
| kostja_osipov | problem | 16:22 |
| kostja_osipov | indeed, when the file is added by the cherry-picking command, there is no file-id issue | 16:23 |
| kostja_osipov | it would be really great if it was possible to change file-ids. I'm not the only one who has stepped on these rakes... | 16:23 |
| vila | kostja_osipov: once you start sharing any history, you can't change file-ids or revi-ids anymore | 16:24 |
| vila | I understand the pain, but I can't think of a good work-around. What you did was telling bzr that you created a new file and then you want to merge it with another one. Until we implement file-tokens (the exact name escapes me right now), there is little that can be done. | 16:26 |
| vila | But once there are implemented, you'll be able to "join" two files saying to bzr: look, these files are really the same one | 16:27 |
| * vila hates saying: come back later, we'll have a such better solution :-( | 16:27 | |
| kostja_osipov | vila: this is a pretty unique situation we're in | 16:31 |
| kostja_osipov | i hope it'll be a one-time issue | 16:31 |
| bialix | vila: path tokens | 16:32 |
| vila | kostja_osipov: yeah, it's a usability issue, but one that can lead to some lost hours :-/ | 16:32 |
| vila | bialix: thanks ! I was close :) | 16:32 |
| bialix | yeah :-D | 16:33 |
| kostja_osipov | vila: the reason I got trapped in this is that I thought that bzr merge -c is equivalent by cd source; bzr diff > ~/tmp; cd dst; patch -p0 < diff | 16:33 |
| kostja_osipov | but it actually isn't | 16:33 |
| kostja_osipov | bzr merge -c is a very "interesting" command. | 16:33 |
| kostja_osipov | it doesn't transfer the original revision id; but on the other hand it's not an equivalent of diff + patch | 16:33 |
| vila | kostja_osipov: yes. You should *never* user patch | 16:34 |
| kostja_osipov | it is unclear why :) | 16:34 |
| vila | err, I meant: You should never *have* to use patch | 16:34 |
| kostja_osipov | I would stick to always using bzr merge -c if I understood exactly what it does | 16:34 |
| kostja_osipov | vila: the reason I used patch instead of bzr merge was this: | 16:34 |
| vila | kostja_osipov: roughly the same as patch, but taking renames into account :) | 16:34 |
| kostja_osipov | I'm cherry-picking a changeset. | 16:35 |
| kostja_osipov | it contains changes to files that are not yet in the destination tree | 16:35 |
| kostja_osipov | so I get a lot of conflicts. | 16:35 |
| kostja_osipov | the easiest way for me to solve them all was to: | 16:35 |
| kostja_osipov | bzr diff > ~/patch | 16:35 |
| kostja_osipov | bzr revert | 16:35 |
| kostja_osipov | patch -p0< ~/patch | 16:35 |
| kostja_osipov | this way I don't have to manually revert all "new" files which I don't want | 16:35 |
| kostja_osipov | but I figured it has a gotcha :) | 16:36 |
| kostja_osipov | so I restarted from a fresh tree, and re-done bzr merge -c, this time bzr reverting all new files I didn't want | 16:36 |
| kostja_osipov | and now I seem to be all set | 16:37 |
| === beuno-lunch is now known as beuno | ||
| nmb | vila: I'm free if you've got a chance to talk about 395714 | 17:47 |
| vila | nmb: Neil ! I've talked with Glenjamin, I'm pretty sure this is caused by bzr-svn, I know why and how to fix it. | 17:48 |
| nmb | Cool! | 17:48 |
| vila | s/pretty sure/now sure/ | 17:48 |
| nmb | vila: I'm glad we tracked down where it was coming from. | 17:48 |
| nmb | vila: Would you like me to try with disabling bzr-svn or do you have all the datapoints you need? | 17:49 |
| vila | nmb: sure ! Thank you so much for your efforts there ! | 17:49 |
| nmb | vila: checking... | 17:49 |
| vila | The root cause is that bzr-svn is using the requests in a way that is not supported. I've talked with jelmer and will make the necessary changes in bzr | 17:49 |
| vila | and may be even provide a patch for bzr-svn so all code paths are covered | 17:50 |
| vila | nmb: search for req.follow_redirections = True in bzr-svn transport.py, this option can't be used with authentication | 17:51 |
| vila | that's where I didn't understand how it occurred to you (I haven't read the traceback close enough :-/) | 17:51 |
| nmb | vila: If I disable bzr-svn, it works on the glenjamin.co.uk URL and on my local URL where I discovered the bug. | 17:52 |
| vila | nmb: and that explains why I didn't reproduce it (the machine I used didn't have bzr-vsn installed) | 17:52 |
| Noldorin | hi. i'm trying to set up loggerhead on an http server here, but don't know how to go about it | 17:52 |
| Noldorin | could anyone direct me please? | 17:52 |
| Noldorin | lifeless: hello? | 17:52 |
| nmb | Noldorin: I've just done it. | 17:52 |
| jelmer | vila: Please let me know if there's anything I can do to help with that | 17:52 |
| vila | nmb: Great ! Thanks for checking | 17:52 |
| === abentley is now known as abentley-lunch | ||
| nmb | Noldorin: Tell me more about your setup | 17:53 |
| Noldorin | nmb: excellent. well i'm trying to set it up on an iss7 server (with isapi-wsgi installed) | 17:53 |
| nmb | vila: I'll mark my branch as abandoned and the merge proposal as obsolete as well | 17:53 |
| Noldorin | so far i've just uploaded the loggerhead files and the dependencies | 17:53 |
| nmb | Noldorin: loggerhead usually works as a proxied local web application... | 17:54 |
| vila | jelmer: well, waiting for the OPTIONS support in bzr you can try to rewrite dav_options to use do_catching_redirections instead of using req.follow_redirections but I'm not sure it's worth the effort and you should keep your energy for tomorrow :-D | 17:54 |
| vila | nmb: ok, thanks | 17:54 |
| Noldorin | nmb: yeah, that's what i gathered from the main web page | 17:54 |
| jelmer | vila: :-) | 17:54 |
| nmb | Noldorin: I don't know IIS, but the general structure is that loggerhead runs on the server on port 8080... | 17:54 |
| Noldorin | i'm on a shared server here... | 17:54 |
| Noldorin | although with a number of config options | 17:54 |
| Noldorin | hmm | 17:54 |
| Noldorin | how are you running it>? | 17:55 |
| nmb | Noldorin: then you proxy a particular location from your webserver to pass the requests on to loggerhead | 17:55 |
| Noldorin | right | 17:55 |
| nmb | Noldorin: I'm using Apache as the outward-facing HTTP server | 17:55 |
| Noldorin | dedicated server? | 17:55 |
| Noldorin | looks like i'll have to play with some isapi-wsgi config settings | 17:56 |
| nmb | Noldorin: yep, dedicated server | 17:57 |
| Noldorin | nmb: hmm. i'm stumped how to get it running on a shared iis server now | 17:59 |
| Noldorin | or any server for that matter | 17:59 |
| Noldorin | any tips? | 18:01 |
| Noldorin | i mean, not having access to the command line is a bit of a pain here | 18:01 |
| nmb | Noldorin: you can't run any command line programs? | 18:02 |
| === deryck is now known as deryck[lunch] | ||
| Noldorin | nmb: at least i'm not aware how to do that on a shared server | 18:03 |
| nmb | Noldorin: loggerhead is running as a service on an Ubuntu machine, but the command that starts it is "loggerhead/serve-branches --prefix=/bzr --port=8080 /var/bzr" | 18:03 |
| Noldorin | mm | 18:04 |
| Noldorin | which is why i'm not sure where to proceed now | 18:04 |
| nmb | Noldorin: where /var/bzr is where the branches live | 18:05 |
| nmb | Noldorin: I know that it is possible to set up commands to run on startup under Windows, but I am not enough of a Windows admin to know how. | 18:06 |
| nmb | Noldorin: Can you get a terminal services/remote desktop login on that shared server? | 18:07 |
| Noldorin | i don't believe so | 18:07 |
| Noldorin | nmb: http://www.storminternet.co.uk/hosting_aspnet.asp - i have the ultimate package | 18:08 |
| Noldorin | hmm | 18:08 |
| Noldorin | i don't even have ssh available it seems | 18:10 |
| Noldorin | nmb: anyway around that, you think? | 18:13 |
| guilhembi_ | Hello. An exception is generated in some bzr plugin that we have in MySQL; I'm running bzr in the debugger, but bzr seems to catch it, print the traceback to some debug file, and terminate. I'd rather want bzr to not catch the exception, so that debugger (winpdb) stops there. How can I do this? | 18:15 |
| nmb | Noldorin: No, I don't think so. Loggerhead needs to be run as a program on a local python installation (as far as I know) | 18:15 |
| Noldorin | nmb: mm, that's what i'm afraid of. i wonder if there's any pure-http alternative | 18:15 |
| guilhembi_ | vila: do you know? | 18:16 |
| nmb | Noldorin: http://bazaar-vcs.org/WebInterfaces for your different options | 18:16 |
| Noldorin | nmb: thanks. i'll take a look | 18:17 |
| nmb | Noldorin: Particularly webbzr: http://thoughts.enseed.com/webbzr/ | 18:17 |
| * guilhembi_ tries -Derror | 18:18 | |
| === abentley-lunch is now known as abentley | ||
| === lamalex_2 is now known as lamalex | ||
| vila | guilhembi_: BZR_PDB=1 before bzr is what I'd use on Linux, you'll have to find how to do that on windows | 18:26 |
| guilhembi_ | vila: I'm using Linux | 18:26 |
| vila | oh, then it should work :) | 18:26 |
| guilhembi_ | vila: but it does put me in the ordinary text-based debugger; isn't there a way to | 18:26 |
| guilhembi_ | 1) not catch the exception | 18:26 |
| guilhembi_ | 2) not have bzr start the debugger, but rather I start bzr in the debugger that I choose | 18:27 |
| guilhembi_ | ? | 18:27 |
| vila | no idea for 1 & 2, but you may be able to replace the bzr call to pdb to the debugger you want ? | 18:28 |
| === abentley1 is now known as abentley | ||
| guilhembi_ | vila: that would require attaching the debugger (winpdb) to a running process via some command-line, | 18:29 |
| guilhembi_ | which I don't yet know how to do, but which I can research. | 18:29 |
| vila | guilhembi_: look at exception_to_return_code in bzrlib/commands.py | 18:30 |
| guilhembi_ | vila: thanks | 18:32 |
| vila | guilhembi_: I just installed winpdb and used launch 'bzr info', it started the bzr script and waits for input, hacking exception_to_return_code seems the way to go... | 18:35 |
| * vila foes back to kitchen | 18:35 | |
| vila | s/foes/goes/ | 18:35 |
| guilhembi_ | bbl | 18:36 |
| jelmer | vila: I'd rather wait for OPTIONS to be in bzrlib and help out with that where possible | 18:37 |
| jelmer | the stuff in bzr-svn is already quite hackish and untested | 18:37 |
| jelmer | (well, not unit tested - it was tested manually) | 18:37 |
| === deryck[lunch] is now known as deryck | ||
| Noldorin | hi. i'm trying to run loggerhead on my server, and i'm getting the following error: | 19:39 |
| Noldorin | File "D:\inetpub\vhosts\noldorin.com\httpdocs\python\loggerhead\loggerhead\main.py", line 24, in <module> from bzrlib.plugin import load_plugins ImportError: No module named bzrlib.plugin | 19:39 |
| Noldorin | any idea what i need to do to fix it? | 19:39 |
| phinze | hey folks, so how much of an overhead price do i pay with bzr+ssh versus $OTHER_BETTER_TRANSPORT | 20:07 |
| thumper | phinze: bzr+ssh gives streaming of revisions, which is v.good | 20:12 |
| thumper | phinze: bzr+ssh has the overhead of ssh compared to just the bzr protocol itself | 20:12 |
| phinze | well that sure _sounds_ good ;) | 20:12 |
| thumper | phinze: has higher semantic communication between client and server | 20:13 |
| thumper | phinze: so not just at a filesystem level | 20:13 |
| phinze | exactly, and i'm wondering about how much that overhead is costing me on `bzr up` | 20:13 |
| thumper | phinze: whose server? | 20:13 |
| phinze | our dev group's central repository server | 20:13 |
| phinze | so i have the ability to switch the transport if there is reason to | 20:14 |
| phinze | s/switch the/recommand a switch to another/ | 20:14 |
| phinze | blah, *recommend | 20:14 |
| thumper | if it is all your servers | 20:14 |
| thumper | then perhaps bzr protocol is enough | 20:14 |
| thumper | I'd ask a core bzr person though | 20:15 |
| * thumper looks at lifeless | 20:15 | |
| bialix | I have couple of questions | 20:15 |
| fullermd | bialix: I have a couple answers. 1492. Yellow. Yes, in a vacuum. | 20:16 |
| bialix | 1) If I want to call external GUI to resolve conflicts as 3-way merge, but I did merge --weave and have only THIS and OTHER. What can I use instead of BASE? | 20:16 |
| bialix | fullermd: missed | 20:16 |
| bialix | evening fullermd :-) | 20:16 |
| fullermd | Darn. I was so close... | 20:16 |
| fullermd | I don't know that you can. External conflict resolution tools are mostly based around 3-way merge, aren't they? | 20:17 |
| bialix | fullermd: I think the right answer is "vacuum"? | 20:17 |
| phinze | thumper: sounds good, thanks | 20:17 |
| bialix | fullermd: not all | 20:17 |
| bialix | many tools can work in 2-way merge mode | 20:17 |
| fullermd | To deal with --weave aftermath, they'd have to implement weave merging themselves, which means they'd also need all the line history too, not just a couple source files. | 20:17 |
| phinze | i imagine jam would know also | 20:17 |
| thumper | phinze: that he would | 20:17 |
| bialix | fullermd: it was joke? | 20:18 |
| bialix | I have example of 1-way merge tool which can be progressed to 2-way: editor | 20:19 |
| fullermd | Not really, know. Weave merge implies working with a lot of intermediate history, so it's way outside the scope of what you could get from BASE/THIS/OTHER files. That only covers 3-way. | 20:19 |
| bialix | but weave in the end generatest THIS and OTHER? | 20:19 |
| * bialix looking for jam | 20:20 | |
| bialix | jam1: are you around? | 20:20 |
| fullermd | Well, there's nothing to generate with those two. There's just what we had, and what the other side had. | 20:20 |
| jam1 | bialix: ? | 20:20 |
| === jam1 is now known as jam | ||
| fullermd | BASE is the only generated one of the 3, but it only makes sense in 3-way (that's why it's 3-way after all). With weaves, there is not 'base' of the whole file. | 20:20 |
| bialix | jam: weave merge | 20:20 |
| bialix | what can I use s BASE after weave merge? | 20:21 |
| bialix | to resolve conflicts in 3-way style? | 20:21 |
| jam | bialix: unfortunately there isn't really a BASE, I believe there is a MySQL bug about it, and I'm trying to investigate if we can put *something* for BASE | 20:21 |
| jam | but really, the BASE is not very well defined for weave | 20:21 |
| bialix | I can use empty file, but it sounds weird? | 20:22 |
| bialix | I'm sketching new external merge support for qbzr | 20:22 |
| bialix | I'm trying to understand what should I do with conflicts when there is no BASE file | 20:22 |
| bialix | maybe I can puth file with conflicts there as BASE? | 20:23 |
| bialix | fullermd: I'm using WinMerge a lot ast time, it's only provides diff/merge tool based on 2 sides: their/mine files | 20:24 |
| bialix | and I can merge changes even without BASE | 20:24 |
| bialix | the tool is able to find common lines and then highlight lines where text at both sides are different | 20:25 |
| jam | bialix: 2-way diff is equivalent to 3-way with BASE being empty | 20:25 |
| bialix | I don't have experience with real 3-way tools yet | 20:25 |
| jam | so the main difference is that there are places where the two texts differ and one clearly supersedes | 20:26 |
| bialix | so, empty file in the end, as I thought | 20:26 |
| jam | 2-way can't tell you that | 20:26 |
| jam | all it can say is "they differ here" | 20:26 |
| bialix | jam: but after bzr doing merge we have only valid conflicts in the file? | 20:27 |
| bialix | maybe winmerge doing the right thing by parsing conflict markers, instead of rely on THIS/OTHER | 20:27 |
| bialix | so there is no obvious answer, empty file as first guess | 20:28 |
| bialix | second question: versioned tags | 20:28 |
| bialix | today we have very unpleasant merge scenario at work when tags was not propagated because there already tagged | 20:29 |
| jam | so using conflict markers is a 2-way diff, after we've already worked out the 3-way base | 20:29 |
| bialix | jam: anybody has sketches or plan on how versioned tags could be implemented? | 20:29 |
| donri | is there something similar to git add -p, that is commit only some changes to a file? | 20:29 |
| jam | donri: generally done by doing the inverse with "bzr shelve" first | 20:30 |
| jam | to pull out the changes you don't want | 20:30 |
| bialix | donri: we have similar to git stash | 20:30 |
| jam | then commit what you do | 20:30 |
| lifeless | moin | 20:30 |
| donri | sounds backwards and cumbersome | 20:30 |
| donri | uhm, but thanks :) | 20:31 |
| bialix | lifeless, jam: versioned tags: how's hard they would be to implement? | 20:31 |
| lifeless | phinze: how long does 'time ssh <server> bzr help' report | 20:31 |
| jam | bialix: the concept isn't very difficult, figuring out how to present it to the user is | 20:31 |
| lifeless | bialix: coding it? not long. deciding on semantics? oh, a year or two :P | 20:32 |
| phinze | lifeless: good call --> real 0.357s user/sys: 0.003s | 20:32 |
| donri | is there something like rebasing in git? | 20:32 |
| bialix | what is semantic? | 20:32 |
| lifeless | bialix: how they should behave | 20:32 |
| bialix | donri: yes, bzr-rebase (bzr-rewrite) plugin | 20:32 |
| donri | nevermind, i can probably google that one | 20:32 |
| donri | thanks | 20:33 |
| bialix | lifeless: a bit better than today | 20:33 |
| Noldorin | hi lifeless | 20:33 |
| bialix | deletion of tags are not propagated, tags are not mergeable | 20:33 |
| Noldorin | lifeless: it seems i have isapi-wsgi on my server... | 20:33 |
| bialix | jam: does user realy need to have other presentation than it is today? | 20:34 |
| bialix | jam: git seems to use signed tags concept? when there is author who created tag, and when | 20:34 |
| jam | bialix: how do you present when tags conflict | 20:36 |
| bialix | as other conflict: special metadata in working tree or branch? | 20:36 |
| bialix | jam: the problem is today they always conflicts, even if other side update the tag made by this side | 20:37 |
| bialix | ok, it seems git has the same problems with tags | 20:41 |
| bialix | it just has name of tag author | 20:41 |
| bialix | jam, lifeless: in the past poolie suggested to use empty string instead of revid to allow push/pull of tag deletion. does adding such thing to current tag dict will be considered a format break? | 20:42 |
| bialix | btw, according to git manual if tags conflict then my tag wins over other tags | 20:43 |
| bialix | so bzr in the same area here | 20:44 |
| bialix | perhaps I should send mail to main list? | 20:45 |
| jam | bialix: so one possibility would be to store the tags as a .weave file where the current tags is just a sorted list of lines | 20:47 |
| jam | adding/deleting/etc a tag is just adding a new text to this list | 20:47 |
| jam | that will propogate | 20:48 |
| jam | support deletes | 20:48 |
| jam | support adds | 20:48 |
| bialix | so every tag will be separate file? | 20:48 |
| jam | etc | 20:48 |
| jam | no, one file, sorted list of tag value pairs | 20:48 |
| bialix | sorted by tag name? | 20:48 |
| jam | yeah | 20:48 |
| jam | that can conflict accidentally from regular merges, but rarely I would guess | 20:49 |
| bialix | is it possible to add additional metadata here? author of tag and date? | 20:49 |
| bialix | jam: does such weaved tags should live in .bzrmeta? | 20:49 |
| jam | .bzrmeta is for versioned texts that are part of the tree | 20:50 |
| jam | I would consider this separate | 20:50 |
| jam | if you put it in .bzrmeta, then I would have it .bzrmeta/tags and just a plain text file, versioned normally | 20:50 |
| jam | with the main problem that tag operations must then be "bzr commit" to work | 20:51 |
| bialix | you wrote "regular merge" so I've confused | 20:51 |
| bialix | yep, like in hg | 20:51 |
| bialix | and that sucks | 20:51 |
| fullermd | I think if you think around and around it enough times, you end up with the conclusion that versioned tags require another axis of versioning (much like editing commit messages) | 20:51 |
| bialix | I think you're right | 20:52 |
| bialix | the more I think about this, the often I conculde this | 20:52 |
| bialix | exactly the same as you saud | 20:52 |
| bialix | said | 20:52 |
| bialix | sorry | 20:52 |
| jam | fullermd: right, hence putting it into a weave | 20:52 |
| bialix | (couple of years is old enough?) | 20:52 |
| jam | which is equivalent to a knit, but is only a single file :) | 20:52 |
| fullermd | And hey, we can put content filtering rules on that axis too, and re-open THAT argument at the same time! | 20:53 |
| bialix | jam: where I can read about weave for mere mortals? | 20:53 |
| fullermd | Well, that's just storage semantics. It's working out the extra axis that takes the time. | 20:53 |
| * bialix fears to say v.p. | 20:53 | |
| fullermd | You can't just store it as a .weave in the WT; that opens up all sorts of horrific bootstrap issues. | 20:53 |
| jam | fullermd: yep | 20:54 |
| bialix | I know | 20:54 |
| bialix | chicken-eggs | 20:54 |
| Noldorin | hi. i'm trying to run loggerhead on my server, and i'm getting the following error: | 21:07 |
| Noldorin | File "D:\inetpub\vhosts\noldorin.com\httpdocs\python\loggerhead\loggerhead\main.py", line 24, in <module> from bzrlib.plugin import load_plugins ImportError: No module named bzrlib.plugin | 21:07 |
| Noldorin | any ideas what i need to do please? | 21:07 |
| bialix | Noldorin: what version of bzr are you using? | 21:08 |
| Noldorin | 2.0.1 i believe | 21:09 |
| Noldorin | but i guess it's the version of bzr that loggerhead wants to use that is important | 21:09 |
| bialix | are you installed standalone bzr.exe or python-based? you need the latter | 21:11 |
| === BasicPRO is now known as BasicOSX | ||
| Noldorin | bialix: since it's on the (shared) server, i guess it indeed has to be the latter | 21:12 |
| bialix | Noldorin: bzr version output tells you the truth | 21:12 |
| Noldorin | i guess i just need the entire source for bzr? | 21:12 |
| Noldorin | the version that loggerhead uses | 21:12 |
| bialix | you can download python-based installers from LP | 21:13 |
| bialix | for your python version | 21:13 |
| bialix | 2.4 - 2.6 | 21:13 |
| Noldorin | bialix: it's a shared server, so the best i can do is transfer files via ftp | 21:13 |
| bialix | I don't understand what it means "shared server" | 21:13 |
| kirkland | i'd like to use bzr export, but --exclude debian/ | 21:14 |
| kirkland | is that possible? | 21:14 |
| kirkland | i see --filters, but I don't understand how to use it | 21:14 |
| bialix | kirkland: --filters is different | 21:14 |
| kirkland | bialix: okay ... so is there any convenient way to --exclude? | 21:15 |
| bialix | kirkland: it seems there is no | 21:15 |
| bialix | delete debian after the export? | 21:16 |
| Noldorin | bialix: virtual server? i.e. a non-dedicated one - i have to access it via a control panel | 21:16 |
| bialix | Noldorin: so how you installed loggerhead? | 21:17 |
| Noldorin | i haven't exactly yet | 21:17 |
| Noldorin | but the server has isapi-wsgi | 21:17 |
| Noldorin | so i think i can just run loggerhead/main.py | 21:18 |
| bialix | so put there bzr sources from tarball | 21:18 |
| === davidstrauss_ is now known as davidstrauss | ||
| bialix | but I fear this is wrong path | 21:18 |
| Noldorin | that's what i was thinking yeah | 21:18 |
| Noldorin | what do you suggest then? | 21:18 |
| bialix | I have no real experience with VPS | 21:20 |
| bialix | try eith bzr sources first | 21:21 |
| bialix | all you need is to put bzrlib in the same folder where main.py resides, perhaps | 21:21 |
| === emmajane is now known as emmajane-joins-t | ||
| === emmajane-joins-t is now known as emmajane-bandwag | ||
| === emmajane-bandwag is now known as emmajane | ||
| mathiaz | Hi! | 22:03 |
| jam | hi mathiaz | 22:03 |
| mathiaz | How do you handle a directory that has been moved during a merge? | 22:04 |
| mathiaz | in my use case, upstream has introduced its own debian/ directory | 22:04 |
| mathiaz | and that conflicts with the existing debian/ directory in the ubuntu branch | 22:04 |
| mathiaz | how can I solve this (ie keep the debian/ directory from the ubuntu branch)? | 22:05 |
| abentley | lifeless: do you have an estimate of how long it would take to fix bug #375013 ? | 22:08 |
| ubottu | Launchpad bug 375013 in rosetta "Cannot commit directly to a stacked branch" [High,Triaged] https://launchpad.net/bugs/375013 | 22:08 |
| lifeless | abentley: a week or more | 22:08 |
| abentley | thumper: ^ | 22:08 |
| thumper | lifeless: why? | 22:08 |
| abentley | lifeless: Thanks. | 22:08 |
| thumper | lifeless: is that just a gut feel? | 22:09 |
| lifeless | thumper: because we have to make commit use the same data integrity checks fetch does | 22:09 |
| thumper | lifeless: or have you some background in it | 22:09 |
| thumper | lifeless: this is something I'd dearly love to see fixed | 22:09 |
| lifeless | thumper: and that is best done by moving commit to the same api, which will reduce overall code size too | 22:09 |
| lifeless | but that means revving the streaming api to meet commits needs | 22:10 |
| lifeless | you /might/ be able to hack something up in only 2 or three days by duplicating the checks and the extra data fetches | 22:11 |
| lifeless | but I would guarantee that doing it that way will lead to bugs and concurrency issues (such as smart server protocol errors ) | 22:11 |
| lifeless | not to mention that duplicating code adds technical debt | 22:11 |
| lifeless | thumper: to summarize, this is a deep defect, not UI level, fixing [so that it stays fixed] requires care and addressing some 4+ year old api issues. | 22:16 |
| thumper | lifeless: ok, thanks for the summary | 22:17 |
| lifeless | turning off the error is easy, one-line. Preventing the repo corruption that that causes is the hard part ;) | 22:18 |
| mathiaz | one solution to my problem (completely different debian/ directories for the upstream and ubuntu branches) would be to have an intermediate branch (upstream-nodebian) where the debian/ directory would be removed | 22:23 |
| mathiaz | and then merge the intermediate branch into the ubuntu branch - would this work for subsequent merges? | 22:24 |
| jelmer_ | mathiaz, I think you would still get conflicts when you merge in changes from upstream to debian/ | 22:26 |
| jelmer_ | (somebody please correct me if I'm wrong) | 22:26 |
| mathiaz | jelmer_: well - in that particular use case, I don't care about the upstream debian/ directory | 22:26 |
| mathiaz | jelmer_: ie changes from the upstream debian/ directory should not be merged into the ubuntu debian/ directory | 22:27 |
| jelmer_ | mathiaz: when you merge from upstream and upstream has modified debian/ since your last merge, bzr will attempt to apply the changes but will be unable to find the relevant files so will create conflicts | 22:28 |
| mathiaz | jelmer_: ah ok. This will happen when you merge the upstream branch into the upstream-nodebian branch? | 22:28 |
| jelmer_ | mathiaz: dealing with those conflicts shouldn't be too hard though if you don't care about what upstream did | 22:28 |
| jelmer_ | mathiaz: yes | 22:29 |
| mathiaz | jelmer_: ok - in which case we know what we wanna do about those conflicts | 22:29 |
| mathiaz | jelmer_: now if upstream decides to remove their debian/ directory from their upstream branch, can we merge directly the upstream branch again (instead of upstream-nodebian)? | 22:30 |
| jelmer_ | mathiaz: yeah | 22:30 |
| mathiaz | jelmer_: merge the upstream branch directly into the ubuntu branch | 22:30 |
| mathiaz | jelmer_: and there shouldn't be any problem in terms of branch history? | 22:31 |
| jelmer_ | mathiaz: *nod* | 22:32 |
| jelmer_ | mathiaz: actually, you shouldn't need a upstream-nodebian branch either - you should be able to merge upstream directly and resolve the conflicts there | 22:32 |
| mathiaz | jelmer_: well - How do I resolve the conflict then? | 22:32 |
| mathiaz | jelmer_: the ubuntu debian/ directory is moved to debian.moved/ | 22:33 |
| mathiaz | jelmer_: and the upstream debian directory is added as debian/ | 22:33 |
| jelmer_ | mathiaz: Remove the existing debian/ directory and then "bzr mv debian.moved debian" | 22:33 |
| * mathiaz tries | 22:33 | |
| jelmer_ | mathiaz, after that, you should be able to resolve the conflicts and "bzr status" should no longer list any changes to debian/ | 22:33 |
| mathiaz | jelmer_: http://paste.ubuntu.com/331989/ | 22:34 |
| NfNitLoop | mathiaz: you should've done bzr rm debian | 22:36 |
| jelmer_ | mathiaz: try "bzr rm debian" before the mv | 22:36 |
| mathiaz | jelmer_: right - bzr remove --force debian/ works as expected | 22:36 |
| mathiaz | now - what is going to happen during the next merge if upstream updates its debian/ directory? | 22:37 |
| mathiaz | will the ubuntu debian/ directory be moved to debian.moved/ again? | 22:38 |
| NfNitLoop | I would've assumed that since you've locally deleted the debian/ directory, it wouldn't try to merge into yours. Don't files/dirs have unique IDs behind the scenes? | 22:38 |
| jelmer_ | mathiaz: I'm not entirely sure but I think you'll get files in the root directory named control.THEIRS or something like that | 22:38 |
| jelmer_ | you'll have to remove those files and run "bzr resolved" | 22:39 |
| * NfNitLoop makes some test cases. :) | 22:39 | |
| NfNitLoop | Oh, weird. Even though I deleted the directory explicitly in the local branch... it still moved the local version to *.moved | 22:43 |
| NfNitLoop | when changes happen in that dir upstream. | 22:43 |
| NfNitLoop | Though, I guess it's good that bzr isn't just swallowing changes that you might've cared about. *shrug* | 22:45 |
| mathiaz | NfNitLoop: well - in my use case here, I'd rather discard any change made by upstream in their debian/ directory | 22:46 |
| NfNitLoop | Unfortunately it looks like you'll have to do that every time they make a change in their debian/ | 22:47 |
| mathiaz | NfNitLoop: ok - we can script that anyway. Thanks for helping with this! | 22:49 |
| rbriggsatuiowa | what are the differences between "Contents conflict in" vs "Text conflict in"? | 22:58 |
| shakaran | Hi, I have a bazaar repository, but I need convert it to a SVN. It is possible? | 23:00 |
| lifeless | yes | 23:00 |
| lifeless | the bzr-svn plugin can do this for you | 23:00 |
| shakaran | Could you give me the exact command or some guide for read? | 23:01 |
| Noldorin | hi. what do i need to include in my path to reference bzrlib.plugin ? | 23:03 |
| NfNitLoop | shakaran: http://tinyurl.com/yjoa4w2 ;) | 23:05 |
| shakaran | NfNitLoop: lol xD | 23:06 |
| NfNitLoop | Noldorin: as in, you want to 'import bzrlib.plugin'? | 23:07 |
| Noldorin | NfNitLoop: the exact line is: from bzrlib.plugin import load_plugins | 23:09 |
| NfNitLoop | Hrmm. bzrlib.plugin is already in my path on my server. | 23:09 |
| NfNitLoop | did you install bzr with the install script, or just unpack it into a directory? | 23:09 |
| Noldorin | NfNitLoop: just unpacked it to a dir. problem is that i'm on a shared server, so the best i can do is include it in my path it seems | 23:10 |
| Noldorin | scriptDir = os.path.dirname(os.path.realpath(__file__)) | 23:10 |
| Noldorin | sys.path.append(os.path.realpath(os.path.join(scriptDir, '../../bzrlib/'))) | 23:10 |
| Noldorin | that's what i currently have | 23:10 |
| NfNitLoop | Hrmm, I'm not sure. | 23:12 |
| NfNitLoop | I remember not having much luck with mucking with paths at runtime in Python. | 23:12 |
| Noldorin | NfNitLoop: shouldn't including bzrlib in the path like that be enough? | 23:12 |
| Noldorin | i see... | 23:12 |
| NfNitLoop | I would think so, yeah. | 23:12 |
| NfNitLoop | but I'm not an expert on that bit. :) | 23:12 |
| Noldorin | fair enough | 23:15 |
| Noldorin | thanks anyway | 23:15 |
| Noldorin | i'm just not sure how else to import that module in a shared server env | 23:16 |
| lifeless | Noldorin: you dont want bzrlib in the path | 23:21 |
| lifeless | Noldorin: you want the directory that bzrlib is in, in the path. | 23:21 |
| Noldorin | oh i see | 23:22 |
| Noldorin | heh | 23:22 |
| Noldorin | lifeless: that does the trick. now it can't find paste however | 23:23 |
| Noldorin | there's a dir called Paste-1.7.3 in the same dir as bzrlib | 23:23 |
| lifeless | whats inside that directory | 23:25 |
| NfNitLoop | Ponies! | 23:25 |
| Noldorin | lifeless: setup.py, paste/, docs/, etc. | 23:26 |
| blueyed | Is there any way to merge from an uncommon ancestor (with the same content)? bzr adds a lot of conflicts since files/dirs are considered to be new/different. | 23:26 |
| lifeless | Noldorin: then you want to add the Paste-1.7.3 dir to the path too, at a guess. | 23:26 |
| Noldorin | right ho | 23:27 |
| Noldorin | lifeless: now i'm getting an even stranger error: | 23:30 |
| Noldorin | ImportError: cannot import name __version__ ". | 23:30 |
| Noldorin | from the line: | 23:30 |
| Noldorin | from loggerhead import __version__ | 23:30 |
| lifeless | that means that there is a directory 'loggerhead' that looks like a module but isn't the right loggerhead module. | 23:31 |
| Noldorin | lifeless: indeed it appears so. | 23:33 |
| Noldorin | i'm afraid i'm going to have to go through a list here....heh | 23:33 |
| Noldorin | ImportError: No module named pkg_resources ". | 23:33 |
| lifeless | jam: Bug 437003 | 23:36 |
| ubottu | Launchpad bug 437003 in bzr/2.0 "Failure to autopack because of 'missing inventories'" [High,Confirmed] https://launchpad.net/bugs/437003 | 23:36 |
| lifeless | jam: nvm | 23:37 |
| Noldorin | lifeless: any ideas? | 23:40 |
| lifeless | Noldorin: you are missing some dependency | 23:41 |
| lifeless | possibly setuptools o r something | 23:41 |
| Noldorin | lifeless: not according to the loggerhead readme | 23:42 |
| Noldorin | oh gosh... | 23:42 |
| Noldorin | but i'll need all the bzrlib dependencies too, eh? | 23:42 |
| lifeless | Noldorin: pkg_resources is a dep of paste, I think. | 23:44 |
| * Noldorin looks for a list of bzr dependencies | 23:44 | |
| Noldorin | oh i see | 23:44 |
| Noldorin | lifeless: it doesn't seem to be available as a download though... | 23:45 |
| lifeless | its not called pkg_resources. I think its setuptools | 23:45 |
| Noldorin | right | 23:45 |
| Noldorin | lifeless: right, so simpleTALs is giving me some trouble | 23:53 |
| Noldorin | ImportError: No module named simpletal.simpleTALUtils ". | 23:53 |
| Noldorin | despite having included the dir in my path | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!