[00:07] hey poolie [00:07] hi maxb [00:07] hello [00:11] hi jelmer, maxb [00:49] thanks for the reviews jelmer [00:52] jelmer: if you're still aroud [00:52] jelmer: can we talk about geoffs patch ? [00:54] lifeless: sure [00:55] so, he put that patch together based on a description of what I wanted in loggerhead [00:55] I'm worried that its being parleyed into a bigger, different change. [00:55] I don't think loggerhead should need to know about doing iter_tree_entries etc for the export. [00:56] lifeless: I'd prefer to change this to be more flexible for other callers as well if we're going to change it, and both options seem to be roughly equally trivial [00:57] jelmer: the implementation you suggested doesn't meet loggerheads needs [00:57] lifeless: what's the context? [00:57] jelmer: we need a generator [00:58] to let us return control to the wsgi framework [00:59] lifeless: but you're not actually going to stream the data, just send it all in a bulk at the end? [00:59] we are streaming [00:59] lifeless: the generator still takes a tarball argument, and adds the data there as well [00:59] I would like it if geoffs patch were evaluated directly on its impact on bzrlib: is it sufficiently tested, will it decrease performance, or make things be structured badly. [01:00] jelmer: that doesn't matter. [01:00] jelmer: loggerheads tarball object is mapped to a file object that accumulates the bytes in a buffer; when each yield occurs the accumulated bytes are handed off to the wsgi stack [01:05] Good morning. [01:07] special mailing list post of the day: [01:10] lifeless: that seems more complicated than just iterating over the items and files and writing out item.tobuf() + file.read() [01:10] jelmer: that would a) not work with zip files, b) not stream. [01:11] lifeless: this function doesn't work with zip files anyway [01:11] but the structure will [01:11] lifeless: both ways stream per file [01:11] shrug [01:11] I don't really want to overdesign this [01:11] I don't want geoff blocked on something that makes it harder for him or loggerhead [01:11] and he is right now [01:12] if the design is poor, we should ask him to fix it [01:12] anyway, I haven't voted on this, and I don't feel strongly about it. I was just saying it seemed simpler to factor out the body of the loop, rather than creating a generator which makes things more complex imho [01:12] but you seem to want to solve different problems [01:12] jelmer: it requires a generator [01:12] _requires_ [01:13] that generator can be in loggerhead [01:13] and just be a three line loop [01:14] jelmer: Well, that won't work for .zip files (which folk will want), because they don't have the same output model [01:14] I don't think it makes sense to make the loggerhead code simpler for tarballs at the cost of needing two codepaths in loggerhead for zip/tarballs [01:15] IIRC zipfiles in Python don't stream anyway [01:16] zipf.writestr(zinfo, content) [01:16] is the per-file stuff [01:16] so, it needs a similar tweak to permit this in loggerhead for zip files [01:16] I think writing to the file is simple and clear [01:17] we can have the same contract for both generators, both live in bzrlib.export.*, and one driver for adapting them to wsgi streaming [01:17] if we have /any/ tar specific code in loggerhead that won't work. [01:17] which is what I don't like about your proposal [01:17] mgz: win [01:18] mgz: I presume you know about the great regex mistake ? [01:20] I thought you'd appreciate that lifeless :) [01:21] lifeless: I don't see how that helps; ZipFile's constructor requires a filename or seekable file object [01:22] jelmer: we manage to export to stdout [01:22] * jelmer gets some sleep [01:22] jelmer: which is nonrewindable [01:22] lifeless: charis:~/src/bzr/bzr.dev% bzr export --format=zip - [01:22] bzr: ERROR: [Errno 29] Illegal seek [01:23] ah! ok, so bugs to fix there. [01:23] still, i think making the contract be tied to tar would be a mistake [01:23] sleep well [01:23] the zipfile module is pretty useless unfortunately [01:23] it's been multiply threatened with a rewrite that's never arrived [01:24] we have/had a fixed copy [01:24] bbiab, grocery shopping needs doing [01:25] I think one of the problems is that the zip file format requires the compressed/uncompressed sizes to be known up front [01:25] anyway, really gone now.. :) [01:26] hm, really? I thought the header was minimal and everything that mattered was in the tail. [01:27] hence the gif/zip hacks. [01:27] yeah, you're right [01:27] wikipedia confused me because it still calls them headers [01:28] beheaded headers [01:28] they're severed and placed in a basket at the end === smoser` is now known as smoser === tchan1 is now known as tchan [06:32] i'm converting all my old repos to bzr and while doing it i just wanted to put one old project under bzr (no conversion from some other DVCS), but bzr failed with: http://pastebin.com/Jtt4HtAP [06:52] i've found it as https://bugs.launchpad.net/bzr-diffstat/+bug/56680 [06:52] Ubuntu bug 56680 in Bazaar Diffstat Plugin "uncaught exception: bzr: ERROR: exceptions.UnicodeDecodeError:" [High,Confirmed] [06:53] and it's more than 4yrs ago since it's reported...it would be cool to fix it before 2.4 [06:55] another one is https://bugs.launchpad.net/bzr-submit/+bug/67973 [06:55] Ubuntu bug 67973 in Bazaar Submit By Mail Plugin "exceptions.UnicodeDecodeError" [Medium,Fix committed] [07:02] the most recent activity in regard to this problem seems to be https://bugs.launchpad.net/bzr-explorer/+bug/735349 [07:02] Ubuntu bug 735349 in Bazaar Explorer "UnicodeError while converting BzrError to unicode" [High,Confirmed] [07:32] does anyone know if launchpad will be getting a wiki? [07:32] cause ive been contributing to a project on github and its a much nicer site :< [07:34] AuroraBorealis: there is discussiion about it atm [07:35] hmm [07:35] AuroraBorealis: check https://bugs.launchpad.net/launchpad/+bug/240067 [07:35] Ubuntu bug 240067 in Launchpad itself "Launchpad projects need wikis" [Low,In progress] [07:37] i think its a bit more then low priority =/ [07:38] AuroraBorealis: note that that the 'launchpad' project only really uses Critical, High, and Low. https://dev.launchpad.net/BugTriage#Importance [07:38] this is certainly one of the features i really miss in LP, but i prefer bzr much more than git [07:39] ..which i simply cannot stand [07:39] i even use bzr-git for fetching github projects [07:39] AuroraBorealis: low means it isn't being worked on by lp devs [07:40] i see [07:40] AuroraBorealis: I'd like to see LP get a wiki... [07:40] but I keep spending time writing other stuff [07:40] perhaps I'll instigate my own 20% time [07:40] cause my projects on launchpad just seem confusing compared to github [07:41] I'm not sure adding a large complex feature to Launchpad will automatically reduce that confusion :) [07:42] I agree a wiki for projects would be nice. [07:43] i feel the entire website needs to be revamped hehe [07:43] but a wiki just seems like another tab [07:48] also i'm confused on the little history graph things launchpad branches have [07:48] https://launchpad.net/inkscape for example, does it go up then right? [07:50] AuroraBorealis: does the larger view at https://launchpad.net/inkscape/+series make it clearer? [07:51] so it seems like 'trunk' is the vertical line [07:51] and they keep branching off [07:51] Or for comparison, https://launchpad.net/bzr/+series [07:52] but am i right that it seems the main trunk branch is on the left? [07:52] The bzr example is a bit more interesting perhaps because you can see the dates of releases from different series overlapping. [07:52] It's not a graph of branches or revision history. [07:53] so its just a graph of versions? [07:53] or 'series' [07:53] It's a visualisation of release series and their milestones. [07:53] ah. k [07:53] so i take it launchpad doesn't have a graph of revisions [07:55] Someone really ought to integrate one into loggerhead. You can browse the revision history by following the “Browse the code” link on e.g. https://launchpad.net/inkscape [07:56] It doesn't yet do the sorts of pretty graphs you get with bzr GUIs like 'bzr qlog', but I'm sure someone will do one for it eventually. [07:56] which take like 5 clicks to get to [07:56] Which do? [07:56] to get to the link to 'view all revisions' hehe [07:56] and yeah i was just using github to contribute to some project and i liked their revision graph [07:56] I count 2 clicks. [07:57] From https://launchpad.net/inkscape click “Browse the code”, from there click “view branch changes” [07:57] ah that. i clicked code at the top [07:58] Yes, it's a nice graph. Fortunately you can get the same thing in a local GUI via 'bzr qlog' (qbzr plugin) or 'bzr viz' (bzr-gtk plugin). [07:58] yeah i use bzr explorer which i think has qlog in there [07:58] https://github.com/sr/git-wiki/network is sweet :> [07:58] Which isn't quite as convenient as having it in a web page, but it's good enough for me at least. [08:01] yeah [08:07] geez branching the bzr source is taking forever xD [08:12] Have you done "bzr lp-login"? [08:12] i have not [08:12] is that why its taking forever? [08:14] AuroraBorealis: yes [08:14] AuroraBorealis: it'll be going over http [08:14] AuroraBorealis: instead of the bzr+ssh protocol [08:14] doh [08:14] well i'll do that after it finishes [08:16] does it not need my password? [08:16] AuroraBorealis: it needs an ssh key on LP [08:16] yeah i have that [08:16] then you're good [08:16] but i just typed launchpad-login and it didnt output anything === AuroraBorealis is now known as aurora|game [08:19] it seems to be working. thanks =) [08:22] aurora|game: have you tried github's bug tracker? [08:22] * gour grins :-) [08:47] sorry gour , no i have not, is it crappy? [08:49] AuroraBorealis_: i'd say, yes [08:49] it cannot compare with LP's features [08:50] haha [08:50] cool. [08:51] im just experimenting with a lot of stuff. I like bzr cuase i can host my private code (stuff for school) on my own server and stuff [09:00] AuroraBorealis_: i used darcs for many years, tried hg, touched git, played with monotone and recently used fossil, but now i'm moving to bzr which is simply the most intuitive & complete dvcs ("..for human being.") [09:04] hehe [09:04] yeah, i like it [09:05] plus its python, git seems to be very linux centric. [09:05] darcs was(is) great tool, but it does not have LP or any similar, even less featured, public hosting solution [09:05] never heard of darcs [09:06] git looks to me as a big hack, without real design behind it...monotone is nicely designed, but it's niche [09:06] i installed git [09:06] and it installed a shitty ssh.exe to my path which screwed up bazaar [09:06] AuroraBorealis_: http://darcs.net/ it has patch theory and it's quite different and very intuitive [09:06] bzr is 'sweet spot' [09:07] yeah =) === AuroraBorealis_ is now known as AuroraBorealis [09:45] gour: still there? [09:45] gour: those two bugs you mentioned are unrelated to the issue you're seeing [09:46] jelmer: yeah, i'm here [09:47] hmm [09:47] last one is relevant? [09:47] gour: they're indeed UnicodeDecodeError tracebacks too, but raised from a different location [09:47] gour: the bzr-explorer one? [09:48] yes [09:50] so, it looks all are from different locations, but same symptoms [09:54] * gour was pointed at the right one - https://bugs.launchpad.net/bzr-explorer/+bug/735349 [09:54] Ubuntu bug 735349 in Bazaar Explorer "UnicodeError while converting BzrError to unicode" [High,Confirmed] [09:55] ahh...wrong one [09:55] this one is correct: https://bugs.launchpad.net/bzr/+bug/715547 [09:55] Ubuntu bug 715547 in Bazaar ""bzr add" crashed ERROR: exceptions.UnicodeDecodeError" [Medium,Confirmed] === zyga-afk is now known as zyga [10:31] maxb: around? [10:31] 'morning spiv [10:34] Good evening jelmer :) [10:53] seeing that SF has support for web pages and wiki, i wonder what do you think about LP vs SF for hosting projects under bzr? [10:54] Depends on what your project needs. You can always use both of course! [10:54] I find the SF bug tracker to be much, much worse than LP's. [10:56] problem is that LP does not have neither space for web page nor wiki [10:56] Not only that, it doesn't even provide CVS. [10:57] Sure. [10:58] i do not worry for lack of CVS :-) [10:58] It is an issue for many projects. Some are small enough that a link in the project description to the contents of the README file in bzr is plenty, and some are large enough that they have their own website anyway. But there's a big set of stuff in between those that want that sort of feature, and LP doesn't yet cater well to that. [10:58] but LP is the only one from {github,bitbucket, google,sf,lp} missing wikis [10:59] Sure. We know. [11:00] Pretty much everyone thinks LP should have them too, including the LP dev team I think :) [11:00] and the 'bug' is quite old already [11:01] Right. The paid LP devs are already pretty busy with other work: [11:01] But if someone were to help write the necessary bits I'm sure it'd be welcomed! [11:02] lack of wiki is turning many people to 'competition' which is sad [11:02] It would be nice to have, but getting free or cheap webhosting elsewhere for those bits isn't too hard, so I understand why it isn't an urgent priority for the LP team. [11:03] Is it? [11:04] i believe it is...having code on one site, tracker on another, wiki on the 3rd...not pretty [11:04] considering that other hostings have all-in-one [11:04] {github,bitbucket, google,sf} probably support wiki with a good reason ;) [11:08] wiki != webhosting fwiw [11:08] lifeless: i'd be satisfied with just having wiki on LP [11:09] well, its getting specced at the moment [11:09] its still ill defined what that actually means [11:09] even just to render sphinx-generated pages [11:10] lifeless: why don't you inspect what's offered at {github,bitbucket, google,sf} instead of reinventing the wheel [11:10] gour: uhm, we have and are? [11:10] gour: what makes you think that's not happening? [11:10] gour: they all have quite different offerings [11:11] gour: and none of those commercial, proprietary services have been kind enough to share their user and market needs analysis with us. [11:12] the point is the many people/projects would like to have wiki, that's why {github,bitbucket, google,sf} have it...it's only question to adjust to the LP [11:12] here i'd say that "even blind uncle" applies [11:12] gour: if it's that easy, then please go ahead and do it! [11:12] gour: it's open source, and patches are certainly welcome. [11:13] it's not that the rest of LP is perfect in the 1.0 release [11:13] spiv: i do not have neither required skills nor time to work on it...wikkid is a project launched for that purpose, afaik [11:14] gour: Ok. Apparently no-one else has had the skills and time yet either, though. [11:14] * gour is thankful to have free LP, but lack of wiki might move me to SF [11:15] Which, as one of those people who also lacks the time, I completely understand! [11:15] spiv: pls. don't think i am criticizing LP...just want to improve it...because, let's face it - less LP customers also means less bzr ones [11:15] gour: we want it, but we want it done well. Getting a free wiki with links to it from LP is -dead- easy - heck we even model links to the wiki in LP today. [11:16] I note that when I put a project on SF, I don't think it had any wiki support. And I think it's had 3 different wiki generations since then. [11:16] i strongly believe github is not popular just because of git [11:17] gour: I agree, github does many things quite well [11:17] fullermd: how are you satisfied with SF & bzr? [11:17] Well, I've never yet used bzr on SF. My project there is in CVS :p [11:18] we're not short on desire, we're short on elbow grease; doing a system that will run 20K wikis with no page renders over 5 seconds and 99% under 1 second, no single points of failure and embeddable in the same domain [so entirely xss free] is -nontrivial- [11:18] spiv: Now I am [11:18] Their docs on bzr aren't seemingly maintained at all. Last I looked, they still said they support bzr 1.10, when it was easy to tell they were running 2.1 or 2.2. [11:18] maxb: oh hey, I was just having a temporary thinko with the kde-l10n-* command [11:19] maxb: it's requeued now, although I see kde-l10n-th has developed a new and interesting failure [11:19] Perhaps an empty bzrdir on LP or something as a remnant of the previous failures? [11:20] * maxb looks at kde-l10n-th and thinks "WTF!?" [11:21] according to wikipedia, github was launched in feb 2008, and wiki 'bug' at LP is from june same year [11:21] maxb: previous line in log is about opening the working tree for kde-l10n-th/karmic-backports [11:22] gour: yes, the desire has been around a while [11:22] gour: I'm really not sure what your point is? LP does many things github doesn't, like PPAs [11:23] gour: because while they may have overlapping goals, they also have differing ones too, and accordingly differing priorities. [11:23] spiv: aren't PPAs rlevant only for Ubuntu? [11:23] gour: they're pretty relevant to where the LP dev spend their time as well :) [11:23] spiv: maybe only to change priority from Low :-) [11:24] gour: see https://dev.launchpad.net/BugTriage#Importance [11:25] gour: low is accurate: we're not going to try and make this happen using paid developers in the next 6 months. And as priorities change, we don't try and assess priorities more than 6 months out. [11:25] spiv: Low - We mark as Low any bug that we recognise as legitimate but that we have no plans to fix. [11:25] gour: right — and the paid LP team doesn't plan more than 6 months in advance. [11:26] (Not in this sense, at least) [11:26] hmm, I think thats confusing [11:26] so I will edit [11:27] and it's already 3years...the whole point, and here i can stop from my side, is that lack of wiki at LP causes harm to the LP & bzr since people/projects needing one go to {bb,github.sf, google}... [11:28] * gour is researching about SF now... [11:28] gour: sure, but so do all the other bugs and missing features of LP [11:28] gour: and so far it's been the opinion that those are even more important to address using the finite resources available [11:29] Your opinion is obviously different, but stating it here isn't going to change matters. [11:29] one of the first hits - http://amanica.blogspot.com/2011/05/bazaar-on-sourceforgenet.html [11:30] spiv: i'm aware of it and won't discuss it any longer [11:30] You could try to advocate for it on the launchpad-dev list perhaps. If you present evidence that it really is a huge factor in driving potential users away that would be useful I think. [11:42] maxb: those kde-l10n-* are failing due to branches on LP that are just empty directories, not even a .bzr dir. I guess we try deleting them from LP and requeuing. [11:42] why bzr over git? [11:43] git is faster? I mean whats a killer feature? [11:43] Many people find it nicer to use. [11:43] an example? [11:49] poolie: I still can't access jubany, what's the rt URL to complain on? [11:49] EM03: git help log vs. bzr help log ;) [11:49] hehehe [11:50] i know git very well and its quick just curious why one would choose bzr [11:50] "it's for human being" [11:50] can i have an example were thats true? [11:50] (not saying it isn't) [11:51] i'm spoild by darcs ui, and bzr is quite pleasant to use...with git one has to think too much about the tool [11:51] git's ui, model... [11:51] EM03: have you tried monotone? [11:53] e.g. i tried to become power user of orgmode, but it required too much time...otoh, taskwarrior was so intuitive...same with git vs. bzr [11:53] EM03: otoh, if you like git, be free to continue with it ;) [11:53] spiv: Right - if only all the failures were that easy :-) [11:54] gour: not that I'm in love with it just want to see se bzr is better :P [11:56] EM03: just try to use it for some time and don't think that some extra ms are worth the effort to think how to avoid shooting one's own feet ;) [11:56] oh gour , you make it sound so easy [11:56] EM03: on which platform you are? [11:57] EM03: http://doc.bazaar.canonical.com/bzr.dev/en/mini-tutorial/index.html [11:58] and http://doc.bazaar.canonical.com/bzr.dev/en/tutorials/tutorial.html [11:58] * gour was playing with bzr when changing the format was the rule :_) [11:58] maxb: still failing; but updated [11:58] s/but/bug/ [11:59] "There is already a branch merge proposal registered for branch lp:~ubuntu-branches/ubuntu/hardy/kde-l10n-th/hardy-201106020937 to land on lp:ubuntu/hardy/kde-l10n-th that is still active." [12:00] gour: we still seem to have that image, while in fact the last change of the default format was quite some time ago (2 years?) [12:02] jelmer: yeah, labelling is hard..just ask lightttpd guy about memory leaks [12:02] *guys [12:03] Funnily enough, every time I use monotone, I get another round of "sorry, I can't do anything until you 'mtn db migrate' to update the database structure". [12:03] i'm also tired about git's tspeed-talk as it's the only relevant feature of dvcs [12:03] tspeed-talk? [12:03] speed-talk [12:04] fullermd: heh, foosil borrowed some stuff from mtn [12:04] *fossil [12:04] Well, in fairness to git, there are some applications where I'd rather use bzr, but am compelled to use git for the performance [12:04] * gour cannot type properly... :-/ [12:04] maxb: you know jam will fix those :) [12:04] * gour does not work on kernel-sized projects ==> no need for git [12:05] * maxb is keeping the revprops tree of a Subversion repository with >1 million revisions in Git [12:05] bzr doesn't really like a tree with >1 million files and 1.9GB in size [12:06] maxb: hmmm, it should handle it [12:06] maxb: the dirstate would be sizable [12:06] It probably can handle it, but not quickly enough to be palatable for a human user [12:07] Even git is far from instantaneous on a tree that size [12:07] sure [12:07] file a bug ? [12:07] gnight all [12:09] A bug on "Performance on big trees does not compare favourably to Git" feels a bit like bug [12:09] A bug on "Performance on big trees does not compare favourably to Git" feels a bit like bug 1 [12:09] Launchpad bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1 [12:12] jelmer: You seem to have push --overwritten me in pkg-bazaar/bzr/2.4 :-/ [12:12] maxb: 'bzr takes 60 seconds to st a 1M file tree with hot cache' [12:12] maxb: you don't need to say git in there at all [12:12] fair enough [12:19] maxb: Yeah, sorry about that - I'd already done the merge locally too, with some additional changes and there weren't any other changes than the merge [12:20] I tried merging your branch, but I got conflicts on the generated files so I opted to --overwrite instead [12:33] Unfortunately those revisions are already merged into the beta-ppa branches [12:34] I guess I'll sort out a merge [12:38] maxb: sorry, I hadn't realized it was there as well === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell [15:47] hi guys [15:47] can anyone tell me how to start the freaking olive gui? i installed bzr-gtk which should be the package for olive [15:53] Not any more. Olive has been split from bzr-gtk and is now a wholly separate project [15:54] maxb: can i find it debain repos? [15:56] I am uncertain whether it has been packaged [15:56] I'd search on the BTS, but bugs.debian.org seems to be down right now [15:56] I'm pretty sure it's not packaged [15:57] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598703 [15:57] Debian bug 598703 in wnpp "RFP: olive-gtk -- Graphical frontend for Bazaar" [Wishlist,Open] [15:57] on the main page it says i can install it via leeny-backports [15:58] i tried to install bzr via squeeze backport and i don't think it installed any gui frontends [15:59] deni: it should install a olive-gtk executable in /usr/bin [16:00] jelmer: nope [16:00] also it can't find it in the repos [16:01] deni: it's there, see http://packages.debian.org/lenny/all/bzr-gtk/filelist [16:02] i hva the bzr-gtk package [16:02] ]don't know how to start that though [16:02] autocomplete says there is no olive or bzr-gtk app [16:03] deni: it's not in squeeze, you need the lenny package [16:06] jelmer: still not luck [16:06] meh [16:06] will try tomorrow [16:06] thank for your help [16:06] deni: see that page, it's definitely there in the lenny package [16:07] jelmer: ok, tnx [16:08] deni: that said, I'm not sure if it will work with newer versions of bzr, for example [16:08] you might have more luck just pulling down the source from lp:olive [16:11] jam: able to take another (hopefully final) look at https://code.launchpad.net/~jr/bzr/598572-zlib-error/+merge/62966 and https://code.launchpad.net/~jr/bzr/707274-commit-message-hook/+merge/62334 ? [16:34] hi Riddell [16:34] Riddell: It's ascension day here in .nl, IIRC John is away for the next couple of days [16:35] ah, religion leaving us without a patch pilot [16:40] hello i am testing a bzr oodifff plugin i get this error: http://pastie.org/2009130 [16:40] i cant fixed so i see is based in bzr api [16:40] any hits to fixed ? [16:40] fix it ? [16:43] its in your doc http://doc.bazaar.canonical.com/plugins/en/oodiff.html [16:45] Riddell: reviewed the zlib error MP [16:45] ovnicraft: hi [16:45] jelmer, hi [16:46] i see in that plugin is trying to use get_default_plugin_path() [16:47] jelmer, can you help me ? [16:59] jelmer_: what does it mean if you approve it in your review but the status is still Needs review? [17:06] Usually means the reviewer forgot that LP's review model has that distinction :-) [17:10] Riddell: what Max says, it means I'm stupid :) [17:10] groovy, I'll self approve === jelmer_ is now known as jelmer [17:16] hello i have this error with my oodiff plugin http://pastie.org/2009303 [17:17] bzr needs any explicit configuration with ASCII ? [17:17] ovnicraft: that looks like a bug in the plugin [17:17] ovnicraft: please file a bug against the bzr-oodiff project [17:18] hmm, it doesn't appear to have been touched since 2009 :-/ [17:18] jelmer, yes [17:18] Riddell: ooh, that builddeb hook is neat [17:18] and i want to support it [17:19] jelmer, method implemented is working now [17:20] jelmer, you can see the method http://paste.pocoo.org/show/399537/ [17:21] ovnicraft: I think you need to pass in plain strings to the diff function [17:22] the XML document probably contains unicode strings, which you'd have to encode (to utf-8, perhaps?) [17:22] so i need encode to utf-8 my files ? [17:23] no, in bzr-oodiff before you call text_differ(), you need to encode the strings you pass to it [17:25] from_text = [l.encode("utf-8") for l in from_text] [17:26] so with utf-8 files encoded is working ok [17:26] cool :) [17:27] now will apply your changes and see waht happen [17:27] what* === deryck is now known as deryck[lunch] [19:16] Hm. Here's a bit of a worrying one. Should bzr-svn ever eat a svn revision. [19:16] As in running svn log on trunk shows the revision yet bzr log doesn't. [19:17] dcoles: there's an open bug report about that - it's fixed in zbr-svn trunk [19:18] at least, if I think it's the issue I think you mean [19:18] Basically the svn revision appears invisible to bzr-svn (I can't -rsvn:# it) [19:19] It resulted in a rather interesting "Why did you revert my change. I didn't revert anything. You never made that change" *grin* [19:20] I'll try trunk. [19:21] dcoles: it's a race condition [19:21] dcoles: upgrading to trunk won't fix the earlier revision, but it will prevent the race in the future [19:33] Was that lp:515850 [19:33] Bug #515850 [19:33] Launchpad bug 515850 in Bazaar Subversion Plugin "Revisions added while a commit is happening are ignored" [High,Fix committed] https://launchpad.net/bugs/515850 [19:33] yep === gour1 is now known as gour === deryck[lunch] is now known as deryck === yofel_ is now known as yofel [21:06] I have been trying to setup a git clone of a bzr tree and have run into a problem. Basically the tree has some tags with ~ in the name which git doesn't like [21:07] is there any way to work around this? [23:12] Hi, I just started using bazaar and believe i am misunderstanding something about shared repositories. i have a project with code files in ~/projectA. i create a repo on a mapped network drive by using 'bzr init-repository --trees /drive/repo' and then create an branch for the project i want to track in the repo using 'bzr init /drive/repo/projectA' [23:13] jelmer: https://code.launchpad.net/~dulwich/dulwich/unstable mirroring has stopped due to the failure of alioth. Could you update the URL to include a /bzr/ path segment and restart it? [23:13] i then do 'bzr checkout /drive/projectA projectA' [23:13] add and commit the files in that working directory using bzr add and bzr commit [23:13] but when i check the repo at /drive/repo, i don't see a working tree there [23:14] Ok, so a couple of things [23:14] First, why would you even want a working tree on a shared drive? [23:14]