[00:02] <lifeless> could be; otoh getting mails from the commits list is enough for me
[00:20] <ubotu> New bug: #165304 in bzr "smart server data streams not used across repository	representations" [Undecided,New] https://launchpad.net/bugs/165304
[00:20] <ubotu> New bug: #165306 in bzr "merge commits are extremely slow" [Undecided,New] https://launchpad.net/bugs/165306
[00:20] <ubotu> New bug: #165307 in bzr "graph.heads() does O(N^2) access to the graph" [Undecided,New] https://launchpad.net/bugs/165307
[00:25] <lifeless> fullermd: what was the bug you filed yesterday about unreferenced texs ?
[00:25] <lifeless> jam-laptop: if you're still hacking, lookin into that check bug would be most excellent iMO
[00:30] <ubotu> New bug: #165309 in bzr "pack index has no topological locality of reference" [Undecided,New] https://launchpad.net/bugs/165309
[00:31] <fullermd> The check one?  I can look up the number in my -bugs mailbox...
[00:31] <lifeless> fullermd: heh
[00:31] <lifeless> poolie: more bugs landed https://bugs.edge.launchpad.net/bzr/+bugs?field.tag=packs
[00:32] <fullermd> 165071
[00:35] <lifeless> jam-laptop: ^
[01:01] <ubotu> New bug: #165313 in bzr-pqm "working tree clean check comes after branch check" [Undecided,New] https://launchpad.net/bugs/165313
[01:30] <ubotu> New bug: #165315 in bzr "Cannot version a 3M path tree" [Undecided,New] https://launchpad.net/bugs/165315
[01:37] <beuno> ouch
[01:38] <beuno> don't you kind folks do tests on the mozilla tree?    Is it that much smaller then the debian source opened up?
[01:39] <Odd_Bloke> beuno: It evidently is. ;)
[01:46] <lifeless> beuno: its 50K paths
[01:47] <lifeless> so 60 times smaller
[01:47] <Odd_Bloke> Aw, I checked out the mozilla tree for nothing. :p
[01:47] <Odd_Bloke> 52218, 'find . | wc -l' tells me.
[01:48] <beuno> lifeless, it's an interesting use cas ethen
[02:09] <lifeless> poolie: https://bugs.edge.launchpad.net/bzr/+bug/159118
[02:09] <ubotu> Launchpad bug 159118 in bzr "can create a pack repository over bzr+ssh, but then not open it" [Low,Confirmed]
[02:09] <lifeless> poolie: just noting it
[02:10] <Nephyrin> 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] <lifeless> Nephyrin: there are no default ignores.
[02:11] <lifeless> Nephyrin: ~/.bazaar/ignore contains your personal ignores, which you can change
[02:11] <beuno> Nephyrin, maybe explicitley adding it?   bzr add foo/bar.a?
[02:11] <beuno> lifeless, he might mean if it's been ignored as a general rule, but wants to make an exception
[02:12] <Nephyrin> Ah, it was in the ~/.bazaar/ignore
[02:12] <Nephyrin> Thanks ^.^
[02:12]  * Nephyrin doesn't consider a tree clean if it has those nasty .o files.
[02:20] <j1mc> 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] <poolie> j1mc, hi
[02:22] <lifeless> jam-laptop: I would say your branch is bound to the http url
[02:22] <lifeless> meh
[02:22] <poolie> j1mc, try 'bzr info'
[02:22] <j1mc> hi poolie
[02:22] <poolie> or just 'bzr unbind'
[02:22] <lifeless> j1mc: did you get the branch by doing 'bzr checkout' if so, try 'bzr unbind', then your push should work
[02:22] <poolie> lifeless, were you trying to call?
[02:22] <lifeless> poolie: yah
[02:22] <lifeless> should I try again
[02:22] <j1mc> poolie: ok, i did that.  no errors or anything
[02:23] <j1mc> lifeless: yes, i did do a bzr checkout
[02:23] <j1mc> i'll give that a try
[02:28] <j1mc> lifeless: here's what i get now: http://pastebin.ca/798882
[02:32] <lifeless> ah, it is a checkout, you really need a full branch I think
[02:32] <lifeless> j1mc: have you seen our tutorial ?
[02:33] <j1mc> lifeless: no, i haven't.
[02:34] <beuno> it's a lightweight checkout. lifeless does unbid work with lightweights too?
[02:58] <abentle1> beuno: unbind doesn't work with lightweight checkouts.
[02:58] <abentle1> However, you can do "reconfigure --tree" to turn a lightweight checkout into a normal tree.
[02:59] <beuno> j1mc, ^   :D
[03:06] <j1mc> 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] <beuno> j1mc, great then
[03:23] <dash> 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] <Odd_Bloke> dash: Define "stuff other than files".
[03:24] <dash> 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] <dash> Odd_Bloke: something /sorta/ like the way smalltalk stores its code
[03:25] <Odd_Bloke> 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] <dash> in an opaque database-ish file
[03:25] <dash> Odd_Bloke: hmm
[03:26] <abentle1> I really don't like your chances of resolving text conflicts in your data.
[03:27] <dash> hmm, why's that?
[03:27] <dash> all the data is going to be source code of some variety
[03:28] <Odd_Bloke> 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] <dash> well, let me rephrase
[03:30] <dash> 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] <dash> The hackish way to expose this would be to write a FUSE driver to interface to this, and use bzr on that
[03:31] <dash> but havng to mount things is tedious and i'd rather just use bzrlib directly.
[03:33] <dash> make sense?
[03:33] <Odd_Bloke> Yeah, I'm just trying to think of a way to do it. :p
[03:34] <Odd_Bloke> You might be best writing a post to the ML, as it'll get more eyes looking at it...
[03:35] <dash> 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] <dash> and i'm wondering how hard it'd be to adapt bzr to deal with that
[03:36] <dash> (for a new language/dev environment)
[03:47] <lifeless> dash: so the layering here is:
[03:47] <lifeless> repository
[03:47] <lifeless> branch
[03:47] <lifeless> tree
[03:48] <lifeless> if you can map your current code into a conceptual tree, you can replace WorkingTree with e.g. SqueakImageTree
[03:48] <lifeless> that combined with language bindings of course, should work reasonably well
[03:54] <abentley> Well, aside from actually performing merging and such.
[03:54] <abentley> Since TreeTransform hits the filesystem pretty explicitly.
[03:59] <lifeless> right, need to replace that; and the ui layer too of course
[04:00] <lifeless> ciao
[04:07] <dash> lifeless: awesome
[04:07] <dash> lifeless: i am expecting to embed python anyway, so that should work
[04:08] <dash> and yeah, I should be able to punt on merging for a while so long as i've got history
[04:25] <j1mc> 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] <ubotu> New bug: #93609 in bzr "Better error messages for bzr lp://" [Medium,Confirmed] https://launchpad.net/bugs/93609
[04:27] <j1mc> beuno: any advice?  ^^
[04:29] <Verterok> j1mc: do a 'bzr commit -m "<your commit message>"'  first, then a push
[04:30] <j1mc> thanks, Verterok
[04:30] <Verterok> y're wellcome
[04:32] <j1mc> "Pushed up to revision 3624."  w00t  :)
[04:32] <j1mc> thanks
[06:40] <ubotu> 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] <AfC> siretart: try dropping SSL and just using http?
[08:20]  * AfC doesn't use launchpad much, though
[08:20] <siretart> AfC: launchpad doesn't support plain http, only https
[08:21] <Odd_Bloke> siretart: https://bugs.edge.launchpad.net/bzr/+bug/82086
[08:21] <ubotu> Launchpad bug 82086 in bzr "pycurl transport causes tracebacks if the server's SSL cert cannot be verified." [Medium,Confirmed]
[08:21] <AfC> 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] <AfC> (needless to say, I have recommended to them that they get with the program and get a bzr:// server going)
[08:23] <siretart> Odd_Bloke: thanks!
[08:25] <vila> morning
[08:25] <vila> Is there a prize associated with the best performance_gained / size(code_modified) ratio ?
[08:45] <vila> lifeless: bug #165601 fixed, more fear than harm, with a fun twist ;)
[08:45] <ubotu> Launchpad bug 165601 in inkscape "win32: non-ascii filenames still don't work" [Critical,Fix released] https://launchpad.net/bugs/165601
[08:46] <vila> lifeless: bug #165061 fixed, more fear than harm, with a fun twist ;)
[08:46] <ubotu> 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] <vila> the hell with the typos !
[09:06] <vila> siretart: what OS/distro are you using ?
[09:11] <vila> 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] <lifeless> vila: ironic to have a typo given the root cause
[09:24] <vila> lifeless: yeah, story of my bzr life ;-)
[09:25] <vila> 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] <lifeless> vila: bb:approve
[09:26] <lifeless> vila: JFDI
[09:27] <vila> lifeless: :) no way, sub minute cycles are too good :)
[09:31] <vila> lifeless: your 'bb:approve' above means I should pqm-submit now ?
[09:31] <siretart> vila: gutsy, and ca-certificates was not installed. installing it doesn't help either
[09:31] <lifeless> vila: hell yes
[09:31] <lifeless> vila: this probably makes knit pulling faster too
[09:32] <vila> lifeless: ok, I'll merge
[09:33] <vila> rats, forgot NEWS update again
[09:38] <vila> 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] <siretart> 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] <siretart> ii  python-pycurl       7.16.4-1        Python bindings to libcurl
[09:41] <siretart> ii  libcurl3-gnutls               7.16.4-2ubuntu1               Multi-protocol file transfer library (GnuTLS)
[09:42] <vila> 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] <vila> siretart: so the obvious workaround is to avoid code.edge
[09:43] <siretart> not sure if this is really a problem or a feature :)
[09:45] <vila> 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] <siretart> vila: what If I don't have root on the machine like in a student lab?
[09:46] <vila> avoid code.edge, only launchpad beta-testers should ever see it or bug launchpad admins :)
[09:49] <vila> 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] <vila> 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] <lifeless> siretart: you can overrite the ca certificates file with an env variable I believe
[10:00] <lifeless> siretart: see vila's last line in fact
[10:01] <siretart> lifeless: seems like a good candidate for being documented in the bzr manual for 1.0
[10:01] <siretart> I think I can fiddle that out for me, but I now have a more easy workaround for myself
[10:01] <lifeless> siretart: could be; you know where to record that :)
[10:02] <siretart> lifeless: on my list. right after updating the opensync packages :)
[12:30] <theSoftMan> Hello.. Does somebody have a comparative experience in using Bazaar and Subversion ?
[12:31] <mwhudson> i suspect most of the people in here have used svn at one time or another
[12:50] <AfC> theSoftMan: what are you looking for?
[13:05] <theSoftMan_> I ask me what is the right choice for me ? actually i'm using CVS... and i'm looking for other one...
[13:06] <theSoftMan_> I like subversion for it's branch versionning system, atomic commit, binaries files improvements, ...
[13:08] <Zindar> hehe... it has no branches... it just thinks it does :)
[13:08] <theSoftMan_> but bazaar looks very "sympatic" too but the GUI for Windows system are not so user friendly as subversion ones ( IMHO )
[13:09] <Zindar> (sorry.. I'd like to answer... but got a phone call...)
[13:11] <theSoftMan_> How bzr treat binary files ?
[14:46] <vila> jam-laptop: ping
[14:46] <jam-laptop> vila: pong
[14:46] <vila> time to synchronize :)
[14:46] <vila> I just replied to an email before seeing the next
[14:47] <vila> the simple fix for 165061 has been merged
[14:47] <jam-laptop> i saw that, which is good
[14:48] <jam-laptop> did you include a NEWS entry?
[14:48] <vila> yes, before merging
[14:49] <vila> lifeless gave the bb:aprove here and and launchpad so I merged a few hours ago
[14:49] <vila> s/and and/and on/
[14:49] <jam-laptop> sure, and I certainly gave you bb:approve
[14:49] <jam-laptop> your patch is definitely correct and an improvement
[14:49] <vila> so, you propose to still coalesce until we get a reasonable number of ranges
[14:49] <jam-laptop> I just think we can go a bit further
[14:50] <vila> I'm concerned about downloading too much data compared with issuing several get requests
[14:50] <jam-laptop> I think issuing multiple requests is *better*, but harder for us to do right now
[14:50] <jam-laptop> And as I mentioned, we may want to limit any given collapsed range
[14:50] <jam-laptop> depending on how we fix the incremental parser
[14:51] <vila> 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] <jam-laptop> right
[14:51] <jam-laptop> I think in *my* repositories
[14:51] <jam-laptop> you are going to get a lot of fragmentation
[14:51] <jam-laptop> bzr.dev and roberts repository
[14:51] <jam-laptop> are probably rather clean
[14:51] <jam-laptop> mine have a lot of uncommits
[14:51] <jam-laptop> and revisions from other projects
[14:52] <jam-laptop> While my public would be a bit cleaner
[14:52] <jam-laptop> (since pushing from local to remote would clean it up a bit)
[14:52] <jam-laptop> I still have a lot of branches in 1 repository
[14:52] <jam-laptop> and not all of them will have been merged
[14:52] <vila> hmmm, I wish we could test against that simply...
[14:52] <jam-laptop> vila: I can put it up for you if you want
[14:52] <jam-laptop> I can probably push it up to a canonical server
[14:53] <jam-laptop> so you don't abuse my bandwidth
[14:53] <vila> or you can push it up here, so *you* abuse mine :-)
[14:54] <vila> then I should find a good candidate from your heads()
[14:55] <jam-laptop> I can give you a few branches along with it
[16:55] <ubotu> 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] <n[ate]vw> 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] <n[ate]vw> (hmm, my IRC client doesn't seem to be showing any conversation....)
[17:10] <n[ate]vw> 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] <dato> added "sübφολδερ/ƒilœ"
[17:11] <n[ate]vw> hey, so my earlier messages must have gone through
[17:11] <n[ate]vw> it says:
[17:12] <n[ate]vw> added "sübφολδερ", then bzr: ERROR: exceptions.AttributeError: 'NoneType' object has no attribute 'file_id'
[17:12] <n[ate]vw> (that's if I bzr add the folder)
[17:14] <n[ate]vw> when I try to add the file itself I get the same "added <folder>", then: bzr: ERROR: The file id "None" is not present in the tree <Inventory object at 11d5f10, contents={ ....massive dump..... }
[17:14] <fullermd> Works for me, too, with 0.92 and .dev.
[17:14] <jam-laptop> n[ate]vw:  can you post the traceback to a pastebin?
[17:14] <jam-laptop> !paste
[17:14] <ubotu> 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] <n[ate]vw> yeah, I can
[17:15] <rthalley> works for me with bzr.dev
[17:16] <dato> works for me to, but when I `bzr revert`, it reverts, but then spits an error
[17:16] <dato> involving loggin, I think; sorry, I lost it
[17:17] <n[ate]vw> http://paste.ubuntu-nl.org/46007/ for the folder
[17:18] <fullermd> Mmm.  Darwin.
[17:19] <jam-laptop> hmm....
[17:19] <jam-laptop> that looks like parent_ie is being None
[17:19] <jam-laptop> which is a bit odd
[17:19] <jam-laptop> n[ate]vw: what happens if you use just plain "bzr add" ?
[17:19] <jam-laptop> to recursively add everything.
[17:20] <n[ate]vw> similar error to adding the folder
[17:22] <n[ate]vw> http://paste.ubuntu-nl.org/46010/ for the file directly
[17:23] <n[ate]vw> hold on, the plain 'bzr add' ives back a KeyError exception instead
[17:23] <n[ate]vw> http://paste.ubuntu-nl.org/46012/ for the recursive add
[17:24] <n[ate]vw> (paste.ubuntu-nl is hosing some of the unicode -> ??? in those dumps)
[17:29] <n[ate]vw> anyone else able to reproduce, or workaround? (sorry, might have missed first responses)
[17:29] <n[ate]vw> (my client started cooperating @ "I'm trying to add a unicodey folder/file to bzr")
[17:34] <jam-laptop> wait a sec, your on Mac, right?
[17:34] <jam-laptop> n[ate]vw: I wonder if there is a path normalization problem
[17:35] <n[ate]vw> yeah, OS X 10.5.1
[17:35] <jam-laptop> as in, when you create a file with å
[17:35] <jam-laptop> you might type it is as u'\xe5'
[17:35] <jam-laptop> but the FS changes it to
[17:36] <jam-laptop> 'u'a\u030a'
[17:37] <jam-laptop> certainly I'm seeing u'su\u0308'
[17:37] <jam-laptop> which would be u with dots
[17:37] <jam-laptop> (u) (with dots)
[17:37] <jam-laptop> rather than
[17:37] <jam-laptop> (u with dots)
[17:37] <jam-laptop> (u'\xfc')
[17:37] <n[ate]vw> doesn't bzr convert to a normalized form internally?
[17:38] <jam-laptop> we used to
[17:38] <jam-laptop> but it added a lot of overhead
[17:38] <jam-laptop> and broke when platforms didn't normalize themselve
[17:38] <jam-laptop> selves
[17:38] <jam-laptop> It turns out that Windows likes to do mixed normalization
[17:38] <jam-laptop> Sometimes using wide parethesis
[17:38] <jam-laptop> but usually using narrow
[17:38] <jam-laptop> etc
[17:40] <jam-laptop> there are also some heavy performance issues if you have to normalize every file in a 50k entry tree
[17:41] <n[ate]vw> but if bzr doesn't do any normalization internally, wouldn't it just keep whatever the shell passed it?
[17:41] <n[ate]vw> or fs, in the case of adding the tree recursively,
[17:41] <n[ate]vw> -,
[17:42] <jam-laptop> except the shell could have passed in one
[17:42] <jam-laptop> versus the fs
[17:42] <jam-laptop> but yeah, I would think recursive adding would have worked
[17:42] <jam-laptop> let me try that here
[17:45] <jam-laptop> I can reproduce it here
[17:45] <jam-laptop> I'll try to track it down
[17:45] <n[ate]vw> great, thanks
[17:45] <n[ate]vw> 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] <jam-laptop> n[ate]vw: you might want to try checking it out on another platform
[17:47] <jam-laptop> at least Windows will puke pretty badly
[17:47] <jam-laptop> last time I tried that
[17:47] <jam-laptop> well, not puke
[17:47] <n[ate]vw> hg, or bzr?
[17:47] <jam-laptop> but it puts the UTF8 strings into OEM encoding
[17:47] <jam-laptop> so all the names are bad
[17:47] <jam-laptop> hg
[17:47] <jam-laptop> hg doesn't pay attention to Unicode
[17:48] <jam-laptop> so it just versions 8-bit strings
[17:48] <jam-laptop> which depends on your encoding
[17:48] <n[ate]vw> ah, indeed
[17:48] <jam-laptop> so while Windows fs is MBCS
[17:48] <jam-laptop> you will get different paths on Russian windows
[17:48] <jam-laptop> versus US windows, etc.
[17:49] <fullermd> So it causes double-pane on Windows?
[17:49]  * fullermd sneaks back under a rock.
[17:50] <dato> I've asked in several channels, so I guess one more can't hurt.
[17:51] <dato> 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] <n[ate]vw> 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] <n[ate]vw> jam-laptop: should I file a bug on the OS X unicode issues, or will you once you've looked into it
[18:11] <jam-laptop> submit one, and I'll comment on it
[18:12] <n[ate]vw> I'm assuming nobody is interested in seeing the several-KB dump when I add the file directly?
[18:13] <n[ate]vw> I suppose I could just link to the pastebin, if those don't get cleaned out too quickly
[18:14] <n[ate]vw> 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] <sabdfl> hey folks
[18:28] <sabdfl> do we have dapper packages for bzr 0.92 yet?
[18:29] <dato> doesn't seem so
[18:45] <ubotu> New bug: #172383 in bzr "Cannot add normalized Unicode file to repo" [Undecided,New] https://launchpad.net/bugs/172383
[18:47] <n[ate]vw> jam-laptop: filed https://bugs.launchpad.net/bzr/+bug/172383
[18:47] <ubotu> Launchpad bug 172383 in bzr "Cannot add NFD normalized Unicode file to repo" [Undecided,New]
[18:48] <n[ate]vw> whoops, bot beat me
[18:55] <n[ate]vw> 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] <n[ate]vw> 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] <n[ate]vw> (or maybe "checking equivalence" doesn't happen like that, I don't really know anything re: the internal architecture)
[19:05] <jam-laptop> n[ate]vw: no, I just responded to bug 172383
[19:05] <ubotu> Launchpad bug 172383 in bzr "Cannot add NFD normalized Unicode file to repo" [Undecided,New] https://launchpad.net/bugs/172383
[19:06] <jam-laptop> Some of the normalization calls are still present
[19:10] <n[ate]vw> not seeing how this relates to bug #165071
[19:10] <ubotu> Launchpad bug 165071 in bzr "check reports spurious unreferenced texts" [Undecided,New] https://launchpad.net/bugs/165071
[19:13] <jam-laptop> n[ate]vw: just a bad copy and paste on my part
[19:14] <jam-laptop> I meant bug 102935.
[19:14] <ubotu> Launchpad bug 102935 in bzr ""combined" unicode characters are renamed on Mac" [Wishlist,Confirmed] https://launchpad.net/bugs/102935
[19:16] <jam-laptop> vila: what is the status of your fix for bug 164567
[19:16] <ubotu> Launchpad bug 164567 in bzr "FTP push does not work without specifying password" [Medium,Fix committed] https://launchpad.net/bugs/164567
[19:17] <jam-laptop> nm, it was merged in 3025
[19:18] <jam-laptop> But your name wasn't mentioned in the commit message
[19:18] <jam-laptop> so i had trouble finding it
[19:19] <n[ate]vw> 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] <jam-laptop> n[ate]vw: from 102935?
[19:20] <jam-laptop> no, unfortunately not anymore
[19:20] <jam-laptop> it used to
[19:20] <jam-laptop> but because of problems of users having filenames in mixed normalization on other platforms...
[19:20] <jam-laptop> (and for whatever reason not being able to change their filenames)
[19:22] <lifeless> hi
[19:29] <jam-laptop> morning lifeless
[19:29] <jam-laptop> any chance you had time to backport any bzr releases to dapper?
[19:31] <n[ate]vw> 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] <lifeless> jam-laptop: if we we're scrambling to make packs default, sure.
[19:33] <jam-laptop> lifeless: sabdfl was just in earlier asking for them, and I know we haven't been getting regular backports to dapper
[19:33] <jam-laptop> I understand you are busy with other things
[19:33] <jam-laptop> Maybe someone else should be doing the .deb building?
[19:34] <lifeless> he wanted them for the datacentre
[19:34] <lifeless> elmo has rolled it out already
[19:34] <jam-laptop> k
[19:34] <lifeless> there is a patch I need to apply
[19:35] <lifeless> so whats up with NFD ?
[19:35] <ubotu> 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] <jam-laptop> Mac stores everything as NFD, our current code is normalizing them when creating an Inventory Entry
[19:36] <jam-laptop> but then the "smart_add" code doesn't realize that
[19:36] <jam-laptop> and looks up the NFD
[19:36] <jam-laptop> So Inventories are still NFC only
[19:36] <jam-laptop> but the smart_add() code is using NFD
[19:36] <lifeless> grah
[19:37] <lifeless> andyou're saying 'dont fix smart_add, stop normalising' ?
[19:37] <jam-laptop> We *could* go through this again and try to make smart_add use NFD
[19:37] <jam-laptop> lifeless: correct
[19:37] <jam-laptop> we have a bug open for it
[19:37] <jam-laptop> because other wise on mac
[19:37] <jam-laptop> bzr add ü
[19:37] <jam-laptop> bzr status
[19:37] <jam-laptop> will show ü as missing
[19:37] <jam-laptop> and an unknown file ü as being present
[19:37] <jam-laptop> If we fix smart_add
[19:37] <jam-laptop> we have to fix status, etc.
[19:38] <lifeless>  well you're the guru
[19:39] <lifeless> but I don't see anything thats changed the validity of your prior argument *to* canonicalise.
[19:39] <lifeless> brb
[19:39] <jam-laptop> lifeless: the effort required to get it working with dirstate trees
[19:39] <jam-laptop> and the performance hit of normalizing
[19:40] <jam-laptop> n[ate]vw: that might be possible
[19:40] <jam-laptop> n[ate]vw: then what happens when someone stores both forms on disk...
[19:40] <jam-laptop> there is also a possibility to work this into case-insensitive issues as well
[19:40] <jam-laptop> lifeless: oh, and on Windows, it likes to create non-normalized names under certain situations
[19:41] <jam-laptop> lifeless: Japanese Windows was creating filenames with Wide-form parenthesis IIRC
[19:41] <n[ate]vw> heh, I suppose there's some OS that would allow both ü's on the same branch
[19:41] <jam-laptop> Which meant that we couldn't version them, since they cannot be accessed under their other names
[19:41] <jam-laptop> n[ate]vw: another possibility was to store the canonicalized name, as well as the form on disk
[19:42] <jam-laptop> so that when scanning through directories
[19:42] <jam-laptop> we could see which path lines up with which other one
[19:42] <jam-laptop> it certainly would be nice to only do this sort of thing on "misses" rather than for every file
[19:45] <n[ate]vw> so each clone could have the working copy in the OS-preferred format, but internally it would be stored canonically?
[19:46] <n[ate]vw> 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] <jam-laptop> the old code did it only for misses
[19:47] <jam-laptop> but always normalized in one direction
[19:47] <jam-laptop> os => normalized form == internal form
[19:47] <jam-laptop> otherwise when you get a miss
[19:47] <jam-laptop> you have to normalize everything (at least in that directory)
[19:47] <jam-laptop> since you don't know *which* one it should have been pointing at
[19:47] <jam-laptop> (since, after all, it missed)
[19:51] <fullermd> Well, you could skip all the known files at least.
[19:52] <jam-laptop> true
[19:52] <jam-laptop> I suppose you could keep track of what things hit, and what missed
[19:52] <jam-laptop> and then at the end compare them
[19:52] <jam-laptop> however,
[19:52] <jam-laptop> the current api (I believe) expects to get everything in sorted order
[19:52] <jam-laptop> so you have to defer returning anything
[19:52] <jam-laptop> until you have processed the whole directory
[19:53] <jam-laptop> not terribly onerous
[19:53] <jam-laptop> but probably would have an impact
[19:59] <n[ate]vw> 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] <n[ate]vw> do users expect bzr to keep the original working form on all same-platform clones?
[20:01] <n[ate]vw> especially with regards to mixed-normalization?
[20:02] <jam-laptop> n[ate]vw: well the concern is that the program generated mixed normalization (MS Office)
[20:02] <jam-laptop> is going to do weird things once you change the normalization.
[20:04] <n[ate]vw> so in the jp locale, MS Office doesn't even want to open a file if it doesn't use fullwidth parentheses?
[20:09] <n[ate]vw> jam-laptop: you'd almost need to keep track of three forms: original form as added, canonical form, form on disk
[20:09] <lifeless> jam-laptop: have you looked at the new check refcount error ?
[20:10] <jam-laptop> lifeless: it looks like it is still present
[20:10] <lifeless> k, I'll fix it then
[20:10] <jam-laptop> !paste
[20:10] <ubotu> 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] <jam-laptop> lifeless: the simple fix should just be: http://paste.ubuntu-nl.org/46034/
[20:11] <jam-laptop> A more complex one would intersect "planned_revisions" with w.versions()
[20:17] <lifeless> abentley: ping
[20:24] <Lo-lan-do> Hallo
[20:25] <Lo-lan-do> I'm stracing a bzr process, just for fun, and I see it repeatedly uses (and unlinks) /tmp/tempfile.tmp
[20:25] <Lo-lan-do> That sounds like a potential security problem, but I'm not sure where it comes from.
[20:25] <Lo-lan-do> (I'm pulling changes from a local bzr-only branch into another branch bound to an SVN repo)
[20:25] <jam-laptop> Lo-lan-do: are you sure it isn't running the test suite?
[20:26] <Lo-lan-do> During a "bzr pull"?
[20:26] <jam-laptop> and is it always explicitly "/tmp/tempfile.tmp"
[20:26] <jam-laptop> or is it using a randomized name
[20:26] <lifeless> Lo-lan-do: I suspect its a bug in bzr-svn
[20:26] <lifeless> jelmer: ^ can you confirm?
[20:26] <lifeless> Lo-lan-do: bzr itself doesn't do that.
[20:27] <Lo-lan-do> There are random names plus /tmp/tempfile.tmp
[20:27] <jelmer> it only uses tempfiles for svn dump files
[20:27] <lifeless> jelmer: does it use a hard coded name though?
[20:28] <jelmer> no
[20:28] <jelmer> tempfile.mkdtemp(prefix='bzr-svn-dump-')
[20:28] <Lo-lan-do> Maybe svn-python then.
[20:28]  * Lo-lan-do grabs the source package
[20:28] <jam-laptop> yeah, I don't see that existing anywhere in the bzr-svn source
[20:28] <jelmer> svn-python doesn't really provide any functionality, it just wraps libsvn
[20:29] <jelmer> and I would be surprised if svn used that file
[20:29] <lifeless> Lo-lan-do: thanks for noticing this
[20:29] <Lo-lan-do> http://paste.debian.net/43600
[20:29] <lifeless> Lo-lan-do: we'd obviously like to fix it; i you can figure out what is doing it that would be fantastic
[20:29] <jam-laptop> any chance you could find what is being written to the file?
[20:29] <lifeless> Lo-lan-do: at least within python you can override open and file
[20:29] <Lo-lan-do> Any wlue what line 3 looks like?
[20:30] <jam-laptop> maybe have a process that spins waiting for it to appear and dumps the content
[20:30] <jam-laptop> I guess the write() calls
[20:30] <jam-laptop> say it is dumping SVN  data into it
[20:30] <lifeless> line 2 suggests SVN
[20:30] <jelmer> Lo-lan-do: can you try with -s 4000 or something?
[20:30] <Lo-lan-do> Yeah
[20:30] <jam-laptop> Lo-lan-do: line 3 *looks* like it might be the data you are copying
[20:31] <jam-laptop> it looks like english with a typo
[20:31] <jam-laptop> 'latd' => 'late'
[20:31] <jam-laptop> other 2, or (atr op) any late inhomogeneous...
[20:32] <Lo-lan-do> http://paste.debian.net/43603
[20:37] <Lo-lan-do> ./subversion/libsvn_client/ra.c:  truepath = svn_path_join(truepath, "tempfile", pool);
[20:37] <Lo-lan-do> Sounds fishy
[20:41] <lifeless> yay svn
[20:41] <lifeless> quick, make an exploit
[20:42] <Lo-lan-do> Maybe I'll just quietly report the problem first :-)
[20:50] <Lo-lan-do> Hm.  Actually, that file is opened with O_EXCL, which fails if a symlink exists.
[20:54] <Lo-lan-do> ...and it even retries with another name if it can't use that precise file.
[20:55] <Lo-lan-do> False alert, then, I guess.
[20:55] <lifeless> Lo-lan-do: still *looks* suspect, and shouldn't be hard to fix
[20:55] <lifeless> what happens if you create that file in advance
[20:55] <lifeless> as root, without permission to unlink
[20:55] <lifeless> (for your user)
[20:56] <Lo-lan-do> From what I read from the code, it tries /tmp/tempfile.2tmp
[20:56] <Lo-lan-do> If that still fails, /tmp/tempfile.3tmp and so on
[21:07] <lifeless> abentley: ping
[21:28] <lifeless> jam-laptop: ping
[21:29] <lifeless> jam-laptop: poolie did not review my fix for 165306; perhaps you could before you finish today ?
[21:45] <jam-laptop> lifeless: sure
[21:46] <lifeless> jam-laptop: thanks.
[22:30] <lifeless> jam-laptop: thanks, replied.
[22:34] <lifeless> bbiab food
[22:59] <poolie> jam, lifeless: ping
[22:59] <poolie> one minute
[22:59] <igc> morning
[23:00] <jam-laptop> morning igc
[23:00] <poolie> hi igc
[23:01] <lifeless> jam-laptop: conf call
[23:01] <poolie> coming to the meeting?
[23:01] <igc> yes
[23:01] <abentley> lifeless: pong
[23:01] <jam-laptop> yep
[23:01] <lifeless> abentley: hi, jst on a call, but will get back to you soon, its about LCA and merge
[23:21] <jam-laptop> lifeless: you don't have to pop the commit, it is fairly trivial, though it has a lot of baggage for such a simple change.
[23:26] <jam-laptop> lifeless: are you sure you want to use __heads? __ parameters can't be used by subclasses
[23:28] <lifeless> jam-laptop: yes, I do
[23:28] <lifeless> jam-laptop: I wanted to use heads() -> _heads(), but you thought that was too public.
[23:28] <lifeless> jam-laptop: we're under a lot of time pressure and I just want to get this out of the way.
[23:29] <jam-laptop> k
[23:29] <jam-laptop> you could just name it
[23:29] <jam-laptop> _graph_heads()
[23:29] <lifeless> if you're not feeling the pressure, fix more bugs:)
[23:29] <jam-laptop> but anyway
[23:29] <lifeless> abentley: hi, so. Did you see my mail about resolving >1 LCA's by merging amonst them rather than recursing for a deeper LCA ?
[23:30] <abentley> You mean the way git does?
[23:30] <lifeless> jam-laptop: I've commented on the missing compression parent bug
[23:30] <lifeless> abentley: appears to; yes.
[23:30] <jam-laptop> thanks
[23:30] <lifeless> jam-laptop: the basic thing is to avoid individual index lookups; so batch and dispatch.
[23:30] <abentley> I don't see why we'd want to do that.
[23:31] <abentley> You can get multiple sets of conflicts, one per merge.
[23:31] <lifeless> abentley: if it can correctly merge without conflicts, even an addition 10% of the time, I'd love it.
[23:31] <lifeless> abentley: I was reminded of this when I spend 40 minutes this morning resolving conflicts because I had a dual-LCA situation
[23:31] <abentley> I'd rather focus on making knit merge rock than follow git's weirdness.
[23:32] <lifeless> abentley: well; I guess I'm asking if its *weird*, or if they've come up with a solid answer.
[23:32] <lifeless> abentley: I agree re: making knit merge rock; its a shame that it will suck in 1.0.
[23:33] <lifeless> (because packs are unannotated)
[23:33] <jam-laptop> what if we go back to per-file LCA's?
[23:33] <jam-laptop> (well, go to, as we haven't ever done it before)
[23:33] <lifeless> jam-laptop: abentley has previous indicated he's against that because it doesn't solve the root problem of >1 LCA's, only defers it.
[23:33] <jam-laptop> The usually have a less complicated graph
[23:33] <lifeless> jam-laptop: my opinion is that deferral is fine if its an improvement :).
[23:34] <abentley> lifeless: Even with un-annotated knits, I bet we can to knit merge quickly.
[23:34] <abentley> As long as we don't annotate lines we don't need to annotate.
[23:34] <jam-laptop> lifeless: your comment on bug 165290 seems like you only detect corruption after the fact, rather than preventing it from the beginning.
[23:34] <ubotu> Launchpad bug 165290 in bzr "packs do not check for missing compression parents" [Critical,In progress] https://launchpad.net/bugs/165290
[23:34] <lifeless> abentley: if a line is common that doesn't mean it has the same introducing revision;
[23:34] <abentley> I actually think using the per-file graph might make sense now.
[23:34] <lifeless> jam-laptop: atomic insertions remember
[23:35] <jam-laptop> write_group.abort?
[23:35] <abentley> lifeless: If a line is common, we don't try to trace its origin in the first place.
[23:35] <lifeless> jam-laptop: just raise an error, there is a sample there - look for missing_texts
[23:35] <lifeless> abentley: oh, ok
[23:36] <abentley> First step in a knit merge is finding the differences in the un-annotated texts.
[23:37] <abentley> So if they came from different sources, but they're the same now, we leave them alone.
[23:37] <abentley> I'm by no means trying to stop other people from implementing merge algorithms.
[23:38] <abentley> But I think knit is the most promising, especialy wrt cherry-picking.
[23:40] <abentley> And using the per-file graph is probably a good fallback strategy when we *are* doing three-way, since semantic mergers will be three-way mergers.
[23:43] <lifeless> yay!
[23:52] <lifeless> jam-laptop: are you redoing your http readv change patch ?
[23:52] <jam-laptop> I submitted an update
[23:52] <jam-laptop> I'm not sure what you are looking for
[23:52] <lifeless> to bb or the bug ?
[23:52] <jam-laptop> to bb
[23:52] <lifeless> the bug is now marked closed wth vila's patch in
[23:52] <lifeless> http://bundlebuggy.aaronbentley.com/request/%3C474C1123.1050903@arbash-meinel.com%3E ?
[23:53] <jam-laptop> lifeless: yes