| lifeless | could be; otoh getting mails from the commits list is enough for me | 00:02 |
|---|---|---|
| ubotu | New bug: #165304 in bzr "smart server data streams not used across repositoryrepresentations" [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:20 |
| 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:25 |
| ubotu | New bug: #165309 in bzr "pack index has no topological locality of reference" [Undecided,New] https://launchpad.net/bugs/165309 | 00:30 |
| 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:31 |
| fullermd | 165071 | 00:32 |
| lifeless | jam-laptop: ^ | 00:35 |
| ubotu | New bug: #165313 in bzr-pqm "working tree clean check comes after branch check" [Undecided,New] https://launchpad.net/bugs/165313 | 01:01 |
| === cprov-out is now known as cprov-zZz | ||
| ubotu | New bug: #165315 in bzr "Cannot version a 3M path tree" [Undecided,New] https://launchpad.net/bugs/165315 | 01:30 |
| beuno | ouch | 01:37 |
| beuno | don't you kind folks do tests on the mozilla tree? Is it that much smaller then the debian source opened up? | 01:38 |
| Odd_Bloke | beuno: It evidently is. ;) | 01:39 |
| lifeless | beuno: its 50K paths | 01:46 |
| 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:47 |
| beuno | lifeless, it's an interesting use cas ethen | 01:48 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 | |
| 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:20 |
| 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:22 |
| j1mc | lifeless: yes, i did do a bzr checkout | 02:23 |
| j1mc | i'll give that a try | 02:23 |
| j1mc | lifeless: here's what i get now: http://pastebin.ca/798882 | 02:28 |
| lifeless | ah, it is a checkout, you really need a full branch I think | 02:32 |
| lifeless | j1mc: have you seen our tutorial ? | 02:32 |
| j1mc | lifeless: no, i haven't. | 02:33 |
| beuno | it's a lightweight checkout. lifeless does unbid work with lightweights too? | 02:34 |
| 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:58 |
| beuno | j1mc, ^ :D | 02:59 |
| 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:06 |
| beuno | j1mc, great then | 03:09 |
| 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:23 |
| 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:24 |
| 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:25 |
| abentle1 | I really don't like your chances of resolving text conflicts in your data. | 03:26 |
| dash | hmm, why's that? | 03:27 |
| dash | all the data is going to be source code of some variety | 03:27 |
| 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:28 |
| 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:30 |
| 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:31 |
| dash | make sense? | 03:33 |
| Odd_Bloke | Yeah, I'm just trying to think of a way to do it. :p | 03:33 |
| Odd_Bloke | You might be best writing a post to the ML, as it'll get more eyes looking at it... | 03:34 |
| 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:35 |
| dash | (for a new language/dev environment) | 03:36 |
| lifeless | dash: so the layering here is: | 03:47 |
| lifeless | repository | 03:47 |
| lifeless | branch | 03:47 |
| lifeless | tree | 03:47 |
| 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:48 |
| abentley | Well, aside from actually performing merging and such. | 03:54 |
| abentley | Since TreeTransform hits the filesystem pretty explicitly. | 03:54 |
| lifeless | right, need to replace that; and the ui layer too of course | 03:59 |
| lifeless | ciao | 04:00 |
| dash | lifeless: awesome | 04:07 |
| dash | lifeless: i am expecting to embed python anyway, so that should work | 04:07 |
| dash | and yeah, I should be able to punt on merging for a while so long as i've got history | 04:08 |
| 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:25 |
| 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:27 |
| Verterok | j1mc: do a 'bzr commit -m "<your commit message>"' first, then a push | 04:29 |
| j1mc | thanks, Verterok | 04:30 |
| Verterok | y're wellcome | 04:30 |
| j1mc | "Pushed up to revision 3624." w00t :) | 04:32 |
| j1mc | thanks | 04:32 |
| === mw is now known as mw|out | ||
| ubotu | New bug: #172249 in bzr "bzr check help out of date / confusing output" [Low,Confirmed] https://launchpad.net/bugs/172249 | 06:40 |
| * 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:18 | |
| 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:20 |
| 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:21 |
| AfC | (needless to say, I have recommended to them that they get with the program and get a bzr:// server going) | 08:22 |
| siretart | Odd_Bloke: thanks! | 08:23 |
| vila | morning | 08:25 |
| vila | Is there a prize associated with the best performance_gained / size(code_modified) ratio ? | 08:25 |
| 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:45 |
| 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 ! | 08:46 |
| vila | siretart: what OS/distro are you using ? | 09:06 |
| 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:11 |
| lifeless | vila: ironic to have a typo given the root cause | 09:23 |
| vila | lifeless: yeah, story of my bzr life ;-) | 09:24 |
| 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:25 |
| lifeless | vila: bb:approve | 09:26 |
| lifeless | vila: JFDI | 09:26 |
| vila | lifeless: :) no way, sub minute cycles are too good :) | 09:27 |
| 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:31 |
| vila | lifeless: ok, I'll merge | 09:32 |
| vila | rats, forgot NEWS update again | 09:33 |
| 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:38 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:45 |
| 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:46 |
| 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:49 |
| 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 | 09:52 |
| 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:00 |
| 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:01 |
| siretart | lifeless: on my list. right after updating the opensync packages :) | 10:02 |
| === cprov-zZz is now known as cprov | ||
| === kiko-zzz is now known as kiko | ||
| === mrevell is now known as mrevell-lunch | ||
| theSoftMan | Hello.. Does somebody have a comparative experience in using Bazaar and Subversion ? | 12:30 |
| mwhudson | i suspect most of the people in here have used svn at one time or another | 12:31 |
| AfC | theSoftMan: what are you looking for? | 12:50 |
| === mw|out is now known as mw | ||
| theSoftMan_ | I ask me what is the right choice for me ? actually i'm using CVS... and i'm looking for other one... | 13:05 |
| theSoftMan_ | I like subversion for it's branch versionning system, atomic commit, binaries files improvements, ... | 13:06 |
| 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:08 |
| Zindar | (sorry.. I'd like to answer... but got a phone call...) | 13:09 |
| theSoftMan_ | How bzr treat binary files ? | 13:11 |
| === mrevell-lunch is now known as mrevell | ||
| === cprov is now known as cprov-lunch | ||
| === kiko is now known as kiko-fud | ||
| 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:46 |
| vila | the simple fix for 165061 has been merged | 14:47 |
| jam-laptop | i saw that, which is good | 14:47 |
| jam-laptop | did you include a NEWS entry? | 14:48 |
| vila | yes, before merging | 14:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| jam-laptop | so you don't abuse my bandwidth | 14:53 |
| vila | or you can push it up here, so *you* abuse mine :-) | 14:53 |
| vila | then I should find a good candidate from your heads() | 14:54 |
| jam-laptop | I can give you a few branches along with it | 14:55 |
| === 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 | ||
| 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 | 16:55 |
| 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:05 |
| n[ate]vw | (hmm, my IRC client doesn't seem to be showing any conversation....) | 17:08 |
| 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:10 |
| 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:11 |
| === weigon_ is now known as weigon | ||
| 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:12 |
| 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:14 |
| n[ate]vw | yeah, I can | 17:15 |
| rthalley | works for me with bzr.dev | 17:15 |
| 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:16 |
| n[ate]vw | http://paste.ubuntu-nl.org/46007/ for the folder | 17:17 |
| fullermd | Mmm. Darwin. | 17:18 |
| 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:19 |
| n[ate]vw | similar error to adding the folder | 17:20 |
| n[ate]vw | http://paste.ubuntu-nl.org/46010/ for the file directly | 17:22 |
| 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:23 |
| n[ate]vw | (paste.ubuntu-nl is hosing some of the unicode -> ??? in those dumps) | 17:24 |
| 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:29 |
| 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:34 |
| 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:35 |
| jam-laptop | 'u'a\u030a' | 17:36 |
| 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:37 |
| 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:38 |
| jam-laptop | there are also some heavy performance issues if you have to normalize every file in a 50k entry tree | 17:40 |
| 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:41 |
| 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:42 |
| 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:45 |
| 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:47 |
| 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:48 |
| fullermd | So it causes double-pane on Windows? | 17:49 |
| * fullermd sneaks back under a rock. | 17:49 | |
| dato | I've asked in several channels, so I guess one more can't hurt. | 17:50 |
| 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. | 17:51 |
| 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:00 |
| 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:11 |
| n[ate]vw | I'm assuming nobody is interested in seeing the several-KB dump when I add the file directly? | 18:12 |
| n[ate]vw | I suppose I could just link to the pastebin, if those don't get cleaned out too quickly | 18:13 |
| 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:14 |
| sabdfl | hey folks | 18:28 |
| sabdfl | do we have dapper packages for bzr 0.92 yet? | 18:28 |
| dato | doesn't seem so | 18:29 |
| ubotu | New bug: #172383 in bzr "Cannot add normalized Unicode file to repo" [Undecided,New] https://launchpad.net/bugs/172383 | 18:45 |
| 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:47 |
| n[ate]vw | whoops, bot beat me | 18:48 |
| 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:55 |
| 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) | 18:59 |
| 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:05 |
| jam-laptop | Some of the normalization calls are still present | 19:06 |
| 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:10 |
| jam-laptop | n[ate]vw: just a bad copy and paste on my part | 19:13 |
| 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:14 |
| 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:16 |
| jam-laptop | nm, it was merged in 3025 | 19:17 |
| jam-laptop | But your name wasn't mentioned in the commit message | 19:18 |
| jam-laptop | so i had trouble finding it | 19:18 |
| 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:19 |
| 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:20 |
| lifeless | hi | 19:22 |
| jam-laptop | morning lifeless | 19:29 |
| jam-laptop | any chance you had time to backport any bzr releases to dapper? | 19:29 |
| 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:31 |
| lifeless | jam-laptop: if we we're scrambling to make packs default, sure. | 19:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| lifeless | well you're the guru | 19:38 |
| lifeless | but I don't see anything thats changed the validity of your prior argument *to* canonicalise. | 19:39 |
| lifeless | brb | 19:39 |
| === abadger1991 is now known as abadger1999 | ||
| jam-laptop | lifeless: the effort required to get it working with dirstate trees | 19:39 |
| jam-laptop | and the performance hit of normalizing | 19:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| n[ate]vw | so each clone could have the working copy in the OS-preferred format, but internally it would be stored canonically? | 19:45 |
| 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:46 |
| 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:47 |
| fullermd | Well, you could skip all the known files at least. | 19:51 |
| 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:52 |
| jam-laptop | not terribly onerous | 19:53 |
| jam-laptop | but probably would have an impact | 19:53 |
| 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.... | 19:59 |
| 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:01 |
| 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:02 |
| 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:04 |
| 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:09 |
| 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:10 |
| jam-laptop | A more complex one would intersect "planned_revisions" with w.versions() | 20:11 |
| lifeless | abentley: ping | 20:17 |
| Lo-lan-do | Hallo | 20:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| Lo-lan-do | http://paste.debian.net/43603 | 20:32 |
| Lo-lan-do | ./subversion/libsvn_client/ra.c: truepath = svn_path_join(truepath, "tempfile", pool); | 20:37 |
| Lo-lan-do | Sounds fishy | 20:37 |
| lifeless | yay svn | 20:41 |
| lifeless | quick, make an exploit | 20:41 |
| Lo-lan-do | Maybe I'll just quietly report the problem first :-) | 20:42 |
| === cprov is now known as cprov-out | ||
| Lo-lan-do | Hm. Actually, that file is opened with O_EXCL, which fails if a symlink exists. | 20:50 |
| Lo-lan-do | ...and it even retries with another name if it can't use that precise file. | 20:54 |
| 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:55 |
| 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 | 20:56 |
| lifeless | abentley: ping | 21:07 |
| lifeless | jam-laptop: ping | 21:28 |
| lifeless | jam-laptop: poolie did not review my fix for 165306; perhaps you could before you finish today ? | 21:29 |
| jam-laptop | lifeless: sure | 21:45 |
| lifeless | jam-laptop: thanks. | 21:46 |
| === kiko is now known as kiko-phone | ||
| === kiko-phone is now known as kiko | ||
| === kiko is now known as kiko-fud | ||
| lifeless | jam-laptop: thanks, replied. | 22:30 |
| lifeless | bbiab food | 22:34 |
| poolie | jam, lifeless: ping | 22:59 |
| poolie | one minute | 22:59 |
| igc | morning | 22:59 |
| jam-laptop | morning igc | 23:00 |
| poolie | hi igc | 23:00 |
| 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:01 |
| 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:21 |
| jam-laptop | lifeless: are you sure you want to use __heads? __ parameters can't be used by subclasses | 23:26 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| abentley | First step in a knit merge is finding the differences in the un-annotated texts. | 23:36 |
| 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:37 |
| abentley | But I think knit is the most promising, especialy wrt cherry-picking. | 23:38 |
| 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:40 |
| lifeless | yay! | 23:43 |
| 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:52 |
| jam-laptop | lifeless: yes | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!