[00:02] could be; otoh getting mails from the commits list is enough for me [00:20] New bug: #165304 in bzr "smart server data streams not used across repository representations" [Undecided,New] https://launchpad.net/bugs/165304 [00:20] New bug: #165306 in bzr "merge commits are extremely slow" [Undecided,New] https://launchpad.net/bugs/165306 [00:20] New bug: #165307 in bzr "graph.heads() does O(N^2) access to the graph" [Undecided,New] https://launchpad.net/bugs/165307 [00:25] fullermd: what was the bug you filed yesterday about unreferenced texs ? [00:25] jam-laptop: if you're still hacking, lookin into that check bug would be most excellent iMO [00:30] New bug: #165309 in bzr "pack index has no topological locality of reference" [Undecided,New] https://launchpad.net/bugs/165309 [00:31] The check one? I can look up the number in my -bugs mailbox... [00:31] fullermd: heh [00:31] poolie: more bugs landed https://bugs.edge.launchpad.net/bzr/+bugs?field.tag=packs [00:32] 165071 [00:35] jam-laptop: ^ [01:01] New bug: #165313 in bzr-pqm "working tree clean check comes after branch check" [Undecided,New] https://launchpad.net/bugs/165313 === cprov-out is now known as cprov-zZz [01:30] New bug: #165315 in bzr "Cannot version a 3M path tree" [Undecided,New] https://launchpad.net/bugs/165315 [01:37] ouch [01:38] don't you kind folks do tests on the mozilla tree? Is it that much smaller then the debian source opened up? [01:39] beuno: It evidently is. ;) [01:46] beuno: its 50K paths [01:47] so 60 times smaller [01:47] Aw, I checked out the mozilla tree for nothing. :p [01:47] 52218, 'find . | wc -l' tells me. [01:48] lifeless, it's an interesting use cas ethen [02:09] poolie: https://bugs.edge.launchpad.net/bzr/+bug/159118 [02:09] Launchpad bug 159118 in bzr "can create a pack repository over bzr+ssh, but then not open it" [Low,Confirmed] [02:09] poolie: just noting it [02:10] Question: How do i remove/override a default ignore for a repository? IE if I don't want *.o files to be ignored, is there a way? [02:10] Nephyrin: there are no default ignores. [02:11] Nephyrin: ~/.bazaar/ignore contains your personal ignores, which you can change [02:11] Nephyrin, maybe explicitley adding it? bzr add foo/bar.a? [02:11] lifeless, he might mean if it's been ignored as a general rule, but wants to make an exception [02:12] Ah, it was in the ~/.bazaar/ignore [02:12] Thanks ^.^ [02:12] * Nephyrin doesn't consider a tree clean if it has those nasty .o files. [02:20] hi all. i'm getting an error when trying to push something to launchpad via bzr. (http://pastebin.ca/798862) can anyone help? [02:22] j1mc, hi [02:22] jam-laptop: I would say your branch is bound to the http url [02:22] meh [02:22] j1mc, try 'bzr info' [02:22] hi poolie [02:22] or just 'bzr unbind' [02:22] j1mc: did you get the branch by doing 'bzr checkout' if so, try 'bzr unbind', then your push should work [02:22] lifeless, were you trying to call? [02:22] poolie: yah [02:22] should I try again [02:22] poolie: ok, i did that. no errors or anything [02:23] lifeless: yes, i did do a bzr checkout [02:23] i'll give that a try [02:28] lifeless: here's what i get now: http://pastebin.ca/798882 [02:32] ah, it is a checkout, you really need a full branch I think [02:32] j1mc: have you seen our tutorial ? [02:33] lifeless: no, i haven't. [02:34] it's a lightweight checkout. lifeless does unbid work with lightweights too? [02:58] beuno: unbind doesn't work with lightweight checkouts. [02:58] However, you can do "reconfigure --tree" to turn a lightweight checkout into a normal tree. [02:59] j1mc, ^ :D [03:06] beuno: i am just trying to do a normal branch now, and will just copy my changes (two files) over those two files in the branch once it's done. [03:09] j1mc, great then [03:23] hi. i'm crazy and I want to use bzr for versioning stuff other than files in the filesystem. How much pain am I in for? [03:24] dash: Define "stuff other than files". [03:24] in terms of writing code to pull data out of whatever structure i've got it in, and putting it into a bzr branch. [03:25] Odd_Bloke: something /sorta/ like the way smalltalk stores its code [03:25] Why not write code to pull data out of whatever structure you've got it in and put it into files and then put those into a branch? [03:25] in an opaque database-ish file [03:25] Odd_Bloke: hmm [03:26] I really don't like your chances of resolving text conflicts in your data. [03:27] hmm, why's that? [03:27] all the data is going to be source code of some variety [03:28] dash: I'm not really sure I understand your use case here. Do you just want to store history, or do you want to take advantage of the merging capabilities of bzr? [03:28] well, let me rephrase [03:30] I'd like to manage a wad of source code with bzr, both for history and merging purposes. This source code isn't stored in individual files in a filesystem hierarchy. It's actually in one big file on the disk, but internally there is some concept of hierarchy and so forth. [03:31] The hackish way to expose this would be to write a FUSE driver to interface to this, and use bzr on that [03:31] but havng to mount things is tedious and i'd rather just use bzrlib directly. [03:33] make sense? [03:33] Yeah, I'm just trying to think of a way to do it. :p [03:34] You might be best writing a post to the ML, as it'll get more eyes looking at it... [03:35] well, mostly i'm thinking about how smalltalk and lisp have pretty rad development environments but you can't use 'normal' VCSes with them [03:35] and i'm wondering how hard it'd be to adapt bzr to deal with that [03:36] (for a new language/dev environment) [03:47] dash: so the layering here is: [03:47] repository [03:47] branch [03:47] tree [03:48] if you can map your current code into a conceptual tree, you can replace WorkingTree with e.g. SqueakImageTree [03:48] that combined with language bindings of course, should work reasonably well [03:54] Well, aside from actually performing merging and such. [03:54] Since TreeTransform hits the filesystem pretty explicitly. [03:59] right, need to replace that; and the ui layer too of course [04:00] ciao [04:07] lifeless: awesome [04:07] lifeless: i am expecting to embed python anyway, so that should work [04:08] and yeah, I should be able to punt on merging for a while so long as i've got history [04:25] hi all - me again. i'm getting closer, but i still can't upload changes to launchpad via bzr, even though i have commit access: http://pastebin.ca/798954 [04:27] New bug: #93609 in bzr "Better error messages for bzr lp://" [Medium,Confirmed] https://launchpad.net/bugs/93609 [04:27] beuno: any advice? ^^ [04:29] j1mc: do a 'bzr commit -m ""' first, then a push [04:30] thanks, Verterok [04:30] y're wellcome [04:32] "Pushed up to revision 3624." w00t :) [04:32] thanks === mw is now known as mw|out [06:40] New bug: #172249 in bzr "bzr check help out of date / confusing output" [Low,Confirmed] https://launchpad.net/bugs/172249 [08:18] * siretart feels stupid. can someone have a look at http://pbot.rmdir.de/6b5ea9950aeacc1ce3c11455362c6b72 and tell me what's wrong with fetching a branch from launchpad via https? [08:20] siretart: try dropping SSL and just using http? [08:20] * AfC doesn't use launchpad much, though [08:20] AfC: launchpad doesn't support plain http, only https [08:21] siretart: https://bugs.edge.launchpad.net/bzr/+bug/82086 [08:21] Launchpad bug 82086 in bzr "pycurl transport causes tracebacks if the server's SSL cert cannot be verified." [Medium,Confirmed] [08:21] siretart: well Launchpad advertises http://bazaar.launchpad.net/~bzr/bzr-push-and-update/trunk for the Bazaar push-and-update plugin that I was experimenting with a few days ago. That looks like HTTP to me. [08:22] (needless to say, I have recommended to them that they get with the program and get a bzr:// server going) [08:23] Odd_Bloke: thanks! [08:25] morning [08:25] Is there a prize associated with the best performance_gained / size(code_modified) ratio ? [08:45] lifeless: bug #165601 fixed, more fear than harm, with a fun twist ;) [08:45] Launchpad bug 165601 in inkscape "win32: non-ascii filenames still don't work" [Critical,Fix released] https://launchpad.net/bugs/165601 [08:46] lifeless: bug #165061 fixed, more fear than harm, with a fun twist ;) [08:46] Launchpad bug 165061 in bzr "bzr branch http:// with a pack repository takes too long" [High,Fix committed] https://launchpad.net/bugs/165061 [08:46] the hell with the typos ! [09:06] siretart: what OS/distro are you using ? [09:11] siretart: if debian or ubuntu check wether or not the ca-certificates package is installed (there seems to be some inconsistencies in dependencies around pycurl/libcurl/ca-certificates) [09:23] vila: ironic to have a typo given the root cause [09:24] lifeless: yeah, story of my bzr life ;-) [09:25] hhtps, 165601, _max_readv_combined, brz, the list goes on...may be scripting languages and their run-time checks nature are not for me finally, will look at ada/c++ again... [09:26] vila: bb:approve [09:26] vila: JFDI [09:27] lifeless: :) no way, sub minute cycles are too good :) [09:31] lifeless: your 'bb:approve' above means I should pqm-submit now ? [09:31] vila: gutsy, and ca-certificates was not installed. installing it doesn't help either [09:31] vila: hell yes [09:31] vila: this probably makes knit pulling faster too [09:32] lifeless: ok, I'll merge [09:33] rats, forgot NEWS update again [09:38] siretart: wow, what version(s) of libcurl and pycurl are installed ? (Note that you can force urllib use if these problems get to boring) [09:40] vila: note that pulling from https://code.launchpad.net/~debian-opensync/opensync/upstream works, but not from https://code.edge.launchpad.net/~debian-opensync/opensync/upstream [09:41] ii python-pycurl 7.16.4-1 Python bindings to libcurl [09:41] ii libcurl3-gnutls 7.16.4-2ubuntu1 Multi-protocol file transfer library (GnuTLS) [09:42] siretart: ha, I think the problem is that code.launchpad.net and code.edge.launchpad.net do not use the same certificate authority (Go Daddy for the later) [09:43] siretart: so the obvious workaround is to avoid code.edge [09:43] not sure if this is really a problem or a feature :) [09:45] siretart: I don't enough about ca-certificates packaging to answer that :-) Short of updating /etc/ssl/ca-certificates.crt yourself or creating your own... [09:46] vila: what If I don't have root on the machine like in a student lab? [09:46] avoid code.edge, only launchpad beta-testers should ever see it or bug launchpad admins :) [09:49] AFAIK people are working on the ca-certificates problem so I hope they'll address that but I don't have more info on the subject, I just saw that new CA days ago, so I don't know when it appears nor if it will stay that way [09:52] from the bzr point of view, as of today, either you use pycurl and relies on it to find the right certificates (or use CURL_CA_BUNDLE env var) or you use urllib and certificates are not verified at all [10:00] siretart: you can overrite the ca certificates file with an env variable I believe [10:00] siretart: see vila's last line in fact [10:01] lifeless: seems like a good candidate for being documented in the bzr manual for 1.0 [10:01] I think I can fiddle that out for me, but I now have a more easy workaround for myself [10:01] siretart: could be; you know where to record that :) [10:02] lifeless: on my list. right after updating the opensync packages :) === cprov-zZz is now known as cprov === kiko-zzz is now known as kiko === mrevell is now known as mrevell-lunch [12:30] Hello.. Does somebody have a comparative experience in using Bazaar and Subversion ? [12:31] i suspect most of the people in here have used svn at one time or another [12:50] theSoftMan: what are you looking for? === mw|out is now known as mw [13:05] I ask me what is the right choice for me ? actually i'm using CVS... and i'm looking for other one... [13:06] I like subversion for it's branch versionning system, atomic commit, binaries files improvements, ... [13:08] hehe... it has no branches... it just thinks it does :) [13:08] but bazaar looks very "sympatic" too but the GUI for Windows system are not so user friendly as subversion ones ( IMHO ) [13:09] (sorry.. I'd like to answer... but got a phone call...) [13:11] How bzr treat binary files ? === mrevell-lunch is now known as mrevell === cprov is now known as cprov-lunch === kiko is now known as kiko-fud [14:46] jam-laptop: ping [14:46] vila: pong [14:46] time to synchronize :) [14:46] I just replied to an email before seeing the next [14:47] the simple fix for 165061 has been merged [14:47] i saw that, which is good [14:48] did you include a NEWS entry? [14:48] yes, before merging [14:49] lifeless gave the bb:aprove here and and launchpad so I merged a few hours ago [14:49] s/and and/and on/ [14:49] sure, and I certainly gave you bb:approve [14:49] your patch is definitely correct and an improvement [14:49] so, you propose to still coalesce until we get a reasonable number of ranges [14:49] I just think we can go a bit further [14:50] I'm concerned about downloading too much data compared with issuing several get requests [14:50] I think issuing multiple requests is *better*, but harder for us to do right now [14:50] And as I mentioned, we may want to limit any given collapsed range [14:50] depending on how we fix the incremental parser [14:51] ha, ok, so you think the risk to encounter too much ranges is still high and want to guard against that until we implement several gets ? [14:51] right [14:51] I think in *my* repositories [14:51] you are going to get a lot of fragmentation [14:51] bzr.dev and roberts repository [14:51] are probably rather clean [14:51] mine have a lot of uncommits [14:51] and revisions from other projects [14:52] While my public would be a bit cleaner [14:52] (since pushing from local to remote would clean it up a bit) [14:52] I still have a lot of branches in 1 repository [14:52] and not all of them will have been merged [14:52] hmmm, I wish we could test against that simply... [14:52] vila: I can put it up for you if you want [14:52] I can probably push it up to a canonical server [14:53] so you don't abuse my bandwidth [14:53] or you can push it up here, so *you* abuse mine :-) [14:54] then I should find a good candidate from your heads() [14:55] I can give you a few branches along with it === cprov-lunch is now known as cprov === kiko-fud is now known as kiko === me_too is now known as too_short === too_short is now known as me_too === m_stone|home is now known as m_stone [16:55] New bug: #172360 in bzr "bzr 0.92 unable to branch from knit repo to pack repo" [Undecided,New] https://launchpad.net/bugs/172360 [17:05] is there a way to add a file "sübφολδερ/ƒilœ" to a bzr repository? my LANG=en_US.UTF-8, and bzr says encoding: 'UTF-8', fsenc: 'utf-8', but no love [17:08] (hmm, my IRC client doesn't seem to be showing any conversation....) [17:10] I'm trying to add a unicodey folder/file to bzr, and getting no love. when it spits back the error it does say encoding/fsenc/lang all UTF-8, though. [17:11] added "sübφολδερ/ƒilœ" [17:11] hey, so my earlier messages must have gone through [17:11] it says: === weigon_ is now known as weigon [17:12] added "sübφολδερ", then bzr: ERROR: exceptions.AttributeError: 'NoneType' object has no attribute 'file_id' [17:12] (that's if I bzr add the folder) [17:14] when I try to add the file itself I get the same "added ", then: bzr: ERROR: The file id "None" is not present in the tree Works for me, too, with 0.92 and .dev. [17:14] n[ate]vw: can you post the traceback to a pastebin? [17:14] !paste [17:14] pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic) [17:15] yeah, I can [17:15] works for me with bzr.dev [17:16] works for me to, but when I `bzr revert`, it reverts, but then spits an error [17:16] involving loggin, I think; sorry, I lost it [17:17] http://paste.ubuntu-nl.org/46007/ for the folder [17:18] Mmm. Darwin. [17:19] hmm.... [17:19] that looks like parent_ie is being None [17:19] which is a bit odd [17:19] n[ate]vw: what happens if you use just plain "bzr add" ? [17:19] to recursively add everything. [17:20] similar error to adding the folder [17:22] http://paste.ubuntu-nl.org/46010/ for the file directly [17:23] hold on, the plain 'bzr add' ives back a KeyError exception instead [17:23] http://paste.ubuntu-nl.org/46012/ for the recursive add [17:24] (paste.ubuntu-nl is hosing some of the unicode -> ??? in those dumps) [17:29] anyone else able to reproduce, or workaround? (sorry, might have missed first responses) [17:29] (my client started cooperating @ "I'm trying to add a unicodey folder/file to bzr") [17:34] wait a sec, your on Mac, right? [17:34] n[ate]vw: I wonder if there is a path normalization problem [17:35] yeah, OS X 10.5.1 [17:35] as in, when you create a file with å [17:35] you might type it is as u'\xe5' [17:35] but the FS changes it to [17:36] 'u'a\u030a' [17:37] certainly I'm seeing u'su\u0308' [17:37] which would be u with dots [17:37] (u) (with dots) [17:37] rather than [17:37] (u with dots) [17:37] (u'\xfc') [17:37] doesn't bzr convert to a normalized form internally? [17:38] we used to [17:38] but it added a lot of overhead [17:38] and broke when platforms didn't normalize themselve [17:38] selves [17:38] It turns out that Windows likes to do mixed normalization [17:38] Sometimes using wide parethesis [17:38] but usually using narrow [17:38] etc [17:40] there are also some heavy performance issues if you have to normalize every file in a 50k entry tree [17:41] but if bzr doesn't do any normalization internally, wouldn't it just keep whatever the shell passed it? [17:41] or fs, in the case of adding the tree recursively, [17:41] -, [17:42] except the shell could have passed in one [17:42] versus the fs [17:42] but yeah, I would think recursive adding would have worked [17:42] let me try that here [17:45] I can reproduce it here [17:45] I'll try to track it down [17:45] great, thanks [17:45] fwiw, mercurial seems to have handled the same folder fine. no complaints on add, and I was able to clone the repo succesfully. [17:47] n[ate]vw: you might want to try checking it out on another platform [17:47] at least Windows will puke pretty badly [17:47] last time I tried that [17:47] well, not puke [17:47] hg, or bzr? [17:47] but it puts the UTF8 strings into OEM encoding [17:47] so all the names are bad [17:47] hg [17:47] hg doesn't pay attention to Unicode [17:48] so it just versions 8-bit strings [17:48] which depends on your encoding [17:48] ah, indeed [17:48] so while Windows fs is MBCS [17:48] you will get different paths on Russian windows [17:48] versus US windows, etc. [17:49] So it causes double-pane on Windows? [17:49] * fullermd sneaks back under a rock. [17:50] I've asked in several channels, so I guess one more can't hurt. [17:51] I'm looking for a tool to manage my configuration files, particularly distributing them over a set of remote machines. I would like to be able to specify which files to transfer, if non-default versions of them are to be transferred, and ideally, that the tool is able to detect remote changes and merge them back, or not. [18:00] by "merge them back", do you mean a diff or just picking one copy of the file? unison is able to do two-way sync, but I'm pretty sure it doesn't do text merges [18:11] jam-laptop: should I file a bug on the OS X unicode issues, or will you once you've looked into it [18:11] submit one, and I'll comment on it [18:12] I'm assuming nobody is interested in seeing the several-KB dump when I add the file directly? [18:13] I suppose I could just link to the pastebin, if those don't get cleaned out too quickly [18:14] I did find this https://lists.ubuntu.com/archives/bazaar/2007q2/024773.html, which clarifies the problem a bit but seems to be posted before the normalization routines were removed [18:28] hey folks [18:28] do we have dapper packages for bzr 0.92 yet? [18:29] doesn't seem so [18:45] New bug: #172383 in bzr "Cannot add normalized Unicode file to repo" [Undecided,New] https://launchpad.net/bugs/172383 [18:47] jam-laptop: filed https://bugs.launchpad.net/bzr/+bug/172383 [18:47] Launchpad bug 172383 in bzr "Cannot add NFD normalized Unicode file to repo" [Undecided,New] [18:48] whoops, bot beat me [18:55] so currently, bzr stores filenames in whatever form they are received, but is aware they are Unicode when writing to disk (the distinction from hg)? [18:59] I guess I'm still wondering how bzr stores/compares the filenames in memory, and whether normalizing only when checking equivalence would be a good compromise [18:59] (or maybe "checking equivalence" doesn't happen like that, I don't really know anything re: the internal architecture) [19:05] n[ate]vw: no, I just responded to bug 172383 [19:05] Launchpad bug 172383 in bzr "Cannot add NFD normalized Unicode file to repo" [Undecided,New] https://launchpad.net/bugs/172383 [19:06] Some of the normalization calls are still present [19:10] not seeing how this relates to bug #165071 [19:10] Launchpad bug 165071 in bzr "check reports spurious unreferenced texts" [Undecided,New] https://launchpad.net/bugs/165071 [19:13] n[ate]vw: just a bad copy and paste on my part [19:14] I meant bug 102935. [19:14] Launchpad bug 102935 in bzr ""combined" unicode characters are renamed on Mac" [Wishlist,Confirmed] https://launchpad.net/bugs/102935 [19:16] vila: what is the status of your fix for bug 164567 [19:16] Launchpad bug 164567 in bzr "FTP push does not work without specifying password" [Medium,Fix committed] https://launchpad.net/bugs/164567 [19:17] nm, it was merged in 3025 [19:18] But your name wasn't mentioned in the commit message [19:18] so i had trouble finding it [19:19] jam-laptop: no prob. from that ticket, do I understand if I were add a directory named süb on an NFC fs, and then clone it to an NFD fs, bzr would eventually: 1) notice the file missing internally, 2) normalize the name and find it in the new form, and 3) do the right thing™? [19:19] n[ate]vw: from 102935? [19:20] no, unfortunately not anymore [19:20] it used to [19:20] but because of problems of users having filenames in mixed normalization on other platforms... [19:20] (and for whatever reason not being able to change their filenames) [19:22] hi [19:29] morning lifeless [19:29] any chance you had time to backport any bzr releases to dapper? [19:31] when dealing with a "missing" file would it be possible to normalize both sides of the comparison - disk names vs. internal name - or would that case be a recurring performance drag? [19:32] jam-laptop: if we we're scrambling to make packs default, sure. [19:33] lifeless: sabdfl was just in earlier asking for them, and I know we haven't been getting regular backports to dapper [19:33] I understand you are busy with other things [19:33] Maybe someone else should be doing the .deb building? [19:34] he wanted them for the datacentre [19:34] elmo has rolled it out already [19:34] k [19:34] there is a patch I need to apply [19:35] so whats up with NFD ? [19:35] New bug: #172392 in bzr "interrupting a client waiting for a lock over bzr+ssh leaves process on server" [Undecided,New] https://launchpad.net/bugs/172392 [19:36] Mac stores everything as NFD, our current code is normalizing them when creating an Inventory Entry [19:36] but then the "smart_add" code doesn't realize that [19:36] and looks up the NFD [19:36] So Inventories are still NFC only [19:36] but the smart_add() code is using NFD [19:36] grah [19:37] andyou're saying 'dont fix smart_add, stop normalising' ? [19:37] We *could* go through this again and try to make smart_add use NFD [19:37] lifeless: correct [19:37] we have a bug open for it [19:37] because other wise on mac [19:37] bzr add ü [19:37] bzr status [19:37] will show ü as missing [19:37] and an unknown file ü as being present [19:37] If we fix smart_add [19:37] we have to fix status, etc. [19:38] well you're the guru [19:39] but I don't see anything thats changed the validity of your prior argument *to* canonicalise. [19:39] brb === abadger1991 is now known as abadger1999 [19:39] lifeless: the effort required to get it working with dirstate trees [19:39] and the performance hit of normalizing [19:40] n[ate]vw: that might be possible [19:40] n[ate]vw: then what happens when someone stores both forms on disk... [19:40] there is also a possibility to work this into case-insensitive issues as well [19:40] lifeless: oh, and on Windows, it likes to create non-normalized names under certain situations [19:41] lifeless: Japanese Windows was creating filenames with Wide-form parenthesis IIRC [19:41] heh, I suppose there's some OS that would allow both ü's on the same branch [19:41] Which meant that we couldn't version them, since they cannot be accessed under their other names [19:41] n[ate]vw: another possibility was to store the canonicalized name, as well as the form on disk [19:42] so that when scanning through directories [19:42] we could see which path lines up with which other one [19:42] it certainly would be nice to only do this sort of thing on "misses" rather than for every file [19:45] so each clone could have the working copy in the OS-preferred format, but internally it would be stored canonically? [19:46] doing something just on misses might be nice for performance, but I'd be worried it would just be wacking one mole to come up again in some other function. I don't know bzr well enough to say, though [19:47] the old code did it only for misses [19:47] but always normalized in one direction [19:47] os => normalized form == internal form [19:47] otherwise when you get a miss [19:47] you have to normalize everything (at least in that directory) [19:47] since you don't know *which* one it should have been pointing at [19:47] (since, after all, it missed) [19:51] Well, you could skip all the known files at least. [19:52] true [19:52] I suppose you could keep track of what things hit, and what missed [19:52] and then at the end compare them [19:52] however, [19:52] the current api (I believe) expects to get everything in sorted order [19:52] so you have to defer returning anything [19:52] until you have processed the whole directory [19:53] not terribly onerous [19:53] but probably would have an impact [19:59] wow, that's a tough problem. it'd be nice to get it right by using a canonical form internally, but then it gets benchmarked against a system that ignores some of those issues.... [20:01] do users expect bzr to keep the original working form on all same-platform clones? [20:01] especially with regards to mixed-normalization? [20:02] n[ate]vw: well the concern is that the program generated mixed normalization (MS Office) [20:02] is going to do weird things once you change the normalization. [20:04] so in the jp locale, MS Office doesn't even want to open a file if it doesn't use fullwidth parentheses? [20:09] jam-laptop: you'd almost need to keep track of three forms: original form as added, canonical form, form on disk [20:09] jam-laptop: have you looked at the new check refcount error ? [20:10] lifeless: it looks like it is still present [20:10] k, I'll fix it then [20:10] !paste [20:10] pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic) [20:10] lifeless: the simple fix should just be: http://paste.ubuntu-nl.org/46034/ [20:11] A more complex one would intersect "planned_revisions" with w.versions() [20:17] abentley: ping [20:24] Hallo [20:25] I'm stracing a bzr process, just for fun, and I see it repeatedly uses (and unlinks) /tmp/tempfile.tmp [20:25] That sounds like a potential security problem, but I'm not sure where it comes from. [20:25] (I'm pulling changes from a local bzr-only branch into another branch bound to an SVN repo) [20:25] Lo-lan-do: are you sure it isn't running the test suite? [20:26] During a "bzr pull"? [20:26] and is it always explicitly "/tmp/tempfile.tmp" [20:26]