| jelmer | hmm, that doesn't make sense to me either | 00:00 |
|---|---|---|
| jelmer | abentley, ^ | 00:00 |
| jelmer | abentley: http://bundlebuggy.aaronbentley.com/request/%3C48859468.40605%40xs4all.nl%3E says conditionally approved | 00:00 |
| jelmer | http://article.gmane.org/gmane.comp.version-control.bazaar-ng.gtk/1294 says semi-approved | 00:00 |
| jelmer | poolie: at the risk of repeating myself.. what's the status on 1.6 ? :-) | 00:01 |
| jelmer | poolie, will you do a rc or something or are there other things you'd like to get fixed first? | 00:02 |
| AfC | jelmer: (fwiw, there have been some emails about that) | 00:16 |
| AfC | jelmer: (but it's a busy list, so easy to miss things) | 00:17 |
| Traveler9 | How do I fix this: Unable to import paramiko (required for sftp support): No module named paramiko | 00:19 |
| Peng_ | Traveler9: You install paramiko. | 00:19 |
| Traveler9 | How do I do that? | 00:20 |
| bob2 | depends on your OS | 00:20 |
| Peng_ | Note that paramiko depends on PyCrypto. | 00:20 |
| Traveler9 | Windows XP | 00:21 |
| bob2 | hm, I thought the bzr windows installer thing included paramiko | 00:21 |
| Traveler9 | I found a site that says | 00:22 |
| Traveler9 | pycrypto compiled for Win32 can be downloaded from the HashTar homepage: http://nitace.bsd.uchicago.edu:8080/hashtar | 00:22 |
| Traveler9 | But the link is dead. | 00:22 |
| bob2 | the links on http://bazaar-vcs.org/WindowsInstall are dead? | 00:23 |
| Traveler9 | I got the Paramiko binaries from there, but I get the same error. | 00:24 |
| nekohayo | seriously. http://ecchi.ca:8000/1.png | 00:33 |
| nekohayo | how can I be prevented from removing my own branch? any solution for this? | 00:33 |
| mwhudson | you have to get the subscriber to unsubscribe | 00:36 |
| Odd_Bloke | mwhudson: As a workaround, or is that intended behaviour? | 00:37 |
| mwhudson | more intended than not i think | 00:37 |
| Odd_Bloke | O.o | 00:38 |
| nekohayo | mwhudson: wtf? :) | 00:38 |
| nekohayo | branch watchers can hold branch makers hostages nowadays? | 00:38 |
| Traveler9 | I installed paramiko on WinXP and I'm getting: Unable to import paramiko (required for sftp support): No module named paramiko | 00:40 |
| mwhudson | nekohayo: the only thing that has changed recently is that you can delete branches at all :) | 00:41 |
| nekohayo | makes me want to reconsider launchpad as a hosting service :) perhaps I should just dump branches on my apache server | 00:41 |
| nekohayo | anyway I guess I'll just change its name and status for now | 00:42 |
| mwhudson | well, i doubt SF let's you entirely blow away the history of a project's svn repo | 00:43 |
| mwhudson | which is what deleting a branch is like | 00:43 |
| markh | Traveler9: you have Python installed, and running bzr from that? | 00:45 |
| Traveler9 | Yes and yes | 00:45 |
| markh | does 'python -c "import paramiko"' work? | 00:46 |
| Traveler9 | Hm I did that and it said nothing | 00:49 |
| Traveler9 | But I get the same error on a bzr push | 00:49 |
| thumper | nekohayo: the intent was to allow the watchers to have time to branch if they are interested before you delete it | 00:49 |
| thumper | nekohayo: I am beginning to think that it isn't such a good reason | 00:50 |
| nekohayo | thumper: hm. perhaps there should be a "it will be deleted in 72 hours" then? | 00:50 |
| thumper | nekohayo: yeah, that sounds sensible | 00:50 |
| Odd_Bloke | Perhaps making the choice to abandon a branch more obvious too. | 00:50 |
| markh | Traveler9: so if you execute 'bzr version', does the location of the "Python standard library" match what you expect (ie, is it your Python's lib directory where paramiko is?) | 00:50 |
| Traveler9 | Python standard library: C:\Program Files\Bazaar\lib\library.zip | 00:52 |
| Traveler9 | Not sure where paramiko was installed to. | 00:52 |
| markh | Traveler9: right - you are running a binary version, not the Python version | 00:53 |
| markh | the simplest answer is probably to update your binary version of bzr - can you remember what version of bzr you installed? | 00:54 |
| Traveler9 | Bazaar (bzr) 1.6b3 | 00:55 |
| is_null | i finnaly got bzr+bzr-svn, but tests don't pass: http://nopaste.com/p/aPc7fi5uh any tip please? is it a local issue? | 00:55 |
| markh | I'm surprised that comes without paramiko | 00:56 |
| === sdboyer|at_work is now known as sdboyer | ||
| markh | I'm putting up a 1.6b4 binary right now that should work :) It will be a few minutes though, and its about 16MB as it has a full copy of Qt4 included (I tried but failed to trim some of that - later!) | 00:57 |
| markh | Traveler9: actually, b4 isn't quite ready :) starship.python.net/crew/mhammond/bzr-setup-1.6b3.exe is a slightly different binary version than what you are using - it contains a rudimentary Tortoise and also works fine with Paramiko, if you want to give it a go. b4 will have a much better tortoise, but I'm sure you can survive a few days :) | 01:03 |
| Traveler9 | Should I uninstall bzr first? | 01:04 |
| markh | it shouldn't hurt not too, but it sure can't hurt to uninstall :) | 01:07 |
| bpeterson | can bzr log and diff be optimized for huge projects? | 01:07 |
| Traveler9 | Okay that version gives me: 0.235 failed to instantiate transport <bzrlib.registry._LazyObjectGetter object at e710a8, module='bzrlib.transport.sftp' attribute='SFTPTransport'> for 'sftp://fortw@67.222.133.33/~/': ParamikoNotPresent() | 01:08 |
| is_null | what does that mean please? "bzr: ERROR: Repository KnitPackRepository('file:///home/jpic/testbzr/.bzr/repository/') is not compatible with repository SvnRepository('file:///home/jpic/testsvn')" | 01:09 |
| mwhudson | beuno: replied to your mail | 01:10 |
| bpeterson | is_null: it means you have to make different repo when you do init-repo | 01:10 |
| markh | bugger. | 01:11 |
| jelmer | is_null, which bzr-svn branch are you using (wrt http://nopaste.com/p/aPc7fi5uh) ? | 01:11 |
| is_null | bpeterson, i see, i'm trying to track/branch a framework svn repo inside the bazaar repo | 01:11 |
| is_null | jelmer, 0.4 | 01:11 |
| jelmer | hmm, perhaps I forgot to push some changes | 01:12 |
| jelmer | is_null: the error is caused by your local bzr repository not being a rich-root-pack repository | 01:13 |
| jelmer | see the bzr-svn FAQ | 01:13 |
| is_null | for testing, i made the bzr repo in ~/testbzr, an svn repo in ~/testsvn (svn wc: ~/testsvn2), i'm trying to get ~/testsvn tracked and branched into ~/testbzr | 01:13 |
| is_null | jelmer, i just saw the faq, sorry | 01:13 |
| is_null | the problem is now "AttributeError: 'SvnWorkingTree' object has no attribute '_transport': http://nopaste.com/p/ayvGv2tIb | 01:15 |
| * mwhudson lunches | 01:16 | |
| markh | Traveler9: I'm stumbling around a little in the dark now, but I'm guessing it might be specifically related to sftp. what does "bzr selftest test_sftp" do for you? I get 18 tests run, 1 failure and 3 skips | 01:16 |
| Traveler9 | 18 tests, 3 skipped, tests failed | 01:18 |
| Traveler9 | [18/18 in 4s, 1 fail] test_sftp_transport.TestSocketDelay.test_delay | 01:18 |
| jelmer | is_null, I'll have a look, probably broken by some recent change in bzr.dev | 01:21 |
| is_null | jelmer, what revision are you using? | 01:23 |
| jelmer | bzr.dev 3565 | 01:24 |
| jelmer | bzr-svn 1489 | 01:24 |
| is_null | thanks! | 01:25 |
| markh | same result - strange. i'm fairly sure paramiko us being used in those builds for bzr+ssh pushes. but I haven't tried sftp | 01:28 |
| poolie | <jam> /train :-) :-) | 01:29 |
| poolie | hi markh | 01:29 |
| markh | hi poolie | 01:29 |
| fullermd | Are these bzr-gtk BB confirmations leaking onto the bzr list? | 01:32 |
| Odd_Bloke | They seem to be. | 01:34 |
| Odd_Bloke | abentley: ^ | 01:35 |
| jelmer | BB uses the branch location to find the project but it doesn't know about all of the aliases for bzr-gtk on launchpad | 01:35 |
| jelmer | if it can't find the submit branch location, it'll default to bzr | 01:35 |
| lifeless | hi | 01:37 |
| lifeless | cjwatson: its in progress on my laptop; haven't finished investigating | 01:38 |
| jelmer | 'morning lifeless | 01:38 |
| lifeless | jelmer: hi, any progress on that bug? | 01:38 |
| jelmer | lifeless, hi | 01:38 |
| jelmer | lifeless, I've merged your rebase branch | 01:38 |
| jelmer | lifeless, Which bug? | 01:38 |
| lifeless | cool | 01:38 |
| mwhudson | hi lifeless | 01:39 |
| lifeless | bzr-svn critical thingy | 01:39 |
| lifeless | hi mwhudson | 01:39 |
| lifeless | jelmer: the one discussed in $gnome-bzr | 01:39 |
| Traveler9 | shoop da woop | 01:39 |
| lifeless | I've literally just got home from the plane, I'll be a bit spotty today | 01:39 |
| lifeless | Bug 250480 | 01:40 |
| ubottu | Launchpad bug 250480 in bzr-svn "Missing texts, ghosts and inconsistent parents" [Critical,New] https://launchpad.net/bugs/250480 | 01:40 |
| Traveler9 | Is cElementTree needed? | 01:43 |
| markh | Traveler9: how you going - i seem to be able to push to sftp fine with those binaries | 01:43 |
| markh | Traveler9: its not in those binaries, so I hope not :) | 01:43 |
| jelmer | lifeless, I've been travelling until late yesterday evening so haven't had much time to look at it yet | 01:44 |
| lifeless | jelmer: ok | 01:44 |
| lifeless | me too :) | 01:44 |
| markh | Traveler9: is it possibly something in your environment? Is it possible you tried to install paramiko into the "\program files\bazaar" directory? | 01:46 |
| Traveler9 | It was installed to the default, I didn't change anything. | 01:46 |
| markh | your python install should not be used at all when using the binaries. Theoretically they couldn't possibly conflict, but theory and practice... | 01:47 |
| Traveler9 | I'm getting this now: bzr: ERROR: exceptions.NameError: global name 'win32ui' is not defined | 01:48 |
| is_null | why isn't bin/bzr compiled? | 01:49 |
| bob2 | to what? it is python code. | 01:49 |
| bob2 | bytecompiled? | 01:50 |
| markh | Traveler9: ack, that is in paramiko. You getting that running "python bzr", or bzr.exe? | 01:50 |
| Traveler9 | cmd.exe /K start_bzr.bat | 01:50 |
| is_null | bob2, yes | 01:50 |
| jelmer | is_null, how did you get the _transport error? | 01:51 |
| bob2 | is_null: it is like 80 lines of code :) | 01:51 |
| is_null | jelmer, sorry, i did not make the investigation log | 01:51 |
| jelmer | is_null, I've just pushed some fixes to the 0.4 branch | 01:52 |
| jelmer | any chance you can try again? | 01:52 |
| is_null | bob2, i'd like to set different pax flags on bzr, i tryed to bytecompile it by running `python -O bzr` as in section 6.1.3 of http://docs.python.org/tut/node8.html but it did not create the bytecompiled file and i'm a newbie with python ... any tip please? | 01:53 |
| is_null | jelmer, sure | 01:53 |
| is_null | (note that i was probably mis-using bzr-svn) | 01:53 |
| jelmer | is_null, that's alright, it shouldn't yell at you if you do that | 01:53 |
| markh | Traveler9: I'm not sure how that happened- I might need to check the paramiko binary - but it looks like you will need to edit paramiko\win_pageant.py :( | 01:53 |
| bob2 | is_null: I don't think that will help, 'python' will still be the executable | 01:54 |
| markh | the paramiko trunk doesn't have that error | 01:54 |
| is_null | jelmer, can't reproduce, sorry | 01:54 |
| Traveler9 | I'm not sure how to go about doing that. | 01:55 |
| is_null | bob2, true ... i was confused | 01:55 |
| markh | The problem isn't simply "paramiko is missing" - if it is, the error looks more along the lines of "bzr: ERROR: Unsupported protocol for url "sftp:... No module named paramiko" | 01:59 |
| Traveler9 | Do you want the entire backtrace? | 02:01 |
| markh | not of the NameError - I'm more interested in your original error from the binary "failed to instantiate transport <bzrlib.registry._LazyObjectGetter object at e710a8, module='bzrlib.transport.sftp' attribute='SFTPTransport'> for 'sftp://fortw@67.222.133.33/~/': ParamikoNotPresent()" and why that is failing to find paramiko | 02:02 |
| Traveler9 | Well right now it's giving me the NameError | 02:03 |
| markh | oh - you mean start_bzr.bat from the "\program files\bazaar" directory? Yeah, please include the 2 lines above the one you show | 02:04 |
| Traveler9 | 2 lines above "global name 'win32ui' is not defined"? | 02:05 |
| markh | yeah | 02:09 |
| Traveler9 | >bzr push --create-prefix sftp://fortw@68.222.133.33/ | 02:09 |
| Traveler9 | Connected (version 2.0, client OpenSSH_4.3) | 02:09 |
| Traveler9 | bzr: ERROR: exceptions.NameError: global name 'win32ui' is not defined | 02:09 |
| jelmer | lifeless, just posted a comment; I can't reproduce it | 02:13 |
| markh | that is looking very much like an error I made making those binaries :( I'll try and have a fixed one in an hour - hopefully less. | 02:15 |
| is_null | jelmer, i've got a segfault with bzr-svn: http://nopaste.com/p/aRwQLnxlk what bzr-dev revision for the current head of bzr-svn please? | 02:26 |
| jelmer | the latest bzr.dev should work with the latest of bzr-svn | 02:27 |
| is_null | still segfaulting ... | 02:29 |
| jelmer | is_null, that sequence of commands works fine here | 02:31 |
| jelmer | what version of python are you using? | 02:31 |
| jelmer | and what hardware platform? | 02:33 |
| is_null | jelmer, amd64, python 2.5.2 | 02:34 |
| jelmer | is_null: The bzr-svn testsuite doesn't segfault? | 02:35 |
| lifeless | spiv: http://svn.gnome.org/tmp/common-pre-commit | 02:35 |
| lifeless | spiv: gnome common hook sources | 02:35 |
| lifeless | jam: ping | 02:37 |
| is_null | jelmer, http://nopaste.com/p/a2J5Ni7Jm | 02:37 |
| lifeless | jam: is there a canned way to disable lazy imports? | 02:37 |
| jelmer | is_null, can you try "make check-one" ? | 02:37 |
| jelmer | (or bzr selftest svn --one) | 02:38 |
| lifeless | jelmer: debugging the segfault I get ? ::) | 02:39 |
| spiv | lifeless: thanks, but I already have a copy of that. | 02:39 |
| lifeless | spiv: cool | 02:39 |
| lifeless | spiv: I was closing browser windows | 02:39 |
| spiv | Ah, right. | 02:39 |
| jelmer | lifeless, I think it's a different one - he's getting unexplainable errors in the testsuite as well | 02:39 |
| is_null | jelmer, http://nopaste.com/p/adjtVmRUI | 02:40 |
| lifeless | jelmer: the test suite that segfaults for me ? :) | 02:40 |
| lifeless | jelmer: python 2.5.2 amd64 | 02:40 |
| jelmer | lifeless: Do you get testsuite errors before the segfault? | 02:40 |
| jelmer | is_null, what version of subversion are you using? | 02:40 |
| is_null | jelmer, 1.5.0 | 02:40 |
| lifeless | jelmer: svn, version 1.4.6 (r28521) | 02:40 |
| lifeless | jelmer: running make check | 02:41 |
| lifeless | jelmer: fail - doesn't honour PYTHONPATH | 02:41 |
| is_null | it seems to do so here: http://nopaste.com/p/aaI6uBvZQ | 02:42 |
| jelmer | lifeless, I'm pretty sure it does - you may need to set $BZR though | 02:42 |
| lifeless | which bzr gets the right bzr | 02:43 |
| libwilliam | I was wondering if there was a place somewhere that listed the strings you couldn't pass into the --message option of bzr log | 02:43 |
| lifeless | jelmer: no errors just hte segfault | 02:43 |
| libwilliam | currently I know of bzr log --message=* --message=? --message=+ | 02:44 |
| markh | Traveler9: http://starship.python.net/crew/mhammond/bzr-setup-1.6b4-mh1.exe will hopefully work better for you. | 02:44 |
| bob2 | libwilliam: surely that is a limitation of your shell, rather than bzr | 02:44 |
| lifeless | libwilliam: it wants a regex | 02:44 |
| lifeless | libwilliam: so "bzr log -m='.*'" will work fine | 02:44 |
| lifeless | (for instance) | 02:45 |
| bob2 | libwilliam: eep, sorry, read 'commit' rather than 'log' | 02:45 |
| libwilliam | lifeless, well I am doing the Anjuta plugin, and I have an entry where someone types in a regex and I update on the go... I just don't want it crashing if the first char they type is * | 02:45 |
| libwilliam | currently I can handle ignoring a first char of * + or ? but I wasn't sure if that was all of them. | 02:46 |
| lifeless | libwilliam: if you're doing that sort of search, I would suggest using bzr-search instead | 02:46 |
| lifeless | libwilliam: but separately - nothing should cause bzr log -m to actually crash; if you see crashes please file a bug | 02:46 |
| libwilliam | ok | 02:46 |
| libwilliam | ill make sure and submit a bug | 02:46 |
| lifeless | it just won't find anything useful if its not a valid regex | 02:46 |
| lifeless | (bzr-search will be stupidly faster than log -m for long lived projects) | 02:47 |
| Traveler9 | Okay | 02:47 |
| libwilliam | k, stupidly fast sounds good :) | 02:47 |
| lifeless | it doesn't suport regexes or stemming or anything yet | 02:47 |
| jelmer | is_null, checking what could cause this.. | 02:48 |
| lifeless | just simply boolean AND with literal matches | 02:48 |
| is_null | jelmer, wait, something is actually eating all my RAM and i can't figure the process | 02:49 |
| libwilliam | unfortunately I need xml output, I am using the xml plugin... but I think something like that is in the works | 02:49 |
| lifeless | there is xml plugin support for search | 02:49 |
| Traveler9 | bzr: ERROR: exceptions.NameError: global name 'win32ui' is not defined | 02:49 |
| libwilliam | bzr-xmloutput has search support? | 02:50 |
| lifeless | libwilliam: Verterok: knows the details, but there is a bzr-eclipse that has search support | 02:51 |
| lifeless | and it uses the xml stuff too | 02:51 |
| jelmer | is_null, any chance you can try again with the latest revision in the 0.4 branch? | 02:51 |
| Odd_Bloke | libwilliam: Surely you can validate whether a string is a regex before passing it through to bzr? | 02:51 |
| spiv | Or just re.escape the search string. | 02:52 |
| lifeless | spiv: kindof prevents them using a re ;) | 02:52 |
| libwilliam | Ya Vertorok mentioned he was working on doing something with search in his plugin | 02:53 |
| spiv | lifeless: well, depends on what they want :) | 02:54 |
| libwilliam | For the mean time I will check if it is a regex beforehand... and I'll submit a bug on the bzr crash with an invalid regex | 02:54 |
| lifeless | libwilliam: the search is in the xmlrpc plugin I think. | 02:54 |
| lifeless | libwilliam: or the rpc branch of xmloutput | 02:54 |
| lifeless | I dunno the details :) | 02:54 |
| lifeless | all I know is I have eclipse here that does bzr-search integration | 02:55 |
| libwilliam | thats the one I have checked out :) so i'll browse the code and see how to use it | 02:55 |
| is_null | jelmer, http://nopaste.com/p/aTshZ4A9y btw, see at the end that there is >2G of free RAM, and it still exits "out of memory" | 02:55 |
| libwilliam | thanks! | 02:56 |
| Verterok | libwilliam: hi | 02:57 |
| libwilliam | Verterok: hey | 02:57 |
| Verterok | lifeless: the xmlrpc service in xmloutput now support bzr-search ;) | 02:58 |
| jelmer | is_null, I suspect this is some 64-bit-related issue | 02:58 |
| libwilliam | Nice :) | 02:58 |
| jam | lifeless: I don't have a canned way to do so, but in the 'bzr' script you could do override the lazy_import function. You could even just use the same ImportProcessor with a different lazy_import_class that just automatically imported them into scope. | 02:59 |
| jam | That said, I know that bzrlib won't import anymore because of cyclical dependencies | 02:59 |
| Verterok | libwilliam: the support is only for the xmlrpc bit, it uses xmlrpc de/serialization to send the results to the client (a simple dict) | 02:59 |
| lifeless | jam: damn | 03:00 |
| libwilliam | Alright, the xmlrpc thing I am going to look into after I get most of the stuff working by itself, which is close. | 03:00 |
| libwilliam | When you explained it it didn't seem so tricky | 03:00 |
| lifeless | mwhudson: how did you make pyflakes/pydocktor work with lazy import? | 03:00 |
| mwhudson | lifeless: i only did pyflakesw | 03:01 |
| Verterok | libwilliam: but I think that writting a xmlsearch command should be quite easy :) | 03:01 |
| lifeless | mwhudson: ... and how? | 03:01 |
| Verterok | libwilliam: be aware that I don't have a clue about how to write a xmlrpc client in C :) | 03:02 |
| mwhudson | lifeless: https://code.edge.launchpad.net/~mwhudson/pyflakes/support-lazy-imports | 03:02 |
| mwhudson | lifeless: by compiling the string that gets passed into lazy_import into an ast and processing that just like the rest of the ast | 03:02 |
| libwilliam | Verterok: you just avoided a question in a couple weeks ;) | 03:02 |
| lifeless | blergh | 03:03 |
| Verterok | heh :) | 03:03 |
| is_null | jelmer, well thanks for your help anyway, i know that you can't do anything about it... too bad i couldn't get my stuff done after all that hours trying (hopefully i'm a newbie and used to it) | 03:03 |
| lifeless | jam: I want to try our freeze | 03:03 |
| lifeless | its been on my list for $too_long | 03:03 |
| jam | freeze? | 03:03 |
| lifeless | jam: do you think the cyclical imports are easy to resolve? | 03:03 |
| jam | lifeless: It would just be delaying them to some later time | 03:03 |
| lifeless | jam: py2exe for linux. ish. | 03:04 |
| jelmer | is_null, Things should hopefully be a bit easier to deal with once the new versions of bzr and bzr-svn are out | 03:04 |
| is_null | jelmer, what do you mean? | 03:04 |
| Leefmc | Question: What is the proper command for uploading a branch to the launchpad? I'm rather confused as if i "register a branch" (Trunk for example), the resulting branch is "located at ~myname/hcrf/trunk", which seems odd to me to tie a project branch to my name | 03:04 |
| jelmer | is_null, well, since you can't use the current release because of some bugs that have since been fixed | 03:04 |
| jelmer | I assume your distro packages bzr and bzr-svn? | 03:05 |
| Leefmc | I'm coming from Git, but this is obviously foreign heh | 03:05 |
| lifeless | Leefmc: well, if you want a project branch that many people can upload to, create a team | 03:05 |
| lifeless | Leefmc: branches in launchpad are in a namespace - owner/project/name | 03:06 |
| jam | lifeless: the other 'quick hack' to do it is to just comment out the "lazy_import(globals(), """ line | 03:06 |
| Leefmc | lifeless: I have to create a team "first"? At the moment i dont have a team, nor do i want one, but later it will be desired. | 03:06 |
| lifeless | Leefmc: this lets anyone call their branch anything they want | 03:06 |
| Leefmc | lifeless: Ah, ok | 03:06 |
| jam | I intentionally made the syntax == regular import | 03:06 |
| lifeless | Leefmc: you can create a team later and hand the branch over to the team | 03:06 |
| Leefmc | lifeless: I just found it odd since my project is launchpad.net/myproj | 03:06 |
| is_null | jelmer, i'm using bzr.dev and the 0.4 branch of bzr-svn ... | 03:06 |
| jam | so I think you could do: | 03:06 |
| jelmer | is_null, yeah, but the 0.4 branch is rather unpolished | 03:06 |
| jam | lazy_import = lambda scope,text: eval text in scope | 03:07 |
| jam | or something to that effect | 03:07 |
| jelmer | is_null, in particular, this 64-bit issue exists at the moment but that should be fixed before the release | 03:07 |
| jelmer | It doesn't exist in 0.4.10 | 03:07 |
| lifeless | jelmer: do you have access to a 64 bit cpu? | 03:08 |
| lifeless | is_null: you could run under gdb | 03:08 |
| is_null | lifeless, can't (aslr) | 03:08 |
| jelmer | lifeless, no, but I'm installing debian on a 64-bit qemu image atm | 03:08 |
| lifeless | jelmer: let me know if you can't reproduce | 03:08 |
| ToyKeeper | No matter how many times I hear that, it still doesn't sound right. | 03:10 |
| jelmer | ToyKeeper, ? | 03:11 |
| pickscrape | hehe | 03:12 |
| pickscrape | I think he was referring to "let me know if you can't reproduce" | 03:13 |
| jelmer | lol | 03:13 |
| pickscrape | Which might be something you'd get referred to a fertility specialist for. | 03:13 |
| Leefmc | Question: Does launchpad code give you the ability to view source code? (Ie, web based source, with highlighting, etc?) | 03:13 |
| jelmer | I had never thought of interpreting it that way | 03:13 |
| pickscrape | Takes a strange mind... | 03:14 |
| lifeless | Leefmc: http://bazaar.launchpad.net/USER/PROJECT/BRANCH | 03:14 |
| * ToyKeeper spent much of the past 2 years trying not to laugh during QA meetings because of that particular language quirk | 03:14 | |
| spiv | Leefmc: you can browse source, he's an example of a file in a branch: http://bazaar.launchpad.net/~bzr/bzr/trunk/annotate/head:/README | 03:15 |
| lifeless | Leefmc: e.g. http://bazaar.launchpad.net/~lifeless/+junk/bzr-index2 | 03:15 |
| Leefmc | ah k ty. I was wondering because it seems i have uploaded my project, but i have yet to find where i can browse the source, etc. | 03:16 |
| spiv | Leefmc: it doesn't do syntax highlighting of files yet, though. | 03:16 |
| Leefmc | no biggie | 03:16 |
| spiv | There's a "Browse code" link on the branch page. | 03:16 |
| spiv | (Assuming that the branch has revisions in it, anyway) | 03:17 |
| Leefmc | yea | 03:18 |
| Leefmc | So what is the proper pushing command then? The tutorial shows bzr push bzr+ssh, but the launchpad pages show bzr push lp: | 03:19 |
| Leefmc | Though i've gotten errors everytime with lp | 03:19 |
| ToyKeeper | Leefmc: Did you 'bzr launchpad-login myname' first? | 03:20 |
| Leefmc | No, i get an error with that | 03:20 |
| spiv | Either is fine, the "lp:" one is just a shortcut. If you get errors with it, it's likely because you haven't run "bzr launchpad-login YOURNAME" first. | 03:20 |
| ToyKeeper | You need to give it your username, and set up ssh keys, before you can push to launchpad. | 03:20 |
| Leefmc | Note that the tutorial never talked about the lp one, nor launchpad-login | 03:20 |
| Leefmc | ToyKeeper: Yea but i can't do that heh,it just gives errors :/ | 03:20 |
| Leefmc | 1 sec, i'll get the error | 03:21 |
| Leefmc | This is part of it: .... is permanently redirected to https://launchpad.net/~... | 03:21 |
| Leefmc | Full: bzr: ERROR: https://launchpad.net/%7ELeefmc/%2Bsshkeys is permanently redirected to https://launchpad.net/~leefmc/+sshkeys | 03:22 |
| bob2 | enter that URL in your web browser to paste your id_rsa.pub in | 03:22 |
| pickscrape | How can I retrospectively add --no-trees to a shared repository? | 03:23 |
| spiv | Leefmc: https://launchpad.net/~leefmc/+sshkeys is not a URL for a bzr branch | 03:23 |
| lifeless | pickscrape: touch .bzr/repository/no-working-trees | 03:23 |
| lifeless | pickscrape: (sorry) | 03:23 |
| pickscrape | lifeless: excellent, thanks | 03:23 |
| pickscrape | Worked like a charm :) | 03:24 |
| jamesh | sounds like something "bzr reconfigure" should let you do | 03:24 |
| lifeless | indeed | 03:24 |
| spiv | Leefmc: also, there doesn't appear to be a 'leefmc' user in Launchpad, although I do see a 'leefmc+0layvar'. | 03:25 |
| lifeless | mwhudson: pyflakes uses the python parser? | 03:25 |
| mwhudson | lifeless: it uses the compiler package | 03:26 |
| mwhudson | (which uses the parser module, which uses the python parser) | 03:26 |
| Leefmc | spiv: About the url, i dont know about that. All i know is i type "bzr launchpad-login Leefmc" and it gives me that error. Also, i assumed it wanted my display name because it roughly accepts "Leefmc", but if i type "leefmc" it returns a "no leefmc user" error | 03:28 |
| Leefmc | I'll try my full name | 03:28 |
| spiv | It wants your launchpad user ID. | 03:28 |
| lifeless | holy cow | 03:28 |
| Leefmc | spiv: So which command should i use for pushes then? As i mentioned the tutorial gives one example, the project pages give another | 03:29 |
| spiv | Leefmc: that error is pretty bad, it seems to be a bug in the launchpad-login command. | 03:29 |
| Leefmc | spiv: Gotcha, i changed my "name" to leefmc anyways, and now it worked :) | 03:30 |
| spiv | Leefmc: either is fine, but "lp:" requires that you've done a successful "bzr launchpad-login ..." first. | 03:30 |
| spiv | Leefmc: the lp: essentially just redirects to the bzr+ssh:// location | 03:30 |
| Leefmc | spiv: Either is fine, but one isn't optimal over the other? | 03:30 |
| Leefmc | Ah ok, gotcha :) | 03:30 |
| spiv | But is obviously much shorter to type. | 03:30 |
| jam | lifeless: if you are just looking to use something like py2exe, our setup.py code already has something to hack in understanding of lazy_import for py2exe | 03:31 |
| jam | you might just grab that | 03:31 |
| lifeless | jam: freeze generates C modules | 03:31 |
| jam | ah | 03:31 |
| jam | interesting | 03:31 |
| lifeless | /usr/share/doc/python2.5/examples/Tools/freeze | 03:32 |
| lifeless | with the bytecode in an array. | 03:32 |
| lifeless | fugly stuff :) | 03:32 |
| * ToyKeeper wonders why bzr remembers the expanded URL instead of the one the user entered | 03:33 | |
| jamesh | do people still use freeze? | 03:35 |
| lifeless | jamesh: I want to see what it does to startup time | 03:37 |
| jamesh | lifeless: I'd have thought that zip imports would give similar performance | 03:38 |
| lifeless | jamesh: depends where the slowdown really is | 03:38 |
| * igc lunch | 03:43 | |
| Leefmc | There doesn't seem to be a link section for a project dev blog, am i correct? (Ie, to tell users of the project dev blogs location) | 03:57 |
| lifeless | markh: does py2exe work on linux? | 03:58 |
| lifeless | Leefmc: don't think there is no; #launchpad is the IRC channel for launchpad specific questions BTW | 03:59 |
| Leefmc | lifeless: Thanks for the heads up | 03:59 |
| markh | lifeless: not afaik | 03:59 |
| lifeless | (though we'll try to answer here, the actual lp devs are better represented on #launchpad) | 03:59 |
| markh | I believe it can run on linux, but not create executables that target linux | 03:59 |
| markh | there is py2app for macosx - and pyinstaller is a revival of a dead project, and it says it works on linux - http://pyinstaller.python-hosting.com/ - but I'm not sure how active that is | 04:02 |
| Leefmc | How do you save a location to bazaar? | 04:02 |
| Leefmc | Mine has an invalid location saved (for pushing) | 04:02 |
| bob2 | "bzr push --remember kajshdfklajsh" will overwrite the existing value | 04:03 |
| lifeless | Leefmc: --remember | 04:03 |
| Leefmc | thanks | 04:03 |
| lifeless | markh: yah, I want a monolithic binary, not an installer. | 04:03 |
| === mw is now known as mw|out | ||
| lifeless | need sleep, back in a few | 04:06 |
| lifeless | hours that is | 04:06 |
| Leefmc | Question: So, just to get my bearings, in Git i would often try out code ideas by creating a separate branch and toying with code. And ofcourse at anytime you can switch pop back and forth between the two branches. How is this done in bzr? | 04:06 |
| Leefmc | bzr branch seems to talk about separate directories and junk | 04:07 |
| Leefmc | so i assume that is not what i want | 04:07 |
| lifeless | what you probably want is: | 04:07 |
| lifeless | bzr init-repo --no-trees REPO | 04:08 |
| lifeless | bzr init REPO/trunk | 04:08 |
| lifeless | bzr checkout --lightweight REPO/trunk WORKING | 04:08 |
| lifeless | cd WORKING | 04:08 |
| * Leefmc is confused :) | 04:08 | |
| Leefmc | So wait | 04:08 |
| lifeless | cp -r /source_I_want | 04:08 |
| lifeless | bzr add | 04:08 |
| lifeless | bzr commit -m 'imported' | 04:08 |
| Leefmc | your cd'ing, so is the git workflow not possible in bzr? | 04:08 |
| lifeless | bzr branch $REPO/trunk $REPO/branch | 04:08 |
| lifeless | bzr switch branch | 04:08 |
| lifeless | bzr switch trunk | 04:09 |
| lifeless | etc | 04:09 |
| lifeless | Leefmc: its totally possible, we have separate concepts for 'source you edit', 'branch', and 'history storage' | 04:09 |
| lifeless | it just looks a tiny bit different than in git | 04:09 |
| Leefmc | Well i mean, your cding.. so your storing your branches as copies, correct? | 04:10 |
| Leefmc | Thats not exactly what i was looking for | 04:10 |
| lifeless | what my commands above setup is one tree to edit your source, N branches, and one repository to store your history | 04:10 |
| lifeless | Leefmc: I don't know what you mean by 'as copies'. Each branch is a few KB of data | 04:10 |
| markh | those tools all try to get as close to a monolithic installer as possible iiuc | 04:10 |
| Leefmc | lifeless: Copies as in, say all your code is in "/src", are you storing "/src" and "/test-branch" ? | 04:11 |
| markh | pyinstaller's history is that it was proving better than py2exe, but then the maintainer vanished, so most people jumped back to py2exe - then it was revived as pyinstaller. | 04:11 |
| lifeless | Leefmc: I don't follow the question | 04:12 |
| Leefmc | lifeless: Ie, in git (and this is the main point im driving at) all your code is stored under "/src" and git modifies your source depending on the branch your in | 04:12 |
| Leefmc | lifeless: So you can have ten branches, but you only have one directory for your source | 04:12 |
| Leefmc | lifeless: And switching between those branches does nothing but change the contents of "/src" | 04:12 |
| Leefmc | lifeless: But git manages that, not me. No cding, etc | 04:12 |
| lifeless | Leefmc: so there are two separate things here: having N directories, and 'switch does nothing but change the contents of "/src"' | 04:13 |
| lifeless | Leefmc: in bzr (without plugins) a branch is always a directory, so that you can use normal tools to manage it | 04:13 |
| Leefmc | lifeless: Gotcha | 04:13 |
| lifeless | Leefmc: but your *source code* is able to be decoupled from the *branch* | 04:13 |
| lifeless | Leefmc: and that gives you 'switch does nothing but change the contents of "/src"' | 04:14 |
| lifeless | Leefmc: e.g. if you have two branches of mysql with only a couple of files different, 'bzr switch' will only write to those two files, and the metadata files during the update | 04:16 |
| Leefmc | lifeless: Gotcha | 04:16 |
| lifeless | Leefmc: give the commands I put up above a poke, and peek around inside .bzr of each thing | 04:18 |
| Leefmc | k | 04:19 |
| lifeless | I'm going away for a few hours (jetlagged), but there are other folk here can probably help you understand what bzr can offer | 04:19 |
| Leefmc | thanks | 04:21 |
| Leefmc | night ;) | 04:22 |
| lifeless | k, really going. but a quick result from freeze: stat system time : 0m0.048s vs 0.072s (wall clock not dramatically different on hot-cache) | 04:23 |
| lifeless | on cold cache, the frozen bzr is 2 seconds faster | 04:24 |
| lifeless | (with --no-plugins given) | 04:24 |
| markh | that's significant | 04:28 |
| * markh the master of understatement ;) | 04:29 | |
| pickscrape | Anyone know the current state of trac-bzr development? | 04:32 |
| pygi | pickscrape, I don't really think it's being developed, tho you probably shouldn't listen to me :p | 04:32 |
| pickscrape | That's a shame | 04:32 |
| pygi | oh well | 04:33 |
| jelmer | pickscrape, devleopment is still happening | 04:33 |
| jelmer | pickscrape, it's not at a very high pace, but there is the occasional patch every now and then | 04:33 |
| pickscrape | jelmer: yes, I'm just trying to decide which branch to install | 04:34 |
| pickscrape | trac0.11 is the obvious choice | 04:34 |
| pickscrape | But then ~menesis/trac-bzr/menesis-dev adds a couple of additional commits on top of that | 04:35 |
| jelmer | pickscrape, I would recommend just lp:trac-bzr | 04:36 |
| pickscrape | Does that suppose 0.11 though? | 04:36 |
| jelmer | yeah, I think it does | 04:37 |
| Odd_Bloke | What's the status of Cart? | 04:48 |
| thumper | Odd_Bloke: :) dormant? | 04:49 |
| thumper | Odd_Bloke: are you doing the weird nocturnal lifestyle thing? | 04:50 |
| AfC | Don't be awake when everyone else in your timezone is. Fight the establishment! | 04:52 |
| alecw1 | What is the best name for a development branch? I've heard dev, devel, head, trunk... which is recommended? | 04:54 |
| thumper | alecw1: I normally use a feature name | 04:56 |
| thumper | alecw1: eg. revision-feed or karma-for-commits | 04:57 |
| alecw1 | I'm talking about the repository that we merge all tested features into; it's like, the main game branch. | 04:57 |
| thumper | trunk | 04:57 |
| thumper | that's what I call it | 04:57 |
| thumper | but often it is devel | 04:57 |
| * thumper shrugs | 04:57 | |
| thumper | bzr has bzr.dev | 04:57 |
| thumper | I don't think there is a recommended name | 04:58 |
| thumper | just as long as there is a concensus | 04:58 |
| * thumper looks at the word thinking he has spelled it wrong | 04:58 | |
| alecw1 | consensus | 04:58 |
| alecw1 | okay, I think I'll stick with trunk | 04:59 |
| alecw1 | that just sounds to-the-point, easy to say, etc | 04:59 |
| AfC | alecw1: we use 'mainline' | 05:03 |
| alecw1 | AfC: but that's not very conventional. =P | 05:03 |
| jamesh | "trunk" is familiar to people who are coming from subversion | 05:04 |
| AfC | alecw1: it is the "mainline" of development. | 05:04 |
| jamesh | and isn't a particularly bad choice | 05:04 |
| pickscrape | For our new repo we're using 'live' because that's what it represents in our case | 05:04 |
| pickscrape | development happens on branches | 05:04 |
| pickscrape | (it's a website) | 05:04 |
| AfC | jamesh: being palatable to people who refused to move on from Subversion wasn't a high priority for us at the time. | 05:04 |
| jamesh | AfC: that is not what I said | 05:04 |
| alecw1 | "trunk" doesn't imply that 'development happens here' though. | 05:05 |
| jamesh | AfC: what I mean is that if there are a number of equally valid choices, why choose to be different? | 05:05 |
| alecw1 | jamesh: agreed, it just seems easier, familiar, and not incorrect. | 05:06 |
| jamesh | and I am not suggesting that blindly copying subversion on everything is a good idea either | 05:07 |
| AfC | jamesh: I can't remember who suggested it at the time, but I was well familiar with the term from both the corporate world and older open source communities. If anything, we found 'trunk' ambiguous. Whatever | 05:07 |
| jamesh | just save your inconsistencies for things that matter. | 05:07 |
| jamesh | AfC: sure. If anything, Subversion picking "trunk" was inconsistent with CVS | 05:09 |
| jamesh | or maybe not. The CVS docs seem to use "main" about as much as "trunk", and often talk of the "main trunk" | 05:10 |
| AfC | Our use of DVCS predates Subversion. I really don't attach a high priority to their terminology for things. Admittedly, I'm not in the business of convincing people who use it to switch. And certainly, far be it from me to tell others what to pick. People can do what they want with their own projects. | 05:11 |
| pickscrape | jelmer: JFYI, ~vslavik/trac-bzr/trac0.11 does a better job with trac0.11 than lp:trac-bzr does | 05:11 |
| pickscrape | trac-bzr won't even let me view a changeset. | 05:11 |
| rusty | Hi all... someone else committed to my repo, but I see the change or pull it. The only clue is that on the server that commit has "branch nick: commit_repo" whereas all mine are "branch nick: ccan" | 05:33 |
| rusty | s/but I see/but I cannot see/ | 05:34 |
| sohail | hey guys, how would I convert a git repository to bzr? | 05:34 |
| mwhudson | sohail: "fast-export" | 05:35 |
| sohail | mwhudson, and then importing to bzr? | 05:36 |
| mwhudson | sohail: right, there is a bzr-fastimport plugin | 05:36 |
| spiv | rusty: where are you seeing "branch nick: commit_repo"? I'm a bit confused, you say both that you can see the nick in a commit, but also that you can't see the commit? | 05:36 |
| AfC | If rusty has pulled, then `bzr update` won't help, will it? | 05:36 |
| sohail | mwhudson, thanks | 05:36 |
| mwhudson | sohail: note that i've never done this, i'm just parroting what i've seen other people say :) | 05:37 |
| rusty | spiv: server ozlabs.org sees commit in the logs. I pull, it says "No revisions to pull." | 05:37 |
| sohail | mwhudson, thats ok.. I probably wouldn't lose any data :-) | 05:37 |
| mwhudson | sohail: :) | 05:38 |
| spiv | rusty: does "bzr log --show-ids -r -1" on both locations show the same thing? | 05:38 |
| AfC | rusty: when you say "logs" do you mean `bzr log` on the serer in that branch there shows the revisions, or something to the effect of "I saw it in the Apache log" (sic) | 05:38 |
| rusty | spiv: no. I have 51. It has 52. | 05:39 |
| rusty | AfC: `bzr log` in server repo dir vs. `bzr log` on my machine. | 05:39 |
| AfC | rusty: got it | 05:40 |
| AfC | rusty: that's a weird behaviour. Something is wedged, I should think | 05:40 |
| rusty | AfC: it's possible that my GSoC student created a branch somehow. | 05:40 |
| spiv | rusty: Hmm, then "bzr pull URL" should pull that new revision. | 05:40 |
| rusty | spiv: yeah, you'd think so! | 05:40 |
| * spiv thinks | 05:40 | |
| spiv | Is this a checkout or a brancH? | 05:40 |
| spiv | (i.e. does "bzr info" include the word "checkout" somewhere in the output?) | 05:41 |
| spiv | If it's a checkout of the remote branch, then the problem might be that you need to run "bzr update" to update the checkout. | 05:41 |
| rusty | spiv: neither end does: | 05:42 |
| rusty | server: Standalone branch (format: pack-0.92) | 05:42 |
| rusty | my end: Standalone tree (format: dirstate) | 05:42 |
| rusty | spiv: Hmm, server is 1.5, I am 1.3.1 | 05:42 |
| spiv | Those versions should be ok. | 05:43 |
| spiv | Hmm. Your side is in an old format though. | 05:43 |
| spiv | I guess it's possible that you have hit a bug that causes the revision-history file in an old format branch to be a bit inconsistent, though that seems pretty unlikely. | 05:45 |
| rusty | spiv: repo is published at http://ccan.ozlabs.org/repo/ via a CGI I got from somewhere... | 05:45 |
| * spiv looks | 05:45 | |
| rusty | spiv: looks like an hgweb ripoff :) | 05:46 |
| spiv | Ah, good ol' bzr-webserve :) | 05:46 |
| rusty | And that doesn't show rev 52 either :( | 05:46 |
| spiv | Ah, no, it's branch format 6, so it's not a revision-history file problem. | 05:46 |
| rusty | spiv: want ssh access to the box? Or a tarball of the whole repo? It's pretty small. | 05:48 |
| spiv | rusty: is there a public URL for the branch with revno 52? | 05:48 |
| spiv | rusty: yeah, a tarball's fine. andrew at canonical.com. | 05:49 |
| rusty | spiv: I don't even know if it is a branch... how do I tell? | 05:49 |
| spiv | If you can do things like "bzr log" in it, it's a branch :) | 05:49 |
| spiv | More precisely, if it has .bzr/branch/* | 05:50 |
| rusty | spiv: http://ozlabs.org/~rusty/repo.tar.bz2 | 05:52 |
| rusty | spiv: 700k. | 05:52 |
| spiv | rusty: ta | 05:53 |
| pygi | aha, now I can send a patch against a patch because I just found a bug :p | 05:53 |
| * pygi hides | 05:54 | |
| spiv | rusty: hmm, so if I untar that to /tmp, and do "bzr branch http://ccan.ozlabs.org/repo/; bzr pull /tmp/repo", it pulls revision 52 | 05:55 |
| AfC | rusty: to elaborate on something spiv said, you can have an "empty" directory that has a branch in it if there's a .bzr/branch/ there; the directory will be populated with the project when there is a Working Tree present, but one doesn't always have to have the full tree sitting there checked out to have a branch location; | 05:55 |
| AfC | rusty: Repository in Bazaar parlance is the .bzr/repository/ directory, which might be at ., might be at .., might be at ../.., etc | 05:56 |
| spiv | rusty: so at this point I guess we should double-check that the location that "bzr pull" is using is what we think it is | 05:56 |
| AfC | rusty: [when at .. or higher it is a "shared repository"] | 05:56 |
| rusty | spiv: trying that cmd here. | 05:56 |
| spiv | Hmm, "bzr branch http://ccan.ozlabs.org/repo/ foo; cd foo; bzr pull /tmp/repo" actually | 05:56 |
| rusty | spiv: yep... will take a while, satellite :) | 05:58 |
| spiv | rusty: ah, ouch :) | 05:59 |
| spiv | I should get back to cutting down round-trips then ;) | 05:59 |
| rusty | spiv: Branched 51 revision(s).... +N etc.. Now on revision 52. | 06:00 |
| rusty | spiv: OK, so that worked. But why didn't pull just go straight to 52? | 06:00 |
| rusty | spiv: (I used branch -v BTW) | 06:00 |
| spiv | Well, what URL did "bzr pull" say it was using before? | 06:01 |
| spiv | (I'm assuming you were just doing plain "bzr pull" with no explicit URL) | 06:01 |
| rusty | http://ccan.ozlabs.org/repo/ I also tried explicitly pulling from bzr+ssh://... | 06:01 |
| rusty | (which should be same repo as cgi points at) | 06:02 |
| spiv | Ah, but http://ccan.ozlabs.org/repo/ only has revision 51. | 06:02 |
| spiv | $ bzr revno http://ccan.ozlabs.org/repo/ | 06:02 |
| spiv | 51 | 06:02 |
| rusty | spiv: yes, but why? | 06:03 |
| rusty | spiv: bzr log on that dir says it has 52. | 06:03 |
| rusty | spiv: and using bzr+ssh:// didn't see 52 either, so I can't blame some cgi weirdness. | 06:03 |
| spiv | What exactly do you mean by "on that dir?" | 06:03 |
| spiv | I see only 51 with "bzr log $ bzr revno http://ccan.ozlabs.org/repo/ | 06:03 |
| spiv | 51 | 06:03 |
| spiv | d'oh | 06:03 |
| spiv | I see only 51 with "bzr log http://ccan.ozlabs.org/repo/ -r -1" | 06:04 |
| rusty | spiv: I ssh into server, do "bzr log" in /home/ccan/repo... | 06:04 |
| spiv | And bzr+ssh://server/home/ccan/repo didn't show 52? | 06:05 |
| rusty | spiv: hold on, I'm using a wrapper for ssh access in the ccan account's .authorized keys... bzr-ssh | 06:05 |
| spiv | Ah, hmm. | 06:06 |
| rusty | spiv: maybe I screwed something there.... one sec, will try circumventing it. | 06:06 |
| rusty | spiv: ah, oops. | 06:09 |
| spiv | rusty: :) | 06:09 |
| rusty | spiv: yeah... so I don't quite know how, but this seems to mess things up: | 06:09 |
| rusty | orig_cmd = os.getenv('SSH_ORIGINAL_COMMAND', '?') | 06:09 |
| rusty | if orig_cmd == 'bzr serve --inet --directory=/ --allow-writes': | 06:09 |
| rusty | os.execlp('bzr', 'bzr', 'serve', '--inet', '--directory=' + sys.argv[1], '--allow-writes') | 06:09 |
| rusty | (I use the authorized_keys file to redirect them to run the script, based on hg-ssh) | 06:10 |
| === beuno_ is now known as beuno | ||
| spiv | Hmm. | 06:11 |
| rusty | spiv: sys.argv[1] is "/home/ccan". It's annoying that bzr serve wants to serve the entire world, but this at least restricts it to writing in the ccan home dir. | 06:12 |
| rusty | spiv: I *really* don't want to grant full ssh access just so people can commit to repo :( | 06:13 |
| sohail | hmm... After importing my git repo to bzr, the packed bzr is twice as large as the gc'ed git | 06:13 |
| sohail | how can I find out what's wrong? | 06:13 |
| spiv | What's argv[1]? -- ah, I look away for a second and you've already told me :) | 06:13 |
| luks | sohail: you have probably lots of junk under .bzr/repository/obsolete-packs | 06:14 |
| sohail | luks, what is that? | 06:14 |
| sohail | luks, indeed, half of the whole repo is contained here.. | 06:14 |
| luks | packs that were used before you ran `bzr pack` | 06:14 |
| AfC | sohail: or, bzr may be storing more {meta,indexing,etc} data, so it's possible that "nothing" is wrong. However, the Bazaar hackers have been working away quite heavily on some neat things that dramatically reduce the size taken by revision data on disk, which is pretty cool. | 06:15 |
| luks | those are useless now | 06:15 |
| sohail | luks, ah | 06:15 |
| luks | you can delete them, but I should add that the official answer is to not touch .bzr :) | 06:15 |
| spiv | rusty: off the top of my head, that script sounds fine to me. I'll see if I can reproduce some weirdness locally. | 06:15 |
| sohail | luks, :-) I can leave it for now I guess | 06:15 |
| AfC | luks: it's like the _next_ operation will auto-clean that for sohail, right? | 06:15 |
| luks | sohail: nah, you really can delete them | 06:15 |
| luks | AfC: the next packing will clean them | 06:15 |
| AfC | yeah, I knew it was something l like that, modulo "things people have worked on that aren't released yet" | 06:16 |
| spiv | rusty: oh, | 06:16 |
| rusty | spiv: mailing appropriate bits now... | 06:16 |
| spiv | rusty: what's the bzr+ssh:// URL you were using? | 06:16 |
| sohail | luks, ok I'll do it | 06:16 |
| spiv | rusty: with that script, you'll need just bzr+ssh://server/repo, not bzr+ssh://server/home/ccan/repo | 06:16 |
| AfC | luks: (or sohail could just run `bzr pack` manually, right?) | 06:16 |
| luks | AfC: yep | 06:17 |
| sohail | well now it is less than git | 06:17 |
| sohail | so good for you :-) | 06:17 |
| sohail | although maybe git has the same problem | 06:17 |
| luks | but of course, in both cases he he will have new ones there :) | 06:17 |
| sohail | "problem" | 06:17 |
| luks | sohail: I don't think git backups the old packs | 06:17 |
| AfC | "problem". Doing apples and apples comparisons is hard, as different systems do different things at different points in the lifecycle. That said, I'm pretty excited about the compression work that's being done, because that will reduce amount-over-the-wire network pressure, etc | 06:18 |
| sohail | luks, then bzr wins :-) | 06:18 |
| luks | you could always tweak git to win | 06:19 |
| luks | with long delta window, etc. | 06:19 |
| rusty | spiv: Ah, that works! | 06:19 |
| rusty | spiv: now, why didn't I get an error when I got the url wrong? | 06:19 |
| spiv | rusty: the --directory= arg causes the bzr server to treat all paths from the client as relative to that directory (and doesn't let the client break out of that directory) | 06:20 |
| spiv | rusty: I'm not sure why you didn't get an error | 06:20 |
| spiv | rusty: presumably there's a /home/ccan/home/ccan/repo somehow! | 06:20 |
| rusty | spiv: err... yeah :) | 06:20 |
| * AfC tries to figure out exactly what script+ssh{,d} config rusty is using as he'd like to cloak actual paths as well | 06:21 | |
| rusty | spiv: and it has a .bzr dir in it... | 06:21 |
| spiv | rusty: I'm betting "bzr revno /home/ccan/home/ccan/repo" on the server reports "51", too. | 06:22 |
| AfC | Also, fwiw, Rusty, you might want to try running a newer version of Bazaar as your client if possible; I mean, 1.3.x will work, sure, but the bug fix and better performance factor between that and 1.5 has [subjectively] been impressive. As will be the case to 1.6 when it stabilizes. | 06:22 |
| AfC | IANABH | 06:22 |
| rusty | spiv: OK, so it's a symlink to my web dir... which means that repo is being rsynced across from my machine by my scripts... digging :) | 06:23 |
| markh | is there a later version of the svn plugin that 0.4.10? | 06:25 |
| rusty | spiv: sorry for the confusion. Looks like I've creatively mixed my old and new setups, and got distracted halfway through. but it mostly "just worked" until someone *else* pushed a rev :) | 06:25 |
| poolie | hi rusty, afc | 06:25 |
| rusty | poolie: hi! | 06:25 |
| AfC | poolie: yo Martin | 06:26 |
| spiv | markh: not released. The development branch has a heap of changes since 0.4.10, but I don't think jelmer considers it stable enough for a release yet. | 06:26 |
| spiv | rusty: ah, right :) | 06:27 |
| markh | but 0.4.10 is complaining it is too old for the bzr version :) | 06:27 |
| rusty | spiv: quite an impressive knot I created here. Thanks for the injection of clue :) | 06:27 |
| markh | maybe its misleading me and its actually the pysvn bindings that are too new | 06:27 |
| spiv | rusty: not a problem | 06:27 |
| rusty | AfC: can publish script, but real python hacker would do better. Problem is that bzr doesn't say what repo it wants to access on the cmdline :( | 06:29 |
| AfC | rusty: yeah, I know. Running `bzr serve` as a [read only] daemon was no problem; we serve up URLs like bzr://research.operationaldynamics.com/bzr/java-gnome/mainline/ too easy. | 06:31 |
| AfC | rusty: But pushing to that ATM is bzr+ssh://epsilon.dal.operationaldynamics.com/export/web/com/operationaldynamics/research/bzr/java-gnome/mainline/ I mean, kill me now | 06:31 |
| AfC | rusty: if you don't want to post publicly, I would be more than honoured to receive an email from one so respected :) | 06:32 |
| rusty | AfC: sent | 06:33 |
| rusty | AfC: with hg-ssh you can specify what repos to allow access to in .authorized_keys. This one only allows you to restrict them to a particualr subdir. | 06:38 |
| spiv | AfC: here's a quick thing I just made based on the snippet rusty pasted earlier: http://rafb.net/p/eHQs9285.html | 06:40 |
| spiv | (Hmm, you probably don't want the --no-plugins bit, that was just to help me test it) | 06:41 |
| cjwatson | lifeless: thanks | 06:41 |
| AfC | Lookin' | 06:41 |
| spiv | AfC: there's a fancier bzr_access script in the contrib/ directory in bzr itself, I think it can do that too. | 06:42 |
| rusty | spiv: and humpty is back together again http://ccan.ozlabs.org/repo/ | 06:44 |
| spiv | Hurrah! | 06:45 |
| jamesh | rusty: you might want to run "bzr whoami" to set your committer ID | 06:46 |
| rusty | jamesh: thanks... is that permenant, per-repo or what? | 06:47 |
| jamesh | rusty: it will store your committer ID in ~/.bazaar/bazaar.conf | 06:48 |
| rusty | jamesh: ah found it. Thanks. | 06:48 |
| spiv | rusty: it's permanent, but you can have per-location ones by editing ~/.bazaar/locations.conf | 06:48 |
| jamesh | it is possible to specify different committer IDs for different branches (or trees of branches), but that is a little more involved | 06:48 |
| rusty | jamesh, spiv: thanks, I'm happy to have one non-sucky one for the moment :) | 06:49 |
| jamesh | e.g. if you segregate work branches into a particular location, you can get bzr to use a work email for them while using a personal email for everything else | 06:49 |
| markh | anyone know off-hand how I can have bzr ignore pycurl certificate errors - eg, like "curl -k ..."? | 07:14 |
| sohail | hey, when bzr says: "N files ignored" how can you find out which files were ignored? | 08:31 |
| luks | bzr ignored | 08:31 |
| sohail | thanks :-) | 08:31 |
| sohail | ah great, its ignoring the object files. :-) | 08:31 |
| sohail | this is strange | 08:33 |
| sohail | bzr clone /path/to/foo ... bzr commit ... bzr push => Error: Need to specify location? | 08:33 |
| luks | it doesn't know where to push | 08:34 |
| sohail | but I cloned it from /path/to/foo | 08:34 |
| sohail | why didn't it remember that? | 08:34 |
| bob2 | it doesn't default to the parent for push | 08:34 |
| bob2 | just pull | 08:34 |
| sohail | but... why | 08:34 |
| bob2 | often that isn't waht you want | 08:34 |
| poolie | sohail: because you'd often be starting work on a new feature | 08:34 |
| luks | because it doesn't mean you want to push there | 08:34 |
| sohail | confusing... | 08:35 |
| bob2 | e.g. if you have a local mirror of 'trunk', and branch from that, you probably want to push to the remote 'trunk' or something | 08:35 |
| poolie | sohail: if you do --remember on the first push you'll only need to give it once | 08:35 |
| sohail | well ok I haven't got to that point yet so I'll take your word on it | 08:35 |
| luks | poolie: er, you don't need --remember | 08:35 |
| sohail | must say that bzr is just about as fast as git (I was using git for the past month but got sick of it's silliness) | 08:35 |
| sohail | and now I must go to bed | 08:36 |
| sohail | night night! | 08:36 |
| poolie | great, glad you like it | 08:37 |
| kiorky | jamesh: rah, its annoying that i cant not branch locally without reaching the svn server :/ | 10:27 |
| jamesh | did you mean jelmer then? | 10:28 |
| kiorky | jamesh: yes, sorry for the noise | 10:45 |
| * mwhudson bounces about http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C48855B28.3070505@canonical.com%3E a bit | 11:03 | |
| jelmer | kiorky: can you try branching while you don't have a network connection and run with BZR_PDB=1 set? | 11:13 |
| jelmer | kiorky: that should get you into a debugger | 11:13 |
| jdobrien | larstiq: I pushed 3 blackbox tests for #30159 last night. https://code.launchpad.net/~jdobrien/bzr/bug30159 | 11:46 |
| LarstiQ | jdobrien: thanks | 11:47 |
| yacc_ | Any idea how to release a remote lock? | 12:15 |
| andrea-bs | yacc_: bzr break-lock | 12:16 |
| yacc_ | thx | 12:17 |
| kiorky | jelmer: BZR_PDB asan env. variable isnt it ? | 13:11 |
| james_w | kiorky: yup, it will drop you in to a debugger on exceptions | 13:27 |
| kiorky | jelmer_: https://bugs.launchpad.net/bzr-svn/+bug/250706/comments/4 | 14:30 |
| ubottu | Launchpad bug 250706 in bzr-svn "branching locally tries to reach forward svn server" [Undecided,Incomplete] | 14:30 |
| kiorky | jelmer_: i gave you the backtrace yet, i will be happy to hack on it, but for now i cant :p | 14:34 |
| kiorky | jelmer_: just for you to see if there is not an obious bug | 14:35 |
| kiorky | *obvious | 14:35 |
| Odd_Bloke | thumper: My sleeping patterns are just weird ATM, not really intentionally so. :) | 14:50 |
| === mw|out is now known as mw | ||
| gnomefreak | how would i fix this Unable to obtain lock file:///home/gnomefreak/tbird-3.0/work/thunderbird-3.0.head/.bzr/repository/lock held by gnomefreak@ubuntu.com on host Development [process #15954] | 15:12 |
| luks | we should have a bot that auto-replies "bzr break-lock" to anything with "lock" in it :) | 15:12 |
| pygi | or just make bzr run that automatically :p | 15:13 |
| gnomefreak | ah thanks ill try it | 15:13 |
| gnomefreak | thanks it worked great | 15:14 |
| gnomefreak | it would be nice if it sees that its locked to give you the choice to break the lock ;) | 15:15 |
| james_w | I think the message might have been tweaked to suggest that now. | 15:20 |
| beuno | it was, in 1.5 IIRC. It now tells you how to unlock it | 15:21 |
| james_w | hi beuno | 15:22 |
| gnomefreak | it doesnt here | 15:23 |
| gnomefreak | 1.5-1 | 15:24 |
| beuno | evening james_w | 15:24 |
| beuno | hmmmm... | 15:24 |
| beuno | http://bundlebuggy.aaronbentley.com/request/%3C2422be180805201918p5baf7b5fq1c10ea8b300adfbe%40mail.gmail.com%3E | 15:25 |
| beuno | it was merged in May | 15:26 |
| gnomefreak | http://pastebin.mozilla.org/497775 is all i got | 15:27 |
| gnomefreak | waited close to a minute than finally hit cntl+c | 15:28 |
| gnomefreak | ctrl | 15:28 |
| luks | there was no release since then, it will be in 1.6 | 15:29 |
| beuno | ah, time sure flies by... | 15:29 |
| luks | nope, it's just that bzr releases are slowing down :) | 15:30 |
| gnomefreak | oh so it missed 1.5 | 15:30 |
| steltho | I am trying to pull from a remote branch, and I am getting this error message: | 15:34 |
| steltho | bzr: ERROR: Invalid http response for http://bzr.savannah.gnu.org/r/gnash/.bzr/repository/indices/2c779c251220f8afce08bcec69277e32.rix: Expected a boundary ("/E9'NLJ'Cd-jBKfDwKZv", application/plain) line, got '--/E9'NLJ'Cd-jBKfDwKZv | 15:35 |
| steltho | anyone have any idea what might be causing this | 15:35 |
| Peng_ | steltho: What version of Bazaar? | 15:37 |
| Peng_ | steltho: I'm pretty sure this was fixed recently. | 15:38 |
| steltho | 1.1.0 | 15:39 |
| meatballhat | what's the right way to specify a merge from a branch without a common ancestor (if possible)? | 15:42 |
| Peng_ | steltho: That's kind of old, and this was within the last couple months. | 15:47 |
| Peng_ | Hmm, the Savannah thing I was thinking of might be a different issue. | 15:48 |
| jelmer | kiorky, still there? | 15:50 |
| kiorky | jelmer: yep but at work | 15:55 |
| jelmer | kiorky, does foo/.svn exist? | 15:55 |
| kiorky | fog: jelmer LC_ALL=C ls bzrsvn/messaging/.svn friendArchives/messaging/.svn | 15:57 |
| kiorky | ls: cannot access bzrsvn/messaging/.svn: No such file or directory | 15:57 |
| kiorky | ls: cannot access friendArchives/messaging/.svn: No such file or directory | 15:57 |
| kiorky | jelmer: :) | 15:57 |
| kiorky | jelmer: http://www.friendpaste.com/8tMhhdet | 15:58 |
| jelmer | kiorky, does "svn info foo" return anything? | 15:59 |
| kiorky | jelmer: nope neither in the locally branched one | 16:01 |
| jelmer | kiorky: You run: | 16:03 |
| jelmer | >rm -rf foo;bzr branch foo bar | 16:03 |
| jelmer | "bzr branch" assumes foo already exists locally | 16:03 |
| jelmer | does "bzr info" in the parent directory do anything? | 16:03 |
| === sdboyer is now known as sdboyer|coding | ||
| kiorky | jelmer: you mean in foo/.. ? | 16:05 |
| jelmer | kiorky: No, in the directory above foo/ | 16:06 |
| kiorky | jelmer: so in foo/? | 16:06 |
| jelmer | kiorky: no, in the parent directory of foo | 16:07 |
| jelmer | kiorky, you seem to be running "bzr branch" on a directory foo that doesn't exist | 16:10 |
| jelmer | since you remove it before you use it | 16:10 |
| kiorky | jelmer: http://www.friendpaste.com/c6vWEJ5F and http://www.friendpaste.com/DwVJQ4KC | 16:10 |
| kiorky | jelmer: foo exists ! | 16:10 |
| kiorky | jelmer: im not a fool :p | 16:10 |
| jelmer | kiorky, in your paste http://launchpadlibrarian.net/16253623/trace | 16:10 |
| jelmer | kiorky, you run ">rm -rf foo;bzr branch foo bar" | 16:10 |
| kiorky | jelmer: no i just replaced some content to hide the real folders | 16:10 |
| kiorky | jelmer: i rm -rf bar | 16:11 |
| kiorky | jelmer: not foo, sorry. | 16:11 |
| jelmer | kiorky: This is happening because one of the the ancestor directories of foo and bar contains some svn working copy | 16:12 |
| kiorky | jelmer: uhm, how can it be possible | 16:12 |
| jelmer | maybe not /somewhere but one of the parents of somewhere | 16:12 |
| kiorky | yep | 16:12 |
| kiorky | on one parent more | 16:12 |
| kiorky | but there is an ancestor common to the twice branches without any bzr or svn metadata directories | 16:13 |
| jelmer | that doesn't matter | 16:13 |
| jelmer | it'll browse down to the root of the fs | 16:13 |
| kiorky | the branches are in /myproject/repos/bzrsvn/foo /myproject/repos/feature/bar, /myproject/repos has nither .svn or .bzr but /myproject/ has an ".svn" | 16:14 |
| kiorky | jelmer: why ? | 16:14 |
| jelmer | kiorky: What version of bzr-svn is this? I did fix something related to this earlier | 16:15 |
| kiorky | jelmer: i gave you the versions on the bug report | 16:15 |
| kiorky | jelmer: https://bugs.launchpad.net/bzr-svn/+bug/250706 :) | 16:16 |
| ubottu | Launchpad bug 250706 in bzr-svn "branching locally tries to reach forward svn server" [Undecided,Incomplete] | 16:16 |
| kiorky | jelmer: basicly a few day earlier co | 16:16 |
| jelmer | kiorky: I'll see if I can make it only create the remote connection a bit more lazily | 16:20 |
| Peng_ | Is bzr-svn supposed to break existing branches in the most horrible ways at the moment? | 16:25 |
| Peng_ | s/supposed/expected/ | 16:25 |
| LarstiQ | Peng_: ah yes, that combination of commit message and change :) | 16:26 |
| Peng_ | ? | 16:26 |
| LarstiQ | Peng_: bzr log -r 1495; bzr diff -c 1495 | 16:27 |
| Peng_ | Yeah | 16:28 |
| Peng_ | Are there any current issues? | 16:28 |
| === sm_ is now known as sm | ||
| jelmer | Peng: yes, the 0.4 is an unstable branch | 16:30 |
| Peng_ | Uh-ohs. | 16:30 |
| jelmer | Peng: It always has been this way, I've just clarified the warning a bit | 16:31 |
| Peng_ | Yeah, I know, but usually it's mostly working right. | 16:31 |
| jelmer | since some people seemed to interpret "output can change" as the console output rather than the revisions outputted | 16:31 |
| jelmer | yeah, it should still work well in most cases | 16:31 |
| jelmer | nothing has changed there | 16:32 |
| Peng_ | Okay. | 16:32 |
| VSpike | I'm trying to push a branch up to a directory I created on my main repository, using bzr push --use-existing-dir .. The repo is on a linux box, shared using Samba, mounted on a Vista machine which is running the Cygwin version of bzr (1.4). | 16:36 |
| VSpike | I'm getting an odd error: bzr: ERROR: Could not acquire lock "[Errno 13] Permission denied" | 16:36 |
| VSpike | /usr/lib/python2.5/site-packages/bzrlib/lock.py:79: UserWarning: lock on <open file u'/cygdrive/r/website/thurayalocate/web/.bzr/checkout/dirstate', mode 'rb' at 0x1329ad0> not released | 16:37 |
| VSpike | warn("lock on %r not released" % self.f) | 16:37 |
| VSpike | Any ideas? | 16:37 |
| matkor | does samba shares support file locks ? | 16:42 |
| VSpike | Yes, AFAIK | 16:43 |
| VSpike | I guess I have a bit of a mix of technologies going on here, but normally it all works really well :) Amazingly enough | 16:44 |
| VSpike | Can't get sftp working on windows but smb does me OK | 16:44 |
| matkor | IIRC I had similar prolbem with glusterfs ... and I had to enable posix locks which might be different than file locks used in samba | 16:46 |
| VSpike | I can merge, push, pull, checkout to this repo normally from the vista machine | 16:47 |
| VSpike | It seems to be pushing to an empty dir that is breaking | 16:48 |
| VSpike | Does that use locks differently somehow? | 16:48 |
| matkor | I am not expert but I was surprised that there are many types of locks | 16:49 |
| matkor | I have to go, so goog luck with solving issue | 16:50 |
| matkor | good | 16:50 |
| vimes656 | is bzr cp available in the latest version of bzr? | 16:57 |
| jelmer | vimes656: I don't think there is such a command | 16:59 |
| vimes656 | jelmer: how can I copy a file keeping the revision history of the original file? | 17:00 |
| jelmer | vimes656, there's no way to do that at the moment | 17:01 |
| jjcroftiv | hello, i am new to bazaar and I am trying to find out how to create an external dependency like subversion externals, TIA | 17:02 |
| jelmer | jjcroftiv, there's an experimental feature called "nested trees" that does something similar | 17:03 |
| jelmer | abentley, thanks for the pqm updates | 17:03 |
| abentley | jelmer: np | 17:04 |
| jelmer | kiorky, I've pushed a fix - any chance you can verify it works? | 17:06 |
| mgedmin | shouldn't bzr get lp:lxml show some progress indication? | 17:10 |
| mgedmin | all I get is a long silent delay and then "Branched 2661 revision(s)." | 17:10 |
| mgedmin | bzr 1.5 | 17:10 |
| mgedmin | this is nice and Unix-y, but I seem to recall progress bars in earlier versions? | 17:11 |
| jjcroftiv | jelmer, do you have any info on where the "nested trees" feature is documented | 17:14 |
| jelmer | jjcroftiv, I don't think it's very well documented yet since it's an experimental feature | 17:14 |
| vimes656 | jjcroftiv: if you know how to use zc.buildout you can use gf.recipe.bzr | 17:17 |
| vimes656 | I'm using it for a project and works quite well | 17:17 |
| vimes656 | http://pypi.python.org/pypi/gf.recipe.bzr/1.0dev-20080117 | 17:18 |
| jjcroftiv | vimes656, thanks for the link, i'm going to check it out | 17:19 |
| jjcroftiv | no pun intended | 17:19 |
| dash | Hi. bzrlib question -- | 17:48 |
| dash | i'm calling branch.create_checkout(). it takes an accelerator_tree argument; can it be a tree other than one associated with that branch? | 17:50 |
| dash | say i've got branchA and branchB in a remote repository and I have a local checkout of branchA. can I use the tree from branchA as an accelerator_tree for checking out branchB? | 17:51 |
| dash | man. wish that 'integrating with bzr' doc showed some stuff about merges :) | 18:01 |
| james_w | dash: I believe you can. It will become less efficient the further the contents of the accelerator tree are away from the requested tree. | 18:13 |
| dash | Sure. | 18:13 |
| james_w | what problems are you having with merges? | 18:13 |
| dash | james_w: figuring out how to do them :) | 18:13 |
| dash | i'm reading builtins.cmd_merge | 18:13 |
| dash | but there's a lot of it | 18:13 |
| james_w | yeah, it's a problem that there is too much logic in some of the cmd classes | 18:14 |
| dash | it's way better than some tools i've worked with... :) | 18:15 |
| LarstiQ | with or on? | 18:15 |
| dash | sure. | 18:15 |
| LarstiQ | dash: gah :P | 18:16 |
| chombee | Hey -- following the centralised lock-step workflow, I create a local repo and commit some stuff then do bzr push to push it to a central a location. At the central location I get a repo with no working tree. Is it safe to do bzr checkout on the central repo to get a working tree? Or must it remain bare as in git? | 18:21 |
| dash | yes, you can checkout with no problem | 18:21 |
| fullermd | The only gotcha is that future 'push's won't update that tree, so you'll have to remember to do it by hand. | 18:23 |
| chombee | Next question, after the push the local repo seems to be a branch rather than a checkout of the remote repo. I guess I want do bind the local repo to the remote one, so I can do bzr updates? | 18:23 |
| chombee | fullermd Yeah, isn't it safer to have a central repo with no tree, so no one gets confused? | 18:24 |
| dash | chombee: possibly so | 18:24 |
| fullermd | Well, depends on why you want the tree there. | 18:24 |
| dash | but there's also this: https://launchpad.net/bzr-push-and-update | 18:24 |
| dash | (perfect for developmenstuction environments) | 18:24 |
| jam | dash: for merge, you probably just want "WT.merge_from_branch" | 18:25 |
| jam | at least that is what I use 99% of the time | 18:25 |
| dash | jam: hm! | 18:25 |
| * dash looks at the docs | 18:25 | |
| jam | dash: The complexity in cmd_merge is because you can supply a bundle, or a working tree, or a file within a working tree, or a branch, or .... | 18:26 |
| dash | jam: looks like that's exactly what I need, thanks | 18:26 |
| dash | jam: Right | 18:26 |
| jam | but for most people, they just want to merge a branch | 18:26 |
| dash | yeah, i'm specifically just merging a branch in this case. | 18:27 |
| chombee | With a centralised, offline workflow is it possible to use bzr as you would use git? i.e. bzr commit does a local commit, bzr push pushes local commits to a central repo, and bzr pull brings commits from the central repo into a local repo? Is it better to use the different centralised with offline commits workflow from the bzr manual? | 18:50 |
| beuno | chombee, you can work exactly like that with bzr | 18:51 |
| beuno | you just need to branch instead of checkout | 18:51 |
| chombee | Hmm, so you can, cool. | 18:53 |
| === mw is now known as mw|food | ||
| dash | oh, great | 19:07 |
| dash | I can't use merge_from_branch because I need to be able to do the equivalent of "merge --force" | 19:07 |
| dash | guess i'll do it the long way :) | 19:07 |
| chombee | By default git makes a crypto hash of each revision, so it can tell me if any file corruption has happened in a repo. Can bzr do that, so I know my content is safe? | 19:27 |
| luks | chombee: bzr does that too, but it's not visible | 19:28 |
| fullermd | It stores a hash. That protects you from incompetence, though not from malice. | 19:28 |
| fullermd | For the latter, there's PGP signing of revs. | 19:28 |
| chombee | Hmm | 19:28 |
| chombee | So say some corruption occurred ina repo, would bzr notify me the next time I ran some bzr command on that repo? | 19:29 |
| chombee | fullermd it's disk faults isn't it, rather than incompetence? | 19:29 |
| fullermd | Well, hardware can be incompetent :) | 19:29 |
| fullermd | ('can be'... ha. I'm so diplomatic...) | 19:30 |
| chombee | :) | 19:30 |
| fullermd | Well, it certainly wouldn't catch it before the next time it has to grab that particular data for something. | 19:30 |
| fullermd | 'check' will preen the whole thing. | 19:30 |
| chombee | So if I do bzr check and it's okay then there's no corruption in the repo? Looks that way | 19:31 |
| * fullermd nods. | 19:32 | |
| fullermd | (mod bugs in check of course, but you have to trust something) | 19:32 |
| chombee | Cool, I like it btter than git, it just makes it easier to do the same thing | 19:32 |
| chombee | Thanks | 19:36 |
| kiorky | jelmer: i ll try it on the evening or tomorrow at least, doctour house time. Ill poke you as soon at it is done | 19:48 |
| mgedmin | launchpad can currently import (some) svn and cvs repositories into bzr branches | 19:49 |
| mgedmin | any chances for importing git repositories? | 19:49 |
| Peng_ | bzr-fastimport might be able to import git. | 19:56 |
| fullermd | AIUI, it can. But fast-import doesn't handle incremental stuff. | 19:56 |
| fullermd | And of course you can't get move info from git... | 19:56 |
| dash | can you from cvs or svn? | 19:57 |
| fullermd | So, you can convert with it. But LP does ongoing imports. | 19:57 |
| Peng_ | fast-import doesn't support incremental imports? Huh | 19:57 |
| fullermd | I don't think so, no. | 19:58 |
| fullermd | (based on vague recollections of discussions of course; igc would have a much more authoritative answer) | 19:58 |
| lifeless | abentley: what is previewtree capable of? | 20:35 |
| lifeless | abentley: and how efficient is it? | 20:35 |
| abentley | lifeless: Right now, it's capable of being the source of a diff, but it should be able to represent any working tree state. | 20:36 |
| lifeless | abentley: I'm thinking about implementation strategies for tree marks | 20:37 |
| abentley | lifeless: It's not written for efficiency, but I want to find out what parts are bad, and fix those first. | 20:38 |
| abentley | The goal so far has been to make it fully conform to the Tree interface and get it under test. | 20:38 |
| abentley | lifeless: Tree marks are the sort of thing I'd like to see it become good at. | 20:39 |
| lifeless | so for marks I need a tree that: | 20:39 |
| lifeless | - when reverted reverts the underlying working tree content, but only for the content the marks selected | 20:39 |
| lifeless | - does not slow commit down at all for the common case (where / is marked 'selected') | 20:40 |
| lifeless | - can 'remove' changes from the working tree where they do not meet the marks the tree is parameterised with | 20:40 |
| lifeless | separately from that I need to figure out how to manage the marks data | 20:43 |
| abentley | wrt revert: A preview tree is "written" to using its TreeTransform. So this sounds like something that belongs in the revert code, not a characteristic of a PreviewTree. | 20:43 |
| abentley | I would expect that commit of a PreviewTree is slower than WorkingTree in the common case. | 20:44 |
| lifeless | abentley: or perhaps previewtree doesn't fit marks? the tree object used when marks are in use probably wants to be a proxy object | 20:44 |
| lifeless | in that it wants to lazily calculate things and return them as asked for: precalculating all the differences could be arbitrarily large | 20:45 |
| kiorky | jelmer: which branch? because pull gave me no revision update | 20:45 |
| abentley | A PreviewTree can have arbitrary changes applied to it, so 'removing' particular changes is not a problem. | 20:45 |
| kiorky | jelmer: i use : http://people.samba.org/bzr/jelmer/bzr-svn/trunk/ | 20:45 |
| jelmer | kiorky, the 0.4 branch | 20:45 |
| abentley | lifeless: The way to use "marks" with a PreviewTree is probably to start with the PreviewTree as an unchanged version of the basis tree. | 20:46 |
| jam | Peng_, fullermd: fast-import *does* support incremental conversions, by writing down whatever mapping it has performed so far | 20:46 |
| kiorky | jelmer: is this safe to use on existing stuff with the version i have ? | 20:46 |
| jam | I don't think it allows you to generate a "partial stream" | 20:46 |
| kiorky | jelmer: i have pending work ^^ | 20:46 |
| abentley | Then as marks are added, the Transform is manipulated to apply the changes. | 20:46 |
| jam | And I wouldn't ever count on an incremental conversion from CVS | 20:46 |
| jam | because borking history is fairly standard practice there | 20:46 |
| jelmer | kiorky, I would recommend only using released versions for production work | 20:47 |
| salgado | hey, if I have an uncommitted merge, can I generated a bundle out of it? | 20:47 |
| salgado | s/generated/generate | 20:47 |
| abentley | salgado: No. A bundle contains committed changes by definition. | 20:47 |
| fullermd | Huh. Learn something new every day... | 20:48 |
| jam | lifeless: any luck with 'freeze' ? | 20:48 |
| lifeless | jam: 2 seconds faster for st on bzr.dev with cold cache | 20:48 |
| lifeless | 13 -> 11 | 20:48 |
| lifeless | no significant change in hot cache | 20:48 |
| salgado | abentley, right. how would I go about turning that into a bundle after I commit it? | 20:48 |
| kiorky | jelmer: someone told me to take bzr.dev and bzr-svn.trunk to have goof svn integration and not much risks | 20:48 |
| kiorky | jelmer: lifeless maybe if i remember well | 20:48 |
| jam | lifeless: sounds about right for the time to load the python libs | 20:48 |
| kiorky | jelmer: but i can afford bugs :), i just want to limit them and not shoot in my feet :) | 20:49 |
| abentley | salgado: "bzr send" | 20:49 |
| jelmer | kiorky, generally the 0.4 branch works pretty well. It may in rare cases break imports though | 20:49 |
| lifeless | jam: consistently lower system time - about 0.03 seconds less | 20:49 |
| abentley | salgado: That actually produces a merge directive, which is what people usually mean by "bundle". | 20:49 |
| jam | lifeless: well, 30ms isn't 0, but not a lot to write home about | 20:50 |
| kiorky | jelmer: OK | 20:50 |
| lifeless | jam: its the cold cache I'm more interested in TBH | 20:50 |
| kiorky | jelmer: so no backward risks with the bzr.trunk? | 20:50 |
| kiorky | jelmer: no migration stuff or any other thbings ? | 20:50 |
| jam | lifeless: so instead we should just write a background process that keeps things out of cold cache, right? | 20:50 |
| jam | :) | 20:50 |
| lifeless | jam: thwack | 20:50 |
| jelmer | kiorky, it's definitely more risky than using a release | 20:50 |
| kiorky | jelmer: i can co, replace and run directly bzr pull in my branches ? | 20:50 |
| jam | lifeless: well, 'bzr service' comes to mind | 20:51 |
| salgado | abentley, but it still contains the actual code changes that I could apply to a branch, right? | 20:51 |
| lifeless | jam: it doesn't improve the cold cache case | 20:51 |
| jelmer | kiorky, what do you mean with bzr.trunk? | 20:51 |
| kiorky | jelmer: well i will tarball my stuff, time to test ^^ enought talk | 20:51 |
| jam | lifeless: depends when you are measuring | 20:51 |
| jam | as it keeps everything in mem | 20:51 |
| lifeless | jam: OTOH the frozen bzr is 7.7MB :( | 20:51 |
| jam | if you drop caches after starting it | 20:51 |
| lifeless | jam: power on | 20:51 |
| kiorky | jelmer: bzr.dev and bzr-svn.trunk | 20:51 |
| abentley | salgado: Yes, it specifies the particular merge that would apply those changes to a branch, and includes all the necessary revision data in a bundle. | 20:52 |
| lifeless | jam: first-use by a new user | 20:52 |
| jelmer | kiorky, you really don't want bzr-svn.trunk but bzr-svn 0.4 | 20:52 |
| lifeless | jam: etc | 20:52 |
| jelmer | kiorky, trunk is just more outdated than 0.4 | 20:52 |
| kiorky | jelmer: ok, good to know | 20:52 |
| kiorky | jelmer: its branching | 20:53 |
| jam | lifeless: you just put the service startup in your .login file | 20:53 |
| jam | so it just seems like 2s more boot time | 20:53 |
| lifeless | jam: I hope you are trolling | 20:53 |
| jam | I'm somewhat serious if you are *just* trying to solve the cold boot process | 20:54 |
| jam | it is really only 1 time | 20:54 |
| jam | and there are a lot easier ways to trick it | 20:54 |
| lifeless | its not about tricking though | 20:54 |
| lifeless | its about being genuinely lighter-weight | 20:54 |
| jelmer | kiorky: bzr-svn you mean or that particular branch you were trying to copy? | 20:55 |
| jam | lifeless: well 'time cbzr status' with the service running is <100ms, 'time bzr st' is 220ms with a hot cache. | 20:56 |
| kiorky | jelmer: im branching and installing the 0.4 you told me about | 20:56 |
| kiorky | jelmer: http://people.samba.org/bzr/jelmer/bzr-svn/0.4 | 20:56 |
| jam | I get down to 80ms for a bzr.dev tree | 20:56 |
| lifeless | jam: http://rafb.net/p/taLkYP27.html | 20:57 |
| lifeless | jam: so I'm not against a service per se; but git does not need one. | 20:57 |
| lifeless | a service seems to have more race conditions, and more chance for bugs like skew on package upgrade | 20:58 |
| salgado | abentley, coolio. works just like I wanted it to. :) | 20:58 |
| lifeless | jam: even with my long list of plugins there is a big difference loading the frozen version | 20:59 |
| jam | lifeless: http://rafb.net/p/MuVvT317.html | 20:59 |
| jam | I don't strictly agree with a service model | 20:59 |
| jam | I'm not very happy with it | 20:59 |
| jam | for the reasons you describe | 20:59 |
| jam | but it is hard to argue dropping from 400=>100ms, when I can get you to 6ms | 20:59 |
| lifeless | jam: service also won't pickup plugin changes dynamically | 21:00 |
| jam | lifeless: you could make ti | 21:00 |
| lifeless | it will be prone to failure-to-test | 21:00 |
| jam | make it do so | 21:00 |
| lifeless | jam: not _very_ reliably - reload() has serious issues | 21:00 |
| jam | and with inotify sort of thing, it could do so cheaply | 21:00 |
| jam | lifeless: if it was serious, it could respawn itself | 21:00 |
| lifeless | I dug into inotify | 21:01 |
| lifeless | its horrible to work with | 21:01 |
| jam | lifeless: sure, there are about 5 different wrappers, and I know "bos" was complaining about one of the python ones destroying his system when in use | 21:01 |
| abentley | salgado: I'm glad. | 21:01 |
| jam | so he wrote another | 21:01 |
| lifeless | you can't listen recursively | 21:01 |
| lifeless | its not the wrapper; its the kernel facility itself | 21:01 |
| lifeless | you have to listen to everything individually | 21:02 |
| lifeless | another issue with service is when the user hits ctrl-C it kills the client not the demon | 21:03 |
| lifeless | so it's harder for them to model what is really happening | 21:03 |
| jam | lifeless: anyway, I would love for us to get "lighter", and service as a plugin really does need a lot of overhaul | 21:03 |
| lifeless | and if they login N times resource use will shoot up | 21:03 |
| lifeless | and python with its cavalier memory management really concerns me | 21:03 |
| jam | what I would *rather* see is better python support for loading pre-cached information | 21:04 |
| jam | like "take a snapshot of where these exist, and re-use it on the next invocation" | 21:04 |
| === mw|food is now known as mw | ||
| jam | anyway, I'm certainly interested in where you get to | 21:06 |
| jam | Also, for 'bzr' being 7MB | 21:06 |
| jam | after frozen | 21:06 |
| jam | it is 9M in my /usr/lib/python | 21:06 |
| jam | and 24 in my bzr.dev folder | 21:06 |
| jam | I suppose 8.7M if you just count the .pyc files | 21:07 |
| fullermd | % du -sh /usr/local/lib/python2.5/site-packages/bzrlib/ | 21:08 |
| fullermd | 25M /usr/local/lib/python2.5/site-packages/bzrlib/ | 21:08 |
| fullermd | (bzrtools is under there too) | 21:08 |
| jam | bzrtools is pretty small | 21:08 |
| jam | I think mine is smaller because it uses symlinks to pycentral | 21:08 |
| fullermd | Just under a meg. | 21:08 |
| lifeless | its about 30ms functional difference | 21:08 |
| lifeless | plugins cost me about 150ms to load | 21:09 |
| fullermd | bzrlib in my bzr.dev is ~12 meg. | 21:09 |
| fullermd | The difference is the .pyo's I presume. | 21:09 |
| === sdboyer|coding is now known as sdboyer | ||
| lifeless | well | 21:09 |
| lifeless | Ubuntu/Debian don't create .pyo files. | 21:10 |
| fullermd | I'm not sure they serve any purpose. The time or two that I tried, I couldn't measure a perf difference... | 21:10 |
| jam | Interestingly, I think if you don't create them at install time, then future "python -O" runs would actually be *slower* | 21:10 |
| jam | fullermd: all it really does is remove asserts | 21:10 |
| fullermd | (not that I tried particularly hard, but...) | 21:10 |
| lifeless | jam: thats correct | 21:10 |
| lifeless | jam: I spent some time last week pointing this out :) | 21:11 |
| jam | lifeless: like, dramatically, because it is on-the-fly recompiling all the .py | 21:11 |
| lifeless | jam: yes | 21:11 |
| lifeless | jam: and there are python upstreams that recommend the use of -O | 21:11 |
| jam | fullermd: actually, I would expect "python -OO" to be quite a bit smaller, but we don't support that mode | 21:12 |
| jam | as we have a *lot* of doc-strings that would then be stripped | 21:12 |
| jam | (but then none of your commands would have help text, either) | 21:12 |
| fullermd | Heck, nobody ever reads the help, right? | 21:13 |
| lifeless | sometimes I think that | 21:13 |
| jam | fullermd: sure, but how can you tell them to RTFM if you stripped it from the installer | 21:13 |
| jam | it at least needs to be there | 21:13 |
| lifeless | jam: how well do you know the patience code? | 21:13 |
| jam | lifeless: fairly well | 21:13 |
| lifeless | I'm looking at a C groupcompressor | 21:13 |
| lifeless | what I need is two things - a matching blocks list that is _not_ constrained to be strictly increasing, and | 21:14 |
| lifeless | a left-side lines-hash that is persistent | 21:14 |
| lifeless | I looked at the patience diff C code, and its seems possible to do this, but I'm not entirely sure it will fit well | 21:15 |
| jam | lifeless: I think it would fit ok | 21:16 |
| jam | add_matching_line will only work on the existing block or start a new one | 21:16 |
| kiorky | jelmer: seems to work :) | 21:16 |
| jam | but I think that is fine for what you need | 21:16 |
| jelmer | kiorky, cool :-) | 21:16 |
| lifeless | jam: have a look at rev 14 of lp:~lifeless/+junk/bzr-groupcompress | 21:17 |
| kiorky | jelmer: you can mark your patch working for my test case, i hope you can merge it :) | 21:17 |
| jam | lifeless: as you are only going to be generating blocks at a time, right? | 21:17 |
| jelmer | kiorky, it's already merged | 21:17 |
| jelmer | (0.4 is the main branch) | 21:17 |
| lifeless | I've cleaned up the compression code to be slower-but-clearer in preparation for a C accelerator | 21:17 |
| kiorky | jelmer: ha, very cool so | 21:17 |
| lifeless | jam: not sure what you mean by blocks-at-a-time | 21:18 |
| lifeless | jam: its basically, start with "" as output, then for each input text | 21:18 |
| jam | lifeless: you will match a range from A=>B, and then might come back later to mark < A, but you won't try to *combine* that with the existing block | 21:18 |
| lifeless | match(output, input); for section of input: if new: emit 'i', if reusable: emit 'c' unless 'i' is cheaper. hash(emitted) and extend output by emitted | 21:20 |
| lifeless | oh, with the caveat that we *don't* hash output lines that we know are not new | 21:20 |
| jam | lifeless: so do you compress within a single text? | 21:24 |
| lifeless | no | 21:24 |
| jam | lifeless: it seems like you could, by incrementally adding the lines, but I don't know if you would gain a lot | 21:27 |
| mwhudson | morning | 21:27 |
| jam | mwhudson: morning | 21:27 |
| lifeless | jam: it would make it into a plain dictionary compressor; increase the lookup size a lot, and prevent the one-parse extraction I think | 21:28 |
| lifeless | hi mwhudson | 21:28 |
| mwhudson | (review my branch) | 21:28 |
| mwhudson | (please) | 21:28 |
| jam | mwhudson: which one would that be? | 21:28 |
| mwhudson | jam: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C48855B28.3070505@canonical.com%3E | 21:29 |
| jam | mwhudson: well, the instant review is bb:resubmit | 21:29 |
| jam | Pending some time to actually fully review :) | 21:29 |
| mwhudson | jam: heh | 21:29 |
| mwhudson | it's the last fix we (know we) need in bzr to get stacking working on launchpad | 21:30 |
| jam | mwhudson: well, a quick statement is that you should be raising "TestNotApplicable" rather than just returning | 21:31 |
| jam | anyone have an idea how you make a window transparent in compiz? I just did it by accident and Iwant it opaque again | 21:31 |
| mwhudson | jam: just returning is what the other tests in the file do, want me to change them too? | 21:31 |
| mwhudson | jam: ctrl-mousewheel, i think | 21:31 |
| mwhudson | certainly <some modifier>-mousewheel | 21:32 |
| jam | well, ctr+mousewheel in FF changes the font size | 21:32 |
| jam | but alt+wheel did it | 21:32 |
| jam | compiz and my trackpad don't get along very well | 21:32 |
| mwhudson | that sounds familiar | 21:33 |
| jam | The default to scroll to another window when you wheel on an edge | 21:33 |
| jam | was really bad | 21:33 |
| jam | because mousing to the edge of the trackpad | 21:33 |
| jam | would give a couple scroll clicks | 21:33 |
| * fullermd takes pleasure in avoiding both compiz and trackpads... | 21:33 | |
| jam | I'm having a hard time deciding if this is a troll or genuine: https://answers.launchpad.net/bzr/+question/40059 | 21:34 |
| beuno | jam, I'm not answering anymore, that's for sure | 21:34 |
| beuno | Odd_Bloke did go to great lengths to answer | 21:34 |
| jam | mwhudson: I would do consistency first, but I thought that TestNotApplicable was the "correct" way | 21:35 |
| beuno | give 'em a URL, if they don't go away, tag him as a troll | 21:35 |
| jam | I haven't dug deeply into the stacked stuff, but what you did looks right IMO | 21:35 |
| lifeless | jam: what is the value of a line in a in patience sort? | 21:35 |
| mwhudson | jam: looks like /most/ of the tests raise TestNotApplicable | 21:35 |
| mwhudson | jam: so i'll fix the others | 21:35 |
| lifeless | jam: is it the index of the line? if so how do you choose /which/ index to use? | 21:35 |
| jam | lifeless: are you talking the C or Py code? | 21:36 |
| jam | they differ, IIRC | 21:36 |
| lifeless | C | 21:36 |
| lifeless | well, to get the same result they can't really? :) | 21:36 |
| jam | at least at a minimum C maintains the hashes | 21:36 |
| jam | so in the C code, a 'line' is effectively a chain of matching lines | 21:37 |
| jam | and "matching_line" the structure is the indexes | 21:37 |
| lifeless | hmmm | 21:42 |
| lifeless | I need to persist some of these structures | 21:43 |
| lifeless | blah! | 21:43 |
| jam | ? | 21:43 |
| lifeless | as output is immutable, recalculating the hashes is O(N^2) times the cost of setting up the hash | 21:43 |
| lifeless | no O needed there - there is a N^2 overhead in not reusing the hash | 21:44 |
| lifeless | so I need to figure out the C api for exposing these things as python objects that can be reused | 21:44 |
| jam | mwhudson: So, it looks good to *me*, but I would rather someone like poolie or lifeless who actually worked more closely on the stacking code to approve it | 21:45 |
| mwhudson | jam: ok, thanks | 21:45 |
| jam | lifeless: I can work out some quick pyrex magic | 21:45 |
| jam | it isn't hard | 21:45 |
| lifeless | jam: in a separate file you mean? | 21:46 |
| lifeless | I can do that too ;) | 21:46 |
| jam | lifeless: no, I mean I've done pyrex to do the wrapping, and I can check its output | 21:46 |
| lifeless | jam: _patiencediff_c is a C source, not a pyrex source. I am confused about what you mean. | 21:47 |
| jam | lifeless: in my walkdirs code, I export a C structure => PyObject | 21:48 |
| jam | using Pyrex to generate the right C code to do so | 21:48 |
| jam | we can crib fromthat | 21:48 |
| jam | I just have to update my bzr.dev first | 21:49 |
| scode | I have a repos with very little activity that i've been pushing to with bzr+ssh. Suddenly I notice that when trying to freshly branch, I get: bzr: ERROR: Error in data for index <bzrlib.index.GraphIndex object at 0x804fcd350>. | 21:49 |
| scode | Any particular common cause for this, or have I encountered a bug? | 21:49 |
| lifeless | jam: I get that; I thought your walkdirs was Pyrex based though? So pyrex is taking care of the headaches/updates/etc | 21:49 |
| jam | lifeless: right | 21:49 |
| jam | But it actually turns out to be relatively simple | 21:49 |
| jam | (the part I like most about pyrex is the exception handling goodness) | 21:50 |
| scode | Important "detail": Oh right, branching locally works. This only happens when branch:ing over http. | 21:50 |
| jam | like getting a stack-trace into the pyrex code | 21:50 |
| lifeless | scode: sounds like a bug, or some interfering proxy | 21:50 |
| lifeless | scode: please do file abug; the full backtrace from ~/.bzr.log is a good start | 21:50 |
| scode | lifeless: No proxie, and I don't see 404:s or similar in the web server log excep tthsoe that I believe are expected | 21:50 |
| scode | lifeless: Ok. Will do, either tonight or tomorrow. | 21:51 |
| lifeless | scode: if you can give us the url to the branch that will help debugging | 21:51 |
| scode | lifeless: http://bzr.scode.org/repo/pkgmanager-portssupport (I'll include in bug report) | 21:51 |
| jam | lifeless: http://rafb.net/p/e3rzPV87.html | 21:51 |
| lifeless | scode: no proxy at all? are you not going to the interwebs ? :) [ISP's often have 'transparent' proxies] | 21:51 |
| scode | lifeless: Firstly, my ISP is sane :) Secondly, it happens with a local http branch from the same host. | 21:52 |
| lifeless | scode: ok | 21:52 |
| scode | lifeless: And I definitely don't have transparent proxying on my machine.:) | 21:52 |
| jam | {"name", T_INT, offsetof(struct, member), READONLY, 0} | 21:52 |
| lifeless | scode: please throw up a bug then and we'll take it from there | 21:52 |
| jam | lifeless: ^- not too hard to repeat that a few times | 21:52 |
| lifeless | jam: thats not the bit that I was going to have to look up | 21:52 |
| scode | lifeless: Thanks. Will do - like I said either in a bit, or tomorrow. Thanks for confirming it seems unexpected. | 21:52 |
| lifeless | jam: its the massive class definition and __init__ etc | 21:52 |
| jam | lifeless: sure | 21:53 |
| jam | though you can also do that in a separate pyrex definition | 21:53 |
| jam | lifeless: I understand your concern, though, and I do like pyrex for that stuff | 21:54 |
| lifeless | how do you feel about us making _patiencedif_c a pyx file? | 21:57 |
| lifeless | seems to me its not exactly pure C and usable from C today | 21:58 |
| lifeless | mwhudson: bzrdir's aren't stacked | 21:59 |
| lifeless | mwhudson: branches are | 21:59 |
| lifeless | mwhudson: your docstring confuses me | 21:59 |
| mwhudson | Create a branch that is stacked on some other branch and return its bzrdir. | 22:00 |
| mwhudson | ? | 22:00 |
| lifeless | mwhudson: the change to TestNotApplicable is wrong in this case | 22:00 |
| lifeless | + """Create a bzrdir that is stacked on some other bzrdir. | 22:00 |
| lifeless | well, I say wrong; I guess I mean 'I did not want the stacking tests to produce lots of irrelevant output' | 22:01 |
| mwhudson | lifeless: ok, so test_stacking is inconsistent about this in bzr.dev | 22:02 |
| lifeless | I've approved | 22:04 |
| lifeless | but the docstring really needs more love | 22:05 |
| lifeless | (its test only code, but still) | 22:05 |
| mwhudson | lifeless: did you seem my suggestion for it above? | 22:05 |
| mwhudson | lifeless: thanks though | 22:05 |
| lifeless | mwhudson: that works better yes | 22:06 |
| mwhudson | grr, too long though | 22:07 |
| lifeless | """Gimme the bzr dir of a newly stacked branch, bitch.""" | 22:08 |
| mwhudson | i guess "Create a stacked branch and return its bzrdir." gets the point across | 22:09 |
| * mwhudson gets ready to send yet another bundle | 22:10 | |
| lifeless | mwhudson: JFDI at this point | 22:10 |
| mwhudson | lifeless: still needs another approve | 22:11 |
| lifeless | mwhudson: jam gave one | 22:11 |
| lifeless | jam: did you see my question about making the patiencediff file pyrex? | 22:11 |
| mwhudson | lifeless: oh, then can someone grab http://people.ubuntu.com/~mwh/repos/bzr/bzrdir.clone-pass-on-stacking-base-bug-250418 (it has the better docstring in now) and send it to PQM? | 22:12 |
| jelmer | lifeless, is it correct that "bzr branch --stacked" doesn't attempt to create a stacked format by default even if the repo it's being created in supports stacking? | 22:12 |
| lifeless | jelmer: known defect | 22:13 |
| lifeless | jelmer: poolie is about to post a branch to address it | 22:13 |
| jelmer | lifeless, ok, I'll shut up then :-) Thanks | 22:13 |
| lifeless | jelmer: oh hmm | 22:13 |
| lifeless | jelmer: I misread | 22:13 |
| lifeless | jelmer: do you mean 'the source branch and repo are stackable and the target repo exists and is stackable', so why doesn't --stacked work ? | 22:14 |
| lifeless | or | 22:14 |
| lifeless | jelmer: do you mean 'the source branch and repo are not stackable but the target repo exists and is stackable', so why doesn't --stacked work ? | 22:14 |
| lifeless | the latter is what poolie is addressing | 22:14 |
| jelmer | the source branch and repo are indeed not stackable (they're svn) | 22:14 |
| lifeless | so yes, this is what poolie is addressing | 22:14 |
| jelmer | awesome | 22:15 |
| lifeless | his fix will need *your* review to say how bzr-svn will interact | 22:15 |
| schierbeck | hi guys | 22:18 |
| schierbeck | bug 238860 | 22:18 |
| ubottu | Launchpad bug 238860 in bzr-gtk "bzr visualise does not allow columns to be resized enough " [High,Confirmed] https://launchpad.net/bugs/238860 | 22:18 |
| schierbeck | sorry, just testing something | 22:18 |
| jelmer | hey Daniel | 22:20 |
| jelmer | lifeless, no problemo | 22:22 |
| jam | lifeless: I would certainly consider it | 22:27 |
| jam | sorry about the delay, had to pick up the baby | 22:27 |
| lifeless | jam: no worries | 22:27 |
| jam | I was thinking for group compress that you might be better off starting top-down into pyrex | 22:28 |
| fullermd | Mmph. Sucks when branches get big enough that check isn't practical anymore... | 22:28 |
| jam | using _patience_diff.c as a crib sheet | 22:28 |
| lifeless | beautiful: http://cgwalters.livejournal.com/17760.html | 22:28 |
| lifeless | I _love_ the gcc wizard | 22:28 |
| lifeless | jam: hmmm, I don't really want to rewrite $foo. | 22:30 |
| lifeless | jam: I'm right now trying to decide if the patience sort we have is even correct :( | 22:30 |
| jam | lifeless: well, it passes the test suite, though that certainly doesn't define "correctness" | 22:34 |
| jam | lifeless: At least I've worked out how we know which line to match | 22:40 |
| lifeless | jam: :P | 22:40 |
| jam | which is that the hash-table buckets contain the head pointer and a "current" pointer | 22:40 |
| jam | and that the equiv is only for identical strings | 22:40 |
| jam | if you get a collision it walks to the next value (j = j + 1 & hsize) | 22:41 |
| jam | lifeless: which sounds like it might mess up your groupcompress, as it doesn't want to match earlier than a line it has already matched. | 22:41 |
| lifeless | yah | 22:45 |
| lifeless | so AFAICT the value used for the patience sort is the line index in A | 22:45 |
| lifeless | its the loop on line 306 that selects the index to use | 22:46 |
| lifeless | and it skips lines that are duplicates | 22:46 |
| lifeless | so patiencediff is looking more and more like 'really geared for humans' to me | 22:46 |
| jam | lifeless: Yeah, the objects that are being *sorted* is the index in A which matches the line in B | 22:50 |
| lifeless | jam: yup | 22:50 |
| jam | and it is looking for the longest "interleaved" monotonically increasing sequence | 22:51 |
| lifeless | interleaved ? | 22:51 |
| jam | just that there may be gaps | 22:51 |
| jam | where some lines matched earlier that we skip over | 22:51 |
| jam | abcd bcad | 22:51 |
| jam | will ignore the a matching to location 0 | 22:51 |
| jam | and give "bc_d" as the longest sequence | 22:51 |
| lifeless | which I presume we then split to bc, d | 22:52 |
| lifeless | ? | 22:52 |
| jam | lifeless: correct | 22:52 |
| jam | that is the "add_matching_line" code | 22:52 |
| jam | which says "if this is the next in the sequence, add it to the block" | 22:52 |
| jam | "else, start a new block" | 22:52 |
| jam | lifeless: for "groupcompress" I don't quite understand "line_locations" has 2 sets with (N) and (N+1) | 22:55 |
| lifeless | seems to me that a variant on recurse_matches should be doable | 22:56 |
| lifeless | jam: its purely an optimisation | 22:56 |
| lifeless | if you remember original sequence matcher, it does a loop lo:hi, trying each of the possible starting points | 22:56 |
| jam | lifeless: so are you trying to find N possible matches as you move forward | 22:57 |
| jam | and then just return whichever is the longest? | 22:57 |
| lifeless | this has quite bad locality of reference, so I turned the loop into a set operation | 22:57 |
| lifeless | starting will all the common points of a given line, and then advancing (transforming set(positions) into set(pos + 1 for pos in positions) each time) | 22:57 |
| jam | lifeless: and doing the intersection so you only include matching lines | 22:58 |
| lifeless | I found that precalculating the first step of this acts as a cache that saves enough steps (the first intersections removes a lot) | 22:58 |
| lifeless | something like 3-4% performance difference, not radical but worth keeping until there is a _real fast_ version and then it can go to be a cleanest-possible reference version | 22:59 |
| jam | lifeless: so if you were removing that | 22:59 |
| jam | line 174 would change from: | 23:00 |
| jam | sorry, looking at the wrong spot | 23:00 |
| jam | you would change the line 185 to | 23:00 |
| jam | copy_ends = next | 23:00 |
| jam | => | 23:00 |
| lifeless | copy_ends = next -> copy_ends = set(loc + 1 for loc in locations) | 23:00 |
| jam | copy_ends = set([l+1 for l in locations]) | 23:00 |
| jam | and that is all the second set is giving you right now | 23:01 |
| lifeless | right | 23:01 |
| jam | lifeless: so, "unique_lcs" is exposed to python | 23:01 |
| jam | if you wanted to play with it as a starting point | 23:02 |
| jam | though it doesn't save the cached hash lookups | 23:02 |
| jam | so it isn't strictly a win | 23:02 |
| lifeless | yeah | 23:02 |
| lifeless | however 10 times faster might be enough to compensate | 23:02 |
| lifeless | though gc is hella-faster than python patiencediff | 23:02 |
| jam | gc? | 23:05 |
| lifeless | groupcompress | 23:05 |
| jam | ah | 23:05 |
| jam | sure | 23:05 |
| lifeless | bad-names-for-the-win | 23:05 |
| jam | python patiencediff doesn't cache any hashes either | 23:05 |
| jam | lifeless: so what would you persist, the "loaded_lines" for the current text, which would then be updated as you output more lines? | 23:07 |
| jam | and presumably the hashtable itself | 23:07 |
| lifeless | yah | 23:07 |
| lifeless | self.lines in the GroupCompress object | 23:08 |
| lifeless | with any transformations needed to actually operate on it | 23:08 |
| lifeless | though the more I look at this | 23:08 |
| jam | so for self.lines, it is the output lines? | 23:08 |
| jam | Including the control codes? | 23:08 |
| lifeless | and self.line_locations | 23:08 |
| lifeless | yes | 23:08 |
| lifeless | though we don't include control codes in self.line_locations | 23:08 |
| jam | lifeless: and something about lines that would have been copies but Insert was shorter? | 23:10 |
| jam | lifeless: and you didn't finish you "more I look at this" statement | 23:10 |
| jam | so, you are looking for an "absolute mininum" diff between any possible matching block, right? You don't care if the same block is referenced multiple times | 23:11 |
| jam | lifeless: I would say the hashtable code with exact equivalences could be easily ported over, the rest doesn't seem like a very good match | 23:12 |
| jam | honestly, the "patience" portion of the code is not its speed bonus | 23:13 |
| jam | tracking the stacks is not particularly fast | 23:13 |
| jam | and doesn't give you what you want | 23:13 |
| jam | which is the longest possible match for this chunk | 23:13 |
| jam | lifeless: Also, as a bit of a torture test for this, imagine a text made up of all the same line... | 23:17 |
| jam | ['a\n']*10000 | 23:17 |
| jam | lifeless: are you still there? | 23:22 |
| lifeless | jam: yes, sorry | 23:33 |
| jam | np | 23:33 |
| jam | we're all allowed to go AFK once in a while | 23:33 |
| lifeless | jam: we want a minimal construction recipe for B | 23:34 |
| lifeless | jam: we reference the basis by bytes, and include new content by a line count | 23:38 |
| lifeless | jam: so you think its the hashtable stuff that makes patience fast? | 23:38 |
| jam | lifeless: yeah, I do | 23:38 |
| === herb__ is now known as herb | ||
| jam | I'm poking around with it now | 23:39 |
| lifeless | It seems to me the patience stuff is a large part of the speed bonus as it reduces the order | 23:39 |
| lifeless | mwhudson: your eagle is landed | 23:39 |
| mwhudson | lifeless: i saw, thanks! | 23:39 |
| mwhudson | now we just need to fix launchpad... | 23:40 |
| thumper | lifeless: thanks | 23:40 |
| thumper | mwhudson: was that the 3rd of 3? | 23:40 |
| mwhudson | thumper: yup | 23:40 |
| lifeless | we really need to include <content-to-fulltext> in fetch always I think | 23:40 |
| lifeless | it will avoid so many future problems | 23:40 |
| awmcclain | What's the easiest way, given an svn repo i have no control over, to create a local bzr repo from a revision? | 23:40 |
| mwhudson | awmcclain: from a revision? | 23:41 |
| lifeless | awmcclain: bzr log svn:// | less - find the revno you want; bzr branch -r revno svn://... local | 23:41 |
| awmcclain | mwhudson: Well, say, from HEAD. I say "from a revision" since I don't have... ah! | 23:41 |
| awmcclain | lifeless: Thank you. | 23:41 |
| awmcclain | lifeless: Is that a feature since 1.4? | 23:42 |
| awmcclain | hrm | 23:45 |
| awmcclain | What's the apt command to update a single package? | 23:45 |
| awmcclain | open | 23:45 |
| awmcclain | ooepn | 23:45 |
| awmcclain | ung | 23:45 |
| awmcclain | oops | 23:45 |
| awmcclain | wrong channel. just ignore me. | 23:45 |
| jelmer | awmcclain: Actually, "bzr branch -rsvn:<REVNO> svn://foo" should work too | 23:52 |
| awmcclain | jelmer: What if I'm just looking for HEAD, and the svn branch is hosted over http? | 23:53 |
| jelmer | awmcclain, don't specify a revno, bzr branch defaults to HEAD | 23:53 |
| awmcclain | jelmer: So, in 1.4rc1 it thinking I'm looking at a bzr branch (bzr: ERROR: Not a branch: "http://code.sixapart.com/svn/perlbal/trunk/"). Should I upgrade to 1.6? | 23:54 |
| jelmer | awmcclain, try "svn+http://code...." | 23:54 |
| awmcclain | jelmer: Great. | 23:54 |
| awmcclain | "unsupported protocol" | 23:55 |
| jelmer | in newer versions of bzr-svn, the svn+ bit should no longer be necessary | 23:55 |
| jelmer | awmcclain, you probably don't have bzr-svn installed or your svn was built without http support | 23:55 |
| awmcclain | jelmer: Checking. Perfect. | 23:55 |
| jelmer | awmcclain: Is bzr-svn listed when you run "bzr plugins" ? | 23:57 |
| poolie | hi | 23:58 |
| awmcclain | jelmer: That's the problem. Oh! Yes. I remember, it uninstalled when I upgraded to 1.4 | 23:58 |
| mwhudson | hi poolie | 23:58 |
| awmcclain | jelmer: Does the 1.6 server have commit hooks yet? | 23:58 |
| jelmer | awmcclain, not afaik | 23:58 |
| awmcclain | jelmer: Ok. | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
