| poolie | it's quiet today... | 00:29 |
|---|---|---|
| lifeless | and how does that make you feel? | 00:32 |
| lifeless | :) | 00:32 |
| jelmer | moin poolie, lifeless | 00:37 |
| * mwhudson grumbles | 01:09 | |
| mwhudson | other things that turn out not to be thread safe in bzrlib: lazy imports | 01:09 |
| lifeless | mwhudson: for that one, you might want to file a bug | 01:12 |
| james_w | things not being thread safe that have bitten me today: LP API | 01:15 |
| poolie | jml, did you send a metronome mail? | 01:16 |
| mwhudson | lifeless: https://bugs.edge.launchpad.net/bzr/+bug/396819 | 01:25 |
| ubottu | Ubuntu bug 396819 in bzr "lazy imports are not threadsafe" [Undecided,New] | 01:25 |
| mwhudson | contrary to what i thought yesterday, lrucache doesn't seem to be that thread un-safe | 02:00 |
| mwhudson | (although if a cleanup function raises, that seems to break the cache pretty badly) | 02:01 |
| poolie | lifeless: is there a command to dump the pack-names file (re bug 396308) | 02:11 |
| ubottu | Launchpad bug 396308 in bzr "bzrlib.errors.ShortReadvError: readv() read 0 bytes rather than X bytes for pack" [Undecided,New] https://launchpad.net/bugs/396308 | 02:11 |
| lifeless | poolie: bzr dump-btree .bzr/repository/pack-names | 02:21 |
| lifeless | poolie: (for 1.9 and above formats) | 02:21 |
| jml | poolie, no, it got crowded out. | 03:02 |
| thumper | poolie: for bug 391411 can the reconfigure --stacked-on give a relative remote path for the branch? | 03:22 |
| ubottu | Launchpad bug 391411 in bzr "want "reconfigure --unstacked" or --stacked-on" [High,In progress] https://launchpad.net/bugs/391411 | 03:22 |
| thumper | poolie: I think that is what we really want for LP stacking | 03:22 |
| poolie | thumper: my current idea (indeed current code) is that you give a cwd-relative or absolute url, but it stores it relative to the branch | 03:48 |
| thumper | poolie: we use absolute paths from /, like /~bzr/bzr/devel | 03:48 |
| thumper | poolie: so it works over whatever transport | 03:49 |
| poolie | ok | 03:49 |
| poolie | hm maybe we need a transport-relative path | 03:49 |
| poolie | btw, staging is a bit hard to test this against because it recommends new branches be stacked on staging/~bzr/bzr/trunk (for example) | 03:49 |
| poolie | but that branch doesn't exist :) | 03:49 |
| poolie | on staging | 03:50 |
| thumper | poolie: bzrtools is on staging | 03:50 |
| thumper | poolie: but I think it is the only project we copy across for testing | 03:51 |
| poolie | ok | 03:51 |
| poolie | i'll test on that then | 03:51 |
| thumper | let me know if you have any problems | 03:51 |
| thumper | although with spm not around, I'm not sure there will be much I could do :) | 03:51 |
| jml | lifeless, Just confirming, is the full fix for bug 390563 in bzr.dev? | 04:21 |
| ubottu | Launchpad bug 390563 in bzr "absent factory exception from smart server when streaming 2a stacked branches" [Critical,In progress] https://launchpad.net/bugs/390563 | 04:21 |
| poolie | jml, it may be that there are other bugs that look similar | 04:29 |
| poolie | not sure | 04:29 |
| RenatoSilva | anyone using maven? | 04:32 |
| RAOF | The only thing I've heard about maven has not been complementary. | 04:34 |
| RenatoSilva | I want to download source for a lib | 04:34 |
| doctormo | I'm trying to help someone who is new to bzr, I asked him the bzr checkout a branch that we can both commit to on launchpad but when he goes to commit he gets: bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Eubuntu-learning-board/ubuntu-learning-moodle/trunk/.bzr/branch/lock): Transport operation not possible: http does not support mkdir() | 04:40 |
| doctormo | I think I may have advised him wrong, any help getting out of this position? | 04:40 |
| beuno | doctormo, he hasn't set his launchpad id | 04:41 |
| beuno | bzr launchpad-login USERNAME | 04:41 |
| doctormo | beuno: Ah right | 04:41 |
| jml | poolie, done! | 04:42 |
| doctormo | beuno: running the launchpad-login caused the same error: Transport operation not possible: http does not support mkdir() | 04:43 |
| beuno | doctormo, that's... odd | 04:45 |
| jml | doctormo, does he have write permission for the branch? | 04:45 |
| jml | that is, is he a member of ~ubuntu-learning-board? | 04:46 |
| doctormo | beuno: Ah no sorry the login didn't error, a new commit command failed the same way,. | 04:47 |
| doctormo | bad communication | 04:47 |
| beuno | doctormo, as jml asked | 04:58 |
| beuno | is he part of the team? | 04:59 |
| lifeless | jml: checking (sorry, laptop powered off, came back and the kms thing had me wedged for a bit) | 05:04 |
| lifeless | and now X has locked up. | 05:04 |
| lifeless | <sigh> | 05:04 |
| doctormo | beuno: yes team: https://code.launchpad.net/~ubuntu-learning-board code: https://code.launchpad.net/~ubuntu-learning-board/ubuntu-learning-moodle/trunk and user: (launchpad wouldn't load) | 05:04 |
| lifeless | doctormo: now you need him to do 'bzr bind lp:<...>' | 05:05 |
| doctormo | matthew.lye | 05:05 |
| lifeless | doctormo: to change the URL that bzr has recorded locally | 05:05 |
| lifeless | or bzr switch lp:... | 05:05 |
| doctormo | lifeless: I see | 05:05 |
| doctormo | I think I remember this problem from before | 05:05 |
| doctormo | https://code.edge.launchpad.net/~ubuntu-learning-board/ubuntu-learning-moodle/trunk <- on here, we got his commit working, but he shows us as an odd name /email, config problem? | 05:18 |
| doctormo | thanks lifeless, beuno for your help with the commit problem | 05:18 |
| lifeless | doctormo: bzr help whoami | 05:21 |
| doctormo | thanks lifeless | 05:22 |
| jml | hey | 05:56 |
| jml | I was just talking with Twisted folk about NEWS files. | 05:56 |
| jml | apparently when they had a NEWS file that was edited on each mainline commit, they got conflicts on every landing | 05:58 |
| jml | this doesn't seem to happen with the Bazaar project: why? | 05:58 |
| lifeless | jml: two things | 06:00 |
| lifeless | a) it does | 06:00 |
| lifeless | we often have to merge down trunk and fix conflicts with news | 06:01 |
| lifeless | just run log -n0 (man that should be the default) and you can see those commits. | 06:01 |
| lifeless | b) we alphabetically order the news items under each header. | 06:01 |
| lifeless | this reduces concurrent editing of the same locations | 06:02 |
| jml | lifeless, ok. thanks. | 06:03 |
| lifeless | chronological ordering will generate many successive edits to the same place | 06:04 |
| RenatoSilva | the args are given to a plugin command by bazaar, right? | 06:15 |
| lifeless | yes | 06:16 |
| RenatoSilva | I mean, I have a source code here, and the command class has a run method with the *args argument | 06:16 |
| RenatoSilva | these args are full objects, right? e.g the rev | 06:16 |
| RenatoSilva | I'd like to know who fills in the data for the rev object... | 06:18 |
| RenatoSilva | it seems that the fields are utf-8 str objects, not unicode | 06:18 |
| lifeless | plugins are no different than any other command | 06:19 |
| RenatoSilva | but I need a documentation | 06:19 |
| lifeless | look at something like cmd_pull | 06:19 |
| lifeless | there are api docs, but there isn't a narrative about this part of bzrlib | 06:20 |
| RenatoSilva | ok, bazaar gives the cmd an arg called rev, it's an object | 06:20 |
| RenatoSilva | I want to know what bazaar has to tell me about the rev strings | 06:20 |
| RenatoSilva | are they always utf-8? may change the encoding? may become unicode someday? | 06:21 |
| lifeless | show me your code | 06:21 |
| RenatoSilva | lifeless: what code exactly? | 06:21 |
| RenatoSilva | lifeless: what I'm trying to achieve is... | 06:21 |
| RenatoSilva | bzr-eclipse gets branch's log by running an xml-rpc call, which in turn runs xmloutput plugin, which returns the XML version of the log. I looked at the source, the xmllog command just runs the builtins.cmd_log passing an XML formatter for the log. This formatter handles the revision object given by bazaar... | 06:25 |
| RenatoSilva | and puts the commit message inside a CDATA for example | 06:26 |
| lifeless | inside bzrlib revisionids are utf8 bytestrings | 06:26 |
| RenatoSilva | I'm not sure if it's using a custom writer or if the data comes from bzr already as utf-8 str | 06:26 |
| lifeless | the commit message is unicode | 06:26 |
| RenatoSilva | the fact is that the data is utf-8 | 06:26 |
| RenatoSilva | lifeless: only message or all data in rev object? | 06:27 |
| lifeless | "only message or all data in rev object?" - what? | 06:27 |
| RenatoSilva | lifeless: what's the compromise of bazaar rgarding rev data format? | 06:27 |
| lifeless | I'm sorry, I'm really not following you. You're talking about objects, not data formats. | 06:28 |
| lifeless | the Revision class has a number of fields, and they are all different types. | 06:28 |
| RenatoSilva | s/data format/string format (aka str+encoding or unicode) | 06:28 |
| lifeless | if you're talking about how something is serialising stuff, it depends on what the serialiser is doing | 06:29 |
| RenatoSilva | lifeless: I need to check if the plugin is using a self writer | 06:30 |
| lifeless | this may help: | 06:30 |
| lifeless | there are three sets of strings that bzr deals with: | 06:30 |
| lifeless | - internal disk data (stuff under .bzr). These we have specific formats for that have varied over time. Commonly they are xml within compressed archives | 06:31 |
| lifeless | and more specifically, the xml tends to be utf8 encoded | 06:31 |
| RenatoSilva | I just want to find the reason I'm receiving utf-8, if it's bzr or the plugin | 06:31 |
| lifeless | - local environment strings: command line parameters, working directory, file system encoding, console encoding | 06:32 |
| lifeless | for these strings bzr usually decodes them to unicode objects, so the core bzr code doesn't have to know what encodings are in use | 06:33 |
| lifeless | - internal strings. These are strings like revision ids, index keys, file ids. For these bzr strives to have them in utf8 all the time, decoding to unicode and encoding to the external encoding only when required | 06:33 |
| lifeless | we do this for speed | 06:33 |
| lifeless | RenatoSilva: You want to know if you're getting utf8 *in python code* ? Or on stdout ? | 06:34 |
| RenatoSilva | lifeless: I want to know what happens from e.g. commit message inside .bzr to it being read by the java plugin. I want to know if the plugin is re-encoding stuff as utf-8 or if it was already encoded by bzr | 06:36 |
| RenatoSilva | anyway I want to know | 06:36 |
| RenatoSilva | sorry | 06:36 |
| lifeless | it will be reencoding | 06:38 |
| lifeless | because the repository is not required to use xml | 06:38 |
| lifeless | as to where it is reencoding, I haven't looked at the xmloutput plugin, so I don't know what code paths its using | 06:38 |
| lifeless | I'm still not clear what you mean 'it being read by the java plugin'. You might be meaning 'when the eclipse process reads teh xml'. Or you might mean 'when a revision object is given to bzr-xmloutput' | 06:39 |
| lifeless | or you might mean 'when xmloutput receives an xml revision string' | 06:39 |
| lifeless | or something else | 06:39 |
| RenatoSilva | I'm checking bzrlib.revision.py, there are just 2 refs for message field, one in __eq__ and the other in get_summary | 06:40 |
| RenatoSilva | ok let me start again... | 06:40 |
| RenatoSilva | the problem is: | 06:40 |
| RenatoSilva | wrong chars in bzr-eclipse log view | 06:41 |
| RenatoSilva | that is, when you want to see the log through ui using bzr-eclipse, you see wrong chars because of an ecoding issue | 06:42 |
| RenatoSilva | this issue can be fixed by just re-decoding the xml-rpc response as UTF-8 | 06:42 |
| RenatoSilva | the problem here is that... | 06:43 |
| lifeless | so the xmlrpc response has to start out as octets | 06:43 |
| lifeless | because its a network protocol | 06:43 |
| RenatoSilva | I don't want to put "UTF-8" hard-coded in the fix | 06:43 |
| RenatoSilva | I want... | 06:43 |
| lifeless | XML defines how encodings are represented | 06:44 |
| RenatoSilva | I want to who is ensuring the data is UTF-8, and if it will always be this way, etc. | 06:45 |
| RenatoSilva | lifeless: ok you could guess by XML preamble but... | 06:45 |
| lifeless | so, you're looking at lass XMLLineLogFormatter(log.LineLogFormatter): | 06:46 |
| lifeless | yes? | 06:46 |
| RenatoSilva | lifeless: unfortunately just printing out a charset in the XML header won't ensure that the XML itself matches such encoding... | 06:46 |
| lifeless | so, bzr-xmlloutput is responsible for this | 06:47 |
| lifeless | it recieves Revision objects | 06:48 |
| lifeless | and it should serialise them | 06:48 |
| lifeless | the revision_id and parent_ids attributes have utf8 bytestrings; the other fields are variously dicts, ints, floats, and unicode | 06:48 |
| RenatoSilva | lifeless: and the data I'm particularly interested in is not generated by the plugin, it's given by bzr.... the question is: is bzr giving unicode and the plugin encoding as utf-8? or is bzr giving utf-8 str, and in this case is the plugin doing any conversion still? or still, is bzr giving non-utf-8 str and the plugin is re-encoding as utf-8? | 06:50 |
| lifeless | RenatoSilva: I think I've answered this | 06:50 |
| RenatoSilva | lifeless: I'm reading the code to find the answer... you're giving me me info about rev object, but in bzrlib.revision.py for example, I can't find the message field. Am I looking at the wrong file? | 06:52 |
| lifeless | Revision is poorly documented, and a bit of a 'data holder' class | 06:52 |
| lifeless | deserialisation is per-repository, you can look at repository.py, and repofmts/*.py to see the different serialisers | 06:53 |
| lifeless | and bzrlib/xml* and bzrlib/*serial* | 06:53 |
| lifeless | as I said above though. revision.message is *unicode* | 06:53 |
| RenatoSilva | you just know this or are you looking at some source code? | 06:54 |
| RenatoSilva | As I said I can't find the definition of the message field :( | 06:54 |
| RenatoSilva | logxml.XMLLogFormatter has a to_file field, but I can't find where it comes from | 06:57 |
| lifeless | the log infrastructure | 06:57 |
| RenatoSilva | I'm trying to know if it is being overwritten by the plugin (codecs.getwriter) | 06:58 |
| RenatoSilva | well I think I don't need to | 06:59 |
| lifeless | I have no idea :) | 06:59 |
| RenatoSilva | if the message is given as unicode by bzr, and it gets in the client as utf-8, that's because bzrl-xmloutput is doing it, no matter how :) | 06:59 |
| RenatoSilva | lifeless: so I can trust that rev object strings will be either unicode or utf-8 str, right? | 07:00 |
| lifeless | in the log formatter yes | 07:01 |
| lifeless | I can't make any assertions about what the log formatter outputs | 07:01 |
| RenatoSilva | anyway I think the plugin should handle the data properly, ensuring its policy will be applied (for example, print always utf-8) | 07:03 |
| RenatoSilva | lifeless: conclusion the answer about what is the encoding should be given by the plugin | 07:03 |
| RenatoSilva | so simple o.O | 07:03 |
| vila | hi all | 07:25 |
| vila | lifeless: I agree with your feelings about pycurl hanging bug, *but* digging to the root cause requires crossing the python/C barrier and that could be really time consuming, keep in mind though, that if real servers can produce such behavior, I will, sooner or later knows it via local_test_server (once I restart my efforts there) | 07:33 |
| vila | s/I agree/I *share*/ | 07:34 |
| lifeless | vila: so a few thoughts | 07:50 |
| lifeless | vila: have you checked that the socket is actually being closed? | 07:50 |
| vila | lifeless: just asnwering to your mail | 07:51 |
| vila | lifeless: I've seen the close() calls | 07:51 |
| lifeless | in strace? | 07:51 |
| vila | in pdb | 07:51 |
| poolie | hi vila | 07:51 |
| vila | hi poolie ! | 07:51 |
| poolie | spiv, istr you had a patch a while ago, that might have been abandoned, to do with better reporting of exceptions masked by unlock failures... | 07:52 |
| lifeless | so _socketobject.close seems to rely on gc() | 07:52 |
| lifeless | vila: ^ | 07:52 |
| spiv | Huh, I wasn't expecting to find a hpss hang here. | 07:52 |
| vila | lifeless: >-/ | 07:52 |
| spiv | poolie: I did, I think it was essentially abandoned. | 07:52 |
| lifeless | vila: I'd really like a little more investigation. Not a lot. | 07:52 |
| lifeless | vila: just - add a gc.collect() call after the server calls close() | 07:53 |
| vila | lifeless: like a call to gc from the server after the close ? | 07:53 |
| vila | :) | 07:53 |
| spiv | I think the bug report(s) are probably fairly up to date about where that's at. | 07:53 |
| lifeless | and when it hangs, poke with lsof | 07:53 |
| lifeless | perhaps run under strace quickly, which should show the data being written, and read, and the socket closed | 07:54 |
| poolie | spiv, where? | 07:54 |
| poolie | i mean, where is the hpss hang? | 07:54 |
| lifeless | if thats all inconclusive, keep it as it is... | 07:54 |
| vila | lifeless: works for me | 07:55 |
| spiv | poolie: there's a race condition(!) in the v3 decoder, if it receives multiple calls to accept_bytes after parsing the end of the message it overwrites, not accumulates, the excess bytes. | 08:00 |
| spiv | The fix is trivial (+= rather than = in the relevant function), but it certainly was confusing for a while, especially before I didn't realise it wasn't necessarily deterministic once sockets get involved... so I was getting random test failures. | 08:02 |
| poolie | oh ok | 08:12 |
| spiv | And of course when you don't realise there's randomness then you start going crazy as you change minor things to debug the failure and get different results... | 08:13 |
| spiv | Just finishing up the network backwards-compat part of this inventory delta patch and then it's ready for review. | 08:15 |
| lifeless | jml: ping | 08:21 |
| jml | lifeless, pong | 08:24 |
| jml | lifeless, just got back from an urgent hair cutting appointment. | 08:24 |
| lifeless | heh | 08:24 |
| lifeless | I wanted youropinion on my last post on https://bugs.edge.launchpad.net/testresources/+bug/284125 | 08:24 |
| ubottu | Ubuntu bug 284125 in testresources "Provide an option for easy instrumenting of resource setup and teardown" [Medium,Triaged] | 08:24 |
| jml | oh right. I saw that go through my email last night.. | 08:26 |
| lifeless | I could ring you? | 08:28 |
| jml | yeah. | 08:28 |
| jml | although skype is better for me | 08:29 |
| lifeless | I'm just heading for a walk | 08:29 |
| vila | lifeless: summary: I need to call gc.collect() *after* the server thread ends to get some difference :-/ | 08:32 |
| vila | which seems to validate poolie's theory.. | 08:32 |
| Spabby | hi there, the location of my bound branch has moved (ip has changed), is there any way to tell bzr this pleasE? | 08:42 |
| bob2 | edit .bzr/branch/branch.conf or 'bzr bind nelocation' | 08:43 |
| Spabby | sorry closed my irc by mistake, thank you bob2 | 08:44 |
| jml | jelmer, can you please set the development focus branch of https://launchpad.net/git to the vcs-imports branch? | 08:55 |
| Mez | jml, still around? | 09:13 |
| Mez | or any of the devvies :D | 09:13 |
| jml | Mez, I am. | 09:14 |
| Mez | jml: I'm thinking of a feature request - don't know whether it's viable. | 09:14 |
| Mez | Well, 2 feature requests. | 09:15 |
| Mez | 1) When you commit, an option to set the "whoami" data for just that commit | 09:15 |
| Mez | 2) the option to force you to have to set that per commit (so you have to specify who you are) | 09:15 |
| Mez | It's cause we've got a dev environment where we all seem to login to and commit, and it doesnt show in the log WHO actually made the commit | 09:16 |
| jml | Mez, ok. | 09:16 |
| jml | Mez, so you can set the author of a commit already | 09:16 |
| jml | Mez, note that 'author' is distinct from 'committer' | 09:16 |
| Mez | hows that then ? | 09:17 |
| jml | Mez, 'bzr commit --author 'Jonathan Lange <jml@mumak.net>' | 09:17 |
| Mez | jml: does that show up in the log ? | 09:17 |
| jml | Mez, I don't know off the top of my head. It should be easy enough to do the experiment though. | 09:18 |
| jml | he said, hintingly. | 09:18 |
| Mez | I'm already doing an experiment, just thought you might know off the top of your head | 09:19 |
| jml | :) | 09:19 |
| Mez | revno: 459 | 09:19 |
| Mez | author: Martin Meredith <martin@sourceguru.net> | 09:19 |
| Mez | committer: root <root@webutils> | 09:19 |
| jml | Mez, as for forcing you to set the author... | 09:21 |
| poolie | lifeless: ok, bzr-guess just helped me :) | 09:21 |
| poolie | or it tried | 09:21 |
| poolie | i ^cd it by instinct first | 09:21 |
| jml | Mez, I guess it's a valid feature, but you might well be the only person who wants it :) | 09:22 |
| Mez | probs | 09:22 |
| jml | Mez, as a crappy hack, you could do this: | 09:22 |
| jml | bzr alias commit='commit --author' | 09:22 |
| poolie | or you can set BZR_EMAIL | 09:22 |
| jml | (but that's a really crappy hack.) | 09:23 |
| Mez | or I can write some sort of plugin | 09:24 |
| jml | yeah. | 09:25 |
| jml | I've talked with lifeless before about a feature for setting the author(s), for use in pair programming sessions. | 09:26 |
| mwhudson | jelmer: does bzr-git import the kernel yet? :) | 09:42 |
| poolie | it might be nice if the config system also looked in the environment | 09:42 |
| poolie | for cases like this | 09:42 |
| vila | lifeless, poolie: I've got a cleaner fix calling shutdown(socket.SHUT_RDWR) and catching EBADF and ENOTCONN when the server connection is closed | 09:42 |
| Mez | well, it's also the fact we all use the same user (near enough) when we're on there | 09:43 |
| poolie | nice | 09:48 |
| poolie | Mez, that's why i was suggesting an env var | 09:49 |
| poolie | so it's not on disk or shared | 09:49 |
| poolie | vila, nice - i agree with you in questioning whether this is worth it, but if you've fixed it, yay | 09:49 |
| poolie | lifeless: are you still here? | 09:49 |
| poolie | jml, nice metronome | 09:49 |
| jml | ta | 09:49 |
| Mez | poolie, then they have to work out how to set that env var | 09:49 |
| jml | poolie, lifeless is gone, methinks. | 09:50 |
| vila | poolie: I feel better having it fixed that way, lifeless rightly pointed the grey area | 09:50 |
| poolie | vila, just to talk over the reconfigure stuff | 09:50 |
| poolie | apparently it fails if there's new history in the stacked branch on top of the fallback repository | 09:51 |
| poolie | 'it' meaning set_stacked_on_url | 09:51 |
| poolie | in other words, if the tip of the stacked branch is new, it fails with revision not present | 09:51 |
| poolie | this is a pretty typical scenario if you think about it | 09:51 |
| poolie | i suspect this covers some number of existing bugs | 09:52 |
| poolie | now i need to work out if i can get fetch() to backfill history the right way | 09:52 |
| vila | poolie: new history ? Between which dates ? | 09:53 |
| poolie | new history in the sense of revisions that aren't in the fallback repository | 09:54 |
| vila | so it can be called only at creation time ? | 09:55 |
| poolie | yeah apparently so | 09:57 |
| poolie | or rather, before committing to the stacked branch | 09:57 |
| poolie | it looks like it tries to handle the other one but it doesn't seem to work | 09:57 |
| vila | hmm, worth fixing :) | 09:58 |
| vila | lifeless: in passing: using --parallel=fork in the test farm gives a very obscure failure: the execution is killed after the timeout without output has triggered but there is no clue about why. I think I'll keep using it though at least until I stabilize the whole setup | 10:14 |
| poolie | vila: you know socket shutdown may (on some OSs?) discard any data sent to the socket and not read by the other party? | 10:17 |
| vila | poolie: pffff, even flushed data ? | 10:17 |
| vila | poolie: because here, both read and write makefiles are flushed, closed, and yet, pycurl got nothing while polling... | 10:19 |
| vila | where is that data then ???? :-D | 10:19 |
| fullermd | I ate it. I'm sorry. | 10:20 |
| poolie | vila, it can discard the socket buffers inside the os kernel | 10:20 |
| poolie | i'm not sure if this is relevant to your patch | 10:20 |
| poolie | vila, do you know if there's a way to do a fetch that allows for this situation i described above? | 10:21 |
| poolie | ie the tip revision we want to fetch is not in the source, but some of its ancestry is? | 10:21 |
| poolie | maybe i should just change it to fetch everything... | 10:21 |
| vila | poolie: the more bugs of that kind I see, the more I'm convinced there is a bug in the python socket stack... | 10:22 |
| vila | poolie: err, I'm not familiar with fetch internals, sorry :-/ | 10:22 |
| poolie | well | 10:22 |
| poolie | doing that makes it pass :) | 10:22 |
| poolie | i think i'll leave it there for tonight and talk to jam or lifeless tomorrow | 10:23 |
| vila | but I feel strange that you request a tip that is not in the source instead of fetching what you're missing | 10:23 |
| poolie | it may be possible to make a fetch spec for it | 10:29 |
| poolie | i agree it sounds strange | 10:29 |
| Fauli | Hi everyone. | 10:46 |
| Fauli | Any bzr-gtk developers available? | 10:46 |
| vila | Fauli: depending on your question you may have different answers, so please just ask | 10:49 |
| Fauli | Is it possible to make release? The current 0.95.0 is broken with Bazaar 1.16, but fixed in trunk. | 10:50 |
| Fauli | I help maintain the Gentoo Bazaar overlay where we have an ebuild available (and I am the Bazaar maintainer in Gentoo anyway). | 10:50 |
| Pilky | poolie: you around? | 10:50 |
| vila | Fauli: ping jelmer and phanatic, I thought jelmer was about to make a release though... | 10:51 |
| Fauli | jelmer: What's the status on a new bzr-gtk release? | 10:52 |
| Fauli | vila: Thanks for the information. | 10:53 |
| awilkins | verterok: Hi there ; is there anything more to installing a Hudson plugin than uploading the hpi to the web interface? I can't seem to get the Bazaar plugin to install | 11:05 |
| awilkins | verterok: Never mind, it installs it rather than just putting it in the list of available plugins | 11:08 |
| jelmer | jml: done | 11:31 |
| jelmer | mwhudson: it should support importing the kernel if you're importing to a 2a repo | 11:31 |
| jelmer | Fauli: I'm not sure - I won't have time for it any time soon, maybe one of the other bzr-gtk folks will | 11:32 |
| Fauli | jelmer: Could you convince them or should I file a bug for that? | 11:35 |
| lifeless | poolie: guess - good. | 11:37 |
| lifeless | poolie: you can ring if you need to chat but I'm not at the laptop after these lines | 11:37 |
| lifeless | vila: yes, I suspected shutdown would be useful | 11:37 |
| jelmer | Fauli: can you perhaps mail to bzr-gtk@lists.canonical.com ? | 11:37 |
| lifeless | vila: this starts to smell less like a pycurl bug with that data | 11:37 |
| * lifeless goes again | 11:37 | |
| Fauli | jelmer: Done. | 11:39 |
| jelmer | Fauli: thanks | 11:40 |
| mwhudson | jelmer: what goes wrong in 1.9-rr? | 11:53 |
| mwhudson | jelmer: https://code.edge.launchpad.net/~vcs-imports/git/trunk:) | 11:56 |
| mwhudson | jelmer: also https://code.edge.launchpad.net/~vcs-imports/wine/git-trunk :( | 12:09 |
| === mrevell is now known as mrevell-lunch | ||
| === mario__ is now known as pygi | ||
| === mrevell-lunch is now known as mrevell | ||
| jelmer | mwhudson: in 1.9-rr xml-invalid characters are squashed | 13:48 |
| jelmer | mwhudson: meaning that you need the cache for proper incremental imports | 13:49 |
| vila | jelmer: I'd be happy to *help* release bzr-gtk but I don't know what need to be done to make a release | 13:54 |
| jml | jelmer, thanks | 14:23 |
| Tak | jelmer: good $timeofday | 14:24 |
| jelmer | vila: there's a tasklist here: http://bazaar-vcs.org/bzr-gtk/releasing | 14:30 |
| jelmer | Tak: hey | 14:30 |
| Tak | I had the same bzr-svn error again yesterday :-/ | 14:31 |
| Tak | I couldn't find any cache dir to remove this time, but a rebase seems to have "fixed" it for now | 14:32 |
| jelmer | Tak: please file a bug next time you hit it | 14:34 |
| Tak | ok - I can't seem to reproduce it consistently - just a couple times I've gone to pull, and bam | 14:39 |
| vila | jelmer: from http://bazaar-vcs.org/bzr-gtk/releasing, I can push a branch where 1-6 are done, I can then do 15-18, can you do 6-14 ? (12 and 13 being... optional it seems, see updated wiki) | 14:52 |
| Pilky | did bzr get a new progress bar in 1.16? | 14:52 |
| vila | Pilky: changes where made in that area yes | 14:52 |
| Pilky | cool, it's a hell of a lot more useful than it was before :) | 14:53 |
| vila | Pilky: compared with what ? | 14:53 |
| Pilky | well I've got 1.10 on my main machine and it doesn't show as much info and seems to be kinda buggy, but 1.16 on my laptop seems more informative and not buggy | 14:54 |
| Pilky | though I didn't realise I was that far behidn on my main machine | 14:54 |
| vila | Pilky: oh, so, you just discovered the traffic blinken lights :) | 14:56 |
| ramaral | Hello, I'm new to Bazaar. I was going through the tutorial (mini version) and tried to publish to my ftp website and got this error message "FTP temporary error 451:......." I noticed some of the files and directories were created on the ftp server but my version files were not copied. Can anyone help me resolve this? | 15:12 |
| === andreas__ is now known as ahasenack | ||
| vila | ramaral: it would help if you say what is after the 451, if it's about appending, you're likely out of luck with a server that doesnt' support a feature bzr need | 15:15 |
| ramaral | The stuff after the 451 error is "/Projects/myproject/.bzr/repository/upload/iqbx62....ftech: Append/Restart not permitted, try again. retrying." | 15:18 |
| bialix | vila: bonjour | 15:18 |
| vila | ramaral: exactly | 15:21 |
| vila | bialix: hi ! | 15:21 |
| ramaral | vila: do you mean exactly I'm out of luck because my ftp server does not support append or you want the rest of the GUI that I truncated in the last message? | 15:25 |
| vila | ramaral: your ftp server doesn't support append | 15:29 |
| ramaral | OK, thanks for your help! | 15:30 |
| bialix | vila: http://pastebin.com/m7f3976a3 | 15:41 |
| bialix | vila: any ideas why explicit URL gives this warning every time? | 15:41 |
| bialix | it affects qpull (in qbzr) | 15:42 |
| bialix | can I file a bug? | 15:42 |
| vila | bialix: <shudder> because some code is stripping the the final '/' you carefully added :-/ | 15:48 |
| bialix | qpull reads saved URL and then run bzr pull with exact string | 15:49 |
| bialix | and I've got this every time | 15:49 |
| bialix | it makes bad impression (even for me) | 15:49 |
| vila | then, the http server, being Apache, insists that you really should put a final '/' if you're talking about a directory, even if it knows damn well that the path is a directory | 15:49 |
| vila | bialix: it's either a trivial patch or a tricky one, depending on how you look at it (I haven't in the last months, but lifeless and abentley discussed it and I seem to remember they ended up with a trivial, I don't remember why it was never submitted...) | 15:51 |
| bialix | so, I'm file the bug. I hope it's possible to fix it in trivial way rather than tricky one | 15:51 |
| bialix | https://bugs.launchpad.net/bzr/+bug/397046 | 15:52 |
| ubottu | Ubuntu bug 397046 in bzr "explicit URL for pull command: bzr eats trailing slash from URL and then complains about permanent redirection" [Undecided,New] | 15:52 |
| abentley | vila: I don't remember. | 15:54 |
| vila | abentley: what ? The fix or why it wasn't submitted ? | 15:55 |
| abentley | vila: All I remember was agreeing that it should be fixed. | 15:55 |
| vila | :) | 15:55 |
| bialix | I don't find a similar bug report to mine | 15:55 |
| jam | morning vila, bialix | 16:05 |
| jam | btw vila, it seems "Review: approve" doesn't work anymore | 16:05 |
| jam | you need to do "vote: approve" | 16:05 |
| jam | (I've run into this a couple times where I approved something and LP didn't notice) | 16:05 |
| bialix | jam: good day | 16:06 |
| vila | I did it yesterday and it did work | 16:06 |
| jam | vila: it didn't work here: https://code.edge.launchpad.net/~jameinel/bzr/1.17-rework-annotate/+merge/8281 | 16:06 |
| jam | not sure why | 16:06 |
| vila | but the mail should be signed | 16:06 |
| vila | rats, I forgot to sign that one too ??? | 16:06 |
| vila | I thought you got an error mail in that case but may be that changed :-. | 16:07 |
| vila | jam: I'm reviewing your lru-cleanup, let's see | 16:08 |
| vila | hmm, reading the help again: Note that you must start the command line with a space or your command will not be recognized. | 16:10 |
| jam | vila: sure, I thought you had | 16:11 |
| jam | I *think* vote is for the vote of the specific patch | 16:11 |
| jam | and Review is the overall status of the merge request | 16:11 |
| jam | so doing *both* is actually reasonable | 16:12 |
| vila | vote (deprecated: use review) | 16:12 |
| jam | vila: where is the help? | 16:12 |
| vila | https://help.launchpad.net/Code/Review | 16:12 |
| vila | and needs_fixing *really* sounds like tweak to me | 16:13 |
| vila | approve: go ahead, merge, needs_fixing: merge with the little changes asked for, resubmit: too many changes asked for, I'd like to view the result | 16:13 |
| vila | oh nice: reviewwer | 16:14 |
| vila | oh nice: reviewer | 16:14 |
| vila | or maybe tweak is really: review needs_fixing, merge approved | 16:14 |
| jam | so it seems that "merge" is now the overall status | 16:15 |
| jam | and "review" is the status of my personall review | 16:15 |
| jam | also interesting | 16:16 |
| jam | the "review" commands are actions | 16:16 |
| jam | (approve, disapprove) | 16:16 |
| jam | but the "merge" commands are *states* | 16:16 |
| jam | (approved, rejected) | 16:16 |
| jam | probably not the best design | 16:17 |
| vila | review approve, merge rejected :-/ | 16:17 |
| vila | jam: it worked | 16:18 |
| jam | bug #397049 | 16:19 |
| ubottu | Launchpad bug 397049 in launchpad-code "code review email interface inconsistent command types" [Undecided,New] https://launchpad.net/bugs/397049 | 16:19 |
| bialix | jam: I have no chance to test/review your patches for bzr-explorer in next few days, because I'm in the process of finishing urgent tasks before my vacation. I hope igc will be able to review them | 16:24 |
| jam | bialix: no problem, I hope you have a nice vacation | 16:25 |
| bialix | I hope too | 16:25 |
| jam | a couple are pretty trivial, though | 16:25 |
| bialix | it's a bit short -- only one week | 16:25 |
| * bialix waves, need to go | 16:26 | |
| mgedmin | what was the name of that plugin that showed notification bubbles when people committed changes in your local LAN? | 16:30 |
| mgedmin | something to do with bzr-avahi, no? | 16:30 |
| * mgedmin plays with bzr help and find bzr lan-notify | 16:32 | |
| mgedmin | bzr commit-notify doesn't exist in my version of bzr-gtk :( | 16:38 |
| jam | vila: I have to duplicate the line to get it into the finally block | 16:41 |
| jam | what would you rather see? | 16:41 |
| vila | wow, a new brain ? | 16:42 |
| vila | if misread the else as being aligned with the try :-/ | 16:43 |
| * SamB wonders what happens when you use bzr-svn to commit a non-linear revision graph | 16:43 | |
| vila | I know, doesn't make sense | 16:43 |
| * SamB supposes there's one way to find out ... | 16:43 | |
| vila | jam: then just a comment in the finally block that you want to ensure the node is warm enough | 16:45 |
| jam | vila: yeah, I added finally comments | 16:45 |
| jam | about why we are using them | 16:45 |
| vila | ok | 16:46 |
| SamB | warm? like, won't go out of cache? | 16:46 |
| jam | SamB: moved to the front of the LRU in an LRUCache :) | 16:47 |
| jam | vila: btw, I did end up inheriting from _py.Annotator in _pyx.Annotator, and it does simplify things a bit | 16:47 |
| jam | so cheers for the idea | 16:47 |
| vila | yeah ! | 16:47 |
| jam | It also meant I didn't need to create _NeededTextsIterator | 16:47 |
| jam | to compensate for the fact that pyrex doesn't support yield | 16:47 |
| jam | which is a fairly big win for complexity | 16:48 |
| vila | regarding pyrex, I browse the archives a little bit but I wasn't convinced there was a lot of activity there... and I see a lot of references to cython, did you research cython yourself ? | 16:49 |
| jam | vila: cython is a fork of pyrex that sounds "better", I believe bialix uses it and like its | 16:50 |
| jam | that said | 16:50 |
| jam | it wasn't as widely available | 16:50 |
| jam | (as in, no packages for Ubuntu) | 16:50 |
| jam | pyrex is basically maintained by 1 person that wants fairly strict control over it | 16:50 |
| jam | as he wants to understand everything that goes into the codebase | 16:50 |
| jam | cython is (AIUI) maintained by many people | 16:51 |
| jam | so if we were to go to the effort of packaging our own thing | 16:51 |
| jam | we should certainly consider switching to cython | 16:51 |
| jam | vila: certainly the 0.9.8 stuff (supporting "cdef list foo" was brought into pyrex from cython) | 16:51 |
| vila | ouch | 16:52 |
| jam | vila: http://wiki.cython.org/FAQ#WhatistherelationbetweenCythonandPyrex.3FArethebarriersbetweenthetwobasedontechnicaldirection.3FDifferinggoals.3F | 16:52 |
| jam | though I think the "for x in blah" was also brought into pyrex | 16:53 |
| vila | ok, I'm printing the Cython manual and willl read it at night | 16:53 |
| vila | jam: blah that url is unreadable :) | 16:53 |
| jam | vila: first item on: | 16:53 |
| jam | http://wiki.cython.org/FAQ | 16:53 |
| vila | jam: kidding, the page *is* readable :) | 16:53 |
| jam | autogenerated urls... yummy | 16:54 |
| * SamB curses Debian and/or GNU for the lack of bash.info, even in non-free ... | 16:55 | |
| vila | jam: If we go to the point where we archive the .c files, we'll get also lower the constraints on the tool we chose... | 16:55 |
| jam | vila: as long as you can make versioning auto-generated files palatable | 16:57 |
| jam | which seems to be the bigger issue | 16:57 |
| vila | jam: I agree. But does cython suffers from the same problem ? | 16:58 |
| * mgedmin finds bzr-notify | 17:00 | |
| jam | vila: cython shares enough history with pyrex that I'm 75% sure it does | 17:01 |
| jam | on the plus side, cython uses Launchpad's bug tracker :) | 17:01 |
| jam | though the user mercurial as the VCS | 17:02 |
| === garyvdm changed the topic of #bzr to: Bazaar version control system | 1.16.1 released 26th June, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | ||
| jam | hmm.. looks like they might be packaged in Jaunty | 17:02 |
| jam | given that they have some [jaunty] bugs :) | 17:03 |
| vila | 0.10.3 in jaunty, bug they seem to use trac not launchpad... | 17:03 |
| jam | vila: well their wiki points you to answers.launchpad.net | 17:05 |
| vila | jam: yeah, weird | 17:05 |
| jam | oh, it also seems that pyrex is pure python, while cython bootstraps itself | 17:05 |
| jam | vila: so I still see absolute paths in the "cython.py foo.pyx" output | 17:11 |
| jam | so yes, they suffer the same issue | 17:11 |
| vila | hmm | 17:11 |
| * vila EDOing | 17:14 | |
| jam | sure | 17:14 |
| jam | going a bit further, they even include the code snippets in the output | 17:15 |
| jam | which means it is a bit bigger, and changing line 10 causes noise in the diff for line 11's comment | 17:15 |
| garyvdm | Hi bialix | 17:29 |
| === sdboyer is now known as Guest45719 | ||
| garyvdm | Hi amanica | 18:00 |
| amanica | garyvdm hi! | 18:01 |
| amanica | garyvdm: nice new photo.. | 18:07 |
| * bialix bbl | 18:12 | |
| ramaral | User question: I'm test driving bazaar following the mini tutorial. I've created a local repository and pushed it onto an ftp server. I'm having trouble getting those files from the server. The files were pushed to ftp://<server name>.com/Projects/myproject, I'm trying to get them into a different local directory (simulating a different user) like this "bzr branch http://<server name>.com/Projects | 18:16 |
| ramaral | /myproject. I get the error "ERROR: A Subversion remote access command failed: Server sent unexpected return value (403 Forbidden) in response to OPTIONS request for http://<server name>.com/Projects/myproject". Help? | 18:16 |
| amanica | ramaral: I assume you didn't use svn at all for this, and that you have the bzr-svn plugin installed? | 18:21 |
| ramaral | amanica: Yes, no SVN. I can only assume I have a bzr-svn pluggin. I installed the Windows version of Bazaar. I was surprised to see references to SVN. | 18:23 |
| amanica | ah, ok yes it is bundled with that afaik | 18:23 |
| amanica | this sounds like a bug I saw | 18:23 |
| amanica | you can try: "bzr --no-plugins branch http://<server name>.com/Projects/myproject. " | 18:24 |
| amanica | (space before the last .) | 18:25 |
| ramaral | OK, let me try that, one min... | 18:26 |
| ramaral | amanica: Now I get "ERROR: Not a branch : http://<server name>.com/Projects/myproject". For server name should I be using "www.<server name>.com" or "ftp.<server name>.com" | 18:29 |
| amanica | can you browse the http site you are trying to branch from/ | 18:31 |
| amanica | is it shared over ftp and http? | 18:31 |
| ramaral | I'll try that too a little later, have a meeting now...thanks amanica | 18:33 |
| amanica | ok ramaral, np | 18:33 |
| bialix | garyvdm: hi | 19:05 |
| schmichael | somehow i've got my branch set with a "submit branch: ." | 19:11 |
| schmichael | sp now merge is using "." by default instead of my parent branch | 19:11 |
| schmichael | s/sp/so | 19:11 |
| schmichael | i'm not even sure what a submit branch is or (more importantly) how to get rid of it | 19:12 |
| schmichael | it appeared when i was playing around with "bzr merge --preview" | 19:12 |
| bialix | schmichael: use merge PATH --remember to override it | 19:21 |
| schmichael | bialix: any clue how i caused it? or what a submit branch is? | 19:28 |
| bialix | тщ | 19:28 |
| bialix | no | 19:29 |
| bialix | schmichael: maybe you playing with `send` command? | 19:30 |
| schmichael | nope, just merge... | 19:31 |
| schmichael | weird huh? | 19:31 |
| bialix | weird? sometimes it makes sense to look at commands history | 19:32 |
| dgoulet | hello people, is it possible to create a branch but with a revision history reset ? (not getting the revision history) | 19:33 |
| bialix | bzr init? | 19:33 |
| dgoulet | without* | 19:33 |
| dgoulet | oups sorry, from an existing repo | 19:33 |
| dgoulet | bzr branch from an existing repo but without the history | 19:33 |
| dash | dgoulet: why create it in an existing repo if you don't need the history in that repo? | 19:33 |
| dash | a repo is just a collection of revisions :) | 19:34 |
| dash | (mostly) | 19:34 |
| dash | 'bzr init' sounds right to me | 19:34 |
| dgoulet | the point is that I have some standard file in a bzr repo. I want to create a branch from that to get these "default file" but without getting the 18673 revision history | 19:35 |
| dgoulet | because some file previously deleted or uncommit might be confidential | 19:35 |
| dgoulet | are you following me? | 19:35 |
| dash | hmm, do you perhaps want 'bzr export'? | 19:36 |
| dgoulet | yep but then I can't make anymore diff with the parent repo right..? | 19:36 |
| dash | right | 19:36 |
| dash | wait | 19:36 |
| dgoulet | that's my problem | 19:36 |
| dgoulet | I want to be able to diff | 19:36 |
| garyvdm | bialix: I'm looking at bug 395817. I think the fix will be in pipeline, and not qbzr. | 19:37 |
| ubottu | Launchpad bug 395817 in qbzr "qbzr and bzr-pipeline not compatable." [Medium,New] https://launchpad.net/bugs/395817 | 19:37 |
| dash | dgoulet: then you need the history | 19:37 |
| garyvdm | bialix: Any thing that I can help with? | 19:37 |
| garyvdm | Update NEWS.txt? | 19:37 |
| bialix | garyvdm: I'm thinking what should be in NEWS | 19:37 |
| bialix | yeah! | 19:38 |
| bialix | you read mymind | 19:38 |
| bialix | my mind | 19:38 |
| * bialix tired a bit | 19:38 | |
| schmichael | bialix: its a bit embarrassing, but here's my bash history :) http://dpaste.com/64664/ | 19:38 |
| schmichael | somewhere around 507, "submit branch: ." was added (afaict) | 19:39 |
| bialix | schmichael: have no idea | 19:40 |
| bialix | I don't think it's horrible bug | 19:40 |
| dgoulet | ok well... to be able to make a diff we need a "common ancester" so there is no way we can connect the first revision of the new branch to the last revision of the main repo ? hehe | 19:40 |
| bialix | you can always override this settings or even delete it (see .bzr/branch/branch.conf file) | 19:40 |
| schmichael | bialix: thanks for your help! | 19:41 |
| bialix | dgoulet: -r0..N is the trick | 19:41 |
| dash | dgoulet: so you want a branch who shares history with another branch, but doesn't share history with another branch? :) | 19:41 |
| dash | dgoulet: perhaps your problem is not with bzr :) | 19:41 |
| dash | dgoulet: if the issue is just downloading all the history to a remote host, there are stacked branches and lightweight checkouts | 19:43 |
| bialix | garyvdm: revno 785: it's about compatibility with bzr 1.17? | 19:44 |
| garyvdm | bialix: Yes | 19:45 |
| bialix | I'll mention it in the NEWS then | 19:46 |
| garyvdm | And rev 787 | 19:46 |
| bialix | what's 790? | 19:47 |
| bialix | it was bug? | 19:47 |
| bialix | or just regression? | 19:47 |
| bialix | garyvdm: thanks for fixing revno painter! | 19:54 |
| garyvdm | Cool - but it was not me - it was luks | 19:55 |
| bialix | rats | 19:56 |
| bialix | sorry luks: many thanks to you | 19:56 |
| dgoulet | dash: lightweight checkout consist of? | 19:57 |
| dash | dgoulet: a working tree and a reference to a remote branch | 19:58 |
| dgoulet | ok right | 19:58 |
| bialix | garyvdm: so here is news: http://pastebin.com/mf7817af | 19:59 |
| bialix | is there anything I'm missing? | 19:59 |
| dgoulet | but let me be clear (might be confusing...). There's a repo bzr on a server A containing files and a very large number of revision (over 18000). What I want a do is to create a branch from that repo on a server B BUT without getting all revision history but still having a link to the parent branch so I can make diff | 20:00 |
| dgoulet | clearer? lolo | 20:00 |
| dash | Right! | 20:00 |
| dash | so maybe you want a stacked branch | 20:00 |
| dash | which you can make local commits to, but doesn't store all history | 20:01 |
| dash | instead it references a different branch as its parent | 20:01 |
| === nevans1 is now known as nevans | ||
| garyvdm | bialix: Re:790 I added the feature before 0.10 (rev 720) but broke it before 0.10 (rev 729) - So we should mention it as a new feature. | 20:01 |
| dash | when it needs data from the remote branch, it fetches it. | 20:01 |
| dgoulet | I see | 20:02 |
| garyvdm | bialix: I would like to add some detail. | 20:03 |
| bialix | garyvdm: "Working Tree" label in qannotate looks a bit strange | 20:03 |
| dgoulet | I found the page on doc.bazaar seems very interesting | 20:03 |
| dgoulet | thanks a lot dash! much appreciate! | 20:03 |
| bialix | garyvdm: I can commit my version and you'll have a chance to improve it, or you prefer pastebin your version? | 20:03 |
| garyvdm | bialix: Commit it. I use a tool bzr that is great for merging stuff like this ;-) | 20:04 |
| bialix | re revno 790: I was under impression it should open new qannotate window. but peraps from speed POV it's better reuse existing data | 20:05 |
| bialix | log should be updated then I suppose | 20:05 |
| * bialix committing NEWS | 20:05 | |
| garyvdm | I don't change log, because otherwise it's not possible to go back forward. | 20:06 |
| garyvdm | bialix: I'm not sure what you mean about "Working Tree" label in qannotate. | 20:07 |
| bialix | in left bottom corner where graph of revisions shown | 20:08 |
| bialix | last revision marked with Working Tree lable (on blue background) | 20:08 |
| bialix | pushed | 20:08 |
| dgoulet | dash: with stacked branch you can still have all history with bzr log | 20:09 |
| bialix | garyvdm: run qannotate for qbzr/__init__.py | 20:09 |
| bialix | latest revno is 808 | 20:09 |
| bialix | but latest change for this file was in revno 781 | 20:10 |
| bialix | but revno 781 is marked in qannotate as Working Tree | 20:10 |
| dash | dgoulet: correct | 20:10 |
| garyvdm | qlog does that if you working tree tip is different from the branch tip. | 20:10 |
| bialix | it's wrong | 20:10 |
| bialix | garyvdm: I'm working in lightweight checkout | 20:10 |
| dash | dgoulet: that's what you were asking for | 20:10 |
| dgoulet | lol no the contrary :P | 20:11 |
| bialix | garyvdm: so in reality I have 2 wt for one branch | 20:11 |
| dgoulet | on the branch, I need NOT to see the log (revision history) ;) | 20:11 |
| dash | dgoulet: if you can't read the log you can't make diffs | 20:11 |
| bialix | there is used wrong wt | 20:11 |
| dgoulet | but still having a link to the parent branch | 20:11 |
| dgoulet | ;) | 20:11 |
| * bialix checks | 20:11 | |
| dash | dgoulet: make up your mind :) | 20:11 |
| dgoulet | okok well that's my problem... | 20:12 |
| dgoulet | so I think what I want to do is not possible | 20:12 |
| dash | why do you want this? | 20:12 |
| bialix | garyvdm: anyway qannotate wrong: in my branch wt at revno 782, not on 781 | 20:13 |
| garyvdm | bialix: Hmmm - What qlog does is if there is are revisions filtered, and the tip is filtered, then the label for the tip is moved down to the next visible ancestor. | 20:13 |
| garyvdm | that was to fix bug.... | 20:13 |
| dgoulet | concept of having a "reference copy" of files and getting these file for client but if the history comes with it ... security issue ;) | 20:13 |
| bialix | for WT label it's maybe counter-intuitive | 20:13 |
| dgoulet | but if the client modify something on is branch, I want to be able to make diff from the "reference" | 20:14 |
| dgoulet | his* | 20:14 |
| bialix | garyvdm: there is similar bugs when running qlog on shared repo: lables for merged branches tips shown incorrectly (for mainline revisions) | 20:14 |
| dash | dgoulet: oh, so you don't actually need to make checkins | 20:14 |
| dash | dgoulet: from that reference copy | 20:14 |
| bialix | garyvdm: I don't want to block this release | 20:15 |
| bialix | but it's looks not very good | 20:15 |
| dash | dgoulet: use bzr export; when you want to produce a diff, copy their version into the working copy of a branch :) | 20:15 |
| garyvdm | bialix: This feature was to fix bug 273311 | 20:15 |
| ubottu | Launchpad bug 273311 in qbzr "qlog FILE with pending merges: no "Pending Merge" label" [Medium,Fix released] https://launchpad.net/bugs/273311 | 20:15 |
| bialix | :-/ | 20:15 |
| dgoulet | that's a solution but diff does'nt consider deleted files or permission right? | 20:15 |
| bialix | garyvdm: ok, I'll try to raise this q again after vacation | 20:16 |
| garyvdm | ok | 20:16 |
| dash | dgoulet: well. delete all the files in the wc then copy in your clients' code :) | 20:17 |
| bialix | garyvdm: pushed again (translations update) | 20:20 |
| garyvdm | ok | 20:20 |
| dgoulet | well that's was the plan B hehe | 20:21 |
| dgoulet | thx again | 20:21 |
| bialix | garyvdm: please use https://code.launchpad.net/~qbzr-dev/qbzr/0.12 to merge 0.12-specific changes | 20:25 |
| garyvdm | ok | 20:25 |
| garyvdm | bialix: How do we describe rev 791 (revno painter)? | 20:30 |
| bialix | there was bug | 20:31 |
| * bialix bbl: House MD on TV | 20:31 | |
| garyvdm | qlog/qannotate/qbrowse: Revision numbers are right aligned on the mainline number.? | 20:32 |
| lamalex | Can you guys help me chose a merge algorithm? the default one is giving tons of conflicts and im wondering if using a different one will help | 20:34 |
| bialix | garyvdm: fine for me | 20:43 |
| garyvdm | And I gave an example... | 20:43 |
| garyvdm | bialix: I just pushed some changes for lp:~qbzr-dev/qbzr/0.12 | 20:44 |
| garyvdm | bbl | 20:44 |
| bialix | ok | 20:44 |
| bialix | garyvdm: so I'm ready to call it release | 20:52 |
| lamalex | anyone able to help me with this merge? | 20:56 |
| bialix | lamalex: what's up | 20:58 |
| lamalex | bialix: I think a different merge algorithm would help me complete this merge, but im not sure what to pick | 20:58 |
| bialix | did you saw message about criss-cross? | 20:59 |
| lamalex | no, i know how tohandle that | 20:59 |
| lamalex | give me a minute, im describing | 20:59 |
| bialix | there is only 2 algorithms: merge3 and lca | 21:00 |
| lamalex | in the branch im merging into mine, many files that i have edited were renamed and have small edits. Our edits dont conflict however. If I rename all of my files into the same name as the new ones, i get conflicting code paths for every file- no good. if i just merge i get text conflicts | 21:00 |
| dash | lamalex: were the files renamed using 'bzr mv'/'bzr rename'? | 21:02 |
| garyvdm | bialix: cool | 21:03 |
| garyvdm | jam: I'm not sure why. I started using fireGPG, and on all of your mails, it say "Wrong signature". | 21:05 |
| lamalex | dash: looking.. not sure off hand but i think so | 21:05 |
| jam | bialix: and --weave | 21:06 |
| jam | which IMO is better than --lca | 21:06 |
| bialix | jam: in my experience lca is better for criss-cross | 21:06 |
| jam | bialix: than --merge3 yes, than --weave probably not | 21:06 |
| jam | bialix: especially given that I did a lot of work on it for mysql | 21:07 |
| bialix | for me: better, but it's just for me | 21:07 |
| bialix | sometimes weave produce wrong conflicts | 21:07 |
| lamalex | dash: actually no, it doens't appear to be the case | 21:07 |
| dash | lamalex: that's a significant problem then | 21:07 |
| lamalex | maybe i can bzr mv --after them now.. | 21:07 |
| bialix | but you know better, of course | 21:08 |
| * lamalex kills the person who did the renaming | 21:08 | |
| jam | bialix: so a while back --weave was utterly broken | 21:09 |
| jam | I don't know if you used it since I worked on it | 21:09 |
| bialix | I don't know when you worked on it | 21:10 |
| jam | bialix: ~ earlier this year | 21:10 |
| bialix | I've not used --weave about a year maybe | 21:12 |
| bialix | will check it next time when I have some conflicts, thx for the info | 21:13 |
| lamalex | dash: think it's possible to reverse cherrypick the commit that did the mvs, then redo it with bzr mv? | 21:17 |
| dash | maybe | 21:17 |
| dash | if i knew what "reverse cherrypick" meant | 21:17 |
| lamalex | pick the commit out | 21:18 |
| lamalex | pretty sure thats the term used in the docs.. | 21:18 |
| lamalex | dash: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#reverse-cherrypicking | 21:21 |
| bialix | jam: one question: if I tag new qbzr release as `release-0.12' instead of `release-0.12.0' it will be ok for your build bzr.exe release script? | 21:23 |
| RenatoSilva | lifeless: hi, about our encoding talk... I did the following... | 21:23 |
| jam | bialix: Whatever you name it is what I'll put into build_release.py | 21:24 |
| jam | so right now I believe I use '0.11.0' | 21:25 |
| jam | but I can put '0.12' in there just as easily | 21:25 |
| bialix | ok | 21:25 |
| === nevans1 is now known as nevans | ||
| RenatoSilva | lifeless: there's a cmd.getStandardOutput() in the Java plugin. It is an XML, so I read the ascii preamble, get the encoding, change the XML itself to bytes form, then I decode it using the detected encoding. It is xmloutput's compromise to ensure that preamble and data encoding match. | 21:26 |
| RenatoSilva | verterok: hi Guillermo. I've sent you a new branch to fix encoding in log view. Please forget what I said about the python-like string inside CDATA. It's not python-like, it's really an actual string. I was just confused by python's prompt when I decoded the base64 message... | 21:28 |
| verterok | RenatoSilva: yes, I got the email. thanks! | 21:29 |
| verterok | RenatoSilva: np :) | 21:29 |
| verterok | RenatoSilva: I'll take a look to it tonight | 21:29 |
| bialix | qbzr 0.12 released | 21:50 |
| * bialix -> sleeps | 21:50 | |
| mwhudson | jam: would a complaint along the lines of "annotate often fails on stacked branches" surprise you? | 21:51 |
| lamalex | how can I merge all revision since rev X | 21:51 |
| lamalex | bzr merge -r X branch | 21:51 |
| lamalex | ? | 21:51 |
| jam | mwhudson: I would be shocked and appalled that you would even hint at such a thing :) | 21:52 |
| mwhudson | hmm seems to be https://bugs.edge.launchpad.net/bzr/+bug/393366 | 21:53 |
| ubottu | Ubuntu bug 393366 in bzr "KeyError in knit.simple_annotate running annotate on a stacked branch" [High,Confirmed] | 21:53 |
| * mwhudson comments | 21:57 | |
| lamalex | anyone got a suggestion for my merge question? | 21:59 |
| lamalex | bzr merge -r X.. branch | 21:59 |
| lamalex | ? | 21:59 |
| NfNitLoop | I dunno, try 'bzr help merge'? | 22:01 |
| NfNitLoop | generally I don't specify revisions. | 22:01 |
| NfNitLoop | Just bzr merge branch. | 22:01 |
| NfNitLoop | it figures out what needs merging. | 22:01 |
| lamalex | NfNitLoop: yah tried --help | 22:02 |
| lamalex | doesnt say and im not sure | 22:02 |
| mwhudson | lamalex: yeah, merge -r x.. should do it | 22:02 |
| mwhudson | it'll do a cherry pick though, not a true merge | 22:02 |
| mwhudson | you can also merge -r ..x, bzr revert ., bzr commit (this is called a "null merge"), then merge normally | 22:02 |
| lamalex | does one have any advantages over the other? | 22:03 |
| lamalex | mwhudson: and just to be sure, that will merge [X,..] or (x,..] | 22:05 |
| RenatoSilva | verterok: a note about my stacked branch: the encoding comes as cp1252 (not static utf-8 anymore ok) but the data as cp850 | 22:05 |
| RenatoSilva | verterok: in terminal I mean | 22:05 |
| mwhudson | lamalex: if you'll be wanting to merge from the branch again, the null merge approach is probably better | 22:06 |
| mwhudson | um, ranges are inclusive start exclusive end for merge i think | 22:07 |
| NfNitLoop | not according to `bzr help merge` | 22:08 |
| NfNitLoop | start exclusive, end inclusive. | 22:08 |
| NfNitLoop | 81..82 will get the changes introduced by 82. | 22:08 |
| mwhudson | ah right yes | 22:08 |
| lamalex | mwhudson: for that null merge did you mean x.. or ..x | 22:09 |
| lamalex | maybe i should just describe the problem :) | 22:10 |
| mwhudson | lamalex: i meant ..x | 22:10 |
| mwhudson | lamalex: yeah, that's probably a good idea | 22:10 |
| lamalex | So we had someone add/remove a bunch of files instead of bzr mv them | 22:11 |
| NfNitLoop | http://doc.bazaar-vcs.org/latest/en/user-guide/index.html | 22:11 |
| lamalex | this was a few commits back, i'm trying to undo what they've done so that i can cleanly merge with a branch that touches those files and was branched before their work | 22:11 |
| NfNitLoop | "Unlike a normal merge, Bazaar does not currently track cherrypicks. In particular, the changes look like a normal commit and the (internal) revision history of the changes from the other branch is lost." | 22:11 |
| mwhudson | lamalex: urgh | 22:12 |
| lamalex | NfNitLoop: I'm not sure if oyu're talking to me, but that's irrelevant. | 22:12 |
| NfNitLoop | ok. | 22:12 |
| lamalex | so pleas shut up, you're not being helpful. I've read the docs- I'm asking because this is complex | 22:12 |
| mwhudson | lamalex: so if x is the branch | 22:12 |
| mwhudson | lamalex: that's a bit harsh, NfNitLoop is trying to help too | 22:13 |
| lamalex | which branch :P | 22:13 |
| mwhudson | lamalex: if x is the revision that screws things up | 22:13 |
| lamalex | mwhudson: you're right. NfNitLoop sorry, im strsessed out trying to fix this | 22:13 |
| mwhudson | lamalex: i think you can bzr merge -r x..(x-1) .; bzr ci; to undo the messy revision, then merge | 22:13 |
| mwhudson | if there have been changes to the files added/removed since the messing up, you're somewhat doomed i think | 22:14 |
| mwhudson | well not doomed, but it's going to be a fiddle | 22:14 |
| lamalex | there's the guilty party | 22:14 |
| lamalex | mwhudson: so there are 3 commits (theyre sequential) i want to cut out that | 22:15 |
| lamalex | no, 2 | 22:16 |
| mwhudson | lamalex: do subsequent commits change the files that were touched by the commits you want to revert? | 22:16 |
| lamalex | 631 and 632, so I would want to bzr merge -r 632..630 . | 22:16 |
| mwhudson | lamalex: yes | 22:16 |
| lamalex | mwhudson: yeah, these merges touched MANY files | 22:17 |
| lamalex | like, at least 1 in every dir | 22:17 |
| mwhudson | that merge command will probably conflict then | 22:17 |
| lamalex | do you think it's possible to branch at the last good before the bad, do the rename, then merge the ones after the bad? | 22:18 |
| dash | quite likely | 22:18 |
| mwhudson | yesh | 22:18 |
| mwhudson | that's probably a good idea, actually | 22:18 |
| mwhudson | man this would be easier to explain with a whiteboard :) | 22:18 |
| lamalex | :) | 22:19 |
| lamalex | there isprobably some collabo software we could use | 22:19 |
| mwhudson | yes, but that would not be easier, i expect | 22:19 |
| lamalex | haha indeed | 22:19 |
| NfNitLoop | Oh, yeah, that's what I'd do. | 22:20 |
| NfNitLoop | If it had just been the *last* commit... | 22:20 |
| NfNitLoop | there's the handy "Uncommit" command. :) | 22:20 |
| mwhudson | yeah, the earlier you find these problems the easier, for sure | 22:21 |
| lamalex | indeed | 22:21 |
| NfNitLoop | you could in theory uncommit twice, if you have a way to reapply the 3rd patch. | 22:21 |
| lamalex | this is autofoo type stuff | 22:21 |
| NfNitLoop | autofoo? | 22:21 |
| lamalex | so we tend to not review it that hard since RAOF is the only one who /really/ understands | 22:21 |
| mwhudson | lamalex: i think it's possible that bzr-rebase's replay command will be useful here, but i've never used it | 22:21 |
| lamalex | hm ill look at that | 22:22 |
| lamalex | ugh | 22:25 |
| lamalex | merge failed | 22:26 |
| lamalex | Conflict because Zim is not versioned, but has versioned children. Versioned directory. | 22:26 |
| lamalex | Conflict: can't delete Zim/Resources because it is not empty. Not deleting. | 22:26 |
| lamalex | repeated many many times | 22:26 |
| garyvdm | I have not been following this to carefully, so this might not be relevant, but rebase uses file-ids and not paths - so I don't think it will help | 22:26 |
| NfNitLoop | you deleted files in r2, then readded them in r3? | 22:27 |
| lamalex | is there a bzr log flag to just show what files changed and not the diff? | 22:29 |
| lamalex | i guess like a diffstat | 22:29 |
| lamalex | NfNitLoop: i think that's what happened in the revs i'm trying to fix | 22:30 |
| lifeless | bzr log -v ? | 22:30 |
| lamalex | lifeless: yes, wow thank you | 22:30 |
| lamalex | so simple | 22:30 |
| lamalex | so am i just totally fscked? | 22:33 |
| NfNitLoop | well, you have history up to 3 revisions ago. | 22:33 |
| NfNitLoop | you can always get your tree before it got all mucked up. | 22:33 |
| NfNitLoop | and a tree after the fact. | 22:34 |
| NfNitLoop | and do a manual merge. | 22:34 |
| NfNitLoop | if you're on linux, I recommend 'meld'. :) | 22:34 |
| lamalex | that's essentially being totally fscked | 22:34 |
| NfNitLoop | why's that? | 22:35 |
| lamalex | because that's a lot of work, more work than not fixing this issue and merging the branch that is the reason im trying to fix this manually | 22:36 |
| lamalex | which is also a lot of work | 22:36 |
| lamalex | but less than this | 22:36 |
| lamalex | hmm.. when I merge my top part of the tree, the ones after it got mucked, it basically deletes EVERYTHING | 22:38 |
| NfNitLoop | well, if you've made so many changes to the source tree in one revision that the one prior can't be cleanly reverse-merged... | 22:38 |
| lamalex | why the hell would it be doing that | 22:38 |
| NfNitLoop | then, yeah, you're out of luck. | 22:38 |
| NfNitLoop | but that's the case with any SCM. | 22:38 |
| NfNitLoop | "merge the top part of your tree"? | 22:39 |
| lamalex | the commits after the botched ones im trying to fix | 22:41 |
| lamalex | tree looks like this: 1---630 | 631, 632 | -- HEAD | 22:41 |
| lamalex | I want to cut out 631, 632 and replace them with a commit that effecively does the same thing | 22:42 |
| lamalex | but does it sanely, at 632 the tree would look the same, only have a slightly different history | 22:42 |
| lamalex | s/at 632/after 632 | 22:42 |
| NfNitLoop | so you're trying to change the history, but leave the file contents as-is? | 22:43 |
| lamalex | effectively | 22:43 |
| NfNitLoop | OH. that's not what I was understanding earlier. | 22:44 |
| NfNitLoop | Hrmm. | 22:44 |
| NfNitLoop | Oh, but in 631 you removed some files, and in 632 you re-added them? | 22:44 |
| lamalex | In 631 a bunch of files were added, I actually have no idea how they were added, probably via some weird script RAOF wrote. They're basically copies of some other files with the same minor change to each one | 22:45 |
| lamalex | then in 632 the old ones were removed | 22:45 |
| NfNitLoop | That sounds fine. WHy are you trying to rewrite history? | 22:46 |
| lamalex | so what should have been a bzr mv, edit, commit was something like copy, edit, commit, remove | 22:46 |
| NfNitLoop | right. | 22:46 |
| NfNitLoop | It's total SCM fail. | 22:46 |
| NfNitLoop | but, it's done. | 22:46 |
| lamalex | right, and im trying to find a way t fix it | 22:46 |
| dash | NfNitLoop: but now he needs to merge | 22:47 |
| NfNitLoop | aha. | 22:47 |
| NfNitLoop | So, yes, to fix it, you're going to have to do it the right way. | 22:47 |
| NfNitLoop | create a branch at r630. | 22:47 |
| NfNitLoop | write a script to do the renames. | 22:47 |
| NfNitLoop | via bzr. | 22:47 |
| lamalex | right, this is easy | 22:47 |
| NfNitLoop | and then do a cp -r to copy the new changes on top of them. | 22:47 |
| NfNitLoop | and commit. | 22:47 |
| lamalex | wait, cp -r to what? | 22:48 |
| NfNitLoop | then throw away the broken branch and shoot the idiot that caused that issue. :p | 22:48 |
| NfNitLoop | so, say you've got broken_head/ | 22:48 |
| NfNitLoop | bzr branch broken_head fixing -r 630 | 22:48 |
| lifeless | NfNitLoop: you know we have a heuristic now? | 22:48 |
| NfNitLoop | lifeless: a wha? | 22:48 |
| NfNitLoop | lamalex: cd into fixing/ and run your script to do bzr mv commands. | 22:49 |
| lifeless | 'bzr mv --auto' | 22:49 |
| lifeless | lamalex: heres what I suggest: | 22:49 |
| NfNitLoop | lifeless: Oh, nice! | 22:49 |
| NfNitLoop | <3 you guys. :D | 22:49 |
| lamalex | lifeless: that's cool to know | 22:50 |
| lifeless | bzr branch -r 630 foo bar | 22:50 |
| lifeless | bzr diff -r 630..632 foo | patch -p0 | 22:50 |
| lifeless | bzr mv --auto | 22:50 |
| NfNitLoop | hot! | 22:50 |
| lifeless | poke around, it should be right | 22:50 |
| lifeless | bzr commit | 22:50 |
| lifeless | bzr replay -r 631.. foo | 22:51 |
| lifeless | erm actuallly the last one will fail | 22:51 |
| lamalex | where does replay come from? | 22:51 |
| lifeless | so just manually (bzr diff -c 632 | patch -p0), repeat | 22:51 |
| lifeless | commit | 22:51 |
| lifeless | diff -c ... | 22:51 |
| lifeless | through any remaining commits | 22:51 |
| garyvdm | lamalex: bzr-rebase plugin | 22:51 |
| lamalex | ah, is there a version that works with 1.16? | 22:52 |
| lamalex | the one in the jaunty repo doesn't | 22:52 |
| NfNitLoop | lifeless: he's saying to do diff | patch, anyway. | 22:52 |
| NfNitLoop | so you don't need replay. | 22:52 |
| lifeless | lamalex: ^^ | 22:52 |
| lamalex | lifeless: so i need to bzr diff -c N for each rev until HEAD? | 22:53 |
| lifeless | lamalex: bzr diff -c N | patch -p0; commit | 22:54 |
| lifeless | lamalex: and yes, for 632, 633 etc | 22:54 |
| lamalex | lifeless: so i branch -r 630 foo bar | 22:56 |
| lamalex | do my renames | 22:56 |
| lamalex | i need to give bzr diff a --old dont I? | 22:56 |
| lifeless | lamalex: no | 22:57 |
| lifeless | to do the renames do | 22:57 |
| lifeless | bzr diff -r 630..632 old | patch -p0 ; bzr mv --auto | 22:58 |
| lifeless | that should pick them all up for you | 22:58 |
| lamalex | lifeless: so i dont branch foo bar? | 22:58 |
| lifeless | you do | 22:58 |
| lifeless | I skipped that step :P | 22:59 |
| lamalex | right, so do i have to do the renames that way? | 22:59 |
| NfNitLoop | the diff|patch does the renames. | 22:59 |
| lamalex | i already have a bash line in my history that does the renames | 22:59 |
| NfNitLoop | actually, the diff|patch will re-move the files... | 22:59 |
| lifeless | lamalex: it does the renames and the first change | 22:59 |
| NfNitLoop | but before you commit, you do: bzr mv --auto | 22:59 |
| NfNitLoop | which does the renames automatically. | 22:59 |
| RenatoSilva | verterok: about what I said: "a note about my stacked branch: the encoding comes as cp1252 (not static utf-8 anymore ok) but the data as cp850"... | 23:00 |
| RenatoSilva | verterok: it is calling osutils.get_user_encoding() instead of bzrlib.user_encoding | 23:00 |
| verterok | RenatoSilva: ok, osutils.get_user_encoding is the preffered way, bzrlib.user_encoding is deprecated | 23:01 |
| lifeless | http://pastebin.com/m5fdf57c1 | 23:01 |
| verterok | RenatoSilva: the xmlrpc service handle that, so it should use utf-8 | 23:01 |
| RenatoSilva | verterok: really? then all the other code generating xml needs to change , xmllog is the only using osutils.get_user_encoding(). | 23:02 |
| lifeless | verterok: you probably *don't* want to autodetect user encoding though, if you want to specify always-utf8-output | 23:02 |
| lamalex | lifeless: all of those bzr diff commands will fail | 23:02 |
| lifeless | lamalex: why? | 23:02 |
| lamalex | you dont hvae a 63X in your tree | 23:02 |
| lamalex | you branched at 630 | 23:02 |
| lifeless | argh | 23:03 |
| lifeless | I missed the path | 23:03 |
| NfNitLoop | lamalex: he means bzr diff t"damaged" | 23:03 |
| verterok | RenatoSilva: probably :) | 23:03 |
| NfNitLoop | or, ../damaged | 23:03 |
| lifeless | http://pastebin.com/m1084f4e | 23:03 |
| RenatoSilva | verterok: but notice that osutils.get_user_encoding() is returning cp1252, but xmllog is returning cp850 data (from terminal) | 23:04 |
| verterok | lifeless: xmloutput don't detect encoding, it's actually hack, but it set the osutils,_cached_user_encoding ;) | 23:04 |
| RenatoSilva | verterok: this makes the xml document invalid | 23:04 |
| verterok | RenatoSilva: in the terminal, the encoding is detected | 23:04 |
| verterok | RenatoSilva: only in the xmlrpc service is forced to utf-8 | 23:04 |
| RenatoSilva | verterok: I'm running manually, no xml-rpc | 23:04 |
| lifeless | RenatoSilva: thats really bad :( | 23:04 |
| lifeless | sorry | 23:05 |
| lifeless | verterok: ^^ | 23:05 |
| lifeless | because, your service is unfriendly to other bits of bzr that way | 23:05 |
| verterok | lifeless: yes, as the xmlrpc is running commands and processing the output | 23:05 |
| verterok | lifeless: my idea is to move out from executing commands over the xmlrpc service, and instead publish real xmlrpc methods | 23:06 |
| RenatoSilva | verterok: I open a terminal, which is cp850, then I run bzr xmllog, then I get a preamble <?xml [..] encoding="cp1252"?>, however the whole output itself is cp850... | 23:06 |
| verterok | RenatoSilva: xmllog don't fiddle with encoding, only the xmlrpc service | 23:06 |
| verterok | lifeless: the only *real* xmlrpc methods published ATM is search | 23:07 |
| lifeless | verterok: heheheh | 23:07 |
| verterok | lifeless: and the one bzr-eclipse uses is run_bzr_xml | 23:07 |
| RenatoSilva | verterok: even if you put cp850 in preamble, it seems that cp850 is an invalid value for an XML document, that is, you need to ensure that any detected charset has a compatible name. In my case, the preamble could declare cp850, it would be still an invalid XML documet anyway (I can't open it with the browser). | 23:07 |
| verterok | RenatoSilva: Firefox? or IE? | 23:08 |
| verterok | lifeless: run_bzr_xml is a wrapper around commands.run_bzr that returns xml version of the exception in case of error | 23:09 |
| verterok | lifeless: that's the main issue with the xmlrpc service, we need to move it to pure methods :) | 23:09 |
| lifeless | verterok: so arguably the bug is that this variable is global state and not a Command attribute? | 23:09 |
| verterok | lifeless: I don't think so, in this case RenatoSilva is executing from the terminal, and xmllog uses the info provided by bzr, maybe something is wrong with the way encoding is used or detected in xmllog | 23:10 |
| verterok | lifeless: the only place that xmloutput changes global state is the xmlrpc service started with: bzr start-xmlrpc | 23:11 |
| lifeless | verterok: but RenatoSilva is doing this to test for bzr-eclipse, which does use the service ;) | 23:11 |
| verterok | lifeless: yes, but now he is testing in the terminal | 23:11 |
| verterok | RenatoSilva: ? | 23:11 |
| verterok | ^ right? | 23:12 |
| lifeless | so I'm saying that encoding results in the terminal don't help testing what the service does ; ) | 23:12 |
| verterok | :) | 23:13 |
| RenatoSilva | verterok: a monet pelase... | 23:13 |
| verterok | lifeless: for testing the service, besides the small tests, there is an example of a python xmlrpc client ;) | 23:14 |
| * verterok need to write more tests | 23:14 | |
| RenatoSilva | verterok: reading... | 23:14 |
| lamalex | wonderful, some of this involves binary files | 23:14 |
| RenatoSilva | verterok: xmllog don't fiddle with encoding, only the xmlrpc service --> it is responsible too as it declares a preamble :) | 23:15 |
| lifeless | lamalex: urggle. Many? | 23:15 |
| verterok | RenatoSilva: yes, but XMLLogFormatter is using osutils.get_user_encoding() to set the encoding in the preamble | 23:17 |
| verterok | RenatoSilva: and looks like isn't encoding the output :) | 23:18 |
| lamalex | lifeless: not sure honestly, ill figure it out though | 23:18 |
| RenatoSilva | verterok: IE says cp850 is invalid, FF ignores it and tries to decode as latin-1. | 23:19 |
| RenatoSilva | verterok: ... | 23:19 |
| verterok | RenatoSilva: ok, thanks | 23:20 |
| verterok | RenatoSilva: I think the problem is that the message in the CDATA isn't encoded explicitly | 23:20 |
| RenatoSilva | verterok: yes I'm testing in terminal, no xml-rpc! | 23:22 |
| RenatoSilva | s/monet/moment | 23:23 |
| verterok | RenatoSilva: would you try this patch? http://bazaar.pastebin.com/m2ec81e83 | 23:24 |
| RenatoSilva | verterok: es, but XMLLogFormatter is using osutils.get_user_encoding() to set the encoding in the preamble ---> either it should encode data with get_ser_encoding(), it it should put the current encoding (terminal) in the preamble | 23:25 |
| lamalex | lifeless: mwhudson: NfNitLoop: thanks so much for your help | 23:25 |
| RenatoSilva | verterok: in the latter case if would break the XML in my case anyway.... | 23:25 |
| verterok | RenatoSilva: right | 23:25 |
| mwhudson | lamalex: np, did you get somewhere in the end? work distracted me | 23:25 |
| lamalex | mwhudson: yah, lifeless helped me solve it | 23:26 |
| lamalex | not full-auto | 23:26 |
| RenatoSilva | s/it it/or it | 23:26 |
| mwhudson | cool | 23:26 |
| lamalex | but semi | 23:26 |
| RenatoSilva | verterok: about the patch, actually it's line 169 | 23:35 |
| RenatoSilva | verterok: I get an UnicodeDecodeError | 23:35 |
| RenatoSilva | verterok: non-ascii chars in the message, to check encoding behavior | 23:36 |
| verterok | RenatoSilva: ok, that's what I wanted to know | 23:37 |
| RenatoSilva | verterok: sorry, IE says it does not support *cp1252* | 23:38 |
| RenatoSilva | verterok: how about this... | 23:39 |
| verterok | RenatoSilva: I don't know how much this is going break (don't know how many people is using xmloutput via the cli), but we could do the "always utf-8" encoding for all commands | 23:39 |
| verterok | ar at least add a --encoding arg to all xmlcommands | 23:39 |
| verterok | *or | 23:39 |
| verterok | so the user can specify what encoding to use, but use utf-8 by default | 23:39 |
| RenatoSilva | verterok: how about this patch: http://pastie.org/539361 | 23:41 |
| verterok | RenatoSilva: that's the terminal encoding right? | 23:42 |
| RenatoSilva | verterok: IE deals with cp850 correctly, but FF does not. No error is raised, but it thinks it's a latin-1 XML, ignoring the preamble. | 23:42 |
| RenatoSilva | verterok: not necessarily, it's the same encoding of the place where I'm writing | 23:43 |
| verterok | RenatoSilva: if this works on windows, I'm ok with it :) | 23:44 |
| garyvdm | I want to define 2 classes with the same name for a test. Is there a way to have a sub module in the same file in python ? | 23:45 |
| RenatoSilva | verterok: data destination is to_file, and I'm guessing to_file.write is using to_file.encoding | 23:45 |
| dash | no | 23:45 |
| dash | why should they have the same name? | 23:45 |
| verterok | RenatoSilva: I think so | 23:46 |
| garyvdm | dash: I' | 23:46 |
| garyvdm | dash: I'm testing the decorating of commands. | 23:46 |
| garyvdm | and the command registory get the name of a command from class.__name__ | 23:47 |
| RenatoSilva | verterok: well it is right? even if you overwrite to_file with codecs.getwriter, such a writer will set encoding prpoperty porperly, right? The only exception if if you put a dog acting a a duck, I mean, you change to_file with a self class containing a write method, but I don't think you have stuff like this in the code, I guess :) | 23:48 |
| verterok | RenatoSilva: yes :) | 23:48 |
| RenatoSilva | s/if if/is if | 23:49 |
| RenatoSilva | s/prpo/prop | 23:49 |
| RenatoSilva | s/a a/as a, sorry! | 23:49 |
| RenatoSilva | verterok: yes you have, or yes you don't? :) | 23:50 |
| verterok | RenatoSilva: yes, xmloutput don't have such code :) | 23:50 |
| RenatoSilva | verterok: ok then I think the patch is fine | 23:51 |
| RenatoSilva | verterok: the problem with trying to always use utf-8 in preamble is that you have to ensure that the data will also be the same, and I can't figure out a way to make to_file behave like this. If you use codecs.getwriter, then it will fail when receiving str objects. AFAIK to_file is provided by the super class from bzrlib, and as such other "guys" may be writing str objects to the file... | 23:56 |
| RenatoSilva | verterok: out of xmloutput control | 23:56 |
| verterok | RenatoSilva: yes, it's a but tricky, I think that using your patch would solve the terminal issues, regarding the xmlrpc service, I think using the encoding specified in start-xmlrpc (once de patch lands in trunk) should solve the issues with bzr-java-lib (plus your patch) | 23:58 |
| garyvdm | For tests, is it ok to call self.addCleanup from setUp? | 23:58 |
| verterok | RenatoSilva: if someone is writting bad data to the to_file, I'ld say that's a bug :) | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!