| jelmer | lifeless: http://pastebin.ubuntu.com/110595/ | 00:07 |
|---|---|---|
| jelmer | lifeless, Knit fails | 00:07 |
| jelmer | ValueError: I/O operation on closed file | 00:08 |
| lifeless | oh | 00:08 |
| lifeless | edit bzrlib/knit.py | 00:08 |
| lifeless | change the order of the lines in the cleanup test helper | 00:08 |
| lifeless | your limit needs to be at least 2.5 orders of magnitude bigger | 00:08 |
| lifeless | its in bytes | 00:08 |
| lifeless | so thats 100K, 10M is on the small side of useful | 00:09 |
| jelmer | oh ok | 00:09 |
| lifeless | 100M is ok, 1G is great | 00:09 |
| asabil | is pulling from launchpad over http broken ? | 00:09 |
| jelmer | I'm sure 1G will kill my laptop the way dulwich works | 00:09 |
| lifeless | jelmer: 100M then :) | 00:09 |
| lifeless | asabil: shouldn't be, are you having trouble? | 00:09 |
| asabil | yes | 00:10 |
| nua | just looking at how to create a working tree on the server we have a shared repo on, I've attached a plugin to 'post_change_branch_tip' on the server, which calls push_result.branch.update(), but it doesn't appear to have created any files ...any tips? | 00:10 |
| lifeless | asabil: its working for me | 00:10 |
| asabil | can you branch http://bazaar.launchpad.net/~asabil/libcore/trunk | 00:10 |
| lifeless | nua: you want push_result.branch.bzrdir.open_workingtree().update() | 00:10 |
| nua | lifeless: thanks, I'll give that a go :) | 00:11 |
| lifeless | nua: branches don't have files :) | 00:11 |
| alf | hello, are there any recent benchmarks (eg including btree index) vs older versions vs other DVCSes? | 00:11 |
| nua | lifeless: I must admit the terms confuse me... I'm sure I'll get the hang of this! | 00:12 |
| alf | asabil: I branched just fine (bzr 1.11) | 00:12 |
| asabil | weird | 00:12 |
| asabil | I am using the latest bzr.dev | 00:12 |
| lifeless | nua: repository -> history storage. branch -> a single line of development [sequence of revisions]. workingtree -> thing with your files on disk | 00:12 |
| lifeless | asabil: I branched that fine | 00:14 |
| nua | lifeless: hmm, the call you just recommended gives me an error: "...not a local path" | 00:14 |
| lifeless | asabil: what error are you having though ... | 00:14 |
| asabil | Invalid http response for http://bazaar.launchpad.net/%7Easabil/%2Bjunk/corelib/.bzr/repository/packs/8ae3694b85ab02e2205240ecfa8e4e7e.pack: Expected a boundary (4HBADSmH0_z:3H2yCsdl) line, got '' | 00:14 |
| lifeless | asabil: thats almost certainly a broken proxy in the middle | 00:14 |
| asabil | stupid network operator | 00:14 |
| asabil | thanks lifeless | 00:15 |
| lifeless | we managed to find a bug in squid with bzr, which was extremely surprising | 00:15 |
| nua | lifeless: thanks for your help, think I should sleep now... bye all | 00:15 |
| lifeless | (a ways back now). So I wouldn't be surprised to find other proxies with issues | 00:15 |
| asabil | I have no idea about where and how they proxy stuff | 00:15 |
| asabil | I am surprised that an ISP does so | 00:16 |
| lifeless | many ISP's intercept HTTP across the board | 00:17 |
| lifeless | cisco and other vendors have dedicated protocols to assist doing this. | 00:17 |
| lifeless | you could try http+urllib://... | 00:18 |
| asabil | ok will do thanks | 00:18 |
| lifeless | slightly different code | 00:18 |
| lifeless | might behave differently | 00:18 |
| asabil | doesn't help | 00:19 |
| asabil | this seems to be a transparent proxy I am behind | 00:19 |
| lifeless | can you pastebin the server headers from 'wget -S http://bazaar.launchpad.net/%7Easabil/%2Bjunk/corelib/.bzr/repository/packs/8ae3694b85ab02e2205240ecfa8e4e7e.pack -o/dev/null' | 00:19 |
| asabil | lifeless: http://pastebin.com/d524bf570 | 00:21 |
| lifeless | asabil: nothing obvious, which probably just means its a commerical intercepting cache :( | 00:22 |
| asabil | that's what I guessed | 00:23 |
| asabil | and wget works perfectly with it | 00:23 |
| lifeless | well its a full range request | 00:23 |
| lifeless | if you wanted to sniff the http requests bzr is making and capture the failing one, I'd be happy to eyeball it and see if it really is broken, or if you've magically found a bug relating to packet arrival or some such | 00:24 |
| asabil | yes I can make a wireshark dump | 00:25 |
| spiv | I think -Dhttp might capture a lot of stuff too, but obviously wireshark will work too. | 00:26 |
| asabil | lifeless: you want the whole dump file ? | 00:28 |
| jelmer | lifeless, looks like, uhm | 00:30 |
| jelmer | lifeless, there is "some" room for improvement in dulwich | 00:30 |
| jelmer | http://pastebin.ubuntu.com/110601/ | 00:30 |
| asabil | lifeless: http://people.freedesktop.org/~asabil/bzr-branch.dump | 00:34 |
| === Guest78906 is now known as tjs | ||
| tjs | G'day, just wondering if there is any way to write a server side hook for a bzr repo. I've taken a look at the user guide which links to bzr-push-and-update but that still seems to be something you install on the client. | 00:36 |
| beuno | lifeless, why did you loose the scrollbars? | 00:36 |
| lifeless | beuno: horizonal ones | 00:42 |
| lifeless | beuno: I can't see my full left<->right text in the diff | 00:43 |
| lifeless | tjs: just write a Branch.post_tip_change hook | 00:43 |
| beuno | lifeless, so drop the auto-wrap? | 00:43 |
| lifeless | beuno: it isn't wrapping | 00:43 |
| beuno | lifeless, ah, it's curring off a chunk of the last word? | 00:44 |
| tjs | lifeless: where does that go? | 00:44 |
| tjs | somewhere in the repo's .bzr dir? | 00:45 |
| spiv | tjs: write a plugin | 00:45 |
| lifeless | beuno: yes | 00:46 |
| lifeless | beuno: my browser is about 800 wide, my screen is 1280 | 00:46 |
| spiv | tjs: that installs a hook function for post_change_branch_tip on Branch. | 00:46 |
| lifeless | tjs: plugins are bzr-wide, but you can consult branches for 'should I act here' if you want | 00:47 |
| beuno | lifeless, gotcha. I have it on my list, will see if I can get to theme tweaking soon | 00:47 |
| === dereine is now known as dereine[OFF] | ||
| lifeless | asabil: looks like garbage in the stream | 00:48 |
| lifeless | asabil: if you look at it, it has a reasonable range header, then cruft, then the bazaar format marker, then more noise | 00:49 |
| lifeless | it should be mime/multipart | 00:49 |
| tjs | lifeless, spiv: ok, thing is I'm comming from the SVN world of 'install hooks in hooks dir in the repository'. I get that bzr supports adding plugins on the client side ~/bzr/plugins/. but I'm not sure how to add a plugin to the repository (on a different server, not where the client is run) that would get executed when someone pushes via bzr+ssh | 00:49 |
| lifeless | asabil: or, perhaps I'm using the wrong tool to view :P | 00:49 |
| lifeless | asabil: what did you capture with? | 00:49 |
| tjs | I want to avoid distributing a plugin to everyone using our repo | 00:50 |
| tjs | is that possible? | 00:50 |
| asabil | wireshark | 00:50 |
| lifeless | tjs: same as any plugin - either in ~/.bazaar/plugins/NAME of the account running the bzr command, or in bzrlib/plugins/NAME of the install of bzrlib | 00:50 |
| spiv | tjs: install the plugin on the server | 00:50 |
| lifeless | tjs: (which most plugins' setup.py does automatically) | 00:50 |
| tjs | ok | 00:51 |
| tjs | well that makes more sense | 00:51 |
| tjs | :) | 00:51 |
| lifeless | tjs: if you have multiple user accounts on the box, you'll want the latter option | 00:51 |
| asabil | lifeless: I don't see the problem | 00:54 |
| lifeless | asabil: yeah, I wasn't decoding properly | 00:54 |
| lifeless | asabil: so the content looks ok but truncated | 00:54 |
| asabil | is it truncated ? | 00:55 |
| asabil | to me it looks correct | 00:56 |
| lifeless | its truncated | 00:57 |
| lifeless | you can tell because its a multipart byte range | 00:57 |
| lifeless | http of a single range uses a different representation | 00:57 |
| lifeless | multipart is used for multiple sections being answered; but there is only one section contained in the response | 00:57 |
| asabil | hmm, I see 2 | 00:58 |
| asabil | lifeless: don't you see the string G/8(76f=Y3=hJv=GZ(Or | 00:59 |
| lifeless | this is what a single part response looks like: | 00:59 |
| asabil | 3 times ? | 00:59 |
| lifeless | Content-Range: bytes 0-180/181\r\n | 00:59 |
| lifeless | Range: bytes=0-41,433-2408\r\n is what was asked for in the final request | 01:01 |
| lifeless | so we should get 1.5K of data more or less | 01:01 |
| lifeless | oh, did you tell wireshark to capture all the packet data? by default it only grabs 500 bytes or so | 01:03 |
| asabil | I see Range: bytes=0-41,3824-10459 | 01:03 |
| asabil | they are full | 01:03 |
| Peng_ | jelmer: ping? | 01:03 |
| asabil | I didn't limit the size of the packets | 01:03 |
| jelmer | Peng_, yo | 01:03 |
| Peng_ | Hi. | 01:04 |
| lifeless | asabil: ok | 01:04 |
| asabil | ah now I see | 01:04 |
| asabil | I wasn't looking at the same request sequence | 01:04 |
| asabil | lifeless: are you using asynchronous sockets ? | 01:05 |
| Peng_ | jelmer: Small thing, but in check_subversion_version(subvertpy), I think the "subvertpy" argument is unused. | 01:06 |
| lifeless | asabil: yes, but the main program flow is synchronous, so you shouldn't see overlap on the wire | 01:07 |
| lifeless | f that makes sense :) | 01:07 |
| lifeless | I'm just installing the gui wireshark, I had tshark already but having a little trouble making sure I'm looking at the right stuff | 01:08 |
| asabil | yes, but I have been bitten by the same kind of issue in python width asynchonous sockets a while ago | 01:08 |
| asabil | and with the same network (at my parents place) | 01:08 |
| lifeless | asabil: ah | 01:09 |
| asabil | never managed to figure out the problem | 01:09 |
| tjs | oeor | 01:09 |
| tjs | pqm looks interesting | 01:09 |
| lifeless | so the backend is in a thread I think | 01:09 |
| lifeless | I'm not sure if its selected on or just blocking read() calls are made | 01:09 |
| lifeless | vila will know | 01:09 |
| asabil | oki | 01:09 |
| lifeless | its just installing | 01:09 |
| jamesh | lifeless: last week you were asking about the valgrind patch I did for Python. Here is the bug I attached it to: http://bugs.python.org/issue2422 | 01:10 |
| lifeless | jamesh: thanks! | 01:10 |
| asabil | lifeless: thanks a lot for your help | 01:11 |
| jamesh | requires the valgrind headers to compile, but has no runtime dependency | 01:11 |
| lifeless | asabil: so | 01:12 |
| lifeless | frame 91 asks for 0-41,433-2408 | 01:12 |
| lifeless | 92 is an ack | 01:13 |
| lifeless | 93 has content | 01:13 |
| lifeless | 94 is an ack | 01:14 |
| asabil | (you can right click and select follow TCP stream :p) | 01:14 |
| lifeless | 95 is a single segment with *just* the range 0-41 in it | 01:14 |
| lifeless | (oh guis, I don't get those :P) | 01:14 |
| lifeless | 98 is a FIN/ACK | 01:15 |
| jelmer | jamesh, it doesn't appear to have changed recently - is there any chance of it making it into 2.6? | 01:15 |
| lifeless | anyhow | 01:15 |
| lifeless | I can think of two reasons | 01:15 |
| lifeless | one is that the content that is arrived is bad, and bzr is dropping the connection | 01:15 |
| lifeless | the other is that the content is truncated and bzr is getting a read()->length 0 indicated EOF and closing it | 01:16 |
| lifeless | the latter is what I think is happening | 01:16 |
| lifeless | async sockets will give 0 when read on if they are not ready-to-read though | 01:16 |
| lifeless | its a bad signalling API :( | 01:16 |
| asabil | are they set to NON blocking ? | 01:17 |
| lifeless | checking | 01:17 |
| lifeless | bzrlib/transport/http/* if you're interested in the guts | 01:17 |
| asabil | oki will check too | 01:17 |
| lifeless | readv() is the programming API to this bzr's fetch code uses | 01:17 |
| lifeless | could you run bzr branch..., and get the backtrace from ~/.bzr.log please | 01:19 |
| jamesh | jelmer: I haven't pushed it much recently. I'd be surprised if it got into a 2.6.x release. More likely 2.7/3.1 | 01:19 |
| jelmer | jamesh, ah, ok | 01:20 |
| asabil | lifeless: sure | 01:20 |
| asabil | jelmer: http://pastebin.ca/1320146 | 01:22 |
| asabil | oups | 01:22 |
| asabil | sorry | 01:22 |
| asabil | lifeless: http://pastebin.ca/1320146 | 01:22 |
| lifeless | asabil: I suggest adding | 01:26 |
| lifeless | import pdb;pdb.set_trace() inside the if block | 01:26 |
| lifeless | if boundary_line != '--' + self._boundary + '\r\n': | 01:26 |
| lifeless | import pdb;pdb.set_trace() | 01:26 |
| lifeless | in bzrlib/transport/http/response.py | 01:26 |
| lifeless | then we can inspect the failure interactively | 01:26 |
| lifeless | e.g. | 01:27 |
| lifeless | pp self._file | 01:27 |
| asabil | oki | 01:28 |
| asabil | lifeless: I am inside pdb | 01:29 |
| lifeless | alrighty | 01:30 |
| lifeless | pp self._file | 01:30 |
| lifeless | pp boundary_line | 01:30 |
| vila | pp self._boundary | 01:30 |
| lifeless | its a vila! yay. | 01:30 |
| lifeless | vila: have you followed the problem? | 01:31 |
| * vila yawns | 01:31 | |
| vila | lifeless: only half awake, but yes, I read the backlog | 01:31 |
| asabil | (Pdb) pp self._boundary | 01:31 |
| asabil | '1f1EePYnnXErcjN2PFX5' | 01:31 |
| asabil | (Pdb) pp self._file | 01:31 |
| asabil | <addinfourl at 178238732 whose fp = <socket._fileobject object at 0xa821ed4>> | 01:31 |
| lifeless | ok, so it is a socket | 01:31 |
| vila | pp boundary_line | 01:31 |
| lifeless | vila: do you know, are the urllib sockets in blocking mode ? | 01:32 |
| vila | lifeless: yes, we do blocking read on the http socket | 01:32 |
| asabil | '' | 01:32 |
| asabil | that was the output | 01:32 |
| lifeless | vila: ok. So the symptoms are basically that we're seeing content truncated exactly at the end of the first content range in this particular file - repeatedly | 01:32 |
| vila | asabil: grr, of course, we want the previous value of it please | 01:32 |
| lifeless | vila: other multipart requests seem to work earlier on | 01:33 |
| lifeless | vila: its a while loop on '\r\n' - it won't be interesting :) | 01:33 |
| asabil | vila: not sure I am following :D | 01:33 |
| vila | I agree with your first diagnosis, feels like a bogus proxy | 01:33 |
| vila | asabil: it was a joke :) | 01:33 |
| lifeless | asabil: can you do | 01:33 |
| lifeless | pp self._file.read() | 01:33 |
| vila | '' | 01:34 |
| asabil | '' | 01:34 |
| asabil | :D | 01:34 |
| lifeless | ok, just checking it wasn't going to magically work :) | 01:34 |
| vila | lifeless: well tried... | 01:34 |
| lifeless | if it was a race condition with received content it may have worked :) | 01:34 |
| lifeless | pp self._file.fp.fileno() | 01:35 |
| lifeless | pp self._file.fp.closed | 01:35 |
| lifeless | pp self._file.fp.mode | 01:35 |
| asabil | *** AttributeError: AttributeError("Response instance has no attribute 'fileno'",) | 01:35 |
| vila | pp self._start, self._size | 01:35 |
| asabil | False | 01:35 |
| asabil | 'rb' | 01:36 |
| asabil | (0, 42) | 01:36 |
| lifeless | this is all consistent with correct state in bzr/python | 01:36 |
| lifeless | an unclosed socket that is getting no more bytes from the source | 01:36 |
| asabil | I guess it is a broken proxy | 01:37 |
| lifeless | do you have a lp account? you can branch from bzr+ssh://<rest of url the same> | 01:38 |
| asabil | yes lifeless I can | 01:38 |
| lifeless | cool | 01:38 |
| asabil | I was just trying to help fixing this problem if it was a bug | 01:38 |
| lifeless | yeah | 01:38 |
| lifeless | thank you - I'm pretty convinced that its not. | 01:38 |
| lifeless | but it would be a pain to be behind that ISP | 01:39 |
| asabil | but it seems like it is my ISP | 01:39 |
| asabil | it is largest ISP in Morocco :) | 01:39 |
| lifeless | are they responsive to client requests? | 01:39 |
| lifeless | I'd be happy to help them diagnose this - be good to get it fixed | 01:39 |
| asabil | I can try to call them | 01:39 |
| lifeless | the fact other ones work suggests its a corner case in their environment | 01:40 |
| asabil | but not sure if the call center would understand | 01:40 |
| lifeless | frame 71 starts a sequence that works | 01:41 |
| lifeless | multipart handled correctly | 01:41 |
| lifeless | yah, you probably need level 2 support :( | 01:41 |
| vila | lifeless: you mean in that bzr-branch.dump ? | 01:42 |
| lifeless | vila: yes | 01:42 |
| vila | I can't find a failing one :-/ | 01:42 |
| lifeless | vila: the last one | 01:42 |
| lifeless | frame 91 | 01:42 |
| asabil | but why does bzr open a second http connection | 01:43 |
| asabil | for the last pack request | 01:43 |
| lifeless | asabil: connection: close | 01:43 |
| lifeless | thats an instruction to start a new connection | 01:44 |
| lifeless | its bogus, probably an apache bug | 01:44 |
| lifeless | well, its kindof bogus | 01:44 |
| vila | wow, the file is only 2603, never saw a proxy choke on small files like that | 01:44 |
| lifeless | arguably standards compliant | 01:44 |
| lifeless | vila: what is interesting to me is the FIN from the client, which is odd | 01:45 |
| lifeless | but clearly we reproduced with pdb - you get 0 length reads at that point in the file | 01:45 |
| lifeless | possibly worth a trivial test | 01:45 |
| lifeless | like python, import socket, s = socket(address); s.write(request-from-branch.dump), s.read() | 01:45 |
| vila | lifeless: FIN from the client.... I encountered that once... but can't remember the details | 01:49 |
| * vila falling asleep finally | 01:50 | |
| vila | cu tomorrow | 01:50 |
| asabil | gnight | 01:53 |
| lifeless | thats very odd >< | 02:10 |
| lifeless | asabil: care to do an experiment ? | 02:11 |
| asabil | lifeless: sure | 02:11 |
| lifeless | http://paste.ubuntu.com/110624/plain/ | 02:12 |
| asabil | lifeless: I get 1448 bytes | 02:13 |
| lifeless | oh, I found a bug in my test | 02:14 |
| lifeless | the HTTP/1.1 should be on the same line as the GET | 02:15 |
| asabil | 443 bytes | 02:16 |
| lifeless | ok | 02:16 |
| asabil | well including everything | 02:16 |
| lifeless | paste the repr(p) here? | 02:16 |
| asabil | oki | 02:16 |
| asabil | here or pastebin ? | 02:16 |
| lifeless | either | 02:16 |
| lifeless | 443 bytes is small :P | 02:16 |
| asabil | 'HTTP/1.1 206 Partial content\r\nContent-Type: multipart/byteranges; boundary="BShaWCvE2DQy\'=s2Wasr"\r\nDate: Wed, 28 Jan 2009 02:16:56 GMT\r\nServer: Apache/2.2.8 (Ubuntu) mod_ssl/2.2.8 OpenSSL/0.9.8g\r\nLast-Modified: Fri, 21 Nov 2008 14:05:05 GMT\r\nETag: "1ff4876-a2b-45c3388336640"\r\nAccept-Ranges: bytes\r\nVia: 1.1 bazaar.launchpad.net\r\nConnection: close\r\nAge: 0\r\n\r\n--BShaWCvE2DQy\'=s2Wasr\r\nContent-Type: text/pl | 02:17 |
| asabil | ain\r\nContent-Range: bytes 0-41/2603\r\n\r\n' | 02:17 |
| lifeless | interesting! | 02:17 |
| lifeless | thats clearly truncated | 02:17 |
| lifeless | I get 2619 bytes | 02:17 |
| * asabil thanks his ISP | 02:18 | |
| asabil | but why did the previous request work ? | 02:19 |
| asabil | I mean the one that wasn't even valid http | 02:19 |
| lifeless | it didn't really, it was http/0.9 or so | 02:19 |
| asabil | oh oki | 02:20 |
| lifeless | http://paste.ubuntu.com/110628/plain/ | 02:20 |
| laughyn1nj4 | is anyone about? | 02:22 |
| lifeless | sure | 02:22 |
| laughyn1nj4 | got a strange error in bzr today | 02:22 |
| laughyn1nj4 | can anyone help me? | 02:22 |
| lifeless | this could take a while if you prompt at each step :P just ask away | 02:23 |
| laughyn1nj4 | ok ... wtf does this mean | 02:23 |
| laughyn1nj4 | ERROR:The API for "<Module 'bzrlib' from 'C:\Program Files\Bazaar\lib\library.zip\bzrlib\__init__.pyo'> is not compatible with "(1, 10, 0)". Â It supports versions "(1, 11, 0)" to "(1, 11, 0)". | 02:23 |
| laughyn1nj4 | brb | 02:24 |
| lifeless | asabil: try that updated version, see if it works better | 02:24 |
| lifeless | laughyn1nj4: you have an old bzr-svn or bzrtools | 02:24 |
| lifeless | laughyn1nj4: probably bzr-svn | 02:24 |
| laughyn1nj4 | hmm ... must have re installed with an old version of bzr?!? no other explanation? | 02:25 |
| laughyn1nj4 | are there backwards compatabliity issues if your repo was made using an older version, and now you're using a new one? | 02:25 |
| lifeless | its confusingly formatted, but that is definitely a plugin API compatibility check failing | 02:25 |
| lifeless | nothing to do with your repo format | 02:25 |
| laughyn1nj4 | alls i did was do bzr add | 02:25 |
| laughyn1nj4 | a simple add | 02:26 |
| laughyn1nj4 | from the command line | 02:26 |
| laughyn1nj4 | ok... thanks i'll chekc into it | 02:26 |
| lifeless | like I say, its nothing to do with your projects/repo formats etc | 02:26 |
| laughyn1nj4 | thanks much | 02:26 |
| lifeless | you can verify this easily by running 'bzr --no-plugins <something>' - e.g. 'bzr --no-plugins st' | 02:26 |
| lifeless | asabil: still there? | 02:33 |
| igc | abentley: pqm is falling over on test_shelve_one for me - http://rafb.net/p/oMY0jZ54.html. I don't think it's my problem? I certainly can't reproduce the test failure in my integration branch | 03:15 |
| abentley | igc: I'm rather distracted atm | 03:15 |
| igc | abentley: np | 03:15 |
| igc | I wonder if the pqm environment (Python version, etc.) has changed lately? | 03:15 |
| lifeless | igc: shouldn't have | 03:16 |
| lifeless | spm: ^^ | 03:16 |
| lifeless | igc: looks like gc occuring during the blackbox test | 03:16 |
| spiv | igc: hmm, a failure involving a __del__, that might mean just bad luck. | 03:17 |
| lifeless | igc: your patch may either be the problem, or just have pushed the gc timing to cause the symptom | 03:17 |
| spm | lifeless: I'm not aware of anything? | 03:17 |
| lifeless | spm: didn't think so :) | 03:17 |
| spiv | igc: try inserting a gc.collect() in the base setUp and tearDown, perhaps. | 03:17 |
| igc | spiv,lifeless: ok, I'll try that. Thanks. | 03:19 |
| spiv | igc: I think there's a high probability of this being a race condition in the tests that only shows up if gc happens at the wrong time. Doing gc.collect() for each test is somewhat likely to notice the problem closer to the cause. | 03:20 |
| igc | spiv: so to confirm, add gc.collect() to bzrlib/tests/__init__.py/TestCaseWithTransport/setUp()? I could add it just to the shelve tests if that was better and/or less intrusive? | 03:25 |
| spiv | igc: I think it's likely to be due to a test run sometime before the test that's being failed. | 03:26 |
| spiv | igc: so I'd add it to *every* test, by modifying TestCase | 03:26 |
| igc | spiv: and any risk of slowing down the test suite much? | 03:26 |
| spiv | igc: roughly twice as slow, IIRC :( | 03:27 |
| spiv | It'd be nice to have a flag to turn this on for debugging, but it's too costly to be worth it as the default. | 03:27 |
| spats | oh my goodness! bzrlib is so easy to use! thumbs up, +1, and +1 on the +1! | 03:29 |
| spiv | spats: :) | 03:30 |
| lifeless | spats: cool! what did you do with it, if I may ask? | 03:31 |
| spats | oh, nefarious things. we're adding some commands to bzr in a plugin that do useful things for our developers here - branch from a central trunk into a task branch and check it out locally, that sort of thing. | 03:32 |
| lifeless | spats: cool, glad you're liking the experience | 03:38 |
| * igc lunch | 03:43 | |
| vila | hi all | 07:09 |
| igc | hi vila | 07:17 |
| igc | vila: any chance of a review of http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C4972C8CE.8000205%40internode.on.net%3E today? | 07:29 |
| vila | igc: I'm still catching up with mail, that one is already marked in my box as needing re-read (in fact three mails are marked in that thread) | 07:31 |
| vila | I was hoping than jam or lifeless will answer your last question about split invs adding delete infos to the per-file graph, but my guess is that it still doesn't | 07:33 |
| igc | vila: np | 07:36 |
| vila | igc: I also have a draft regarding -n/--levels I should send (but no review of the code yet) | 07:36 |
| === thekorn_ is now known as thekorn | ||
| etenil | Hi there | 09:28 |
| etenil | I'm having difficulties running bzr-gtk n windows | 09:28 |
| etenil | I can't find any way to start the interface... | 09:29 |
| etenil | oh, I can use bzr olive actually | 09:32 |
| asabil | lifeless: sorry, I got disconnected yesterday | 09:43 |
| asabil | and now branching over http works | 09:45 |
| asabil | I guess it was a problem with my ISP | 09:45 |
| awilkins | etenil: All the "g" commands are gtk equivalents of the CLI ones | 09:55 |
| awilkins | gcommit, gconflicts, etc. | 09:56 |
| etenil | i found my way around | 09:57 |
| etenil | my colleagues are VERY allergic to the console (they're windows users) | 09:57 |
| awilkins | I like qbzr better but it currently has no conflict viewer | 10:00 |
| awilkins | I'd also like it to support external diff viewers | 10:00 |
| awilkins | So I just use gconflicts and the rest of my GUI needs are qbzr | 10:01 |
| etenil | is it possible to use an external program to solve conflicts? | 10:03 |
| etenil | and which one is best in windows? | 10:03 |
| awilkins | etenil: Yes, this is what gconflicts does, by default it uses meld | 10:03 |
| awilkins | etenil: I use Beyond Compare 3 Pro (payware, but cheap for what it does) | 10:04 |
| etenil | is meld available on windows? | 10:04 |
| awilkins | etenil: There's TortoiseMerge, KDiff, all sorts | 10:04 |
| etenil | tortoise merge looks like what i need | 10:05 |
| awilkins | WinMerge | 10:05 |
| etenil | how can i specify to olive to use winmerge or tortoise merge? | 10:06 |
| awilkins | gconflicts has a box for the path to the executable | 10:06 |
| etenil | would it remember the one I choose or do i need to specify it every time? | 10:07 |
| awilkins | I have a patch that lets you feed it a template that hasn't made it into the codebase yet, but it's probably required to get some Windows programs working properly | 10:07 |
| awilkins | Yes, it saves it to the config files | 10:07 |
| etenil | ok | 10:07 |
| etenil | that sounds good | 10:07 |
| etenil | just need to try then ;-) | 10:07 |
| luks | hm, an equivalent of gconflicts seems trivial to implement | 10:14 |
| === asac_ is now known as asac | ||
| awilkins | luks: It can't be that hard, it's only 193 lines of code. | 10:45 |
| awilkins | Well, my patched one is | 10:45 |
| awilkins | I've added a few lines so you can use a template for a parameter for which app to start | 10:46 |
| awilkins | Not all windows apps like the argument style you get from passing a list to popen | 10:47 |
| luks | awilkins: do you mind showing me the modified version? in the future it should be integrated into https://bugs.launchpad.net/qbzr/+bug/247976 but for now I might use a simple gconflicts-like app launching | 10:53 |
| ubottu | Launchpad bug 247976 in qbzr "Support external diff programs" [Wishlist,In progress] | 10:53 |
| etenil | How can I resolve a conflict in bzr-gtk? | 11:06 |
| etenil | I didn't see the command anywhere on the interface | 11:06 |
| etenil | could you help me? | 11:13 |
| etenil | How can I resolve a conflict in bzr-gtk? | 11:26 |
| LarstiQ | etenil: `bzr gconflicts` I suppose? | 11:28 |
| etenil | no I mean form olive, the interface of bzr-gtk | 11:29 |
| etenil | I can merge manually with an external tool, but I still need to run bzr resolve after that | 11:29 |
| etenil | I couldn't find any button for this one | 11:29 |
| LarstiQ | I have no clue what the status of Olive is, but it is not 'the' interface of bzr-gtk | 11:30 |
| * LarstiQ would think most people use the different commands by themselves | 11:31 | |
| etenil | well, probably you don't HAVE to have it on the interface for your users to use it... | 11:32 |
| etenil | I'd really appreciate if it was possible to do it | 11:32 |
| LarstiQ | etenil: I agree with that. I'm just saying, since afaik most people either start commands from the commandline, or use shell integration, Olive doesn't see as active development as the individual gcommands | 11:33 |
| etenil | would it be easy to implement a button to resolve conflicts? | 11:34 |
| LarstiQ | etenil: so while it would be nice to have the alternative, Olive, complete also, that might not be the best way forward for you | 11:34 |
| LarstiQ | etenil: if you can confirm gconflicts does what you think it should, then yes, popping up gconflicts from Olive should be easy. | 11:34 |
| LarstiQ | etenil: if gconflicts does not do enough, that needs to be improved (first, I'd argue) | 11:34 |
| etenil | well, I do use the CLI, but the other users I serve think it sucks, and in a company environment, I don't feel like giving them the finger T_T | 11:35 |
| * LarstiQ nods | 11:35 | |
| LarstiQ | etenil: I get that. | 11:36 |
| etenil | sorry, don't mean to be rude with you | 11:36 |
| LarstiQ | etenil: Olive's conflict support would just be gconflict though, so that needs to work first. | 11:36 |
| etenil | would it be possible to run "bzr resolve" after the external merge tool has exited? | 11:36 |
| etenil | if it would be trivial, I could modify the python script for that | 11:37 |
| etenil | what do you think? | 11:37 |
| LarstiQ | etenil: running it is trivial, I'm not sure it's the right thing to do. | 11:37 |
| etenil | well, that'd be an improvement already | 11:38 |
| LarstiQ | etenil: not if it resolves too much. | 11:38 |
| etenil | it can run only on the current file | 11:38 |
| etenil | ie: bzr resolve <file> | 11:38 |
| LarstiQ | etenil: yes, if after the closing the external merger you are actually done. | 11:39 |
| LarstiQ | etenil: if it is a complex conflicts case, you may well not be. | 11:39 |
| etenil | is it possible to put a button on olive's interface then? | 11:40 |
| LarstiQ | etenil: if it wasn't external, you could have a "resolved/resolve" functionality, and then run it | 11:40 |
| LarstiQ | etenil: sure | 11:40 |
| etenil | would it be hard? | 11:40 |
| LarstiQ | etenil: with external, it is harder to tell | 11:40 |
| LarstiQ | etenil: no | 11:40 |
| etenil | I've never used gtk with python | 11:40 |
| etenil | that would be the best solution in my opinion | 11:43 |
| etenil | are you knowledgeable about python LarstiQ? | 11:43 |
| LarstiQ | etenil: I know my way around. | 11:44 |
| etenil | ok, I'll ask you if I get stuck | 11:45 |
| LarstiQ | ok :) | 11:45 |
| etenil | is that ok? | 11:45 |
| etenil | thx | 11:45 |
| === Pieter__ is now known as pieter | ||
| === pieter is now known as Pieter | ||
| === rocky1 is now known as rocky | ||
| etenil | do I need to import a module to be able to resolve conflicts? | 11:51 |
| etenil | I have a menu item, but I need to run the command now | 11:51 |
| etenil | and I'm not sure how | 11:51 |
| luks | awilkins: FYI qbzr trunk@585 now contains qconflicts, but only as useful as gconflicts, so probably not much :) | 11:52 |
| LarstiQ | etenil: have a look at how it opens a diff window for example | 11:53 |
| LarstiQ | etenil: and then have a look at conflicts.py for the definition of the conflicts window | 11:54 |
| LarstiQ | etenil: and __init__.py for cmd_gconflicts | 11:54 |
| etenil | well, what I just need to run the resolve command and print its output, no? | 11:56 |
| LarstiQ | etenil: for that, see what cmd_resolve from bzrlib.conflicts does | 11:58 |
| etenil | ok | 11:58 |
| etenil | er | 12:02 |
| etenil | I have found the command, but I need to pass the tree to it | 12:02 |
| etenil | not sure where to find it | 12:02 |
| etenil | ok | 12:06 |
| etenil | will try out | 12:07 |
| etenil | I did it!! | 12:19 |
| etenil | cool | 12:19 |
| etenil | is it ok to send back my changes on launchpd? | 12:19 |
| Lo-lan-do | jelmer: I'm sorry for intruding again, but... help! | 12:58 |
| jelmer | Lo-lan-do, np | 12:58 |
| jelmer | Lo-lan-do, what's up? | 12:58 |
| Lo-lan-do | I filtered out all the bzr:* properties from the repo | 12:58 |
| Lo-lan-do | $ bzr branch filtered2/trunk f2+bzr | 12:58 |
| Lo-lan-do | Initialising Subversion metadata cache in /home/roland/.bazaar/svn-cache/9d84d37e-dcb1-4aad-b103-6f3d92f53bf6 | 12:58 |
| Lo-lan-do | bzr: ERROR: The branch filtered2/trunk has no revision None. | 12:58 |
| igc | night all | 13:00 |
| jelmer | Lo-lan-do, can you put that repo online somewhere? | 13:00 |
| jelmer | 'night Ian | 13:00 |
| Lo-lan-do | Sure | 13:00 |
| jelmer | igc: Thanks for the reviews | 13:00 |
| jelmer | igc: Looking forward to trying out your log improvements (-: | 13:00 |
| * Lo-lan-do de-does the filtering on the server | 13:01 | |
| jelmer | Lo-lan-do, hmm, that exception handler triggers in too many situations | 13:02 |
| Lo-lan-do | s/de-does/re-does/ | 13:04 |
| Lo-lan-do | Urgh, apparently some bzr:* properties are still there. | 13:05 |
| Lo-lan-do | Damn, they're *revision* properties and not file properties :-( | 13:05 |
| Lo-lan-do | Fortunately I think I can filter that out without doing the dump|filter|load routine. | 13:07 |
| * Lo-lan-do tries again | 13:09 | |
| Lo-lan-do | Slightly unrelated question: can specifying a newer format when branching accelerate the branching process? | 13:21 |
| Lo-lan-do | What seems to take time here is the "copying revision 1968/5459" stuff. | 13:21 |
| jelmer | Lo-lan-do, yes, 1.9-rich-root will be faster because it's got faster indexes | 13:23 |
| Lo-lan-do | Right. I'll try that for the next try then :-) | 13:23 |
| ToyKeeper | ... it would be terribly nice if bzr had a way to destructively edit history. | 13:27 |
| ToyKeeper | Like dump / edit / reload in svn. | 13:27 |
| ToyKeeper | I have a tool in a closed-source repo that I want to open up, but I'd need to edit any sensitive data out of the history. | 13:28 |
| nevans | ToyKeeper: you can certainly uncommit (and rebase, using the rebase plugin). That would probably get you what you want. | 13:28 |
| nevans | dunno if someone has made any filter script/plugin to automate what you seem to be looking for. | 13:28 |
| ToyKeeper | I've also wanted to do things like split a branch subdir, with history, into the root of a new branch. | 13:29 |
| nevans | bzr help split :) | 13:29 |
| jelmer | ToyKeeper, check out "bzr split" | 13:29 |
| ToyKeeper | I know it would invalidate all the revision IDs, but that's not really a problem. | 13:29 |
| nua | having a real nightmare with this error: http://pastebin.com/m7387496f, it keeps appearing after I've used a repository for a while, this time it occured after commiting .bzrignore | 13:29 |
| ToyKeeper | Last I checked, 'split' didn't do what I was looking for. | 13:29 |
| ToyKeeper | (the opposite of merge-into, basically) | 13:30 |
| jelmer | nua, please file a bug | 13:30 |
| nevans | split retains the old history. that could be a problem if you are looking to open source a closed source package but retain the history. | 13:30 |
| jelmer | nua: (I have no idea what's happening, but that way the problem should get some attention from those who do) | 13:30 |
| jelmer | hi nevans | 13:30 |
| nevans | heya jelmer | 13:31 |
| nua | jelmer: will do, but if anyone knows a workaround let me know, I really need repo access so we can update! | 13:31 |
| ToyKeeper | The use case for the "opposite of merge-into" feature is something like... say a project includes a lot of themes, and someone wants to break a theme into its own repo without the rest of the project history. | 13:32 |
| ToyKeeper | Or, if several projects were incorrectly kept together in one branch, and someone later wants to clean it up by splitting them. | 13:33 |
| jelmer | ToyKeeper, ah, split keeps the history nideed | 13:33 |
| jelmer | ToyKeeper, that operation will always require breaking revision ids | 13:33 |
| ToyKeeper | That's perfectly acceptable. :) | 13:33 |
| ToyKeeper | I'd like to keep the timestamps and log messages, but I expect revision IDs to break. | 13:34 |
| luks | some kind of filter for the bzr-fast-export output should do the job | 13:35 |
| ToyKeeper | Hmm, that's a thought. | 13:35 |
| ToyKeeper | That might work for the opening-a-closed-project case too, though I'm not sure it's worth the effort. It may be better to just use the latest as a new first version, instead of editing sensitive data out of hundreds of patches. | 13:37 |
| jelmer | asabil is working on a filter-branch command that should do something like this I believe | 13:39 |
| asabil | jelmer: I pushed an initial branch | 13:40 |
| asabil | but something is wrong | 13:40 |
| asabil | the commits are empty :/ | 13:40 |
| Lo-lan-do | Over-enthusiastic filter? | 13:40 |
| ToyKeeper | For the remove-sensitive-history case, it might be easier to import it into darcs, edit patches, then convert back. | 13:40 |
| asabil | yep | 13:41 |
| ToyKeeper | Rebase at least should take care of simpler things like removing a revision entirely, like if someone adds a huge binary which shouldn't be there. | 13:42 |
| Lo-lan-do | jelmer: Success! | 13:47 |
| Lo-lan-do | jelmer: The branch completed :-) | 13:47 |
| Lo-lan-do | I therefore present the world with http://pastebin.com/f539dd4ff a filter for "svnadmin dump|filter|svnadmin load" that removes all bzr:* properties from an SVN repo. | 13:49 |
| jelmer | Lo-lan-do, in this particular case I think just the bzr:base-revision / bzr:revision-id revision properties would've sufficed | 13:50 |
| Lo-lan-do | Well, it didn't hurt, and since we changed repos we might as well start from a clean state. | 13:53 |
| jelmer | Lo-lan-do: yeah, of course | 14:10 |
| jelmer | hmm, those version numbers in the ppa are a bit crazy: 0.5.0~rc2~bzr2391-1~bazaar1~jaunty1 | 14:11 |
| asabil | jelmer: you were talking about calling set_revision() before calling complete_revert() yesterday | 14:33 |
| asabil | could you please explain a bit ? | 14:33 |
| hazmat | is there any reason bzr asks users to try and understand 10 different repo formats, and doesn't just default to the latest stable format? | 14:35 |
| hazmat | ie.. just choose the one with the best performance | 14:35 |
| asabil | backward compatibility | 14:36 |
| hazmat | for an init or init-repo command? can't that assumed to be new dev? or you mean compatiblity across distributed clients? | 14:37 |
| asabil | accros distributed clients | 14:37 |
| LarstiQ | hazmat: if you just `bzr init/init-repo` it won't ask about formats and pick the default | 14:38 |
| hazmat | it picks the oldest (0.9.2) .. when there are newer faster versions | 14:38 |
| asabil | for example if you create a repo using the 1.9 format, bzr-1.5 clients will definitely have problems with it | 14:38 |
| LarstiQ | hazmat: 0.92 is still the default | 14:38 |
| LarstiQ | hazmat: which would be 'latest stable format' from a compatibility standpoint | 14:39 |
| hazmat | is there some sort of project/dev policy in place to update that default, or is bzr stuck on 0.9.2 for ? | 14:39 |
| asabil | hazmat: 0.9.2 is not the oldest btw | 14:39 |
| LarstiQ | hazmat: the default has been bumped several times, we are not stuck on 0.92 (no extra .) forever | 14:40 |
| hazmat | cool. thanks for the info.. just wanted to give bzr the best opportunity to impress with speed improvements.. cheers | 14:40 |
| asabil | LarstiQ: could you btw please explain the duality rich-root vs non-rich-root ? | 14:41 |
| Lo-lan-do | What, again? | 14:41 |
| LarstiQ | hazmat: right, you can trade compatibility for speed, if you know who is going to interact with your stuff, you may choose to do so | 14:41 |
| asabil | never got an explanation for that one :D | 14:41 |
| hazmat | and wondering about the conflict for simplicity when compared to the complexity of all the --help options on commands like init/init-repo | 14:41 |
| LarstiQ | asabil: we went over it yesterday with kfogel | 14:41 |
| asabil | oh oki | 14:41 |
| asabil | let me see the log | 14:41 |
| asabil | thanks | 14:41 |
| LarstiQ | asabil: if that doesn't make it clear, feel free to ask again | 14:42 |
| Lo-lan-do | (Might be worth a place in the docs or on the wiki) | 14:42 |
| LarstiQ | Lo-lan-do: yeah | 14:42 |
| LarstiQ | hazmat: maybe we shouldn't display all the formats there by default | 14:43 |
| * LarstiQ makes his first scmproj project | 14:44 | |
| hazmat | hard to say.. but it feels like a case of leaky abstractions.. ditto for rich-root.. end user conceptualization of rich-root.. is to use bzr-svn do magic x | 14:44 |
| sidnei | hazmat: fwiw, i've been bitten by the default repo format too. it's trivial to upgrade to later formats though, just a 'bzr upgrade --<version>' away. i agree that it should probably default to a later version, or at least give you more hints about how to do so. | 14:46 |
| Lo-lan-do | jelmer: Am I right that current versions of bzr-svn don't use svn properties anymore? | 14:50 |
| jelmer | Lo-lan-do: not sure I follow? | 14:52 |
| jelmer | Lo-lan-do, svn file properties you mean? | 14:52 |
| sidnei | one issue is that the next format after 0.92 is 1.6, which is not even 6 months old yet | 14:53 |
| Lo-lan-do | Ah, yes, it's stored in revision properties now I guess. | 14:54 |
| Lo-lan-do | I was wondering why I didn't see anything in an svnlook diff :-) | 14:54 |
| Lo-lan-do | Great, so I'm back with a working bzr-svn setup on the new repo, yay :-) | 14:55 |
| sidnei | LarstiQ: maybe the help for init-repo should refer to 'bzr help current-formats', that text looks a lot more clear | 14:55 |
| LarstiQ | sidnei: yes. Although a place for old formats is probably needed as well. | 14:57 |
| sidnei | LarstiQ: that would be 'bzr help other-formats' | 14:58 |
| LarstiQ | sidnei: done well, I'd support merging a patch that makes the init-repo/init help less overwhelming | 14:58 |
| LarstiQ | sidnei: ah, good :) | 14:58 |
| LarstiQ | sidnei, hazmat: care to write a patch/file a bug for this? | 14:58 |
| asabil | can someone with deep bzr knowledge help me with filter-branch please ? | 15:04 |
| LarstiQ | asabil: I don't know if I can help, but ask your question. | 15:12 |
| asabil | I followed jelmer's advice by using some code from bzr-rebase | 15:13 |
| asabil | I am ablt to rebuild the history graph | 15:13 |
| asabil | but all the commits are empty | 15:13 |
| asabil | the code is in lp:~asabil/+junk/bzr-filter-branch | 15:13 |
| LarstiQ | asabil: entirely empty? No log, no file deltas? | 15:19 |
| asabil | there is a log | 15:23 |
| asabil | but there are no deltas | 15:24 |
| kfogel | https://ldn.linuxfoundation.org/article/dvcs-round-one-system-rule-them-all-part-3#comment-639 | 15:33 |
| kfogel | I've asked for details on how he ran those experiments. | 15:33 |
| jelmer | kfogel, thanks, interesting link | 15:43 |
| jelmer | the brisbane-core branch should fix that last benchmark | 15:43 |
| kfogel | jelmer: might want to follow up saying that | 15:44 |
| LarstiQ | asabil: hmm, the command line has something like --unchanged ('pointless' in bzrlib iirc), you're not doing that I suppose? | 15:47 |
| asabil | no not at all | 15:47 |
| LarstiQ | asabil: I'm currently a bit too winded up to actually look at the code, sorry | 15:47 |
| asabil | no problem LarstiQ, I am not in a hurry anyway | 15:48 |
| asabil | thanks for your help | 15:48 |
| awilkins | vila: ping? | 15:50 |
| vila | awilkins: pong | 15:50 |
| awilkins | vila: Ran into an auth error in 1.11 | 15:50 |
| LarstiQ | vila: Aha! I got .netrc to serve up a password. I had to change some code though, since it tries credentials['host'] but that key isn't present | 15:51 |
| vila | LarstiQ, awilkins: respect the yellow line please except if you're sprinting together :-) | 15:51 |
| awilkins | Is there a sprint on? | 15:52 |
| LarstiQ | vila: unrelated afaik, though we could have stumbled on the same thing at the same time | 15:52 |
| awilkins | Ah | 15:52 |
| vila | LarstiQ: kidding :) | 15:52 |
| vila | awilkins: go ahaead :) | 15:52 |
| LarstiQ | vila: I was making good on my promise from yesterday that I'd look further into .netrc ;) | 15:52 |
| vila | LarstiQ: bug filing or patches welcome anyway | 15:53 |
| awilkins | http://pastebin.ubuntu.com/110884/ | 15:53 |
| awilkins | The value of header on the break line is "NTLM" | 15:53 |
| vila | well, that's not supported anyway :-/ | 15:54 |
| LarstiQ | vila: will do | 15:54 |
| awilkins | vila: Yes, I'm not sure why it's using NTLM, I don't think it's configured that way | 15:54 |
| awilkins | But it may be our proxy sticking it's beak in | 15:55 |
| * awilkins turns off proxy in IE | 15:55 | |
| vila | awilkins: that's your server :) But if you can write a test to reproduce the problem , I'd welcome that warmly | 15:55 |
| awilkins | Aha, when I turn that off, the header is 'Basic realm="webds1lds"' | 15:56 |
| vila | awilkins: by the way, since that's a 407 error, that's indeed your proxy | 15:56 |
| awilkins | So I guess the split is splitting on " " by default | 15:56 |
| awilkins | (Python noob) | 15:57 |
| vila | the problem is that NTLM seems to be unsplittable... | 15:58 |
| awilkins | Yes, I thought so | 15:58 |
| vila | i.e. if the header is only 'NTLM' this can't be split into scheme == 'NTLM' and raw-auth = '' | 15:58 |
| jelmer | that reminds me, I wanted to look at supporting WWW-Authenticate: Negotiate | 15:59 |
| vila | jelmer: isn't it the same thing ? | 16:00 |
| awilkins | Does urllib2 support PAC scripts? | 16:04 |
| awilkins | I get the error when I configure a fixed proxy in IE even if it's configured to ignore local addresses, but if you disable that and just set the PAC script it works ; is this because it's reading the PAC script and going "DIRECT" or is it because it can't use them..... | 16:05 |
| sidnei | it doesn't support PAC scripts, afaict. | 16:06 |
| vila | awilkins: I'd be surprised if urllib2 supported PAC scripts... | 16:08 |
| awilkins | Likewise, must just be because I turned off the manual proxy | 16:09 |
| vila | awilkins: how comes you find the problem only today ? | 16:09 |
| awilkins | I don't push to this server from this network location often | 16:09 |
| awilkins | And I've been running 1.9 too | 16:09 |
| vila | oh, ok, that's worth reporting as a bug anyway mentioning the traceback and the value of header on the break line | 16:10 |
| awilkins | Looks like we need an NtlmAuthRequestHandler in http_utils.py | 16:10 |
| awilkins | I've got a bit of code for detailed stack dumps with parameter values somewhere | 16:11 |
| vila | awilkins: even if it justs refuse to authenticate, yes, that will be a good start | 16:11 |
| vila | or you may define it just in test_http.py for a start | 16:11 |
| vila | igc: ping, I have bzrlib.plugins.usertest.tests.test_blackbox.BlackboxTests.test_usertest_strict failing since a couple of days/weeks and no idea on how to fix it (the test is 3 lines long but the failure output is 800 lines long giving me little hints :-/) | 16:17 |
| jelmer | vila, NTLM is one of the backends of "WWW-Authenticate: Negotiate" | 16:18 |
| jelmer | vila, I'm mainly interested in kerberos, which is the other one | 16:18 |
| vila | jelmer: thanks for the precision | 16:18 |
| jelmer | We'll need custom code to deal with both of them | 16:19 |
| xnox | Hello everyone =D I thought a saw somewhere randomly that ipython can be used as shell, but so that it keeps bzr imported to improve invocation time | 16:40 |
| xnox | Can anyone point me to the right place? | 16:40 |
| Lo-lan-do | xnox: No need for ipython, just run "bzr shell" | 16:40 |
| Lo-lan-do | (In the bzrtools plugin) | 16:41 |
| xnox | ok. But ipython integrates incredibly nicely into emacs......... sigh | 16:43 |
| xnox | but do you think it is possible to merge the two? | 16:44 |
| Lo-lan-do | I may be mistaken about what you call ipython... | 16:44 |
| Lo-lan-do | Isn't it the Microsoft reimplementation of Python over the .net thingy? | 16:44 |
| xnox | no | 16:44 |
| awilkins | ipython is a shell | 16:45 |
| awilkins | IronPython is the CLR implementation of Python | 16:45 |
| Lo-lan-do | Oh, sorry, I'm confusing it with ironpython. | 16:45 |
| Lo-lan-do | Then I'm afraid I don't know :-) | 16:45 |
| xnox | Lo-lan-do: ipython is multi-threded + python interpreter on streroids | 16:45 |
| santagada | xnox: you want to import bzr on ipython and still use ipython for python development? | 16:46 |
| santagada | I don't know but seems like a bad idea | 16:46 |
| xnox | I use it a lot with nympy+scipy+matplotlib which can do resource hungry calculations in a more user-friendly way (+ it opens gui windows with graphs) | 16:46 |
| === NfNitLoo` is now known as NfNitLoop | ||
| santagada | ok but mixing two programs that were not made to work together is flaky | 16:47 |
| xnox | santagada: and use it as my default shell | 16:47 |
| xnox | santagada: there is a launchpad profile for ipython already with uses launchpadlib | 16:47 |
| santagada | the whole idea of modern operating systems is protected memory (well ignoring sing#) | 16:47 |
| santagada | even if it exists I would not trust it with my code :) | 16:48 |
| xnox | I haven't tried it but you can query launchpad for bugz and people | 16:48 |
| santagada | ok | 16:48 |
| santagada | I'm not saying that using it with ipython is bad | 16:48 |
| santagada | I'm saying that mixing it with another completely unrelated program is a bad idea | 16:49 |
| santagada | using it for work | 16:49 |
| * xnox already runs emacs for email, irc, shell, ipython and what not =D | 16:49 | |
| santagada | for example, numpy might be corrupting memory | 16:49 |
| santagada | after all it is a c extension | 16:49 |
| xnox | I see your point | 16:50 |
| santagada | xnox: all those were made to be used together | 16:50 |
| xnox | hmmmmm | 16:50 |
| santagada | xnox: and you can have a subshell in emacs with protected memory and all to run bzr shell | 16:50 |
| xnox | santagada: I'll do that then | 16:51 |
| LarstiQ | as a vi and ipython user, I wouldn't mind some bzr support in ipython | 16:51 |
| santagada | xnox: and I will some day learn emacs :) | 16:51 |
| santagada | I mean really learn emacs | 16:51 |
| LarstiQ | xnox: any idea where you saw that? | 16:51 |
| xnox | LarstiQ: seriosly I can't remember and I've already searched all my browser history | 16:52 |
| xnox | santagada: funny you should say this. I've learned emacs by accident and it was a reason why I've switched to ubuntu | 16:52 |
| santagada | xnox: I'm a textmate user right now, but I use emacs from time to time | 16:54 |
| xnox | santagada: I needed good TexLive installation and a good Latex editor. I've googled and Auctex came up (part of emacs). I managed to install a half broken texlive and a half broken emacs on my mac. Then someone told me "it's all in the repos in Ubuntu" and I'm like really????? So that's why I've tried Ubuntu in VM.... to run emacs =DDDD | 16:54 |
| santagada | it still amases me the python indentation that emacs does and the html mode is also impressive | 16:54 |
| xnox | santagada: textmate is HOT | 16:54 |
| santagada | there is a bzr plugin somewhere, do anyone knows who is responsible for it? | 16:55 |
| santagada | because it is not on the textmate plugin repository and it should really be there if there is any intention to be used by a lot of people | 16:55 |
| xnox | santagada: and then it can't wrap lines backwards. So if you have a paragrah and you strart deleting lines on the say 3 row it will not automaticly join the 3rd line back up | 16:55 |
| xnox | santagada: I thought textmate came prepackaged with it..... | 16:56 |
| LarstiQ | santagada: it is not listed on http://bazaar-vcs.org/IDEIntegration eitehr | 16:57 |
| santagada | xnox: textmate comes with a lot of plugins, them you can install the svn plugin repository that brings many more | 16:57 |
| santagada | LarstiQ: http://bazaar-vcs.org/TextMateBundle | 16:58 |
| LarstiQ | santagada: ah, could you check that out and add it to IDEIntegration and TextMate plugin list if it's still alive? | 16:59 |
| santagada | LarstiQ: it is not... last updated in 2007 | 16:59 |
| santagada | maybe I can improve it | 16:59 |
| LarstiQ | santagada: ah. Contact the author? | 17:00 |
| santagada | LarstiQ: I will contact Jeremy Wilkins... let me see if I can find John Whitley | 17:01 |
| santagada | LarstiQ: can you find its registering email on Bazaar wiki? | 17:02 |
| LarstiQ | awilkins: Jeremy Wilkins doesn't happen to be related to you? | 17:02 |
| * xnox lol | 17:03 | |
| LarstiQ | santagada: you could try bangpath.org@gmail.com | 17:04 |
| LarstiQ | santagada: but as the entire site seems MIA, maybe that doesn't work either | 17:04 |
| LarstiQ | santagada: aha, whitley@acm.org | 17:05 |
| LarstiQ | santagada: if that does not work, the Internet can not help him. | 17:06 |
| santagada | I will mail those guys to see if they want to continue the work somewhere or anything like that | 17:07 |
| LarstiQ | santagada: cool, thanks | 17:09 |
| santagada | LarstiQ: done | 17:13 |
| santagada | LarstiQ: do you know if anyone tried to run baazar on top of some other python implementations? | 17:14 |
| santagada | I could give a try on pypy... though I think that paramiko is not supported | 17:14 |
| LarstiQ | santagada: I'm not aware of such a feat | 17:15 |
| jelmer | monodevelop bzr does some ironpython stuff I think | 17:17 |
| Lo-lan-do | Can one disable display of progress bars for bzr operations? | 17:18 |
| Lo-lan-do | I'd like to run a bzr update in a cron job, and only see the errors. | 17:19 |
| Lo-lan-do | (-q doesn't help) | 17:19 |
| jelmer | Lo-lan-do, there is an environment variable, not sure how it's called | 17:19 |
| Lo-lan-do | Thanks, I'll look it up. | 17:20 |
| Lo-lan-do | BZR_PROGRESS_BAR=none :-) | 17:21 |
| LarstiQ | Lo-lan-do: also see bug 320035 | 17:22 |
| ubottu | Launchpad bug 320035 in bzr "progress bar is shown regardless of the --quiet option" [Low,Incomplete] https://launchpad.net/bugs/320035 | 17:22 |
| xnox | thanks ubottu that was quick! | 17:24 |
| jpds | !thanks | xnox | 17:25 |
| ubottu | xnox: You're welcome! But keep in mind I'm just a bot ;-) | 17:25 |
| xnox | ubottu: stop pretending | 17:25 |
| ubottu | Sorry, I don't know anything about stop pretending | 17:25 |
| santagada | LarstiQ: there isn't a --batch for bzr? | 17:25 |
| santagada | it should | 17:25 |
| santagada | I'm working with the svn client daily and I really hate its support for being used on the command line | 17:26 |
| xnox | ubottu: really? are you like psychotherapist in emacs? | 17:26 |
| ubottu | Error: I am only a bot, please don't think I'm intelligent :) | 17:26 |
| * xnox thinks ubottu should marry emacs psychotherapist | 17:26 | |
| santagada | well if it was made in python it would be much easier to just use the api directly... but there is people who doesn't use python... | 17:27 |
| xnox | santagada: there is pymacs a two way interface between python and elisp which is as close as you can get =D | 17:27 |
| LarstiQ | santagada: what would --batch do? | 17:27 |
| santagada | LarstiQ: don't ask for anything and don't be fancy on output (like progress bars) | 17:29 |
| santagada | if it would also turn strictier error messages the better | 17:30 |
| * vila thinks xnox is weird... what will the children of ubottu and emacs psychotherapist will look like.... | 17:31 | |
| LarstiQ | santagada: ah. I don't think so. | 17:32 |
| LarstiQ | santagada: but BZR_PROGRESS_BAR=none and -q get you a long way | 17:32 |
| === Pilky_ is now known as Pilky | ||
| LarstiQ | santagada: prompts could happen on push/pull/update/commit (the latter on checkouts), uncommit | 17:33 |
| santagada | LarstiQ: svn at least has --non-interactive | 17:33 |
| santagada | turn every prompt to an error | 17:34 |
| santagada | the problem is that sometimes svn fails silently | 17:34 |
| LarstiQ | santagada: I haven't had use for --batch or --non-interactive, but I think it would be merged | 17:34 |
| santagada | LarstiQ: --batch was something I asked about, does it really exists? | 17:35 |
| LarstiQ | santagada: in bzr? No | 17:36 |
| santagada | LarstiQ: ahh ok | 17:44 |
| LarstiQ | !summon bialix | 17:55 |
| ubottu | Sorry, I don't know anything about summon bialix | 17:55 |
| jelmer | jam, ping | 18:15 |
| jam | jelmer: pong | 18:15 |
| jelmer | jam, How should I be using deprecated_list ? | 18:15 |
| jelmer | (since I would have to create SPEC_TYPES on demand) | 18:15 |
| jam | SPEC_TYPES = symbol_versioning.deprecated_list() | 18:15 |
| jelmer | ahh, ok | 18:16 |
| jam | and then later on, consult SPEC_TYPES as part of finding a matching prefix | 18:16 |
| jam | either that, or override .append() and make it actually forward to register | 18:16 |
| jelmer | I'll do the latter, that keeps the deprecated stuff in a single place | 18:17 |
| LarstiQ | are there any other scmproj users around? I'm struggling a bit with how to use subprojects | 18:29 |
| kfogel | If I did 'bzr init-repo', and now want to do it over with the --1.9 or some other option, can I just rm -rf .bzr? | 18:43 |
| santagada | kfogel: I'm not sure, but I guess yes, why would it not be the case? | 18:45 |
| kfogel | santagada: makes sense to me | 18:45 |
| santagada | kfogel: | 18:45 |
| santagada | ops | 18:45 |
| kfogel | Anyone know if I should use --1.12-preview, or just --1.9? | 18:45 |
| santagada | kfogel: why would you use --1.9? | 18:46 |
| kfogel | (I'm testing bzr performance on a large tree -- the Emacs conversion from CVS -- so it's okay to use modern formats). | 18:46 |
| santagada | kfogel: speed? | 18:46 |
| kfogel | santagada: I just assume higher is better. | 18:46 |
| kfogel | santagada: AFAIU, the only reason --1.9 isn't the default is for compat reasons, right? | 18:46 |
| santagada | kfogel: bzr help current-formats | 18:47 |
| santagada | and bzr help formats | 18:47 |
| santagada | and other-formats | 18:47 |
| kfogel | santagada: thank you. | 18:48 |
| santagada | kfogel: If I understood correctly 1.9 is the fastest stable format | 18:48 |
| === dereine[OFF] is now known as dereine | ||
| kfogel | But as a user, I don't want to have to know this stuff... :-). I just want to get "whatever the best format is for a team who will all be using the latest bzr". | 18:48 |
| santagada | kfogel: but if you are benchmarking for a future migration then I think testing the newest kid on the block is also an option | 18:48 |
| === jfroy|work is now known as jfroy | ||
| kfogel | IOW, the only reason I'm even thinking of --1.9 is because I understand that it would be the default were it not for compat concerns. | 18:49 |
| === jfroy is now known as jfroy|work | ||
| kfogel | santagada: well, the future migration may happen before 1.12 comes out, so 1.9 is probably my best bet. | 18:49 |
| LarstiQ | kfogel: bzr upgrade --1.9? | 18:49 |
| santagada | kfogel: help formats has a simple algorithm to choose the repo version :) | 18:49 |
| kfogel | LarstiQ: thank you | 18:49 |
| kfogel | santagada: thanks, reading now | 18:49 |
| LarstiQ | kfogel: might need some care on tree/branch/repo format distinctions, possibly. | 18:50 |
| LarstiQ | kfogel: there is alos `bzr reconfigure` for slightly different usecases | 18:50 |
| santagada | LarstiQ: what kfogel told is that he has not made any commits, so upgrade or deleting and recreating would be the same right? | 18:51 |
| kfogel | LarstiQ: so I'm doing 'bzr init-repo' here, and then I'm going to clone an already-existing branch into it (bzr://bzr.notengoamigos.org/emacs-merges-ce/master/) | 18:51 |
| LarstiQ | kfogel: oh you just have a repo? | 18:51 |
| LarstiQ | santagada: yeah, should be. | 18:51 |
| kfogel | LarstiQ: I'm creating a repo, into which I'm going to pull/mirror this branch. | 18:52 |
| * LarstiQ nods at kfogel | 18:52 | |
| kfogel | The branch is 1.9, so maybe that answers my question. | 18:52 |
| kfogel | hmmm | 18:52 |
| kfogel | I might be saying "branch" where I mean "repository". | 18:52 |
| kfogel | sigh | 18:53 |
| kfogel | I was going to point you at the mail from the person who created that repos, but the emacs-devel@ mailing list archive is broken in such a way as to omit exactly his messages. | 18:54 |
| * kfogel .oO Why is everything at GNU always in a half-broken state? | 18:54 | |
| LarstiQ | hey, the Hurd is not half-broken! :) | 18:55 |
| santagada | :) | 18:55 |
| kfogel | http://paste.lisp.org/display/74430 | 18:55 |
| LarstiQ | kfogel: what does -ce stand for? | 18:56 |
| LarstiQ | are the two the same, apart from 0.92 vs 1.9? | 18:57 |
| kfogel | I'm a little unclear on the difference between a repository and a branch in this context. Jason Earl has created a test conversion of Emacs CVS tree; that's the bzr://bzr.notengoamigos.org/emacs-merges-ce/master/ referred to above. So do I 'bzr init-repo --1.9 emacs-repo' locally and then 'cd emacs-repo' and then 'bzr branch bzr://bzr.notengoamigos.org/emacs-merges-ce/master/ emacs-merges-ce-master', or something like that? | 18:57 |
| kfogel | LarstiQ: I'm not sure why he chose "ce" to refer to the 1.9 version. | 18:57 |
| kfogel | Common Era? | 18:57 |
| santagada | kfogel: creative enhancement? | 18:58 |
| james_w | kfogel: that'll work | 18:58 |
| LarstiQ | kfogel: that'll work | 18:58 |
| kfogel | Personally, I can't stand that abbreviation when used in scholarly publication, because it loses information. But hey, if Jason is doing test conversions for us, I'll make an exception! | 18:58 |
| kfogel | LarstiQ, james_w: cool, thank you | 18:58 |
| LarstiQ | kfogel: I think the entire repo would be 1.9 though, since it's mainly a repository format afaik. | 18:59 |
| james_w | there is a bit of confusion caused by the fact that there are formats for repositories (dealing with revisions storage), branches (tags and the like) and working trees (how the basis tree is stored amogst other things), but they are all wrapped up in to common formats | 18:59 |
| * LarstiQ nods | 18:59 | |
| james_w | so --1.9 refers to a format for each object | 19:00 |
| pickscrape | Does anyone know when bzrtools 1.11 will hit the PPA? | 19:00 |
| LarstiQ | kfogel: in the case that Jason had provided a standalone branch, `bzr reconfigure` would be a tool to make it into a shared repository. | 19:00 |
| kfogel | james_w: thank you. Yes, sometimes that confusion leaks out to user-land. | 19:00 |
| james_w | kfogel: yeah, it's unfortunate. In an ideal world it would be transparent. | 19:00 |
| LarstiQ | pickscrape: I don't. Do you know who the uploader is? | 19:00 |
| pickscrape | Currently apt won't let me upgrade to bzr 1.11 without uninstalling bzrtools first. | 19:00 |
| kfogel | LarstiQ: so a standalone branch is basically a branch that contains its own mini-repository in its .bzr dir? | 19:01 |
| kfogel | james_w: amen | 19:01 |
| LarstiQ | kfogel: exactly. | 19:01 |
| pickscrape | LarstiQ: bzr 1.11 was uploaded by mbp | 19:01 |
| LarstiQ | pickscrape: and bzrtools 1.10? | 19:01 |
| pickscrape | LarstiQ: By jameinel | 19:01 |
| * LarstiQ reads ppa.txt | 19:02 | |
| kfogel | LarstiQ: do you know the hysterical raisins behind the situation? I confess it worries me that pretty much every time someone goes to switch a project over to bzr, or start something new in bzr, the first thing they have to do is enter into this long consideration of (and often discussion of) storage formats and whether or not to make a full repository. | 19:02 |
| LarstiQ | kfogel: I'm frankly surprised at people considering formats. I personally stick with whatever is the default unless I have a very good reason. | 19:04 |
| pickscrape | Yes, that's what we did too | 19:04 |
| LarstiQ | kfogel: but someone today noted that the init/init-repo help lists all the formats | 19:04 |
| LarstiQ | kfogel: That might be a source of the people considering formats, I think moving them away and instead referencing the topics formats, current-formats and other-formats would be better. | 19:05 |
| LarstiQ | kfogel: another reason people consider formats might be interopability with bzr-svn, since that uses a non-default format. | 19:06 |
| santagada | LarstiQ: if you have a repository as big as emacs I think considering the fastest one avaliable is important, as the help formats says | 19:06 |
| kfogel | LarstiQ: Unfortunately, when large (many files, big files, deep history, whatever) projects are considering switching, they have to consider formats, or run into performance issues. | 19:06 |
| LarstiQ | santagada: true | 19:06 |
| kfogel | LarstiQ: yes, that's another cause | 19:06 |
| kfogel | LarstiQ: agreed, about just referencing the formats/current-formats/other-formats help from the option help in init-repo | 19:07 |
| LarstiQ | kfogel: does `help formats` carry a decision tree? It should | 19:07 |
| LarstiQ | ah, it does (in bzr.dev at least) | 19:08 |
| santagada | LarstiQ: yes... help formats is really well written | 19:08 |
| LarstiQ | kfogel: do you think `help formats` helps to diminish the long considering/discussing? | 19:09 |
| mm-mysql | Hey, does anyone know if --fixes=... creates metadata anywhere? If so, how does one see it, I don't see it come up with "bzr log --long".. | 19:09 |
| kfogel | LarstiQ: once one knows about 'help formats', it is a great help! | 19:09 |
| kfogel | But the hurdle is having to think about formats at all. | 19:09 |
| LarstiQ | mm-mysql: yes, it does | 19:09 |
| kfogel | Once the user is there, the lossage is already huge, and 'help-formats' can only mitigate it. | 19:10 |
| LarstiQ | kfogel: right. On that topic, I don't feel too qualified. | 19:10 |
| santagada | kfogel: if help formats were the first place anyone would go to find out more about formats I think it would be a minor problem before some point in the future when a faster repository format is the default, don't you think? | 19:11 |
| LarstiQ | I know I switched to fsfs after the nth time of bdb breaking on me. | 19:11 |
| LarstiQ | mm-mysql: let me have a lookg | 19:11 |
| LarstiQ | mm-mysql: I know launchpad uses the information, and some trac hooks too | 19:12 |
| kfogel | LarstiQ: you mean in svn? | 19:12 |
| mm-mysql | LarstiQ: okay...thanks | 19:13 |
| LarstiQ | kfogel: yes, sorry | 19:13 |
| kfogel | santagada: having to think about repository format at all is a major problem, I think. But it'll be solved once a) the best format is the default, and b) format interop is better. | 19:13 |
| kfogel | LarstiQ: yeah. Fortunately, fsfs is the default and no one has to think about BDB these days unless they're doing something very unusual. | 19:14 |
| LarstiQ | mm-mysql: `bzr help bugs` mentions it is stored in the revision property, but not how to get at it, looking at more code | 19:14 |
| LarstiQ | kfogel: yeah, when I switched bdb was still default | 19:15 |
| kfogel | LarstiQ: long time ago! :-) | 19:15 |
| Lo-lan-do | jelmer: I'm happy to find myself able to work on the svn repo through bzr again, but I'm back into performance problems. | 19:15 |
| Lo-lan-do | http://pastebin.com/d59b55836 for a timing | 19:16 |
| jelmer | Lo-lan-do, was there a bug open about this yet? If not, please file one | 19:16 |
| jelmer | Lo-lan-do, I would like to get this fixed, but I'd like to get 0.5 out first, otherwise I end up maintaining 0.4 and 0.5 in parallel | 19:17 |
| santagada | Is bzr already able to serve a repo using svn's protocol? that was mentioned on the python scm migration thread | 19:17 |
| LarstiQ | kfogel: yeah, I started using svn on 0.11 or something? | 19:18 |
| jelmer | santagada, somewhat | 19:18 |
| jelmer | santagada, It's not production ready yet | 19:18 |
| jelmer | santagada, but some commands (e.g. svn log) are supported | 19:18 |
| Lo-lan-do | jelmer: I'll file a bug, sure. | 19:18 |
| kfogel | santagada, LarstiQ: not bad: http://paste.lisp.org/display/74432 | 19:18 |
| kfogel | LarstiQ: wow, looooooong time ago | 19:19 |
| LarstiQ | kfogel: you has a branch :) | 19:20 |
| LarstiQ | kfogel: not important, but you know you could `bzr init-repo --1.9 emacs-bzr` and save a mkdir step? | 19:21 |
| kfogel | LarstiQ: yes, knew, thanks | 19:22 |
| kfogel | LarstiQ: I put some other notes in there too; didn't show that in the transcript as it can't possibly affect anything, right? | 19:22 |
| kfogel | (they're unversioned) | 19:22 |
| LarstiQ | kfogel: you've lost me. You have unversioned files in the emacs-bzr repo, or in the emacs-merges-ce-master branch? | 19:24 |
| LarstiQ | log only reads historical data, so I would be very surprised if that affected anything | 19:24 |
| kfogel | LarstiQ: 'mkdir emacs-bzr; cd emacs-bzr; emacs mynotes.txt; bzr init-repo --1.9 .; ...' | 19:24 |
| Lo-lan-do | jelmer: Would you remind me of the magic monster sequence of -D flags I should use? | 19:24 |
| LarstiQ | kfogel: unless you get in the territory of 'it was in the file cache and had to be swapped out first', but I think we can ignore that | 19:25 |
| jelmer | Lo-lan-do, I usually only use -Dtransport | 19:25 |
| Lo-lan-do | 'kay | 19:25 |
| jelmer | Lo-lan-do, oh, -Dcache may also be useful | 19:25 |
| kfogel | LarstiQ: now I'm doing a 'bzr log --long -v' | 19:25 |
| LarstiQ | kfogel: I know we can be finicky about creating a bzr object in a non-empty directory, I don't think init-repo minds though. | 19:25 |
| kfogel | and wondering what the difference between -v and --long is (that is, wondering if one is a superset of the other) | 19:25 |
| kfogel | LarstiQ: *nod* thanks | 19:25 |
| LarstiQ | kfogel: -v adds a list of files touched in the revision | 19:26 |
| kfogel | LarstiQ: that wasn't the actual order anyway | 19:26 |
| LarstiQ | kfogel: so it needs to act on more information than just displaying the log | 19:26 |
| LarstiQ | kfogel: -p and -v should have the same cost on reading/parsing I think. | 19:26 |
| kfogel | LarstiQ: conceptually, some people may think of the list of changed files as *part* of the log, the same as all the other metadata associated with the log | 19:27 |
| santagada | jelmer: is there any plans to support http repository access for svn clients? | 19:27 |
| jelmer | santagada, that's already supported | 19:27 |
| LarstiQ | kfogel: right. commit message only > add status output > diffstat > full diff | 19:28 |
| nua | is .bzrignore depreciated? | 19:28 |
| santagada | jelmer: to serve to svn clients? cool, can I read more about it somewhere? | 19:28 |
| jelmer | santagada, oh, you mean the server side? | 19:28 |
| LarstiQ | kfogel: displaying/needing progressively more data from left to right, all can be considered the "log of changes" | 19:28 |
| santagada | jelmer: yep | 19:29 |
| jelmer | santagada, no, there's no work going on to suppport that | 19:29 |
| kfogel | LarstiQ: yeah, that's how I think of it | 19:29 |
| LarstiQ | nua: not at all. `bzr ignore/unignore` are preferred ways to interface with it though. | 19:29 |
| LarstiQ | nua: if you just made it by hand, you might want to `bzr add` it | 19:29 |
| LarstiQ | kfogel: I disagree with people pasting all that information into the commit message though. | 19:30 |
| nua | LarstiQ: ok thanks, it appears to work for me, I was just suspicious as after commiting it to a shared repo the repo died on us. could of course be unrelated | 19:30 |
| LarstiQ | kfogel: the pyglet project for example has (not all of them luckily) commits where the log includes the full diff. | 19:31 |
| sidnei | jelmer: barry mentioned somewhere that the server might start supporting svn clients soon | 19:31 |
| * LarstiQ finds that unreadable | 19:31 | |
| kfogel | LarstiQ: !! | 19:31 |
| LarstiQ | nua: unrelated, I'm rather sure. | 19:31 |
| kfogel | that's insane | 19:31 |
| jelmer | sidnei, the http server? | 19:31 |
| LarstiQ | kfogel: yeah. | 19:31 |
| sidnei | jelmer: he wasn't very specific. | 19:31 |
| LarstiQ | sidnei: launchpad, or svn-serve? | 19:31 |
| jelmer | sidnei, I have put some effort into supporting the native svn protocol (not http) | 19:31 |
| jelmer | sidnei, and that's not very far away | 19:32 |
| sidnei | jelmer: that might have been what he was referring to then | 19:32 |
| sidnei | santagada: so i guess that answers your question | 19:32 |
| santagada | yep | 19:33 |
| * LarstiQ runs to the supermarket for groceries | 19:33 | |
| LarstiQ | if bialix shows up, I've been busy with scmproj today and have ~400 lines of raw notes, the main problem I don't know how to solve is how to use subprojects | 19:33 |
| LarstiQ | bbl | 19:34 |
| theAdib_ | hello: what does does answer to bzr pull means? (I did a bzr branch bla days ago) | 19:48 |
| theAdib_ | adib@nbdel171:~/Projekte/libgnupdf$ bzr pull | 19:48 |
| theAdib_ | Using saved location: http://bzr.savannah.gnu.org/r/pdf/libgnupdf/branches/trunk/ | 19:48 |
| theAdib_ | http://bzr.savannah.gnu.org/r/pdf/libgnupdf/branches/ is permanently redirected to | 19:48 |
| theAdib_ | bzr: ERROR: No repository present: "http://bzr.savannah.gnu.org/r/pdf/libgnupdf/branches/trunk/" | 19:48 |
| === rizitis_ is now known as rizitis | ||
| thumper | theAdib_: it seems that the repo is at http://bzr.savannah.gnu.org/r/pdf/libgnupdf/ | 19:51 |
| thumper | theAdib_: are you missing something? redirected to what? | 19:52 |
| kfogel | LarstiQ: this has been running for at least half an hour I think: time bzr log --long -v > log-long-verbose.out | 19:52 |
| theAdib_ | thumper: I only wanted the files from http://bzr.savannah.gnu.org/lh/pdf/libgnupdf/branches/trunk/files and not the additional directories branches/trunk in my local file system | 19:54 |
| thumper | theAdib_: sure | 19:54 |
| thumper | theAdib_: what have you done so far? | 19:55 |
| theAdib_ | thumper: I only build and run the test suite | 19:56 |
| thumper | theAdib_: so you did a `bzr branch what?` | 19:57 |
| theAdib_ | bzr branch http://bzr.savannah.gnu.org/r/pdf/libgnupdf/branches/trunk libgnupdf | 19:57 |
| jelmer | hmm | 19:58 |
| jelmer | vila, pqm seems to hang on a request from you | 19:58 |
| theAdib_ | thumper: I took this from http://www.gnupdf.org/Dev:Newcomers . | 19:58 |
| thumper | theAdib_: and then you did a bzr pull? | 19:58 |
| theAdib_ | I will remove everything and start again .... | 19:59 |
| thumper | theAdib_: I'm trying this too to see what I get | 19:59 |
| thumper | theAdib_: no, don't do that yet | 19:59 |
| theAdib_ | Yes I did bzr update and after bzr pull | 19:59 |
| mtaylor | lifeless: upgrading from pack-0.92 to 1.9, there are local operations that should become quicker, right? | 19:59 |
| theAdib_ | thumper: btw I work here an Ubuntu 8.10 | 20:00 |
| theAdib_ | adib@nbdel171:~/Projekte/libgnupdf$ bzr version | 20:00 |
| theAdib_ | Bazaar (bzr) 1.6.1 | 20:00 |
| theAdib_ | Python interpreter: /usr/bin/python 2.5.2 | 20:00 |
| theAdib_ | Python standard library: /usr/lib/python2.5 | 20:00 |
| theAdib_ | bzrlib: /usr/lib/python2.5/site-packages/bzrlib | 20:00 |
| theAdib_ | Bazaar configuration: /home/adib/.bazaar | 20:00 |
| theAdib_ | Bazaar log file: /home/adib/.bzr.log | 20:00 |
| thumper | theAdib_: sure, since it looks like you have a standalone branch, you shouldn't need to do an update after the pull | 20:01 |
| thumper | theAdib_: as the pull will update the working tree | 20:01 |
| thumper | theAdib_: you should get a message like: Tree is up to date at ... | 20:01 |
| theAdib_ | pull will synchronize my branch with the original source even I modified my branch? | 20:02 |
| thumper | theAdib_: if you have committed to the branch locally, you should get a warning about diverged branches | 20:03 |
| thumper | theAdib_: if you have uncommitted changes, I think it updates and merges and will let you know of conflicts | 20:03 |
| theAdib_ | I did not commit anything | 20:04 |
| fullermd | kfogel: Interesting set of benchmarks, that. Nice contrast to the more common "make a history with 1..5 revisions and make claims about performance" | 20:08 |
| kfogel | fullermd: when I look at the in-progress log, it's going incredibly slowly. It's only back to March of 2008 so far. The Emacs history goes back to 1985! | 20:10 |
| fullermd | Oh, the log -v? Yeah. That's "special". | 20:11 |
| santagada | kfogel: I think cvs is from around 1984 no? | 20:11 |
| fullermd | On bzr.dev, log --long >> /dev/null takes a bit under 30 seconds for me. Last time I tried it with -v, it was like 15 minutes or so. | 20:12 |
| fullermd | kfogel: I walk talking about that URL you pasted earlier today. | 20:12 |
| kfogel | fullermd: not sure which of several URLs you saw | 20:14 |
| kfogel | santagada: cvs from 1986, but RCS predates CVS | 20:14 |
| santagada | kfogel: cool, so you have history from before cvs... | 20:14 |
| kfogel | santagada: we do, yep | 20:15 |
| kfogel | santagada: Most people don't know it, but Emacs was originally written in ancient Babylonian times on base-60 machines. | 20:16 |
| Lo-lan-do | And before RCS... CPOLD? | 20:16 |
| kfogel | heh. I think RCS was Emacs' first vcs. Unless sccs, maybe. | 20:16 |
| Lo-lan-do | (...by people with 24 fingers) | 20:16 |
| OltreIrc`16561 | hello | 20:18 |
| OltreIrc`16561 | !list | 20:18 |
| ubottu | Hi! I'm #bzr's favorite infobot, you can search my brain yourself at http://ubottu.com/factoids.cgi - Usage info: http://wiki.ubuntu.com/UbuntuBots | 20:18 |
| thumper | :) | 20:19 |
| thumper | perhaps he was wanting people to reply? | 20:19 |
| fullermd | kfogel: The DVCS Roudnup one. | 20:20 |
| kfogel | fullermd: ah yeah, thanks | 20:23 |
| sidnei_ | my guess was that emacs was literally 'written', as in handwritten. that was a close guess then. | 20:24 |
| fullermd | Written? Why write, when we have chisels and all the free stone we could want? | 20:26 |
| fullermd | bialix: LarstiQ was looking for you about an hour ago with scmproj notes. | 20:26 |
| LarstiQ | and I've just returned myself | 20:27 |
| LarstiQ | fullermd: thanks :) | 20:27 |
| bialix | fullermd: hi! | 20:27 |
| fullermd | Synchronicity :) | 20:27 |
| bialix | LarstiQ: heya | 20:27 |
| LarstiQ | bialix: evening! | 20:27 |
| LarstiQ | bialix: did you also just buy toilet paper? ;) | 20:27 |
| bialix | fullermd: thanks, you're my favorite immortal | 20:27 |
| bialix | :-D | 20:27 |
| bialix | no, dinner with daughter | 20:28 |
| * bialix reading backlog | 20:28 | |
| bialix | what is !summon? | 20:29 |
| bialix | LarstiQ: I gues you can ask AmanicA about scmproj | 20:30 |
| LarstiQ | bialix: summon means 'ask to come'. !summon is then an attempt to ask the bot/internet to make you appear :) | 20:30 |
| bialix | LOL | 20:30 |
| LarstiQ | sometimes it works, but maybe that is random chance ;) | 20:31 |
| bialix | Ubootu is not wizard then | 20:31 |
| AmanicA | hi | 20:31 |
| bialix | :-) | 20:31 |
| bialix | Hi! | 20:31 |
| LarstiQ | AmanicA: hello | 20:31 |
| bialix | LarstiQ: subprojects actually in the active development | 20:32 |
| AmanicA | hi LarstiQ, bialix | 20:32 |
| LarstiQ | bialix: ah ok | 20:32 |
| LarstiQ | bialix, AmanicA: I've got a 'libraries' scmproj with 11 branches from a svn repo, that worked nicely after I figured out how to get it there. | 20:32 |
| bialix | nice | 20:32 |
| AmanicA | cool | 20:32 |
| * LarstiQ would now like to include that in a different project that has 3 components itself, and then the libraries subproject | 20:33 | |
| bialix | you're using bzr-svn | 20:33 |
| LarstiQ | bialix: are subprojects supposed to work yet? | 20:33 |
| bialix | :-) | 20:33 |
| bialix | more or less | 20:33 |
| LarstiQ | bialix: yes, I considered branching them from svn myself first, but I figured, why not let scmproj do it! | 20:33 |
| LarstiQ | bialix: only minor point with bzr-svn is that I had set FORMAT in [COMPONENTS], but it didn't carry over to the sub components | 20:34 |
| bialix | I think jelmer and J2ck very close to make bazaar people more happy with bzr-git | 20:34 |
| bialix | all components are independent | 20:35 |
| LarstiQ | but I have lots of notes I can distill out into bugreports/patches | 20:35 |
| bialix | that's great | 20:35 |
| bialix | AmanicA, LarstiQ: while our new layout is not shaped yet I can code subprojects support (experimental) based on old spec. What you think? | 20:36 |
| LarstiQ | bialix: right. But BRANCHES and RELPATH seem to only need to be set in [COMPONENTS] if they're the same for every component (RELPATH = {COMPONENT} suits me fine) | 20:36 |
| AmanicA | yes | 20:36 |
| LarstiQ | bialix: how much work do you think that would be? | 20:36 |
| bialix | LarstiQ: hmm, do you want to say it will be useful to specify default format in COMPONENTS section? | 20:36 |
| AmanicA | then we would have a basis for further work | 20:37 |
| LarstiQ | bialix: yes | 20:37 |
| LarstiQ | bialix: assuming it can be overriden? | 20:37 |
| bialix | LarstiQ: an old spec does explicitly disallow nested subprojects | 20:37 |
| LarstiQ | bialix: one level deep works for me I think | 20:38 |
| bialix | so it should be as easy as one sleepless night | 20:38 |
| LarstiQ | bialix: and if I hit that limit, I know I have to just specify all components again, I can do that if that is how it is | 20:38 |
| bialix | LarstiQ: yes, all defaults can be overriden | 20:38 |
| LarstiQ | bialix: cool | 20:38 |
| bialix | AanicA: yes, basis sounds great | 20:38 |
| LarstiQ | bialix: I don't want to give you sleepless nights, but if it's not too much trouble I'd appreciate subprojects :) | 20:38 |
| bialix | AmanicA: ^ , sorry | 20:39 |
| LarstiQ | kfogel: yeah, log -v is too slow :( | 20:39 |
| bialix | actually the core is already there | 20:39 |
| bialix | it's run_action method | 20:39 |
| AmanicA | bialix, how stable is the config file format? can I start using hacking on it yet? | 20:39 |
| bialix | new format? | 20:39 |
| AmanicA | that format branch | 20:40 |
| LarstiQ | bialix: is [SUBPROJECTS] needed? It's missing from the default project.cfg | 20:40 |
| AmanicA | bialix (I'm not in a hurry, but I may have some time next week) | 20:40 |
| bialix | AmanicA: to make the sketch of subprojects I'll use old format (from trunk branch). New format is good enough, just "everything is optional" is not implemented | 20:41 |
| bialix | LarstiQ" [SUBPROJECTS} ? | 20:41 |
| bialix | sorry | 20:41 |
| bialix | typo | 20:41 |
| bialix | I'd like to defer them right now | 20:42 |
| bialix | there is much smaller set of options for subprojects | 20:42 |
| AmanicA | bialix : I thought you would rather branch lp:~bialix/bzr-scmproj/format-change/ | 20:43 |
| LarstiQ | bialix: get_subproject and set_subproject seem to index on it | 20:43 |
| bialix | AmanicA: but I guess LarstiQ uses trunk | 20:43 |
| LarstiQ | bialix: I did, but if I should use a different branch, I'll switch | 20:43 |
| AmanicA | bialix: I'm just scared that to merg it into format-change later might be more effort | 20:44 |
| bialix | wait a sec guys | 20:45 |
| AmanicA | bialix: but if you think the changes are isolated enough, it should be fine | 20:45 |
| bialix | AmanicA: I guess so. | 20:47 |
| AmanicA | bialix: its up to you as your the one thats going to merge it:) | 20:47 |
| bialix | LarstiQ: will you be there some time? I'll look into the code | 20:47 |
| bialix | :) | 20:48 |
| LarstiQ | bialix: I'll be here till ~23.00 CET | 20:48 |
| bialix | 1 hour? | 20:48 |
| LarstiQ | at least, I always plan to go sleep at time, doesn't always work | 20:48 |
| LarstiQ | bialix: yes | 20:48 |
| bialix | that's ok, I need some time and I'll give some answers about subprojects | 20:49 |
| LarstiQ | cool | 20:49 |
| bialix | LarstiQ: if you want to summon me then it's better to use jaber/googletalk/icq rather than IRC | 20:50 |
| LarstiQ | bialix: aah, good to know | 20:51 |
| LarstiQ | bialix: you have some method of reading irc backlog even though you're not on-channel? | 20:52 |
| bialix | irclogs.ubuntu.com | 20:52 |
| LarstiQ | check | 20:53 |
| bialix | but it's usually 2 hours late | 20:53 |
| fullermd | Darn timezones. | 20:53 |
| === sabdfl1 is now known as sabdfl | ||
| LarstiQ | bialix: it explains how you could reply to things I said :) | 20:53 |
| bialix | no, the script itself is working by cron Iguess | 20:54 |
| fullermd | It's a little known fact that there are actually timezones that never get anything until several hours after it should get there. | 20:54 |
| bialix | LarstiQ: :-D | 20:54 |
| fullermd | For instance, everybody I need things urgently from mysteriously lives in them... | 20:54 |
| LarstiQ | fullermd: :) | 20:54 |
| bialix | fullermd: :-D | 20:54 |
| fullermd | At the moment, there are several that are days off, even. Luckily, in those cases, the alleged "urgency" is on their side, so it's Not My Problem. | 20:55 |
| bialix | LarstiQ: "~400 lines of raw notes" -- wow | 20:55 |
| bialix | LarstiQ: ping | 20:57 |
| bialix | LarstiQ: I'll try to make something workable, though our new format/ new layout should be better here | 20:58 |
| LarstiQ | ~. | 20:59 |
| LarstiQ | bialix: those notes include pasted output of scmproj commands, so I didn't write a lot of prose ;) | 21:00 |
| LarstiQ | bialix: ok | 21:00 |
| bialix | LarstiQ: I guess today I'd better look at your notes | 21:00 |
| LarstiQ | jelmer: are you sure 82086 is fixed? | 21:00 |
| jelmer | bug 82086 ? | 21:00 |
| ubottu | Launchpad bug 82086 in bzr "pycurl transport causes tracebacks if the server's SSL cert cannot be verified." [Medium,Fix released] https://launchpad.net/bugs/82086 | 21:01 |
| LarstiQ | bialix: they're currently in a very raw state, I ask questions that I later answer and such | 21:02 |
| bialix | LarstiQ: that said I'm better to ask the question and write some code at morning | 21:03 |
| bialix | or maybe answer the questons | 21:03 |
| LarstiQ | bialix: fine with me too | 21:04 |
| jelmer | LarstiQ, yeah, you're right. Thanks | 21:06 |
| jelmer | lifeless, ping | 21:06 |
| lifeless | pong | 21:06 |
| jelmer | lifeless, pqm hangfs | 21:07 |
| jelmer | *hangs | 21:07 |
| lifeless | pqm.ubuntu.com? | 21:07 |
| LarstiQ | jelmer: I didn't check all of that spree intensively | 21:07 |
| jelmer | pqm.bazaar-vcs.org | 21:07 |
| lifeless | k | 21:07 |
| lifeless | is it hung now? | 21:07 |
| jelmer | lifeless, yes | 21:07 |
| jelmer | for a couple of hours on "Wed Jan 28 17:03:20 2009 UTC: Vincent Ladeuil <v.ladeuil+lp@free.fr>, '(vila, jam) Make merge_content lca aware' " | 21:07 |
| LarstiQ | jelmer: bug 294479 I'm also not sure of | 21:08 |
| ubottu | Launchpad bug 294479 in bzr "Vast number of round-trips pushing stacked branch" [High,Fix released] https://launchpad.net/bugs/294479 | 21:08 |
| jelmer | LarstiQ, crap, you're right. thanksd | 21:10 |
| lifeless | spm: I'm going to peek | 21:10 |
| jelmer | I'll check the others again as well I guess | 21:11 |
| lifeless | spm: multiple reports of this | 21:11 |
| LarstiQ | jelmer: ok, let me know if I should do a more indepth check too | 21:11 |
| jelmer | LarstiQ, launchpad didn't actually send me any sort of notification though :-( | 21:11 |
| LarstiQ | jelmer: about the changes you made? I got ~60 emaisl | 21:11 |
| jelmer | LarstiQ, yeah | 21:12 |
| jelmer | I'm still waiting for them | 21:12 |
| Lo-lan-do | (It's all an evil plot by me so you'll fix my bugs first :-) | 21:13 |
| lifeless | spm: mail -s Rev... (pid 7014) is blocking pqm | 21:13 |
| lifeless | spm: can we *not* kill it but rather debug it | 21:13 |
| lifeless | jelmer: pqm isn't hanging per se; sending mail is blocking | 21:14 |
| james_w | lifeless: hey, are you in Berlin next week? | 21:14 |
| spm | lifeless: yerrrs. but we're kinda a bit busy with the prep for the LP rollout atm. But will do what I can? | 21:14 |
| lifeless | james_w: no; have metric tonnes of bzr code to get done | 21:14 |
| james_w | lifeless: shame, but I look forward to the output :-) | 21:15 |
| lifeless | spm: ok, well please unhang it for now, but the next hang this really needs debugging | 21:15 |
| spm | lifeless: can we hold for another hour or 2? | 21:15 |
| lifeless | well, commits to bzr trunk are blocked | 21:15 |
| spm | is that a yes or no? :-) | 21:16 |
| lifeless | jelmer: ^ please answer yes or no :P | 21:16 |
| spm | Hahahahahaha :-D | 21:16 |
| jelmer | no :-) | 21:18 |
| jelmer | I think we need a multi-threading PQM and patch order analysis | 21:18 |
| spm | oki, unblocked and should all start working again shortly | 21:19 |
| AmanicA | jelmer: did you run some script or something to close all those bugs?! | 21:20 |
| AmanicA | jelmer: did you run some script or something to close all those bugs?! | 21:20 |
| AmanicA | jelmer: did you run some script or something to close all those bugs?! | 21:20 |
| AmanicA | jelmer: did you run some script or something to close all those bugs?! | 21:22 |
| AmanicA | (sorry if I repeated myself but somethings up with my irc client) | 21:22 |
| LarstiQ | bialix: I'm really sleepy, I'll talk to you tomorrow | 21:33 |
| bialix | me too | 21:33 |
| bialix | good night | 21:33 |
| LarstiQ | sleep well | 21:33 |
| bialix | :-) | 21:33 |
| * bialix waves bye to all | 21:33 | |
| jelmer | lifeless, still there? | 21:55 |
| jelmer | lifeless, I'm pondering about introducing ControlDirFormat and using a separate registry for them | 21:55 |
| sewmyheadon | Hi Folks! Been using BZR for the last three months (migrating from SVN) and have a boneheaded question: I've setup five local repos for projects and would like to change the directory name in which they reside. What's the best way to 'move' or rename the containing directory without harming things? Thanks! | 21:55 |
| jelmer | sewmyheadon, simply renaming them using mv | 21:56 |
| sewmyheadon | I think I found my answer here: https://answers.launchpad.net/bzr/+question/25535 | 21:56 |
| sewmyheadon | jelmer - thanks a bunch! | 21:57 |
| xnox | I've used Olive to see what it looks like and what it does. Played with it until it crashed =D now the bzr tree is locked. How can I unlock it? | 22:03 |
| xnox | Errno 11 | 22:03 |
| phanatic | xnox: bzr break-lock from the command line | 22:03 |
| * xnox feels like he is doing a bank job | 22:05 | |
| xnox | phanatic: bzr: ERROR: The lock for '/home/dmitrij/src/libsword/dima' is in use and cannot be broken. | 22:05 |
| xnox | 22:05 | |
| lifeless | beuno: thank jml please :) | 22:06 |
| jelmer | lifeless, you already mention a hypothetical ControlDir and ControlDirFormat class in bzrdir.py at the moment - was that intended to just be a superclass of BzrDir and BzrDirFormat? | 22:09 |
| lifeless | yes | 22:10 |
| lifeless | the generic logic not tied to.bzr | 22:10 |
| jelmer | Ok | 22:11 |
| jelmer | lifeless, does it sound reasonable to just add that superclass for now, providing the same interface that BzrDir right now implements? | 22:13 |
| lifeless | sure, I mean the reason I haven't is that there aren't obvious benefits other than a sort of clarity | 22:14 |
| lifeless | and it will need tests etc | 22:14 |
| jelmer | hmm | 22:14 |
| lifeless | so I'd be glad to have it there; if its absence is causing you a problem definitely do it. But if having it won't actually help you, well - its your time :) | 22:15 |
| jelmer | yeah, I think I'll just look at making BzrDir.register_control_format() use a registry | 22:15 |
| lifeless | jelmer: isn't it already? | 22:16 |
| jelmer | lifeless, no, it's a list | 22:16 |
| lifeless | oh hmm | 22:16 |
| lifeless | I used a list for ordering | 22:16 |
| jelmer | lifeless, it's the last thing blocking bzr-svn's __init__ to just being a list of register_lazy() calls | 22:16 |
| jelmer | *from | 22:16 |
| lifeless | ok | 22:17 |
| lifeless | so this object that is in the list could be a lazy object | 22:17 |
| jelmer | similar story for bzr-git and bzr-hg (that one will save a lot of time) | 22:17 |
| jelmer | If ordering matters I guess I should keep it a list | 22:17 |
| lifeless | probing costs | 22:18 |
| lifeless | old obsolete formats shouldn't be probed before current [thats internal to the bzr specific ones atm] but also .bzr should be probed before .svn/.it/.hg | 22:18 |
| spiv | Yeah, I agree with lifeless. | 22:20 |
| lifeless | a ListRegistry would be useful | 22:21 |
| lifeless | transports need this too | 22:21 |
| jelmer | hmm | 22:21 |
| lifeless | but I think its done specifically for transports today rather than generically | 22:21 |
| jelmer | So I could use _LazyObjectGetter and _ObjectGetter from registry, but they're private at the moment | 22:22 |
| lifeless | that just means they are not stable IMO | 22:22 |
| lifeless | consenting adults - its ppython | 22:22 |
| jelmer | I always get confused by what _ means | 22:23 |
| lifeless | it means nothing | 22:23 |
| lifeless | python fails so epically here you can basically ignore it | 22:23 |
| lifeless | a thing without _ is 'public stable supported and maybe deprecated' in bzr. Something with '_' is not (public and stable and supported) | 22:24 |
| spiv | I could have sworn bzr imbued a leading _ with meaning that's relevant to plugin authors? | 22:25 |
| jelmer | lifeless, yeah, that bit I do get - it's clear for external API users. It's a bit more vague for internal or plugin users | 22:25 |
| lifeless | spiv: we try, but I think we fail | 22:25 |
| jelmer | lifeless: So I take it to mean it's fine to use those objects from bzrlib.bzrdir ? | 22:25 |
| lifeless | concretely | 22:25 |
| spiv | jelmer: hmm, I think of plugins as external API users. | 22:25 |
| lifeless | concretely we have no way to discriminate between 'I used this for impleentation noone else gets to play' | 22:26 |
| lifeless | and between 'this is not to be used outside of bzrlib because its subject to change' | 22:27 |
| lifeless | so really, you need to read docstrings to decide | 22:27 |
| lifeless | the key thing is that if you use something with _ you need to be willing to deal with it changing or being told that its not supported to you get to pickup both pieces | 22:27 |
| lifeless | which boils down to 'be a consenting adult' | 22:28 |
| lifeless | lifes too short :) | 22:28 |
| lifeless | spiv: I agree that plugins are external users - but they have the same needs as much of the in-bzrlib code - to reuse things the author didn't expect reuse to occur on | 22:30 |
| lifeless | Aaron has expressed a desire not to incur tech debt or migration costs for code he doesn't consider 'done', which came up in a discussion around what _ really means | 22:30 |
| spiv | Oh definitely. Plugins are great at finding places where our public+stable+supported API needs improvement :) | 22:30 |
| lifeless | spiv: thats one side of the coin :) | 22:31 |
| spiv | Hmm. It is nice to avoid tech debt. But it's also nice to enable sexy plugins... | 22:31 |
| jfroy|work | lifeless: This will be an unusual, out of the blue question which you may not know the answer to, but here goes: who at Canonical should someone contact about Bazaar? | 22:31 |
| lifeless | spiv: so sexy plugins should use what they need; and if they care file bugs asking for the things they use to be made into stable apis. But don't block on the api existing - thats a chicken n egg situation | 22:32 |
| lifeless | jfroy|work: well, any of us are good starts. What can I help you with ? :) | 22:33 |
| spiv | lifeless: right. But at that point a "not done" API has magically turned into something that starts to incur a bit of tech debt for someone (possibly us, possibly the plugin author). | 22:34 |
| lifeless | spiv: my point is that on the bzrlib side it doesn't have that debt: the plugin author using it has the onus of dealing with changes until the thing is made stable | 22:34 |
| * spiv nods | 22:35 | |
| LaserJock | is there a reason why the ~bzr repo has been inconsistent for a bit? | 22:36 |
| lifeless | LaserJock: ? | 22:39 |
| LaserJock | lifeless: I've been unable to upgrade bzr/bzrtools/bzr-svn for a couple weeks | 22:39 |
| LaserJock | it keeps wanting to remove bzrtools and/or bzr-svn | 22:39 |
| lifeless | oh you mean the ppa? | 22:39 |
| LaserJock | yeah, the ~bzr one | 22:39 |
| lifeless | heh, repo terminology conflict :P | 22:40 |
| LaserJock | sorry, was perhaps not clear | 22:40 |
| LaserJock | oh, right, too much overloading | 22:40 |
| LaserJock | ;-) | 22:40 |
| lifeless | I'm not sure | 22:40 |
| lifeless | jam: ? | 22:40 |
| lifeless | probably a on uploaded bzrtools and bzr-svn or something | 22:41 |
| jam | lifeless: I believe Martin failed to build the extras like bzr-svn and bzrtools when he built the bzr-1.11 package | 22:41 |
| LaserJock | I know often bzr will get updated and it takes a while to get bzrtools/bzr-svn updated | 22:41 |
| jelmer | I uploaded bzr-svn a couple of days ago | 22:41 |
| jelmer | I mean yesterday | 22:41 |
| LaserJock | yeah, it looks like right now it's blocking on bzrtools | 22:42 |
| === dereine is now known as dereine[OFF] | ||
| thumper | something in the last few days of bzr updates has made it impossible over the smart server | 22:55 |
| thumper | especially to launchpad | 22:55 |
| thumper | I'm not sure what it is | 22:55 |
| thumper | but it was taking over an hour (I killed it) to pull udpates | 22:55 |
| thumper | when there wouldn't have been much | 22:55 |
| thumper | is this just me or are others effected? | 22:55 |
| spiv | thumper: it's news to me, at least. What's the -Dhpss trace look like? | 22:57 |
| fullermd | Casual use in the last few days didn't show anything up to me. | 22:57 |
| asabil | lifeless: did you see my message ? | 22:58 |
| lifeless | asabil: oh thanks | 22:59 |
| lifeless | asabil: did you see my updated test? | 22:59 |
| asabil | no, I got disconnected yesterday | 22:59 |
| lifeless | http://paste.ubuntu.com/110628/plain/ | 22:59 |
| asabil | lifeless: 1171 bytes | 23:00 |
| asabil | and branching over http works now | 23:00 |
| thumper | spiv: I'm going to privmsg a pastebin as it has some sensitive stuff in it | 23:01 |
| lifeless | asabil: 1171 is still short :( | 23:01 |
| asabil | I guess one of their proxy wasn't working correctly | 23:01 |
| asabil | heh | 23:01 |
| asabil | oups sorry | 23:02 |
| thumper | spiv: it may just be my freaking ISP | 23:02 |
| thumper | spiv: I've been having some issues with disconnections on IRC | 23:03 |
| thumper | spiv: however I did manage to stream a big bzr branch over http at almost 4meg/sec | 23:03 |
| asabil | lifeless: 1448 + 1171 | 23:03 |
| asabil | sorry, didn't count the 1st chunk | 23:04 |
| lifeless | asabil: ah cool | 23:05 |
| lifeless | asabil: thats good | 23:05 |
| asabil | :) | 23:05 |
| asabil | thanks a lot for your help and patience | 23:05 |
| lifeless | bzr is close to my heart :) | 23:06 |
| asabil | hehe :) | 23:06 |
| fullermd | The angioplasty of version control. | 23:06 |
| thumper | spiv: I'm investigating my local network speed, it seems to be somewhat fuxored | 23:08 |
| spiv | thumper: interesting; it got the start of a readv response, but didn't get the body of it | 23:09 |
| asabil | if someone with some free time can help me with bzr-filter-branch I would be more than happy | 23:09 |
| spiv | thumper: the largest .six file in that repo is < 3MB, so I doubt the server got bogged down with buffering it | 23:09 |
| spiv | thumper: so yeah, I suspect network issues. | 23:09 |
| asabil | the code is in lp:~asabil/+junk/bzr-filter-branch | 23:09 |
| asabil | it rebuilds the history graph correctly, but the commits are empty | 23:10 |
| asabil | no deltas | 23:10 |
| * thumper doesn't really want to talk to stupid ISP help desk :( | 23:10 | |
| lifeless | asabil: so this is meant to be a git-filter-branch lookalike ? | 23:16 |
| asabil | lifeless: yes | 23:17 |
| asabil | but better | 23:17 |
| asabil | :p | 23:17 |
| asabil | since it's for bzr | 23:17 |
| lifeless | so I'm curious why you are building fresh rather than reusing rebase | 23:17 |
| asabil | it will probably be merged with rebase | 23:18 |
| asabil | it is still experimental | 23:18 |
| asabil | I talked to jelmer about it yesterday as well, for the merge with rebase | 23:18 |
| asabil | (and maybe have some kind of bzr-history-manipulation plugin) | 23:18 |
| asabil | I am still trying to dive into the bzrlib APIs | 23:19 |
| mwhudson | is there a ui for "make this branch not stacked" yet? | 23:20 |
| mwhudson | something on reconfigure? | 23:20 |
| * mwhudson looks | 23:20 | |
| mwhudson | seems not | 23:20 |
| * fullermd . o O (bzr topple?) | 23:20 | |
| mwhudson | snort | 23:21 |
| mwhudson | anyway, the python command line is all the ui _i_ need :) | 23:21 |
| lifeless | asabil: is it unit tested? | 23:23 |
| asabil | lifeless: nop, not at all | 23:24 |
| lifeless | k, well I probably won't look then :P - I know rebase's unit tests, and would be inclined to add this sort of thing there | 23:24 |
| asabil | as I said, for now, it is a way for me to explore the bzrlib apis | 23:24 |
| lifeless | ok, cool | 23:24 |
| asabil | but I am a fervent lover of tdd, so don't worry | 23:24 |
| asabil | I just need help understanding how history information is represented in bzr | 23:25 |
| lifeless | there are various docs scattered around | 23:26 |
| lifeless | most of the library talks about apis for history rather than actual representation | 23:26 |
| lifeless | http://bazaar-vcs.org/Classes | 23:27 |
| sohail | hi, I want to do some parallel development on version+1 with my bzr repo... how do I do it without creating a copy of everything? | 23:28 |
| lifeless | sohail: do you mean you want two branches but only one working copy? | 23:28 |
| sohail | lifeless, that would be ideal | 23:28 |
| asabil | oh thanks lifeless | 23:29 |
| lifeless | sohail: assuming you have a branch today, you just need to seperate out the branch and tree | 23:30 |
| lifeless | sohail: so ... | 23:30 |
| lifeless | cd $branch | 23:30 |
| lifeless | bzr push ../b1 | 23:30 |
| lifeless | bzr push ../b2 | 23:30 |
| sohail | what what... | 23:30 |
| lifeless | bzr bind ../b1 | 23:30 |
| sohail | I'm lost already | 23:30 |
| lifeless | then hack hack hack, commits will be going to ../b1 | 23:31 |
| lifeless | when you want to switch, 'bzr switch b2' | 23:31 |
| lifeless | and you'll be on the b2 branch, hack hack hack here, commits go to b2 | 23:31 |
| sohail | ok so I have (on another machine) /home/sohail/bzr/code/master | 23:31 |
| sohail | I have done bzr clone $THAT_REPO here | 23:32 |
| sohail | where does bzr push ../b1 come from? | 23:32 |
| lifeless | well you need two branches | 23:32 |
| lifeless | so if master is one of the branches | 23:32 |
| lifeless | you still need to create a second | 23:32 |
| lifeless | that is seperate from your working copy | 23:32 |
| sohail | but my repo is gigantic | 23:33 |
| lifeless | ok | 23:33 |
| sohail | are you saying I need to create another copy (i.e., the second branch?) | 23:33 |
| lifeless | if you have a huge repo we need to be a little bit more complex | 23:33 |
| lifeless | is there a repository at /home/sohail/bzr/code on the other machien? | 23:33 |
| sohail | I have a "main" repository at server:/home/sohail/bzr/code/master that I push to | 23:34 |
| lifeless | thats a branch | 23:34 |
| lifeless | did you setup a shared repository for that ? | 23:34 |
| sohail | nope | 23:34 |
| lifeless | ok, lets do that, its only a couple commands | 23:34 |
| lifeless | can you ssh in there? | 23:34 |
| sohail | yep | 23:35 |
| lifeless | do so, and please psate the result of 'bzr info master' | 23:35 |
| sohail | ok I'm there | 23:35 |
| sohail | Location: | 23:35 |
| sohail | shared repository: /home/sohail/bzr | 23:35 |
| sohail | repository branch: master | 23:35 |
| sohail | I guess it is shared... | 23:35 |
| lifeless | ah - there is a shared repo :) | 23:35 |
| lifeless | cool | 23:35 |
| sohail | what does that mean anyway | 23:35 |
| sohail | nm, I'm reading please continue | 23:36 |
| lifeless | it means that the history store - the thing that gets big with all your commits :) - is shared across multiple branches | 23:36 |
| lifeless | bzr branch master $NEWBRANCHNAME | 23:36 |
| lifeless | this should be subsecond | 23:36 |
| sohail | still going... | 23:36 |
| lifeless | ok when it finishes | 23:37 |
| lifeless | cd $NEWBRANCHNAME | 23:37 |
| lifeless | bzr info | 23:37 |
| sohail | still going hehe | 23:38 |
| sohail | ok here comes the paste | 23:38 |
| sohail | Repository tree (format: pack-0.92) | 23:38 |
| sohail | Location: | 23:38 |
| sohail | shared repository: /home/sohail/bzr | 23:38 |
| sohail | repository branch: . | 23:38 |
| sohail | Related branches: | 23:38 |
| sohail | parent branch: /home/sohail/bzr/code/master | 23:38 |
| lifeless | bzr remove-tree . | 23:38 |
| sohail | done | 23:39 |
| lifeless | what happened here is that your repository is set to create working trees, but you don't need one here, you just want the branch data | 23:39 |
| sohail | nice | 23:39 |
| lifeless | so you should have an emptyish directory (only having .bzr) | 23:39 |
| sohail | yep.. 44k | 23:39 |
| lifeless | ok | 23:39 |
| lifeless | now, back on your other machine | 23:39 |
| lifeless | do you want to work disconnected ? | 23:40 |
| sohail | not usually | 23:40 |
| lifeless | ok | 23:40 |
| lifeless | so the simplest thing then is just to go to your clone that you made | 23:40 |
| lifeless | and run 'bzr bind $URL_OF_MASTER' | 23:40 |
| sohail | done | 23:41 |
| lifeless | now, when you do a commit, it will go immediately to master on the other machine | 23:41 |
| sohail | ah | 23:41 |
| sohail | sweet | 23:41 |
| * sohail was getting tired of commit && push :-) | 23:41 | |
| lifeless | to change the target you can run 'bzr branch $NAME_OF_NEW_BRANCH' | 23:41 |
| lifeless | sorry | 23:41 |
| lifeless | s/branch/switch/ | 23:42 |
| sohail | ok so if $NEWBRANCHNAME was next, I do bzr switch next | 23:42 |
| lifeless | e.g. 'bzr switch next' | 23:42 |
| lifeless | yes | 23:42 |
| lifeless | and you can switch back with 'bzr switch master' | 23:42 |
| sohail | done | 23:42 |
| sohail | sweet | 23:42 |
| sohail | maybe I should rename that to be... current | 23:42 |
| lifeless | you can give switch any url you want, but short names are looked up adjacent to the current target | 23:42 |
| davidstrauss | Can I reorder threads in bzr loom? | 23:42 |
| sohail | so how would I merge between them? | 23:42 |
| lifeless | sohail: bzr switch master; bzr merge url_of_next; bzr commit -m 'merge next' | 23:43 |
| sohail | thanks lifeless | 23:43 |
| sohail | am I set? | 23:43 |
| lifeless | yah | 23:43 |
| lifeless | read up on this stuff if yo ulike | 23:43 |
| sohail | you are a saint | 23:43 |
| sohail | I tried | 23:43 |
| sohail | is there a bzr book like the svn book | 23:44 |
| === thumper_laptop is now known as thumper | ||
| sohail | oh one more thing, is it possible to see which commits would get merged? It would make a changelog easier | 23:44 |
| lifeless | bzr st -v | 23:44 |
| lifeless | after doing the merge before committing | 23:45 |
| thumper | spiv: my network was slowed to dial-up, which may have been part of the problem | 23:45 |
| sohail | great | 23:45 |
| sohail | thanks lifeless | 23:45 |
| spiv | thumper: ah :) | 23:45 |
| lifeless | davidstrauss: there isn't really a ui for it today; it is effectively a cherrypick though - so | 23:47 |
| lifeless | bzr create-thread new-lower | 23:48 |
| lifeless | bzr merge -r thread:one_below_old_upper..thread:old_upper . | 23:48 |
| lifeless | bzr commit -m "merge old -upper" | 23:48 |
| lifeless | bzr switch old-upper | 23:48 |
| lifeless | bzr remove-thread | 23:48 |
| lifeless | (roughly that; do a record first, so you can revert-loom if you mess it up :) | 23:49 |
| davidstrauss | lifeless: thanks! | 23:49 |
| davidstrauss | lifeless: remove-thread? | 23:50 |
| davidstrauss | lifeless: that command does not exist | 23:51 |
| lifeless | combine-thread | 23:51 |
| davidstrauss | lifeless: after reverting the changes, i assume | 23:51 |
| lifeless | davidstrauss: uhm maybe :P | 23:52 |
| lifeless | housekeeping wise what you want to achieve is | 23:54 |
| lifeless | - merge the higher thread into a new lower one, and propogate this up through all the threads that didn't previously have the higher ones content | 23:55 |
| lifeless | - tell the thread immediately above where the higher thread was that it still has the content of the moved thread | 23:55 |
| lifeless | - remove the old higher thread as its now a meaningless placeholder | 23:56 |
| davidstrauss | Is there a way to collaborate on looms? | 23:56 |
| davidstrauss | Looms seem to not replicate over push | 23:56 |
| lifeless | absolutely - bzr record; bzr push URL | 23:57 |
| lifeless | the thing missing today is 'bzr merge LOOM' cause noone has gotten around to it :( | 23:57 |
| lifeless | the data structure has space for it though | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!