| === visik7|away is now known as visik7 | ||
| jml | lifeless: how hard would it be to add a rename-thread feature to loom? | 00:43 |
|---|---|---|
| lifeless | jml: trivial - load the dict, alter it, save it, change the current nick (which points into the dict) IF its the same as teh thread breaing renamed | 00:44 |
| lifeless | jml: got a few minutes? | 01:05 |
| jml | lifeless: I will in a bit. | 01:05 |
| jml | lifeless: ok. what's up? | 01:10 |
| * jelmer once again wishes Python did tail recursion properly | 01:41 | |
| mwhudson | i need a plugin that has an "oh crap, i've been editing in trunk again" command | 03:25 |
| igc | hello all | 03:37 |
| mwhudson | hello igc! | 03:37 |
| igc | hi mwhudson | 03:37 |
| mwhudson | igc: i gave my bzr talk at osdc last week | 03:39 |
| igc | how did it go? | 03:39 |
| mwhudson | alright, i think | 03:41 |
| mwhudson | i went for a fairly gentle introduction to dvcs | 03:41 |
| mwhudson | most people had used cvs, almost all svn, a few bzr, about the same git, not so many hg | 03:42 |
| mwhudson | a good way to start a talk: "how many of you have used branches with subversion?" | 03:42 |
| mwhudson | (almost all the hands go up) | 03:42 |
| mwhudson | "how many of you enjoyed it?" | 03:43 |
| mwhudson | (most hands go down) | 03:43 |
| igc | mwhudson: :-) | 03:44 |
| spiv | mwhudson: that bit was very good :) | 03:57 |
| mwhudson | i do think it's worth making the point that most "next gen" vcs tools are just _better_ than svn | 03:58 |
| mwhudson | even if you don't do distributed things | 03:58 |
| pygi | mwhudson, tho people sometimes just don't care :) | 04:00 |
| mwhudson | pygi: well yes, but that's fine | 04:00 |
| mwhudson | pygi: but some people also say "this is a one man/in house project, the d in dvcs doesn't get me anything" | 04:00 |
| pygi | mwhudson, right... | 04:01 |
| spiv | jelmer: congrats on the 0.5.0rc1 ! | 04:03 |
| jelmer | spiv, thanks :-) It took me long enough... | 04:03 |
| pygi | jelmer, you really never sleep o.O | 04:04 |
| pygi | isn't it like 5AM for you? o.O | 04:04 |
| jelmer | yeah, I just wanted to get this release out.. | 04:05 |
| jelmer | I do usually sleep at this time of day :-) | 04:05 |
| jelmer | pygi, you're still in CA ? | 04:05 |
| pygi | jelmer, when was I in CA? :P | 04:06 |
| pygi | jelmer, I'm in Croatia :P | 04:06 |
| jelmer | pygi, I figured it would be 5 AM for you as well.. | 04:06 |
| pygi | jelmer, yes, it is 5AM for me too :p | 04:06 |
| jelmer | so I assumed you were at UDS | 04:06 |
| jelmer | pygi, heh, ok | 04:06 |
| pygi | congrats on the release ;) | 04:07 |
| jelmer | thanks :-) | 04:07 |
| * jelmer sees he has another 5 hours left for sleep, might as well use them | 04:08 | |
| jelmer | g'night! | 04:08 |
| pygi | night night :) | 04:08 |
| mwhudson | i don't bother thinking about what time it is for someone before pinging them on irc any more | 04:08 |
| spiv | jelmer: I thought you were sleeping :P | 04:53 |
| === spm_ is now known as spm | ||
| shelagh | I'm trying to use bzr for a local file that I want to get weekly snapshots for. | 06:42 |
| shelagh | I think I've stuffed the setup stage as I keep getting asked about branches, when I try to add the file to bzr. | 06:42 |
| shelagh | What I want is essentially simple (I thought). But I'm obviously missing something. | 06:44 |
| shelagh | I've used rcs before, but eventually this file will be mirrored on a file server and so bzr seems like a better choice. | 06:45 |
| AfC | shelagh: you're describing about the simplest use case going | 07:14 |
| AfC | $ bzr init . | 07:14 |
| AfC | $ bzr add filename.txt | 07:14 |
| AfC | $ bzr commit -m "It is 6 o'clock and all is well" | 07:15 |
| AfC | followed by a commit next week. | 07:15 |
| AfC | (on the assumption that you want to make . the Bazaar branch) | 07:15 |
| vila | hi all | 07:18 |
| === toytoy_ is now known as toytoy | ||
| shelagh | AfC: thanks for that. | 08:09 |
| shelagh | AfC: so I need to go into the directory that I put into bzr and add the file? | 08:09 |
| shelagh | I need to practice this at home before I try it at work again. | 08:09 |
| jaavaaguru | regardless of how /win 12 | 08:40 |
| jaavaaguru | oops | 08:41 |
| Peng_ | Hmmm, I think turning off plugins may have fixed my Loggerhead memory issues. | 09:49 |
| Peng_ | I haven't given it much time to confirm it, but it only grew a few KB in 30 minutes. Before, it would've been...10 or 20 MB, maybe? | 09:52 |
| spiv | Peng_: wild guess... you had bzr-svn installed? | 10:09 |
| Peng_ | spiv: Heh, it's always bzr-svn, isn't it? :P | 10:12 |
| Peng_ | Since my last update it's been growing a bit, so that may not have fixed it anyway. | 10:13 |
| Peng_ | OK, I can say now that disabling plugins definitely seems to have fixed it. | 11:20 |
| spiv | Peng_: Interesting! | 11:23 |
| Peng_ | Is it possible to exclude a specific plugin from being loaded from code, or should I just uninstall it? | 11:39 |
| spiv | Peng_: echo 'raise ImportError' > ~/.bazaar/plugins/plugin_name.py | 11:51 |
| spiv | Peng_: Oh, from code :) | 11:52 |
| spiv | Peng_: You can probably do something like "import sys; sys.modules['bzrlib.plugins.plugin_name'] = None" | 11:52 |
| spiv | Which IIRC is how sys.modules caches that an import cannot be found. | 11:52 |
| Peng_ | So when bzr imports it, it would load the dummy instead of the real module? Huh, neat. | 11:53 |
| spiv | (if you go with the dummy module that raises ImportError, don't forget to remove the .pyc as well as the .py when you want to remove the dummy) | 11:54 |
| Peng_ | The sys.modules hack seems to work. Neato! | 11:55 |
| * spiv -> sleep | 11:59 | |
| Peng_ | Good night. | 12:00 |
| Arjen | What would be the best way to count the number of commits in a repository? | 13:33 |
| === vednis is now known as mars | ||
| etank | Arjen: just a guess but wouldn't bzr log show you the revno? is that the same thing? | 13:43 |
| Arjen | That's only the mainline | 13:50 |
| Arjen | I want the total number of commits | 13:51 |
| etank | im trying to get the all-in-one install of bzr for windows to work | 13:52 |
| etank | it works fine on one machine but not another | 13:52 |
| etank | it is the 1.9 version that i am working with | 13:53 |
| === asac_ is now known as asac | ||
| luks | asac: bzr info -v | 14:29 |
| luks | er | 14:29 |
| luks | Arjen: ^ | 14:29 |
| etank | argh | 14:44 |
| etank | finally got my bzr on windows to work | 14:47 |
| etank | had to reinstall then do "set BZR_SSH=paramiko" | 14:48 |
| * etank is happy now :) | 14:48 | |
| etank | pingdotfm: finally got my bzr on windows to work. had to reinstall then do "set BZR_SSH=paramiko" to get it to work. | 14:50 |
| etank | oops :) | 14:50 |
| Tak | wait, how did you get your bzr on windows to work? :-P | 14:50 |
| etank | Tak: i used the all-in-one installer | 14:58 |
| etank | how can i make bzr always use paramiko instead of plink? | 15:03 |
| etank | it keeps going back to plink and i get "ssh implementation is Putty's plink." | 15:03 |
| luks | hm, I though it uses paramiko by default | 15:04 |
| luks | you can set the BZR_SSH variable globally | 15:04 |
| luks | Control Panel -> System -> Environment Variables or something like that | 15:04 |
| etank | thanks luks that did the trick | 15:06 |
| oldman | is there an easy way to 'forget' remembered submit branch locations? | 15:16 |
| jelmer | oldman, see .bzr/branch/branch.conf | 15:16 |
| jelmer | you can also get it to remember a new location by using --remember | 15:17 |
| oldman | excellent, thanks | 15:17 |
| === ja1 is now known as jam | ||
| jam | Good morning to all | 15:21 |
| jam | Anyone have experience debugging DNS issues on Windows 2003? | 15:21 |
| jam | It seems that there are DNS servers, and doing "nslookup" works, but doing "socket.gethostbyname()" does not. | 15:21 |
| etank | jam: maybe flush your dns cache first | 15:25 |
| === ja1 is now known as jam | ||
| jam | I don't know if anyone responded, I seemed to have a network glitch | 15:26 |
| etank | jam: maybe flush your dns cache first | 15:26 |
| jam | etank: well, I did do "repair" which is supposed to do that, and I've even rebooted that machine | 15:26 |
| etank | ipconfig /flushdns | 15:27 |
| jam | (It is a virtual host, which we use for the win32 builds) | 15:27 |
| jam | I'll try that, I guess | 15:27 |
| jam | I found one google result that looked interesting, but it is a "members only" page: http://www.experts-exchange.com/Networking/Unix_Networking/Q_22643954.html | 15:28 |
| etank | jam: i have an account there if you want me to look at it for you | 15:29 |
| jam | etank: still failing | 15:30 |
| jam | etank: that would be nice, though I don't know if it will actually know the answer | 15:30 |
| jam | probably worth trying | 15:30 |
| jam | btw, do you remember the location of "hosts" and "lmhosts" ? | 15:30 |
| etank | c:\windows\system32\drivers\etc | 15:31 |
| jam | I never quite understood that. Maybe because the network stack was BSD based? | 15:31 |
| etank | jam: here is the "answer" from the ee page http://dpaste.com/97018/ | 15:32 |
| etank | may not be of any use though | 15:32 |
| jam | ugh | 15:33 |
| jam | yeah, not the problem I'm having | 15:33 |
| jam | it seems that lmhosts.sam is empty, hosts is almost empty | 15:34 |
| etank | thats normal | 15:35 |
| jam | the one interesting entry in 'hosts' does indeed resolve for "gethostbyname()" | 15:36 |
| etank | should have a "127.0.0.1 localhost" by default and that is it | 15:36 |
| jam | It has 2 lines: | 15:36 |
| jam | 127.0.0.1 LOCALHOST | 15:36 |
| jam | 10.0.10.14 vzsveaddress | 15:36 |
| jam | I assume the latter has to do with how the virtual host was set up | 15:36 |
| etank | or you wanted it to resolve even if the dns server was not found | 15:37 |
| jam | sure, but regardless those are the only ones that "work" on this machine for "gethostbyname()" while "nslookup" seems to do just fine. | 15:38 |
| etank | what module does bzr use to read the config? | 15:40 |
| etank | ConfigParser? | 15:40 |
| jam | ConfigObj | 15:40 |
| jam | bzrlib/util/configobj/configobj.py | 15:40 |
| jam | similar, but also supports writing | 15:41 |
| jam | and has support for some stuff that we don't really use | 15:41 |
| jam | like lists | 15:41 |
| etank | cool | 15:41 |
| jam | interesting, it seems to be "the default gateway is not on the same subnet + subnet mask as the ip address" | 15:50 |
| jam | so my guess it is getting confused by that | 15:51 |
| jam | ok, really weird | 15:51 |
| etank | that sounds about right | 15:51 |
| jam | the IP address is a public address | 15:51 |
| jam | but the default gateway is a 192.168 addres | 15:51 |
| etank | are you natting or bridging the connection? | 15:51 |
| jam | I have no idea | 15:51 |
| jam | this is a virtual host provided by someone in Australia | 15:51 |
| etank | oh | 15:51 |
| jam | as I can connect via terminal services and openssh, my first guess would be bridge | 15:52 |
| jam | but I don't know yet | 15:52 |
| jam | I think it is at the point that we need to escalate to their support, but I think only poolie can do tha | 15:52 |
| jam | that | 15:52 |
| jam | yeah, I can submit a support request, but it will go to his email address, which makes it hard for me to respond :) | 15:55 |
| jam | lifeless: ping | 15:55 |
| lifeless | jam: pong | 16:31 |
| jam | just asking if you could give poolie a poke if you see him | 16:31 |
| jam | I need him to open a support case with the host of kerguelen | 16:31 |
| lifeless | k | 16:31 |
| jam | thanks | 16:31 |
| lifeless | I think he's still to arrive at the venue | 16:31 |
| jam | lifeless: it isn't critically urgent, so you don't have to go search for him, but if you do run into him, just let him know | 16:38 |
| jam | thanks | 16:38 |
| gioele | hi | 16:58 |
| gioele | is there a way to clean the obsolete_packs dir (pack-0.92 format) | 16:59 |
| gioele | I used bzr pack to save some space but I ended up doubling the space used: X in packs and X+something in obsolete_packs | 17:00 |
| jam | gioele: rm .bzr/repository/obsolete_packs/* | 17:00 |
| jam | It will clean itself out eventually | 17:00 |
| jam | at the next time it goes to pack/autopack | 17:01 |
| gioele | jam: is that safe to do? | 17:01 |
| jam | don't delete the *directory* but you can delete the files | 17:01 |
| jam | I would probably run "sync" first | 17:01 |
| gioele | why are these "obsolete" packs kept around? | 17:02 |
| jam | because we don't know if the OS will order things correctly | 17:02 |
| jam | and actually write things to disk before the system crashes | 17:02 |
| jam | as it is your precious ancestry we are dealing with | 17:02 |
| jam | we default to safe | 17:02 |
| gioele | jam: is it my $HOME backup, almost as precious as my ancestry ;) | 17:03 |
| jam | so if you know you have another backup, you know the system won't crash right away, etc | 17:03 |
| jam | sync && rm .bzr/repository/obsolete_packs/* | 17:03 |
| jam | should be fine | 17:03 |
| jam | just make sure to not delete the directory itself | 17:04 |
| gioele | ok (I have a backup of the backup anyway) | 17:04 |
| gioele | done | 17:04 |
| gioele | everything seems fine | 17:15 |
| gioele | thanks jam | 17:15 |
| jam | happy to help | 17:15 |
| lifeless | jam: I suggest mailing him | 17:18 |
| jam | I did | 17:18 |
| lifeless | :) | 17:18 |
| lifeless | jam: I intend to read your updated commit-uses-add-by-delta patch, haven't had time to grab a diff vs my branc to see the changes | 17:19 |
| jam | I'm pretty sure I summarized the important changes in the email. | 17:20 |
| jam | but that doesn't give you a code-level view | 17:20 |
| lifeless | right | 17:20 |
| lifeless | cocneptually I'm cool with it | 17:20 |
| seb_kuzminsky | i'm converting a smallish svn repo with a couple of branches to bzr | 17:51 |
| seb_kuzminsky | i'm planning to use "bzr svn-import" | 17:51 |
| seb_kuzminsky | i'm planning to put it in a shared bzr repo | 17:51 |
| seb_kuzminsky | i'm using bzr 1.10 | 17:51 |
| seb_kuzminsky | what repo format should I use (for "bzr init-repo")? --1.9? | 17:52 |
| seb_kuzminsky | --1.9-rich-root? | 17:52 |
| lifeless | seb_kuzminsky: 1.9-rich-root | 17:53 |
| lifeless | though I think svn-import makes its own repo | 17:53 |
| lifeless | poolie: jam was pinging for you | 17:53 |
| seb_kuzminsky | thanks lifeless | 17:54 |
| jelmer | lifeless, yep, it does | 17:54 |
| seb_kuzminsky | so i dont need to init-repo before svn-import? | 17:55 |
| seb_kuzminsky | i did a 'bzr svn-import' and it gave me a rich-root-pack repo, not 1.9-rich-root | 18:08 |
| seb_kuzminsky | i have bzr-svn 0.4.16 | 18:08 |
| seb_kuzminsky | and bzr 1.10rc1 | 18:08 |
| jelmer | seb_kuzminsky, that's correct | 18:08 |
| jelmer | seb_kuzminsky, rich-root-pack should work fine as well | 18:08 |
| jelmer | seb_kuzminsky, and is supported by more older versions of bzr | 18:08 |
| seb_kuzminsky | going back to 1.0 it says | 18:09 |
| jelmer | seb_kuzminsky, if you would like to use 1.9-rich-root, you can use "bzr upgrade --1.9-rich-root" in that directory | 18:09 |
| seb_kuzminsky | ok thanks jelmer | 18:09 |
| seb_kuzminsky | jelmer: it worked :-) | 18:20 |
| seb_kuzminsky | jelmer: but is there a way (some --schema perhaps) to turn svn's trunk/branches/tags structure into native bzr representations? | 18:21 |
| seb_kuzminsky | i'll try --scheme=trunk | 18:23 |
| seb_kuzminsky | the default is "auto", but even with -v, svn-import didnt tell me what it was doing | 18:24 |
| seb_kuzminsky | and it seems to have used "none" scheme, instead of "trunk" which is what i think i want | 18:24 |
| Peng_ | Thanks to that hack to load most plugins but not bzr-svn, it seems bzr-svn is the source of my Loggerhead memory leak.. | 18:32 |
| beuno | Peng_, that's interesting | 18:32 |
| jelmer | Peng_: which bzr-svn ? | 18:32 |
| jelmer | beuno, does loggerhead use find_branches() at all? | 18:32 |
| beuno | I guess we should add a --no-plugins to server branches? | 18:33 |
| beuno | jelmer, no, it shouldn't | 18:33 |
| jelmer | beuno, what about find_bzrdirs() ? | 18:33 |
| Peng_ | jelmer: Latest 0.4 branch. | 18:34 |
| beuno | jelmer, nope | 18:34 |
| jelmer | beuno, how does it find the branches then in serve-branches ? | 18:34 |
| beuno | Peng_, want to write a patche for --no-plugins? :) | 18:34 |
| beuno | jelmer, it tries Branch.open() | 18:34 |
| Peng_ | beuno: --no-patches. :P | 18:34 |
| jelmer | Peng_, depending on how loggerhead is trying to open branches, 0.5 fixes that issue | 18:34 |
| beuno | Peng_, also, without bzr-svn, is the memory usage down? | 18:34 |
| Peng_ | beuno: Yes, it is. | 18:35 |
| beuno | Peng_, w00t! by how much aprox? | 18:35 |
| jelmer | beuno, ah, thanks | 18:36 |
| jelmer | Peng_, so, yes, bzr-svn 0.5 should fix the memory usage issue | 18:36 |
| beuno | poolie, lifeless, james_w ^^^ LH memory usage down, but still blows up on production | 18:37 |
| Peng_ | beuno: Oh, right. I forgot about the improvements. I can't really say at this point; all I can say is that disabling bzr-svn stopped it from constantly growing. | 18:38 |
| Peng_ | jelmer: You figure 0.5 is usable enough at this point that I can try it safely? | 18:38 |
| Peng_ | Hmm, I'm not even sure I ever use bzr-svn on that machine. | 18:38 |
| jelmer | Peng_: Yes, I think so | 18:39 |
| jelmer | Peng_, There was a similar bug a while ago in "bzr multi-pull" | 18:39 |
| seb_kuzminsky | i did "bzr svn-import --schema=trunk" and still it gave me a single bzr branch with /trunk, /branches, and /tags | 18:40 |
| jelmer | seb_kuzminsky, you want --scheme=trunk0 | 18:41 |
| seb_kuzminsky | "bzr branches" returns without producing any output, and "bzr heads" shows just one head | 18:41 |
| seb_kuzminsky | jelmer: oh ok | 18:41 |
| poolie | hi jam, beuno, lifeless | 18:42 |
| jam | hi poolie, how is mountain view? | 18:42 |
| jelmer | seb_kuzminsky, though I think it should yell at you if you use --schema | 18:44 |
| jelmer | (since that is not a valid argument) | 18:45 |
| seb_kuzminsky | hrm, sorry, i did type --scheme, my bad | 18:46 |
| seb_kuzminsky | --scheme=trunk resulted in no branches in the bzr repo | 18:46 |
| * Peng_ tests bzr-svn 0.5. | 18:46 | |
| seb_kuzminsky | trying --scheme=trunk0 now | 18:46 |
| jelmer | seb_kuzminsky, in that case trunk0 won't help much I think | 18:46 |
| jelmer | seb_kuzminsky, you might want to try 0.5 as well then | 18:46 |
| seb_kuzminsky | jelmer: yea after "bzr svn-import --scheme=trunk0" i still have no branches | 18:49 |
| seb_kuzminsky | that's ok, i didnt really want my branches anyway.... | 18:49 |
| jelmer | seb_kuzminsky, you can get the individual branches manually by running "bzr branch <repos-path>/trunk my-trunk" | 18:50 |
| mwhudson | morning | 18:50 |
| jelmer | hey mwhudson | 18:50 |
| seb_kuzminsky | jelmer: right, good idea | 18:50 |
| seb_kuzminsky | jelmer: i'm doing this on the machine that hosts the svn repo and i'm using file:// urls to the svn repo, might that have anything to do with the problem? | 18:52 |
| jelmer | seb_kuzminsky, no, that shouldn't matter | 18:53 |
| jelmer | seb_kuzminsky, I think it's just a general problem causing bzr-svn to use the guessed scheme rather than the specified one | 18:53 |
| seb_kuzminsky | ok | 18:53 |
| jelmer | seb_kuzminsky, I think it's fixed in bzr-svn 0.5.0~rc1 | 18:54 |
| jelmer | seb_kuzminsky, looking at the code, I'm sure it's fixed in 0.5 | 18:56 |
| jelmer | seb_kuzminsky, did you only just start using the trunk/, branches/ structure? | 18:56 |
| seb_kuzminsky | the svn repo was created with that structure | 18:57 |
| seb_kuzminsky | it has two branches (plus trunk) and no tags yet | 18:57 |
| seb_kuzminsky | of the two branches, one is about halfway back in history, and the other is very recent | 18:57 |
| seb_kuzminsky | history is about 300 revs long | 18:59 |
| Necoro | hmm - is pycurl needed for anything under linux? | 19:00 |
| Necoro | because it is not mentioned anywhere - but in the logs there are lots of complaints about not finding it | 19:00 |
| LarstiQ | Necoro: the only thing I can think of that it possibly adds over plain urllib is ssl certificate checking | 19:17 |
| lifeless | .join #ubuntu-foundations | 19:28 |
| jam | LarstiQ: maybe we should only make it the preferred default for https connections, rather than both http and https | 19:36 |
| jam | Necoro: we don't need it, we just use it if we find it, and log when we don't find it | 19:36 |
| LarstiQ | jam: that sounds like an excellent idea. | 19:37 |
| jam | vila: what do you think? | 19:37 |
| Necoro | jam: ah ok - the "DependencyNotFound" just sounded quite drastic and I thought whether it could be a reason for some errors ;) | 19:38 |
| === etank is now known as service_desk | ||
| === service_desk is now known as etank | ||
| jam | LarstiQ: patch submitted, though I want to hear what vila thinks before we switch | 19:48 |
| * LarstiQ nods | 19:48 | |
| poolie | hello jam | 19:51 |
| jam | hi poolie | 19:51 |
| jam | For some reason the login you gave us before isn't working for me now | 19:51 |
| jam | trying to follow your support request linke | 19:51 |
| jam | link | 19:51 |
| poolie | ah :/ | 19:51 |
| jam | I was able to use it just this morning | 19:52 |
| poolie | i reset my password because i didn't have it on my laptop :) | 19:52 |
| jam | when I wanted to try myself | 19:52 |
| poolie | can you encrypt it and send it back to me | 19:52 |
| poolie | plesae | 19:52 |
| jam | sure | 19:52 |
| poolie | please* | 19:52 |
| jam | poolie: sent | 19:52 |
| poolie | ok, it's reset back to that | 19:54 |
| poolie | so you're welcome to use that to file or comment on support requests | 19:55 |
| poolie | just login as mbp@canonical | 19:55 |
| Peng_ | If http defaults to urllib and https defaults to curl, and an http url redirects to https, will it still switch to curl? | 19:55 |
| poolie | yes | 19:59 |
| Peng_ | :) | 20:01 |
| lifeless | abentley1: mirror stuff: init-branch .; set-stacked(mirror_url);pull (official-source) | 20:06 |
| === Mario__ is now known as pyg | ||
| === pyg is now known as pygi | ||
| jam | poolie1: the only support ticket I see is the "System is not available as the server is currently stopped" ticket | 20:25 |
| jam | which I don't think is the same | 20:25 |
| poolie1 | it is the same, i added on to that ticket | 20:26 |
| jam | ah, I see it now | 20:26 |
| jam | yeah | 20:26 |
| poolie1 | because they broke this while trying to fix the first | 20:26 |
| === poolie1 is now known as poolie | ||
| jelmer | Is it possible to commit when one of the parent revisions is a ghost? | 20:43 |
| jelmer | In particular, what sort of arguments should CommitBuilder.record_entry_contents() receive in that case, since it requires a list of parent inventories. | 20:45 |
| === Hydrogen_ is now known as Wasserstoff | ||
| lifeless | jelmer: its a little tricky:) | 20:48 |
| lifeless | jelmer: but yes, and its tested for commit.py, in bzr's test suite; I don't recall the exact mapping to CommitBuilder though | 20:49 |
| jelmer | lifeless, thanks, I'll have a look there | 20:50 |
| strk | how to update to a specific revision ? | 21:18 |
| strk | bzr help update doesn't tell? | 21:18 |
| jam | spiv: are you around? | 23:03 |
| seb_kuzminsky | i've got a rich-root-pack repo on a server running bzr 1.10rc1 | 23:05 |
| seb_kuzminsky | when i try to checkout using hardy (bzr 1.3.1), it fails because it makes the local repo (on the client) pack-0.92 | 23:05 |
| jam | seb_kuzminsky: I believe it is a known bug in older versions of bzr | 23:06 |
| jam | fixed somewhere around 1.6 | 23:06 |
| seb_kuzminsky | thanks jam, that was quick :-) | 23:06 |
| seb_kuzminsky | hardy backports has only 1.3.1... | 23:06 |
| seb_kuzminsky | it's easy enough to work around by creating the repo explicitly before doing the checkout | 23:07 |
| spiv | jam: yep | 23:07 |
| jam | spiv: so I was wanting to implement a FIFO cache, similar to our LRUCache | 23:08 |
| jam | and basically, on *access* I don't need to do any work | 23:08 |
| jam | just on add() do I need to possibly pop things out of the cache | 23:08 |
| jam | and I was hoping to have it have minimal overhead | 23:08 |
| jam | but if I try to do "self.__getitem__ = self._adict.__getitem__" | 23:09 |
| jam | I get a "readonly" attribute error | 23:09 |
| spiv | Right, __getitem__ is special, because it's an operator. | 23:09 |
| jam | So the next thing I tried was to subclass a dict | 23:09 |
| spiv | (You could do that in a classic-class, but not a new-style class) | 23:09 |
| jam | but: TIMEIT -s "x = {10:20}" "x[10]" | 23:09 |
| jam | is about 0.07us | 23:10 |
| jam | and using the subclass | 23:10 |
| jam | it is 0.2 us | 23:10 |
| jam | or not quite 5x slower | 23:10 |
| * spiv tries | 23:10 | |
| jam | even worse is doing def __getitem__(self, k): return self._d[k] | 23:10 |
| mwhudson | oh right, dict.__getitem__ is special cased in the interpreter look i think | 23:10 |
| jam | which is about 0.6us | 23:10 |
| jam | or another 2-3x slower than subclassing dict | 23:11 |
| mwhudson | loop | 23:11 |
| jam | so if I wrote a C class | 23:11 |
| jam | which subclasses __dict__ | 23:11 |
| jam | would it be possible to get the same performance, mwhudson? | 23:11 |
| mwhudson | jam: no | 23:11 |
| jam | it checks the type first? | 23:12 |
| mwhudson | yes | 23:12 |
| jam | not the attribute | 23:12 |
| jam | :( | 23:12 |
| mwhudson | think so, anyway | 23:12 |
| spiv | jam: I only see about a 30% speed hit for a subclass | 23:12 |
| spiv | jam: well, for a trivial dict subclass with no logic | 23:12 |
| mwhudson | actually | 23:12 |
| mwhudson | maybe i'm lying | 23:12 |
| jam | spiv: well, I only special cased __setitem__ | 23:12 |
| jam | I'll try without that | 23:13 |
| mwhudson | it's list[int] that's special cased, it seems | 23:13 |
| jam | I still see 0.06 versus 0.24 | 23:13 |
| jam | I'm on win32 | 23:13 |
| jam | which makes a difference | 23:14 |
| jam | but still | 23:14 |
| spiv | jam: on, hmm, now I get numbers more like yours, it seems a package upgrade in the background was skewing my timings | 23:14 |
| === visik7_ is now known as saltapozzanghere | ||
| jam | now the 30s I was seeing is more about LRUCache.get() overhead | 23:15 |
| jam | which has to record the access for the LRU part | 23:15 |
| jam | I'm sure a FIFO would still do a lot better | 23:15 |
| jam | I was just hoping to remove all overhead through some sort of magic | 23:16 |
| jam | subclassing dict still gives 2:1 benefit versus using a dict | 23:16 |
| spiv | jam: there's already a collections.deque, btw | 23:16 |
| jam | spiv: true, but I want a dict | 23:17 |
| jam | not a list | 23:17 |
| jam | so I want to use a dict + deque | 23:17 |
| jam | and when the dict gets full | 23:17 |
| jam | pop things out of the deque | 23:17 |
| jam | and remove them from the dict | 23:17 |
| spiv | Sounds like a weird FIFO :) | 23:17 |
| jam | It would only *have* to override __setitem__ | 23:17 |
| jam | spiv: FIFOCache | 23:17 |
| jam | sorry I wasn't more explicit | 23:18 |
| spiv | Oh, right. | 23:18 |
| jam | versus the LRUCache | 23:18 |
| jam | which we have in bzrlib now | 23:18 |
| jam | I also wish I could implement it with a list, because I've also seen deque slower than a list | 23:18 |
| === saltapozzanghere is now known as visik7 | ||
| jam | probably because of stuff like mwhudson's inlining of list[int] | 23:18 |
| jam | mwhudson: is tuple[int] also inlined? | 23:18 |
| spiv | lists are pretty quick. | 23:18 |
| jam | that would make sense to me | 23:18 |
| spiv | Also because lists are very simple. | 23:19 |
| jam | spiv: yeah, lists are certainly faster, for everything except stuff like a real FIFO because they aren't double-ended | 23:19 |
| jam | so pop(0) has to reallocate and move the whole list | 23:19 |
| mwhudson | jam: no | 23:19 |
| jam | mwhudson: interesting. Considering how tuples themselves are so much faster, and internally python uses tuples for lots of things, like arguments, etc. | 23:20 |
| mwhudson | jam: micro-optimizing the python interpreter has a long history, which may not be entirely coloured with sensible-ness | 23:20 |
| spiv | Right, but moving the whole list is fairly fast, depending on the size of the list. That is, although pop(0) scales O(n), the constant factor is quite low, so you may need a pretty large n for it to be slower than a deque. | 23:21 |
| jam | but yeah "list[int]" == 0.0495us, and tuple[int] == 0.0712us | 23:21 |
| jam | for a list of 10k entries | 23:24 |
| jam | .pop(0) seems to take 7us | 23:24 |
| jam | sorry 9us | 23:25 |
| jam | at the same time, I can't *measure* the time for deque.pop() | 23:25 |
| jam | because the time to build the deque causes enough noise to make it unreliable | 23:25 |
| jam | but I would guess significantly less | 23:25 |
| jam | something around .2us | 23:26 |
| jam | doing the "wrong" thing of creating one long enough to not have to recreate it. | 23:27 |
| jam | deque(range(10000)) takes approx 300us, versus list(range(10000)) taking only 50us | 23:27 |
| spiv | jam: so if I make the timeit inner-loop be pop(0)/popleft(); append(1), I get 0.43µs for deques vs. 18.7µs for lists. (with 10000 elems). | 23:29 |
| jam | seems about what I'm seeing | 23:30 |
| jam | for the pop + append, I see 0.293 for deque, and for pop(0)+append I see 7.7us, for pop + append I see 0.391us | 23:31 |
| jam | I'm actually surprised to see y.pop(); y.append(1) being slower with a list than a deque | 23:32 |
| jam | but it is consistent with 20k nodes as well | 23:32 |
| jam | 0.4us versus 0.28us | 23:32 |
| spiv | Right. | 23:34 |
| jam | interesting BLOCKLEN=62 for deque | 23:34 |
| jam | I'm curious how they came up with that | 23:34 |
| jam | I suppose it is the freeblock cache? | 23:35 |
| spiv | I have no idea :) | 23:37 |
| mwhudson | 62 probably gave optimum results on raymond hettinger's computer | 23:37 |
| jam | :) | 23:38 |
| jam | I assume there is some amount of tradeoff between wasting space and lots of malloc calls | 23:39 |
| jam | And I would imagine it depends dramatically on your workload | 23:39 |
| jam | lots of 50-node deques, versus 1M deques | 23:39 |
| jam | spiv: are you working, btw, or just wasting your vacation time on IRC :) | 23:39 |
| spiv | jam: working :) | 23:40 |
| spiv | jam: the wasting holiday time on IRC was last week. | 23:40 |
| jam | ok, I don't feel bad for pinging you, then | 23:40 |
| eartha` | I have file in bzr. | 23:46 |
| eartha` | I want to do a commit once a week in a cron job | 23:46 |
| eartha` | do I need to cd to the directory that holds the file under bzr? | 23:46 |
| eartha` | I mean do I need to write the cd into the script? | 23:47 |
| mwhudson | i think bzr ci /absolute/path/to/file will work | 23:47 |
| eartha` | thanks mwhudson | 23:48 |
| mwhudson | but try it! | 23:48 |
| === mw_ is now known as mw | ||
| CraPoLa | http://chatroll.com/chatroll-pub#2 | 23:48 |
| CraPoLa | come free beer | 23:48 |
| eartha` | I certainly will. | 23:48 |
| CraPoLa | you will good lol | 23:49 |
| CraPoLa | whre u from eartha | 23:49 |
| eartha` | earth | 23:49 |
| CraPoLa | yeah me to lol | 23:49 |
| CraPoLa | now the geophrapic location would be nice | 23:50 |
| CraPoLa | australia here | 23:50 |
| eartha` | same here | 23:50 |
| CraPoLa | good | 23:50 |
| CraPoLa | what this site about | 23:51 |
| eartha` | ? | 23:51 |
| eartha` | site | 23:51 |
| CraPoLa | the irc channel | 23:51 |
| CraPoLa | the one you on | 23:51 |
| eartha` | bzr is a version control system | 23:51 |
| eartha` | bazaar | 23:51 |
| CraPoLa | ?? | 23:51 |
| CraPoLa | like a server | 23:51 |
| eartha` | as in the "bazaar and the cathedral | 23:52 |
| CraPoLa | hmm lost me here sorry | 23:52 |
| eartha` | no, more like document change tracking. | 23:52 |
| CraPoLa | ahhh ok | 23:52 |
| CraPoLa | cool | 23:52 |
| eartha` | Or more usually, for source files | 23:52 |
| CraPoLa | so what do u do with them | 23:52 |
| CraPoLa | do you work for a government place | 23:53 |
| eartha` | put your project/ documents/source files in version control and then if you change something that does not work, you can go back to a version that does work | 23:53 |
| eartha` | In my case I have a file which needs to be printed out once a week for legat reasons. | 23:54 |
| CraPoLa | cool | 23:54 |
| eartha` | I want to have a weekly snapshot of the file so that if required I can print out the weekly version if requested, insteadof wasting paper. | 23:54 |
| CraPoLa | so the link above planet-bazaar-vcs.org is where i go | 23:55 |
| eartha` | I guess so. | 23:55 |
| eartha` | what os are you on? | 23:55 |
| CraPoLa | me Vic | 23:55 |
| eartha` | operating system | 23:55 |
| eartha` | windows/freebsd/linux | 23:55 |
| CraPoLa | ll have a look at his eartha looks cool | 23:57 |
| CraPoLa | urself what part of oz | 23:57 |
| eartha` | nice talking, have to get back to work. | 23:57 |
| eartha` | nsw | 23:57 |
| CraPoLa | nice | 23:57 |
| CraPoLa | ok later | 23:58 |
| eartha` | ooroo! | 23:58 |
| CraPoLa | cya | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!