[00:02] <mathrick> https://bugs.launchpad.net/bzr/+bug/303820
[00:02] <mathrick> lifeless: ah
[00:02] <mathrick> now, lessee if it still eats all my RAM
[00:05] <lifeless> Peng_: ok if I put that in the branch?
[00:09] <mathrick> yup, still does
[00:09]  * mathrick frees up some RAM to see if it succeeds eventually
[00:09] <lifeless> back after doctor visit
[00:29] <Peng_> lifeless: Sure.
[00:30] <mathrick> okay, so it still fails to serve anything, except this time it doesn't even throw backtraces :(
[00:33] <Peng_> lifeless: Although, I've made two completely unnecessary style changes that don't matter at all since the last version I pasted. http://paste.pocoo.org/show/C5sF67TUM5P1Mw9phfTQ/
[00:38] <mathrick> okay, so it reports "no repository", that's all I can gather from the packets
[00:42] <poolie> mathrick: maybe you started it, or limited it to a path, that didn't include the repository directory?
[00:48] <mathrick> poolie: nope, it's a straightforward "bzr serve" with no parameters
[00:49] <poolie> iirc it runs in the directory where you invoke it
[00:49] <mathrick> it happens reproducibly for that repo
[00:49] <poolie> so you need to make sure you're not standing in one of the branches
[00:49] <mathrick> "branches"?
[00:49] <poolie> let's back up
[00:49] <mathrick> oh
[00:49] <mathrick> it is in a shared repo, yeah
[00:50] <mathrick> lemme try with that
[00:50] <poolie> you must cd to the shared repo directory before running bzr serve
[00:50] <mathrick> right, it didn't tell me anything when I started it in the wrong dir
[00:54] <mathrick> it also continues to insist on eating all my RAM, which I don't appreciate
[00:54] <poolie> it should print something to give you a clue
[00:54] <poolie> is this with 1.10rc1?
[00:55] <mathrick> no, 1.9
[00:55] <poolie> at what point does it use too much memory?
[00:55] <mathrick> 1) when I start it in the wrong dir (ie. in the branch dir instead of the shared repo dir)
[00:56] <mathrick> 2) when I start it in the shared repo dir
[00:56] <mathrick> 2) seems to be more severe
[00:56] <poolie> as soon as you start it?
[00:56] <mathrick> yes
[00:56] <mathrick> it climbs steadily
[00:57] <mathrick> I've started it about 30s ago, and it's at 700M
[00:57] <poolie> wow
[00:57] <poolie> are you on unix or windows?
[00:58] <mathrick> 1300M virt, 700M res
[00:58] <mathrick> linux, ubuntu
[00:58] <poolie> please press Control-Backslash in the window where you ran bzr serve
[00:58] <poolie> you should get a debugger
[00:59] <poolie> by which i mean, it should say "(pdb) "
[00:59] <mathrick> lemme run it with BZR_PDB
[00:59] <poolie> that shouldn't be necessary
[01:00] <mathrick> ^\ alone doesn't cut it
[01:00] <poolie> nothing happens?
[01:00] <mathrick> nope
[01:00] <mathrick> it's rather slow to react to ^C as well
[01:01] <mathrick> nope, kill -INT doesn't help either
[01:02] <mathrick> it just sits there, allocating like crazy
[01:22] <poolie> mathrick: does strace show anything?
[01:22] <mathrick> dunno, I can check
[01:24] <visik7> anyone using bzr-upload + eclipse integration ?
[01:24] <visik7> I got eclipse exception if auto upload on commit is on
[01:24] <mathrick> poolie: nope, the last thing it shows is a futex
[01:24] <poolie> and it's still growing in size?
[01:24] <mathrick> yes, completely silent
[01:25] <mathrick> oh, wait, it clones
[01:25] <poolie> that is bizarre, i don't understand how it could grow without using
[01:25] <poolie> ah
[01:26] <mathrick> so it's stat()ing every dir under my ~/Dev, which is a lot of files, but shouldn't really result in such memory usage
[01:27] <poolie> and this is just when you started it, there's no client doing anything?
[01:27] <mathrick> yep
[01:27] <poolie> and there are only stat calls?
[01:27] <mathrick> I had the same thing when I started it in the wrong dir, btw
[01:27] <poolie> and C-\ doesn't work
[01:28] <poolie> if you ^C do you get a backtrace in ~/.bzr.log?
[01:28] <mathrick> [pid 28773] open("/home/mathrick/Dev/Lisp/cl-rdbms/_darcs/patches/20071026164922-6b9e8-dc57c67fcc6c56c8cb8cf9968ae7598378e3a6c2.gz/.bzr/branch-format", O_RDONLY|O_LARGEFILE) = -1 ENOTDIR (Not a directory)
[01:28] <mathrick> there are also those
[01:28] <mathrick> I'll check
[01:28] <mathrick> I can see lstat64, access, occasional open, and brk
[01:29] <mathrick> brk being obviously the one responsible for allocations
[01:29] <awmcclain> jelmer: ping?
[01:29] <mathrick> but I dunno where it comes from
[01:29] <jelmer> awmcclain, pong
[01:30] <awmcclain> jelmer: Quick question about how autoppa and bzr-builddeb work together... I noticed you had an autoppa branch dealing with builddeb, but didn't see the attachment in Bug #252774.
[01:31] <jelmer> awmcclain, That was just to be able to build the autoppa package itself using bzr-buildde
[01:31] <jelmer> it wasn't about integration between the two or anything
[01:31] <awmcclain> jelmer: Ahhhh. Understood.
[01:40] <awmcclain> Am I going to screw up my package branch if I run autoppa on the same branch?
[02:03] <jelmer> awmcclain, I wouldn't recommend it, autoppa's use of tags is a bit strange
[02:04] <jelmer> awmcclain, also, be warned that it throws away pending changes in your working tree
[02:04] <mrooney> Hrm, I am trying to add my project to http://bazaar-vcs.org/WhoUsesBzr as it says I can, however it says I am not allowed to edit that page
[02:04] <mrooney> Do I need to do something special other than create an account?
[02:04] <awmcclain> jelmer: All right. I'll branch and use autoppa from that.
[02:05] <mrooney> Oh, now it works after logging in for a third time, never mind :)
[02:14] <poolie> mrooney: i don't know why that happened, it normally works first time
[02:14] <poolie> maybe some kind of caching bug
[02:15] <mathrick> poolie: just for the record, no backtraces in ~/.bzr.log
[02:15] <mrooney> poolie: I have a rather locked down browser with noscript and no cookies by default so I suspect it was something on my end
[02:15] <poolie> even from ^c?
[02:15] <mathrick> not even
[02:15] <mathrick> and now I need to sleep, I'll followup to the list tomorrow or something
[02:16] <poolie> mathrick: tomorrow, file a bug with strace running from the beginning of the invocation please
[02:16] <poolie> in a directory with no confidential file names
[02:16] <mathrick> will do
[02:17] <mathrick> I'll try to make a non-confidential repo showing that, if possible
[02:17] <mathrick> sadly, the biggest dir in there is closed source
[02:17] <mathrick> so I'll have to make something up of similar structure
[02:39] <jelmer> I guess that also answers the question of whether bzr.debian.org can start running the smart server :-(
[02:39] <jelmer> does launchpad utilise the bzr smart server somehow or is it all custom?
[02:40] <jelmer> or does it just have infinite amounts of memory at its disposal ? ;-)
[02:44] <Peng_> LP also runs Loggerhead, so my guess is they have infinite amounts of memory. ;P
[02:44] <Peng_> What are we talking about?
[02:48] <thumper> jelmer: launchpad does use the smart server
[02:49] <thumper> jelmer: but not entirely directly
[02:49] <thumper> jelmer: jml should be able to answer questions on that
[02:49] <jml> jelmer: we have infinite amounts of memory and a crack team of sysadmins.
[02:51] <jml> jelmer: actually, memory is a problem for us.
[02:51] <jml> I've half-mentioned it to #bzr folk before.
[02:52] <jelmer> thumper, jml: Thanks
[02:52] <jelmer> I was half-hoping launchpad was using some magic flag in bzr to get the memory usage down
[02:52] <jml> I would love such a flag.
[02:53] <jml> jelmer: another issue we have is bzr subprocesses hanging around.
[02:53] <jml> jelmer: that *might* be an issue with our SSH server though.
[02:54] <jelmer> I've seen it on samba.org as well
[02:54] <jelmer> There it's mainly related to connections being terminated abruptly
[02:54] <jelmer> and some interaction with the fact that the client time and server time are slightly out of sync
[02:55] <jelmer> which prevents me from actually breaking locks without ssh-ing in
[02:55] <jml> interesting.
[02:55]  * jml needs to write a manifesto or something on hosting Bazaar.
[03:00] <jelmer> I think there would be an audience for that
[03:03] <jml> jelmer: me too.
[03:04] <jml> jelmer: it probably wouldn't add much to what I said at the London sprint this year, but who knows, it might help someone solve some of my problems for me :)
[03:06] <mwhudson> jelmer: what problem does bzr.debian,org have with the smart server?
[03:06]  * mwhudson feels he is missing context
[03:06] <jelmer> jml, :-)
[03:06] <jelmer> bzr+ssh: works fine
[03:06] <jelmer> but that's mainly because processes are short-lived
[03:06] <jelmer> and most branches are small
[03:06] <jelmer> there's been talk about running bzr:// as well
[03:07] <Peng_> You can do bzr:// with inetd so those processes will be short-lived too.
[03:07] <Peng_> Or something.
[03:07] <jelmer> but you lose the advantage that it doesn't have any startup overhead
[03:08] <Peng_> Right.
[03:08] <Peng_> I run bzr+http over CGI, meaning there's startup overhead for every request. Whee. :)
[03:09] <mwhudson> oh right
[03:09] <mwhudson> yes, we'd like to run bzr:// at some point, and i've had similar thoughts
[03:09] <mwhudson> i guess you could just fork for each connection...
[03:10] <Peng_> Why doesn't bazaar.launchpad.net use HTTPS? The rest of the website does.
[03:12] <jml> Peng_: because it runs in a different webserver and there's no compelling reason to use HTTPS
[03:12] <jml> Peng_: and at least one good reason not to.
[03:14] <Peng_> jml: What's the reason not to?
[03:15] <jml> Peng_: https is slower for end users.
[03:17] <Peng_> There's a significant difference for bzr over https?
[03:18] <poolie> sending an https request is several times slower than sending over http
[03:18] <poolie> and i would expect substantially slower than sending over ssh
[03:19] <Peng_> Huh.
[03:19] <jml> poolie: I would be mildly interested in actually experimental data on that last point.
[03:19] <poolie> mm
[03:19] <poolie> it should be reasonably easy with -Dhpss
[03:19] <poolie> ..
[03:19] <jml> poolie: I expect that establishing an SSH connection takes longer.
[03:20] <jml> poolie: but, my interest is so mild, I could be a central banker.
[03:20] <bob2> haha
[03:20] <poolie> wow nice one spivvo
[03:20] <poolie> bzr -Dhpss info http://bazaar.launchpad.net/~bzr/bzr/trunk does one hpss round trip
[03:21] <lifeless> mathrick: you have the bzr-avahi plugin in stalled ?
[03:21] <lifeless> robertc@tungsten:~$ ./test-mem  bzr 50 500 5000
[03:21] <lifeless> 50,273516,2173.65908694
[03:21] <lifeless> 500,319888,498.259073973
[03:21] <lifeless> 5000,931452,304.59688592
[03:22] <lifeless> Peng_: whats vmpeak in, MB?
[03:22] <poolie> hm, actually not quite so nice, there's no smart server there
[03:22] <spiv> poolie: heh :)
[03:23] <poolie> the interaction between auto-bzr+http, -Dhpss and log+ is a bit confusing
[03:24] <Peng_> lifeless: I glanced in /proc a couple times, and it said KB, but I don't know if it's ever something different.
[03:24] <poolie> jml, sending requests across ssh vs http is approximately the same speed, modulo network variability and measurement error
[03:24] <poolie> or, eyeballing the numbers error
[03:24] <lifeless> Peng_: ok, so 270MB, 330MB, 930MB, for bzr
[03:24] <poolie> i'd expect https will be awful if you don't keep the connection alive
[03:25] <lifeless> its sublinear, which is good, but a GB is awful large :P
[03:26] <Peng_> lifeless: You were indexing a copy of bzr.dev?
[03:26] <lifeless> yes
[03:26] <Peng_> I got very different numbers when I did it.
[03:27] <Peng_> When I ran it for 50 and 500, VmPeak was about half of what you got.
[03:28] <lifeless> Peng_: 32-bit machine?
[03:28] <Peng_> lifeless: Yeah
[03:28] <lifeless> 64-bit
[03:29] <Peng_> Note to self: Don't upgrade to 64-bit without doubling your RAM...
[03:29] <mwhudson> man
[03:29] <lifeless> I'm doing another more granular run
[03:29] <mwhudson> this branch of mine is cursed
[03:29] <lifeless> get the slope
[03:29] <mwhudson> push said this to me:
[03:29] <mwhudson> ShortReadvError: readv() read 0 bytes rather than 185 bytes at 25704 for "00/00/71/72/.bzr/repository/upload/xkxs5h4uy9mq79wr2t1h.pack"
[03:30] <lifeless> 500 is 50% longer than 5000, and only 10% more mem than 50
[03:30] <lifeless> so 500 is looking apealing
[03:32] <poolie> mwhudson: i wonder if that's related to spiv's change for caching when writing out packs?
[03:32] <poolie> can you file a bug with the traceback please
[03:32] <mwhudson> poolie: ok
[03:33] <spiv> mwhudson: and the formats; if poolie's right at least one side will be a stacked branch.
[03:34] <mwhudson> spiv: the remote side is stacked
[03:34] <mwhudson> it's all branch7/knitpack5
[03:35] <mwhudson> spiv, poolie: https://bugs.edge.launchpad.net/bzr/+bug/303856
[03:35] <lifeless> probably a plugin if core works doing this
[03:35] <lifeless> try pushing it with --no-plugins
[03:36] <lifeless> (plugins can cause a read, its why the cache-change has to be done at transport not the pack writer to work reliably)
[03:38] <mwhudson> lifeless: same thing with --no-plugins
[03:39] <lifeless> mwhudson: ok, one theory down
[03:40] <jml> what does 'f' do in the new shelve?
[03:42] <spiv> mwhudson: if you edit bzrlib/repository.py, so that InterPackRepo.fetch has "set_cache_size = None" rather than what it currently is, does that fix it?
[03:43] <mwhudson> spiv: ok
[03:45] <spiv> If it does, it appears that the issue is that for a target repository to take a delta record and turn it into a fulltext it needs to read from a pack file that's still in progress...
[03:46] <lifeless> spiv: yes, it will
[03:46] <spiv> Ideally I think that case would be reading that data out of the local repo, rather than the remote one.
[03:46] <lifeless> spiv: I don't think thats ideal
[03:47] <lifeless> spiv: because that requires a) fullduplex and b) the server asking the client for data it already has - when you consider streaming
[03:47] <spiv> Ok, well that explains why the non-stacked pack-to-pack case can get away with buffering writes and this case can't.
[03:48] <spiv> lifeless: by "that case", I meant the case where the client is doing the file ops on the local and remote repos.
[03:48] <lifeless> spiv: mmm, I really hope we can get just one code path to optimise, and having very clear read-from, write-to patterns will help that immensely
[03:49] <spiv> lifeless: right, one code path would also be ideal
[03:49] <spiv> lifeless: there can be conflicting ideals :)
[03:49] <spiv> I'm not going to try decide which is more important, at least not on my week off ;)
[03:49] <lifeless> fair 'nuff
[03:49] <spiv> And on that topic...
[03:50]  * spiv wanders off :)
[03:50] <spiv> (the cricket is going well, btw)
[03:51] <spiv> Oh, before I go... mwhudson, if that does fix it (as I now expect it will), make sure poolie knows so he can revert that change for the 1.10 final release.
[03:51] <jml> spiv: I didn't know you were on a week off.
[03:51] <jml> lucky devil.
[03:51] <spiv> jml: accumulating annual leave is good like that ;)
[03:51] <mwhudson> ah well, at least the wallabies lost
[03:52]  * spiv really goes
[03:52] <jml> mwhudson: rugby is a tier 2 sport.
[03:52]  * poolie looks
[03:53] <mwhudson> bah
[03:53] <poolie> lifeless: mark was asking something about getting a dodgy nearly-full-duplex connection over http by using 100 continue responses
[03:53] <mwhudson> i got BzrCheckError: Internal check failed: Newly created pack file <bzrlib.repofmt.pack_repo.NewPack object at 0x1a71780> has delta references to items not in its repository:
[03:53] <mwhudson>  on pushing again
[03:53] <poolie> i'm pretty skeptical
[03:54] <poolie> also i think this has already been discussed
[03:54] <mwhudson> lifeless, poolie: how can i fix by broken local branch?
[03:54] <mwhudson> my
[03:54] <mwhudson> oh
[03:54] <poolie> actually this is not urgent, and it's probably a silly idea
[03:54] <mwhudson> it's the remote branch that's messed up, isn't it
[03:54] <poolie> i think so
[03:54] <lifeless> mwhudson: branch the parent with a good bzr, then pull your local dodgy branch into the new branch
[03:56] <mwhudson> lifeless: branching within a repo will be ok?
[03:56] <lifeless> mwhudson: no
[03:56] <lifeless> mwhudson: the repo is the thing that is confused
[03:56] <mwhudson> ah
[03:56] <mwhudson> right
[03:58] <Peng_> When you get that "Internal check failed" error, is creating a new repo the only way to fix it?
[04:00] <mwhudson> well you can also push with an older bzr, which is definitely sneaky :)
[04:02] <Peng_> I get it under entirely different circumstances (pulling, and before the "Internal check failed" error was introduced, I got a different one), but I thought I'd ask since it was getting discussed.
[04:02] <Peng_> Not to distract from your issues..
[04:08] <poolie> Peng_: if it's the one about a newly-created pack file then it should cause the transaction to abort and the repository will be unchanged
[04:09] <lifeless> Peng_: if you have a repo with a bad delta, there isn't currently a command to fix the delta up
[04:09] <lifeless> Peng_: 'bad' meaning 'points outside the repo'
[04:11] <Peng_> lifeless: Okay. ...Will there be eventually?
[04:11] <lifeless> Peng_: probably, FSVO probable
[04:12] <lifeless> Peng_: with a repo, just init a new repo, branch --stacked from the original again for all your branches, and pull --overwrite them all in - scriptable
[04:13] <Peng_> BTW, I'm not using stacking in this repo, AFAIK. :)
[04:15] <lifeless> Peng_: if its not stacked, you definitely shouldn't have a bad delta. when do you get the error? and what precise error?
[04:15] <Peng_> lifeless: It's a large repo (Python), and bzr-svn is involved.
[04:24] <Peng_> Hmm, if I'm reading this right, all the bad deltas are for directories.
[04:30] <Peng_> lifeless: Still interested?
[04:30] <lifeless> Peng_: bug filing time!
[04:30] <Peng_> Eep
[04:30] <Peng_> Nice timing.
[04:30] <Peng_> Anyway, like I said, bzr-svn is involved. It's kind of complicated.
[04:32] <Peng_> There's http://svn.python.org/projects/python/ , Python's svn branches. There's also http://code.python.org/python/ , bzr-svn imports of them.
[04:33] <Peng_> I created a repo, made my own imports of svn.python.org, and later branched copies of the ones from code.python.org (which, being bzr-svn, are identical to my imports).
[04:33] <Peng_> With one code.python.org branch, pulling it dies with one of the "Internal check failed" messages. Before that message was introduced, it died with something less useful.
[04:34] <Peng_> If I pull the equivalent svn.python.org branch with bzr-svn, it works fine and generates the revisions.
[04:34] <Peng_> So...yeah.
[04:35] <Peng_> .bzr.log snippet at http://paste.pocoo.org/show/FZSj4YB6aiyVinJfSWfw/ :)
[04:36] <lifeless> Peng_: definitely file a bug
[04:36] <lifeless> Peng_: I smell bzr-svn off the cuff
[04:36] <lifeless> Peng_: a new repo suffers this?
[04:37] <Peng_> lifeless: I haven't tried.
[04:49] <lifeless> robertc@tungsten:~$ ./test-mem  bzr 50 500 1000 2000 2500 3000
[04:49] <lifeless> 50,273520,2107.63493299
[04:49] <lifeless> 500,319884,498.597379923
[04:49] <lifeless> 1000,398488,373.639508009
[04:49] <lifeless> 2000,552916,305.507139206
[04:49] <lifeless> 2500,622240,302.449185133
[04:49] <lifeless> 3000,721288,304.617379904
[04:49] <lifeless> Peng_: ^
[04:49] <lifeless> flat at 2000+, for bzr.dev
[04:50] <Peng_> That's interesting.
[04:52] <lifeless> zooming in on 1K to 2K now
[04:52] <lifeless> I think we probably need to look at the file group_size too
[04:54] <lifeless> Peng_: if I can twist your arm a little more :)
[04:56] <Peng_> lifeless: Unless you want to test combinations of both at once, you could open up index.py, change the first group_size line a little so it won't match the regexp (e.g. add another space before the = sign), and it'll start changing the other group_size.
[04:57] <Peng_> (or add a space or comment to the end of the line, I guess)
[05:15] <lifeless> Peng_: well, I can run combinations outside it
[05:16] <lifeless> Peng_: ideally we'd run both and look for a correation, chi-squared regression or whatever
[05:16] <lifeless> robertc@tungsten:~$ ./test-mem  bzr 1000 1250 1500 1750 2000
[05:16] <lifeless> 1000,398492,372.275660992
[05:16] <lifeless> 1250,424632,334.12329483
[05:16] <lifeless> 1500,484364,306.166346073
[05:16] <lifeless> still running
[05:17] <lifeless> but it looks like 1500 hits a bottleneck of some kind
[05:18] <lifeless> where it stops getting faster
[05:21] <lifeless> poolie: https://wiki.ubuntu.com/EtcUsingEtckeeperSpec
[05:29] <lifeless> Peng_: so -
[05:29] <lifeless> robertc@tungsten:~$ ./test-mem  bzr 1000 1250 1500 1750 2000
[05:29] <lifeless> 1000,398492,372.275660992
[05:29] <lifeless> 1250,424632,334.12329483
[05:29] <lifeless> 1500,484364,306.166346073
[05:29] <lifeless> 1750,526364,304.78441
[05:29] <lifeless> 2000,552908,304.097445011
[05:29] <lifeless> for bzr.dev at least, 1250/1500 is good, at about 240MB for you
[05:33] <RAOF> Hm.  Is there any reason for the bzr-search package to be in Experimental but not Jaunty?
[05:36] <lifeless> none
[05:36] <lifeless> its perfect as is, release kthx
[05:36] <lifeless> oh, thats me.. hmm
[05:36] <RAOF> :P
[05:38] <RAOF> Builds, installs, works.  Those seem sufficient conditions for asking for a sync at this point.
[05:38] <lifeless> sync it baby
[05:39] <lifeless> Peng_: trying the current test-mem on python
[05:40] <lifeless> Peng_: I'd love to have an option though to control which thing is altered :)
[05:40] <poolie> lifeless: i don't understand your comment about "not related to the Transport abstraction"
[05:41] <poolie> i understood John's
[05:41] <lifeless> poolie: uhm
[05:41] <poolie> nm, now i do
[05:41] <lifeless> :)
[05:42] <poolie> i think you're just reiterating what he said
[05:42] <lifeless> probably
[05:42] <poolie> that it's not on transport because it's local scratch space
[05:42] <lifeless> yes, and also that there isn't any motivation (for me at least) to put it on transport
[05:44] <poolie> 'it'?
[05:44] <lifeless> management of scratch files
[05:45] <poolie> mm
[05:51] <lifeless> poolie: are we talking past each other, or so violently agreeing we're confusing?
[05:51] <poolie> the latter
[05:51] <poolie> it's fine
[06:09] <Peng_> lifeless: I'm starting to get out of my depth here.
[06:10] <lifeless> Peng_: no worries, tell you what
[06:10] <lifeless> Peng_: commit whatever you've got to bzr-search, as e.g. test-mem.py
[06:10] <lifeless> Peng_: and throw me a bundle/merge-request on lp/whatever
[06:12] <Peng_> lifeless: I actually have been versioning it (though so far the only commits have been comments and stuff), in my hg repo where I throw random stuff.
[06:13] <lifeless> Peng_: lol.
[06:13] <lifeless> Peng_: we so gotta make bzr more attractive for you, for that
[06:14] <Peng_> lifeless: I'm mostly using hg for historical reasons. Although it's nice that "hg convert" can easily spin something out into its own, independent repo.
[06:14] <Peng_> (by filtering the history and creating a new repo)
[06:16] <jml> thread rename pls.
[06:28] <Peng_> lifeless: What do you /call/ the two group_size variables? "inventory group_size" and "text group_size" or "revision group_size" or something?
 mathrick: you have the bzr-avahi plugin in stalled ? <-- yes
[06:28] <mathrick> should I uninstall it?
[06:29] <lifeless> mathrick: its trying to share all your branches
[06:29] <lifeless> mathrick: do you have 'bzr-svn' installed too ?
[06:29] <mathrick> yes
[06:29] <lifeless> Peng_: yes, that makes sense
[06:29] <lifeless> mathrick: ok, so here is whats happening
[06:29] <Peng_> lifeless: Which ones make sense? :P
[06:30] <lifeless> mathrick: there is a bzr-svn bug where 'bzr branches' takes a lot of memory up
[06:30] <lifeless> Peng_: 'revision group_size' and 'text group_size'
[06:30] <lifeless> mathrick: and bzr-avahi uses 'bzr branches' to find the branches to share
[06:30] <mathrick> oh
[06:30] <mathrick> I see
[06:30] <Peng_> lifeless: The former for _index_revisions and the latter for the other method?
[06:30] <mathrick> I'll remove bzr-avahi for now, I don't use it anyway
[06:30] <lifeless> mathrick: uninstalling *either* will fix your problem :P. Probably subscribing to the bzr-svn bug would be a good idea.
[06:30] <lifeless> Peng_: yes
[06:32] <mathrick> lifeless: https://bugs.launchpad.net/bzr-svn/+bug/54253 ?
[06:35] <mathrick> btw, is there a way to serve only some branches in a repo?
[06:36] <poolie> mathrick:  bzr_access, i think
[06:36] <poolie> lifeless: nice to see you invalidating your own bug 181367 :)
[06:37] <poolie> i'm glad i didn't work on it any further
[06:37] <mathrick> poolie: is that a command or a plugin?
[06:37] <lifeless> poolie: ah yes, well I claim temporary insanity
[06:38] <lifeless> poolie: perhaps having it work-when-it-can would be good, but I suspect too-much-effort for now
[06:38] <poolie> missing smiley here: :-)
[06:38] <poolie> that's what i concluded when i looked into it
[06:38] <lifeless> mathrick: its a addon in the contrib directory
[06:38] <poolie> mathrick: it's a script in contrib in the bzr distribution
[06:39] <lifeless> mathrick: no, I don't think thats the byg
[06:39] <lifeless> *bug*
[06:39] <lifeless> jelmer: ping; is there a bug for 'bzr branches w/bzr-svn chews ram'?
[06:39] <mathrick> poolie: re: invalidating bug, reminds me of an anecdote from one of PL unis, one of the professors was appointed dean *and* rector simultanously. Reportedly at one point he applied for funds to himself and then rejected the application
[06:39] <jelmer> lifeless, yes
[06:39] <jelmer> lifeless, I think it has "multi-pull" in the description
[06:40] <poolie> PL=poland?
[06:40] <mathrick> lifeless, poolie: thanks
[06:40] <mathrick> yes
[06:40] <poolie> anyhow, nice to see he can be objective :)
[06:40] <poolie> we should all do so well :)
[06:41] <lifeless> amen
[06:41] <mathrick> are contrib scripts packaged?
[06:41] <mathrick> jelmer: ah, I've seen one like that
[06:42] <poolie> maybe into doc/
[06:42] <mathrick> https://bugs.staging.launchpad.net/bzr/+bug/262513
[06:42] <poolie> no!
[06:42] <poolie> but they should be
[06:42] <mathrick> should I file a bug?
[06:42] <jelmer> ubottu, yeah, that's the one
[06:43] <poolie> i will
[06:43] <jelmer> mathrick, that's the same bug as for "bzr branches"
[06:43] <mathrick> jelmer: I see, thanks
[06:44] <mathrick> jelmer: do you have any idea what causes that? The bug is a bit short on that
[06:45] <jelmer> mathrick, No, I haven't spent time debugging it yet
[06:45] <mathrick> hmm, it's marked fixcommitted for bzr-svn
[06:45] <jelmer> hmm, perhaps I fixed it already
[06:46] <mathrick> it's a pity it doesn't link to a specific revision
[06:46] <mathrick> jelmer: is trunk supposed to work with 1.9?
[06:47] <jelmer> mathrick, no, only 1.10
[06:47] <poolie> bug 303888
[06:47] <jelmer> mathrick, it's indeed fixed in the 0.5 branch
[06:48] <mathrick> I see, and 0.5 is the 1.10-only?
[06:48] <jelmer> yes
[06:49] <mathrick> okay, that confuses me
[06:49] <jelmer> why?
[06:49] <jelmer> 0.4.15 should work with 1.9
[06:49] <mathrick> not the branches, something else, sorry for being confusing myself
[06:49] <mathrick> jelmer: does it have the fix committed?
[06:50] <jelmer> mathrick, 0.5 does, yes
[06:50] <mathrick> 0.4.15 I mean
[06:50] <jelmer> no, the fix is only in trunk/0.6
[06:50] <jelmer> *0.5
[06:50] <mathrick> ok
[06:52] <mathrick> http://pastebin.ca/1272124 <-- could someone explain?
[06:53] <Peng_> lifeless: I'll turn my index thingy into a regular bzr command later, so I can take advantage of the option infrastructure and make it possible to alter either group_size, but anyway, I'd rather watch TV right now. :P
[06:53] <Peng_> (I don't have experience with bzrlib's command stuff, but anyway, I'm sure I'll manage to half figure it out. :P )
[06:53] <jelmer> mathrick, you can't list the contents of something that's not a branch/workingtree
[06:53] <mathrick> oh
[06:53] <mathrick> right
[07:05] <poolie> lifeless: quick ping re the reconfigure rfc
[07:06] <poolie> if you still exist
[07:06] <lifeless> Peng_: thats cool; just shove it in the tree and I'm happy.
[07:06] <lifeless> poolie: yes, walking up the street - can you ring my mobile ?
[07:07] <poolie> np
[07:07] <mathrick> has anyone used TortoiseBzr?
[07:08] <mathrick> http://bazaar-vcs.org/TortoiseBzr/Screenshots shows a dialogue for creating a new checkout, but I can't find it hooked into explorer anywhere
[07:08] <jelmer> poolie, bzr reconfigure --stacked-on seems like a good idea, indeed
[07:08] <mathrick> which is kind of important to have my boss have something clickety for all steps
[07:16] <CXI> Hi! I'm getting some strange behaviour from the 1.9 windows installer. I already had python installed, which was recognised by the installer and it installed everything in my python library path. That's all fine, but it doesn't seem to have installed the bzr-svn plugin.
[07:17] <CXI> I keep getting "unable to load bzr-svn" messages, coupled with some stuff about being unable to load "svn" from my python library path and a "cannot import name client" for good measure
[07:21] <awmcclain> Is there a version of bzr-email that works with 1.9?
[07:21] <vila> hi all
[07:30] <poolie> markh^^
[07:30] <poolie> awmcclain: the current one does not?
[07:30] <poolie> hi vila!
[07:31] <vila> hey ! :)
[07:31] <awmcclain> poolie: Ungh. Sorry. It's been a long day of staring at debian packages. Let me go check the branch.
[07:31] <CXI> oh, wait... that's a lie, it does seem to have installed the plugin - I just found it in bzrlib\plugins, but it doesn't seem to have any compiled libraries (which client is)
[07:32] <mathrick> CXI: FWIW, it doesn't seem to work on a (non-programmy) Win32 I installed it on either, presumably subversion isn't installed
[07:32] <markh> poolie: I'm afraid I've never looked at the Python based installer
[07:33] <markh> it appears the svn binaries aren't installed though
[07:34] <markh> poolie: Where are these binaries made?  It would appear its not our shared host due to the lack of the compiler I mailed about today...
[07:35]  * markh can never remember how to spell that host name without looking it up :)
[07:36] <CXI> hm
[07:37] <CXI> I wonder if there's a way I can get into the installer
[07:37] <CXI> could be it tried to put them somewhere I'm not looking
[07:37] <markh> CXI: I think I can find the binaries
[07:37] <markh> they "should" be in the bzr-svn directory I think
[07:38] <markh> CXI: if you grab svn-win32-1.5.4.zip from http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91, it should have the binaries you need.  You will probably want to copy the 'bin' directory to the bzr-svn plugin dir
[07:39] <markh> (it will probably have more than you need, but it will get you going :)
[07:43] <CXI> hm, are you sure? that bin directory looks awfully similar to the python-svn bindings I already have installed, and not very similar to the [editor,client,ra,repos,util,wc] compiled python library files I don't have
[07:45] <markh> CXI: I'm misunderstanding the problem then :)
[07:45] <CXI> yeah, I think I'm only just starting to figure it out :/
[07:45] <markh> bzr-svn doesn't depend on the python-svn bindings
[07:46] <markh> so they may not be being found
[07:46] <markh> ir binds directly to the svn api
[07:46] <markh> it
[07:46] <CXI> ah, well I'll give it a shot
[07:46] <CXI> "cannot import name client" says to me something about missing python libraries, though
[07:47] <CXI> they're in, no difference :/
[07:48] <CXI> the bzr-svn package is part python and part c libraries, right?
[07:56] <markh> CXI: yeah - right - it appears you are missing all the extension modules :(
[07:56] <markh> client.pyd is part of the c implemented stuff.
[07:57] <markh> I could put one up on the web for you to see if it helps :)
[07:57] <CXI> sure, that'd be great :)
[07:57] <CXI> I just realised I can open the installer as a zipfile
[07:57] <CXI> there aren't any files that look like c extensions in there
[07:58] <markh> CXI: right :(
[07:58] <markh> as I said above, sadly I've never tried it
[07:58] <CXI> ah
[07:58] <markh> http://starship.python.net/crew/mhammond/client.pyd might help
[07:58] <markh> but you probably don't have any of the performance related core extensions either, which is likely to suck :(
[07:59] <CXI> I wonder if that means the installer is broken
[08:00] <markh> CXI: right, putting 2+2 together, it appears the machine used to build these recent installers doesn't have the c compiler installed.  I'm actually installing that as we speak!
[08:01] <CXI> ah
[08:01] <CXI> bleh
[08:01] <markh> yeah :(
[08:01] <CXI> ordinal 284 could not be located in ssleay... time for me to run around in dll hell for a bit
[08:01] <markh> yeah - check %PATH% for other binaries of the same name
[08:05] <CXI> rockin', okay, that's fixed
[08:05] <CXI> but it looks like are a bunch of other extensions it wants
[08:05] <CXI> asking for ra now
[08:06] <CXI> if you're fixing the installer, I can wait - no hurry
[08:33] <lifeless> wow, python bzr-search index @ 50 is taking for-ever
[09:02] <kingfishr> I'm kind of new to version control. I made a big mistake in the last one or two commits. How do I browse my commit messages and compare the files?
[09:02] <markh> CXI: still here?
[09:03] <CXI> sure am
[09:03] <kingfishr> (i'm not sure where I want to revert to)
[09:03] <markh> ok - I should have looked - there are 4 .pyd files in bzr-svn - I'll zip 'em
[09:04] <markh> CXI: bzr-svn-pyds.zip in the same palce
[09:05] <markh> kingfishr: try, "bzr log", then "bzr diff -rrevno:xxx" where xxx can be seen from the log output
[09:05] <markh> if you have a gui extension installed (eg, pygtk or pyqt), using its equivalent might be better
[09:06] <markh> s/py/bzr/ :)
[09:06] <kingfishr> markh, ok thanks...figured it out
[09:06] <CXI> hey, rockin', that appears to have done the trick
[09:06] <kingfishr> yay having version control...I would have been so screwed without it :P This is the first time I've been really glad i had it.
[09:08] <CXI> markh: out of curiosity, what does dir /s /a /b "c:\path\to\bzrlib\*.pyd" give you?
[09:09] <CXI> I'm wondering specifically about those performance-enhancing dlls
[09:09] <CXI> but just in case there's anything else that will trip me up
[09:12] <CXI> I've got five other than the ones you sent me: _btree_serializer_c, _dirstate_helpers_c, _knit_load_data_c, _patiencediff_c, _walkdirs_win32
[09:12] <markh> I don't actually have a "python" install of bzr around.  Only source trees and binaries.  There are certainly some perf related ones missing, but nothing else leaps out.
[09:13] <markh> (there are 50 .pyd files in my binary distro, but many of them come with python, or should come with packages you've already optionally installed, such as pycrypto, pyqt, etc)
[09:14] <markh> actually > 50
[09:14] <CXI> interesting
[09:15] <CXI> so how's your binary distro related to the windows standalone installer?
[09:17] <markh> binary distro is completely stand-alone
[09:17] <markh> uses py2exe to create .exe files etc
[09:17] <CXI> oh, jesus, wouldn't you believe it
[09:17] <CXI> I thought I'd gotten the standalone installer
[09:17] <markh> but I fear the 1.9 binary install will have the same problem :(
[09:18] <markh> it appears to have come from a machine with the compilers.  I've not tested the installers I didn't make, and 1.8 was the last one I personally did.
[09:18] <CXI> somewhere along the line I convinced myself it was *so* clever that it recongised my existing python install and just put itself there
[09:18] <markh> I think you grabbed the wrong installer - it should be completely independent of any Python's installed
[09:19] <CXI> yeah, I did
[09:19] <CXI> damn click-the-top-thing-it'll-be-fine mentality
[09:19] <CXI> that said, I suppose the problem ended up being independent of that
[09:19] <markh> but I do think a 1.9 binary will have the same problem - or else I'm quite confused about how it was built
[09:20] <markh> 1.8 binaries are known to be good.
[09:20] <CXI> anyhow, I'm pulling down a copy of the standalone so I can take a look and see if I'm missing anything particularly egregious
[09:20] <markh> (for some definitions of "good" ;)
[09:20] <CXI> so I'll let you know if the binaries are in there
[09:22] <CXI> by which I mean I'm heading home now so look forward to that news later on :D
[09:22] <CXI> thanks for all your help - I appreciate it
[10:42] <mathrick> who knows something about bzr win32 installer?
[10:43] <mathrick> it doesn't seem to register the TortoiseBzr shell extensions
[10:43] <mathrick> which makes including it rather pointless
[11:19] <CXI> markh: looks like the standalone does have all the compiled extensions
[11:20] <markh> CXI: interesting...  good to know - thanks.
[11:22] <CXI> no problem... incidentally, any idea where I'd want to look for a list of the performance-related ones?
[11:23] <markh> not really - but look for _btree_serializer_c.pyd, _helpers_c.pyd, _load_data_c.pyd, _c.pyd and _win32.pyd
[11:23] <markh> hrm - that 2nd-to-last one looks suspect...
[11:24] <CXI> interesting
[11:25] <CXI> looks like most of those, or at least similar ones, were in the python installer
[11:26] <CXI> oh, right, you lopped off the first part of each
[11:33] <awilkins> Hmm, who builds the Python-flavoured windows installer now?
[11:33] <awilkins> I have a working build process for it here, apart from the "extras"
[11:33] <awilkins> I never got TBZR to work properly after I built it.
[11:37] <mathrick> awilkins: it has issues in the windows installer as well
[11:38] <mathrick> I'm trying to make it work, so far with little luck
[11:39] <awilkins> The bzr-svn SVN client extensions are not packaged in the python-flavoured one, I just delete the folder.
[11:39] <awilkins> Or it moans about not having built it forever.
[11:39] <mathrick> yeah, that is a good idea probably
[11:39] <mathrick> I need to try with the standalone installer
[11:39] <awilkins> I think Windows needs a bit of package'n'distribution loving
[11:39] <AfC> a bit?
[11:40] <awilkins> Heh
[11:40] <awilkins> I was under the impression that Canonical wanted to move the building of the win32 packages in house, onto a VM or something?
[11:41] <mathrick> whatever works, I just want tbzr working off the shelf, it's really rather useless having it without registered extensions
[11:52] <markh> there is a canonical "owned" machine we are using for builds now to less rely on any individual.  It seems that process does indeed need some lovin' tho...
[11:52] <markh> awilkins: can you recall what issues you had?
[11:53] <awilkins> markh: It would crash ; sorry not to be specific. I got it building and wrapped into the exe installer, but it didn't work after installation
[11:53] <markh> awilkins: can you recall what crashed?
[11:54] <awilkins> I didn't have time to probe further as I don't use it ; I was interested from the POV of my users who could do with some GUI lovin' :-)
[11:54] <markh> or when?
[11:54] <markh> what were the symptoms?
[11:54] <awilkins> It was right at the shell integration level I think
[11:54] <awilkins> But I can't recall well, this was a while ago
[11:54] <awilkins> about 1.6 time I think
[11:54] <awilkins> On Vista Business 32
[11:55] <awilkins> I built it with the MSVC 7.1 compiler ; do you use mingw?
[11:56] <markh> nope - I use the same MS compiler version used by Python itself.  The "good" news is that the next version will have a c++ extension that will have no hope of building under mingw ;)
[11:57] <awilkins> What, of TBZR or Python?
[11:57] <awilkins> I presume TBZR since Python 2.6 is out already :-)
[11:57] <markh> the truly good news with that though is that there are zero external deps other than windows itself - not even the crt - so it will be much less reliant on a "friendly" environment.
[11:58] <markh> the "shell extension" (ie, dll loaded into almost *any* arbitrary process) part of the jigsaw...
[11:58] <awilkins> I found it a right PITA to get Jelmers SVN client wrappers built for a while.
[11:58] <awilkins> Mostly because of the primitive nature of the MS compiler, I fear
[12:00] <markh> bzr-svn has built from sources for a while now - but roughly since 1.6-ish time, which is about when you said you checked.  setup.py should now have recent and current instructions that work.
[12:01] <awilkins> Yes, although the tip of 0.5 needs a few minor kicks to get started and I've not got it working yet
[12:01] <markh> about 3 env-vars and 4 .zip packages from tirgirs.org later... ;)
[12:01] <awilkins> Built, yes, working, not
[12:01] <markh> I just tried today and had no such problems...
[12:01] <awilkins> 1.5 or 1.46 SVN?
[12:01] <markh> heh - quite possibly :(
[12:02] <markh> lack of svn:externals support means I can't personally use bzr-svn day-to-day yet...
[12:02]  * markh tries not to mention lack or windows-line-ending support means he can't use bzr itself for "real world" projects yet either :(
[12:03] <awilkins> Meh, to be honest, I'm not especially fussed about that, but I've never really been on any cross-platform projects
[12:03] <awilkins> But I would think you can work around it by using tools that are not stupid and rude about line endings.
[12:03] <awilkins> (whether they are available is another point)
[12:04] <CXI> hm
[12:05] <markh> I can't see a way - case in point, I have launchpad mirroring a cvs repo that is primarily used on windows.  My windows checkouts of the bzr mirror differ in each and every line from the real cvs trunk.
[12:05] <markh> any project that already has \r\n line-ending is SOL from bzr's pov :(
[12:05] <awilkins> Is that because CVS forces *nix line endings at the back though
[12:06] <markh> it is because the same checkout on linux has different line endings than the same checkout on windows, yeah
[12:06] <CXI> surprised there's not a line-endings plugin
[12:06] <awilkins> (I have some rusty familiarity with the internals of CVS from having to covert a commercialised subspecies of repository)
[12:07] <markh> I'm not sure where the magic happens - but a cvs co on linux has \n line-ending, but the same checkout on windows has \r\n.  But, if the bzr mirror is created on linux, a windows checkout of that bzr branch has \n line-endings
[12:08] <awilkins> So your bzr working tree has *nix endings and your windows CVS tree has CRLF?
[12:08] <markh> yep
[12:08] <awilkins> Can your tools work with the *nix endings?
[12:08] <markh> well - the bzr mirror created by launchpad has \n line-endings, and the bzr co/branch has \n regardless of os.
[12:09] <markh> most can - except the unix tools, like diff.exe, which need special magic, if you are lucky, to ignore those differences.
[12:09] <awilkins> Do you need both trees?
[12:10] <awilkins> I suppose you can't commit to the bzr tree
[12:10] <awilkins> Being a mirror
[12:10] <awilkins> Or rather, push from it to the CVS repo
[12:11] <markh> correct - cvs is the "canonical" <wink> source.  The mirror is supposed to help me merge tricky stuff, but sadly it doesn't
[12:11] <markh> the mirror, and my copy of the bzr branch, always differ on every single text file :(
[12:11] <awilkins> Hmm ; you ever used Beyond COmpare?
[12:12] <markh> oops - "the mirror and the real trunk"
[12:12] <markh> "real trunk" as it is a windows-based project - regardless of what the server stores...
[12:12] <markh> I've no interest in fancy tools to help with this problem ;)
[12:12] <awilkins> Fair enough @:-)
[12:13] <markh> cvs remains the trunk and what I care about
[12:13] <uws> hmm
[12:13] <uws> bzr refuses to let me add files named '..\index.html'
[12:13] <awilkins> I mention it solely because it does a very nice job of comparing files with differing line endings
[12:14] <markh> but I'm fairly confident that the eol-support, as planned and described, should solve the problem.
[12:16] <markh> yeah - good tools would help if I had to work around this problem - but I don't - I just can't use a launchpad-based bzr mirror of a windows-base cvs project in any practical way atm.  I've figured I'll just be patient for bzr to grow that support...
[12:16] <markh> and when it *does* work, migrate that cvs repo to bzr once and for all :)
[12:16] <awilkins> Just another thing that's CVSs fault really :-)
[12:17] <awilkins> I suppose you could take a cvs-fast-export and munge it
[12:17] <awilkins> If such a thing exists
[12:17] <markh> actually, I'm not sure about that - all files without "-kb" get "native" line-endings.  What is wrong about that?
[12:18] <awilkins> Because it's destroying the original line endings?
[12:18] <markh> somewhat ironically given its age, cvs does exactly what I expect
[12:18] <awilkins> I prefer the SVN way of doing it ; don't mess with the file content AT ALL unless told to explicitly.
[12:19] <markh> destroying how?   I guess you could argue the CVS checkout on linux is broken as it "only" has \n line endings on text files, but I can't see how ;)
[12:19] <awilkins> Well, suppose you grab a checkout on Linux and open the files in a Windows VM sharing that folder - VB6 would choke, for example/
[12:20] <awilkins> Because it hates having it's line endings messed with
[12:20] <markh> well, that seems somewhat theoretical given "diff.exe" chokes today
[12:22] <awilkins> The underlying problem is that CVS saves diffs as "ed" commands and that isn't ending-agnostic, so it wants to make everything comply with *nix line endings.
[12:22] <markh> "-kb" with vcs sucks, as does "svn:eol-style" - but at least they both exist :)
[12:22] <markh> oops - s/vcs/cvs/
[12:23] <markh> hrm - recall the windows cvs co has \r\n - so as mentioned, I'm not sure where that happens, but I'm glad it does.,
[12:23] <awilkins> I think it happens in the client
[12:23] <awilkins> The actual RCS storage seems to have LF endings
[12:24] <awilkins> And I think it's basically a #define in the source (but I haven't personally looked)
[12:25] <awilkins> I shall add it to my list of reasons I'm happy I've never used CVS extensively :-)
[12:26] <markh> :)
[12:30] <markh> I believe that if the launchpad cvs->bzr mirror process happened on a windows box, both the repo, and working trees on all OS's would have different line-endings.  The fact it doesn't means I'm, practically, SOL on Windows best I can tell.  Shops that can't guarantee their tools also handle \n line endings are too in the short term.  I'm not trying to complain, but also trying to counter any arguments it doesn't matter in the real world for
[12:31] <awilkins> I think if it happened on a Win box, all the line endings of non-binary files would be CRLF
[12:31] <awilkins> And all bzr checkouts on all OS would also have them
[12:31] <markh> correct - but it happens on a linux box, so my windows branch also has \n
[12:31] <markh> hence the problem
[12:31] <awilkins> Which is nasty if your tools hate that, and nasty because your CVS is still live
[12:32] <markh> and means in the general sense, diffs between the 2 working trees must use smart tools, or else they fail.
[12:33] <markh> and trying to apply the same patch between the 2 trees will also fail
[12:33] <awilkins> cvs2svn has a fast-import compatible out-filter ; you could munge the line-endings back and migrate the whole history to bzr :-) (but not necessarily pracical)
[12:34] <awilkins> Yeah, you really need a line-ending-agnostic diff/patch
[12:34] <awilkins> Or EOL munging in bzr :-)
[12:35] <markh> yep :)
[14:35] <thrope> is jelmer about? or any bzr-svn people... got this traceback trying to commit http://pastebin.com/m13240b95
[14:36] <jelmer> thrope, known bug with checkouts in bzr 1.9
[14:36] <jelmer> it'll be fixed in 1.10
[14:36] <thrope> ok thanks
[14:37] <thrope> just found the bug actually - so I can unbind, commit and push
[14:47] <lamalex> Hi, are any of the loggerhead people around?
[14:47] <lamalex> I submitted a bug report a few weeks ago on LP with a patch and it has had 0 activity
[14:59] <jelmer> lamalex, what bug ?
[14:59] <lamalex> https://bugs.launchpad.net/loggerhead/+bug/297930
[14:59] <lamalex> jelmer: ^
[15:02] <jelmer> lamalex, I think the problem may be that there is no agreement that this patch is desired, since next and prev are correct atm from the pov of the tip of the branch (which loggerhead displays first, by default)
[15:02] <jelmer> lamalex, You may want to ping beuno or mwhudson_ when they're around
[15:03] <lamalex> jelmer: I don't think that next or prev are correct, even with that pov
[15:03] <lamalex> if you're at the top, the head, there should be no next
[15:04] <lamalex> picture yourself at the top of a flight of stairs, you can step down the the previous stair, but there is no next stair available
[15:04] <jelmer> lamalex, the steps down then are the "next" steps, as you are on your way down
[15:04] <jelmer> and the previous steps are the steps up as you have already passed them
[15:05] <lamalex> but if your steps were numbered, going "down" from 9 to 10 would be confusing
[15:05] <lamalex> and is
[15:06] <jelmer> I disagree, I don't think "next" implies an increasing number
[15:06] <lamalex> next implies forward motion
[15:06] <lamalex> at least when paried with previous
[15:06] <jelmer> and that's exactly how it is at the moment
[15:06] <lamalex> s/paried/paired
[15:06] <lamalex> no, it's reverse motion
[15:06] <jelmer> If you are on the first page from loggerhead, it's confusing to have to press "previous" to go to the next page of revisions
[15:07] <jelmer> it's forward motion since the direction you are going into is from the tip to the beginning of the branch
[15:07] <lamalex> no it's backward motion, you're just starting from the other end
[15:08] <jelmer> we are also showing the revision with the highest number on the top of the page and the one with the lowest number on the bottom
[15:08] <lamalex> well if you're looking at it in terms of pages it's forward but that's a silly perspective, you need to think in terms of revisions
[15:08] <jelmer> that would conflict with your reasoning as well
[15:08] <jelmer> anyway, I'm not a loggerhead developer so I can't make this decision but that's what my view on it is at least :-)
[15:09] <lamalex> :) like I said, even if they dont accept the patch I'd at least like acknowledgment by them
[15:09] <lamalex> it's not very encouraging to submit a patch and just be ignored
[15:10] <jelmer> lamalex, ping beuno or mwhudson_ here later today (they're most likely not around atm)
[15:10] <lamalex> Will do, thanks
[15:23] <Jc2k> jelmer: have you fixed any bzr-svn HTTP redirect related issues recently?
[15:23] <jelmer> Jc2k, fairly recently, yes
[15:24] <Jc2k> i have one where it is doing an OPTIONS on /$module/branches and then stopping looking after it hit a 302.
[15:24] <Jc2k> (bzr-playground_
[15:25] <jelmer> it should convert any svn redirect exceptions to bzr redirect exceptions
[15:25] <Jc2k> https://bugs.edge.launchpad.net/bzr/+bug/303959
[15:26] <jelmer> Jc2k, it was something similar to that that I fixed earlier
[15:26] <jelmer> Jc2k, have you tried 0.4.15?
[15:26] <Jc2k> i have 0.4.15dev0
[15:27] <CaMason> could somebody just explain the branching concept to me in this situation? I have a branch that I've bound to a central location. It's at /srv/bazaar/myproject/trunk. Let's say I now want to make a (svn branch) to build some features outside of the trunk..
[15:28] <CaMason> how would I go about that, and how does that relate to my original 'branch' (trunk)
[15:33] <Jc2k> jelmer: trying a 0.4.15 final tarball now..
[15:34] <jelmer> Jc2k, when cloning that branch, I get two messages saying http://bzr-playground.gnome.org/gtk%2B/branches/ is permanently redirected to
[15:34] <jelmer> but other than that it seems to work ok
[15:34] <Jc2k> jelmer: branch works, then a subsequent pull fails
[15:35] <CaMason> I believe I set up my central folder with --no-trees
[15:37] <Jc2k> CaMason: where to svn come in to this exactly?
[15:37] <CaMason> Jc2k: In my head, that's all. I'm used to SVN and I'm comparing to bazaar concepts to see how they differ
[15:37] <Jc2k> CaMason: publishing a branch to a server with a --no-trees repository is covered here: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html
[15:40] <jelmer> Jc2k, I think I found it
[15:40] <jelmer> Jc2k, bzr's RedirectRequested requires a full new URL whereas svn is only giving a relative one sometimes
[15:41] <CaMason> so, with reference to this section, how should I go about creating a /branches/mybranch1 'branch'? http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#choosing-a-shared-repository-layout
[15:41] <Jc2k> jelmer: ah.
[15:42] <CaMason> so I need to bzr-init branches bzr-init branches/mybranch1 ?
[15:42] <CaMason> do*
[15:42] <Jc2k> no need for bzr-init branches
[15:42] <CaMason> ok just make folder?
[15:42] <Jc2k> yep
[15:42] <CaMason> or not even that?
[15:43] <CaMason> ok nice. So, when I merge that particular branch with the 'trunk' branch, will the history move across also?
[15:43] <Jc2k> yes
[15:43] <Jc2k> make sure you did a bzr init-repo in the root folder
[15:43] <CaMason> great, so then I could delete the 'branched' branch
[15:44] <Jc2k> bzr init-repo myproject
[15:44] <Jc2k> bzr init-repo myproject/trunk
[15:44] <Jc2k> etc
[15:44] <CaMason> how can I check that?
[15:44] <Jc2k> whoops
[15:44] <Jc2k> 2nd command was meant to be just init *blush*
[15:45] <LarstiQ> CaMason: `bzr info`
[15:45] <CaMason> Shared repository with trees (format: pack-0.92)
[15:45] <Jc2k> jelmer: shall i reassign my bug to bzr-svn :)
[15:46] <CaMason> I thought I made my repository with --no-trees. Would that suggest otherwise?
[15:47] <LarstiQ> CaMason: yes, that suggests otherwise.
[15:47] <jelmer> Jc2k, already happened :-)
[15:48] <CaMason> ok I suppose I should fix this
[15:49] <Jc2k> =p
[15:49] <Jc2k> jelmer: and you fixed it already too :p
[15:49] <CaMason> sorry I'm slightly confused as to whether I need the no-trees options
[15:51] <LarstiQ> CaMason: if you don't care, either is fine.
[15:51] <CaMason> I'll pastie my layout
[15:51] <LarstiQ> CaMason: with trees disk size will be bigger.
[15:52] <jelmer> Jc2k, looks like it's not just bzr-svn though
[15:52] <Jc2k> jelmer: i thought i caught pycurl returning relative urls..
[15:53] <CaMason> Here's how I envisage my layout: http://pastie.org/327827
[15:54] <CaMason> would anybody be able to give me an idea of which commands I *should* be using?
[15:54] <LarstiQ> CaMason: bzr init-repo /srv/bzr/myProject;
[15:54] <zooko> Greetings, folks!  I'm trying to push a change to lp, and it says it can't because I'm using HTTP. How do I tell it to go ahead and use ssh, or whatever it is that it needed to push changes?
[15:54] <luks> zooko: how are you pushing it to lp?
[15:54] <LarstiQ> CaMason: trunk, branch1, branch2, and both releases would then just be branches
[15:55] <LarstiQ> CaMason: so either init, branch or push them to their location.
[15:55] <CaMason> LarstiQ: OK that makes sense. What about the 'containing' folders?
[15:55] <CaMason> so the 'branches' and 'tags' folders
[15:55] <LarstiQ> CaMason: the containing folders need no special treatment
[15:56] <LarstiQ> CaMason: either mkdir them on the server, or supply --create-prefix when pushing a branch
[15:56] <CaMason> LarstiQ: aha, thanks that's making sense now
[15:56] <LarstiQ> CaMason: they are just regular directories after all.
[15:56] <CaMason> yeah, that's what's causing me the confusion I think.. vs SVN :) I think directories are tidier. Seperates the history and 'branches' from the project structure
[15:57] <Jc2k> of course, you dont need the tags folder.
[15:57] <CaMason> no?
[15:57] <Jc2k> read bzr help tags
[15:57] <CaMason> will do
[15:57] <Jc2k> and bzr help tag
[15:57] <LarstiQ> the tags folder would be for svn style 'tagging', which is fine in itself, but not necessary.
[15:57]  * LarstiQ goes afk
[15:58] <CaMason> Ah i see
[15:58] <CaMason> I assume that would take up less disk space also?
[15:59] <Jc2k> i dont know about that kind of stuff :)
[15:59] <CaMason> ok thanks LarstiQ and Jc2k that's helped me a lot
[16:04] <zooko> luks: I think I should push over ssh.  Is that how things are done?
[16:04] <luks> zooko: I meant what command do you run?
[16:05] <luks> zooko: e.g. if you are using `bzr push lp:something`, you need `bzr launchpad-login USERNAME`
[16:05] <luks> zooko: but if you are using a full URL, just change the protocol
[16:05] <luks> (to bzr+ssh or sftp)
[16:06] <zooko> luks: Ah, thanks.
[16:06] <CaMason> I founf SFTP to be a very easy way to share projects :D
[16:06] <CaMason> found*
[16:07] <zooko> Hm.
[16:07] <zooko> HACL yukyuk:~/playground/pyOpenSSL/buildbinaries$ bzr launchpad-login zooko
[16:07] <zooko> HACL yukyuk:~/playground/pyOpenSSL/buildbinaries$ bzr push zooko@lp:~zooko/pyopenssl/buildbinaries
[16:07] <zooko> bzr: ERROR: Parent directory of zooko@lp:~zooko/pyopenssl/buildbinaries does not exist.
[16:07] <zooko> You may supply --create-prefix to create all leading parent directories.
[16:08] <zooko> I don't understand that error message.
[16:08] <jelmer> Jc2k, It's working here now; I've commented in the bug
[16:08] <jelmer> Jc2k, thanks for tracking this down
[16:10] <Jc2k> jelmer: no no, thank you :)
[16:16] <zooko> So, bzr apparently knows that I got the current working directory over HTTP.  How do I tell it that I am going to push it over ssh, so that I can do things like "bzr commit" without getting this error message: $ bzr commit
[16:16] <zooko> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Ezooko/pyopenssl/buildbinaries/.bzr/repository/lock): Transport operation not possible: http does not support mkdir()
[16:20] <james_w> zooko: "bzr bind lp:~zooko/pyopenssl/buildbinaries"
[16:20] <zooko> Thanks!
[16:21] <james_w> the "lp:" is writeable now because you did the launchpad-login, but it saved the http:// url to disk, "bind" just tells it to save the new (bzr+ssh://) url
[16:22] <zooko> Thanks.
[16:22] <zooko> Howdy abadger1999.
[16:22] <abadger1999> zooko: Howdy
[17:06] <marcoil> bzr-gtk asserts with brz-svn branches, is this known?
[17:08] <jelmer> marcoil, What command exactly?
[17:09] <marcoil> jelmer: I've tried visualize and gcommit
[17:10] <jelmer> marcoil, both work fine here - how does it assert?
[17:10] <marcoil> jelmer: bzr: ERROR: exceptions.TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
[17:10] <marcoil> do you want a traceback?
[17:10] <jelmer> are you using bzr 1.9 by any chance?
[17:11] <marcoil> jelmer: yes...
[17:12] <marcoil> I updated to get the latest bzr-svn
[17:13] <marcoil> jelmer: http://pastebin.be/15139
[17:13] <jelmer> There is a regression in bzr 1.9 wrt branch nicks, this appears to be causing what you're seeing
[17:15] <marcoil> also, I have a branch bound to the trunk of a svn repo and another one to a branch of it, but I can't merge between them. It can't find the common ancestor, is there some way of telling it?
[17:17] <jelmer> marcoil, in bzr-svn 0.4 it's only possible if the two branches are using the same "branching scheme"
[17:18] <marcoil> jelmer: I can't find much info on that...
[17:20] <jelmer> marcoil, To put it a bit simpler, if the branches are following the standard svn naming convention (trunk, branches/*) you should be fine
[17:21] <marcoil> jelmer: if I set both branches svn-branching-scheme, should that work?
[17:21] <marcoil> the repo is using the /project/trunk|branches/subproject scheme, btw
[17:22] <jelmer> marcoil: it will work in 0.4, but not without a lot of trouble (you'll need to set the branching scheme the same for both branches and probably re-fetch them)
[17:25] <marcoil> jelmer: is there any info on the format of svn-branching-scheme? I've changed it but now I get "is not a valid Subversion branch path"
[17:26] <jelmer> marcoil: see bzr help svn-branching-scheme
[17:26] <jelmer> that's pretty much all there is
[17:27] <marcoil> jelmer: that doesn't say a lot, just that there's one named "none" :(
[17:27] <marcoil> jelmer: thanks for the pointers, anyway
[17:28] <jelmer> well, branching schemes are gone in 0.5, so I haven't put a lot more work into documenting them
[17:28] <marcoil> jelmer: oh, that's great. Will that work with old svn servers, though? Also, should I update to 0.5?
[17:29] <jelmer> yeah, it should work with old svn servers as well (>= svn 1.2)
[17:29] <jelmer> 0.5 is still in development, although it should be fairly stable
[17:29] <jelmer> I hope to make a stable release around christmas
[17:32] <marcoil> jelmer: I'll try with 0.5, then
[17:34] <marcoil> jelmer: is there a package of it somewhere?
[17:34] <jelmer> marcoil: no, it's all bleeding edge (lp:bzr-svn/0.5, and required bzr >= 1.10rc1)
[17:35] <jelmer> marcoil, also, there's an open bug dealing with older roundtripped revisions ("bzr push" into svn using bzr-svn 0.4.x)
[17:35] <marcoil> jelmer: then not for production use, I guess :) Well, I'll look a little at the branching schemes and if not I'll just merge manually for now. Thanks again!
[17:35] <jelmer> marcoil, n/p
[17:47] <visik7> anyone using bzr on a mac ?
[17:47] <visik7> is it good is it bad ?
[18:31] <marcoil> jelmer: I finally solved it using a branch list :)
[18:33] <marcoil> jelmer: the only problem has been losing the connections with previous local branches I had
[18:44] <jelmer> marcoil, yeah, that's the main problem with branching schemes
[18:45] <marcoil> jelmer: does that mean that every time I add a branch to the list I'll lose the connections?
[18:46] <jelmer> marcoil, yes
[18:46] <marcoil> argh...
[19:16] <awmcclain> Is there a way to un-bzr remove a file?
[19:16] <awmcclain> I keep getting the error that it's not a versioned path...
[19:19] <Tak> revert or merge to a revision where it existed?
[19:31] <nevans_> I especially like the "Any Workflow": http://whygitisbetterthanx.com/  ;-)
[19:34] <cr3> hi folks, how can I increase verbosity for bzr? I'm getting a connection refused error message behind a proxy but I can't even see where/how it's attempting to connect to lp
[19:34] <nevans_> cr3: not sure, but you might get lucky by looking into ~/.bzr.log
[19:35] <cr3> nevans_: it just shows the output I got from the command line
[19:40] <cr3> no matter whether I set the https_proxy or http_proxy environment variables, I still get: connect(4, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("91.189.90.218")}, 16) = -1 ECONNREFUSED (Connection refused)
[19:40] <cr3> nevans_: strace seems to be the debug flag
[19:42] <nevans_> sorry, I've never had to use it behind a proxy...
[19:42] <nevans_> cr3, "bzr help global-options" says something about -Dhttp
[19:42] <nevans_> dunno if that would help
[19:43] <james_w> cr3: are you using "lp:something" when you get the error?
[19:44] <cr3> james_w: yes
[19:45] <james_w> cr3: that's a bug in python that it doesn't use the http_proxy for xmlrpc
[19:45] <james_w> cr3: you can work around it by using the expanded URL
[19:45] <james_w> bzr+ssh://bazaar.launchpad.net/whatever
[19:46] <cr3> james_w: cheers, http://code.launchpad.net also works just for branching, which might be sufficient for the person I'm helping
[19:46] <cr3> james_w: I was just telling that person that I've encountered problems with some python libraries when dealing with https proxies
[20:07] <jam> mm-mysql__: ping
[20:07] <mm-mysql__> mm-mysql__: pong
[20:07] <mm-mysql__> Wow...two underscores
[20:07] <mm-mysql> That's better
[20:08] <jam> Good to see you around.
[20:09] <jam> Just thought I'd see how things are going, and if you would be interested in getting together some time soon
[20:09] <mm-mysql> Things are good, other than some thugs knocked down our post light Friday night, and broke all four legs on one of our reindeer decorations :P
[20:10] <mm-mysql> But sure, getting together would be great...what are you thinking? Lunch, or?
[20:11] <jam> you don't live on reindeer alley, right?
[20:11] <jam> Sorry to hear about the vandalism.
[20:11] <jam> Lunch would be fun.
[20:12] <mm-mysql> jam: Okay, let me look at the calendar, and then talk to the social coordinator (the wife), so I don't schedule something when she thought I'd be home...Give me a day or so to pick some possibilities?
[20:12] <jam> sounds good
[20:12] <jam> My noon-time is generally open
[20:12] <jam> though I'll probably be away the week of the 15th or so.
[20:13] <mm-mysql> Okay, noted.
[20:13] <mm-mysql> Working at home sometimes actually *complicates* the schedule :)
[20:13] <mm-mysql> (people get used to you being around)
[20:16] <jam> :)
[20:29] <lifeless> hi jam
[20:29] <jam> hi lifeless, are you in Mountain View?
[20:30] <lifeless> not yet
[20:30] <lifeless> fly tomorrow
[20:39] <zdobersek> I have a question about moving from SVN to Bazaar. The svn repository is quite big, almost 400 megabytes, and there are also about 40k revisions. As far as I tried to complete the move, I saw Bazaar gets data about every single revision and then applies that data one by one. This get _very_ slow on a repository that big, at least in the way I try to do it - so far I've tried with "bzr checkout" (which gets even slower when downloading data f
[20:39] <lifeless> vila, bug 255687, I'm not sure its a log issue?
[20:40] <lifeless> zdobersek: your text cut off at "when downloading data f"
[20:40] <zdobersek> I'll reposte it in parts.
[20:41] <zdobersek> Or at least the last part.
[20:41] <zdobersek> This get _very_ slow on a repository that big, at least in the way I try to do it - so far I've tried with "bzr checkout" (which gets even slower when downloading data from a web server) and "bzr svn-import", but both take an enormous amount of time. Is there any faster way or should I leave my computer on and processing for the night?
[20:41] <lifeless> if you want to migrate, I suggest using 'bzr svn-import'
[20:42] <lifeless> this will convert all your branches at once. And yes, leave it running overnight, if that what it needs
[20:57] <Peng_> zdobersek: What version of bzr-svn?
[20:58] <Peng_> zdobersek: FWIW, older versions of bzr-svn might leak a lot of RAM on a repo that large.
[20:58] <zdobersek> Peng_: 1.6.1
[20:58] <Peng_> zdobersek: That's bzr, not bzr-svn. Check "bzr plugins".
[20:59] <zdobersek> Peng_: 0.4.13
[21:00] <Peng_> OK. Carry on then.
[21:07] <lifeless> robertc@tungsten:~$ ./test-mem python 50 500 1000 2000 2500 3000
[21:07] <lifeless> 50,746876,33720.086226
[21:07] <lifeless> 500,727064,6420.87136602
[21:07] <lifeless> 1000,819836,4832.82598305
[21:07] <lifeless> 2000,806848,3699.43931794
[21:07] <lifeless> 2500,708820,3237.27468991
[21:07] <lifeless> 3000,736232,3597.21533608
[21:08] <lifeless> Peng_: ^
[21:08] <lifeless> flattens out around 2500
[21:09] <lifeless> Peng_: I *think* its noise on the last three
[21:13] <lifeless> Peng_: I think I'll bump it to 1500 which seems to be well past the 'too small' size, and doesn't use *more* silly-scale-more memory on python than '50' does.
[21:49] <jam> lifeless: what is that test?
[21:50] <lifeless> jam: group_size,peak_memory_kb,time for bzr index
[21:52] <Peng_> Erk, 700-800 MB to index Python? Fun.
[21:54] <jam> lifeless: that is the "bzr search" index time, right?
[21:54] <Peng_> jam: Right.
[21:55] <jam> It is, indeed, interesting that the memory consumption goes down a little bit with increased group size
[21:55] <jam> probably depends on exactly how the keys fit together
[21:56] <lifeless> jam: it uses repo.make_mpdiffs
[21:56] <lifeless> jam: so that peak is likely actually revno 1
[21:59] <jam> lifeless: it doesn't help that make_mpdiffs combines and re-splits all the lines
[21:59] <jam> it uses _get_lf_split_line_list
[21:59] <jam> which does
[21:59] <jam> [StringIO(t).readlines() for t in self.get_texts(version_ids)]
[21:59] <jam> so it reads everything into lists of lines (because that it how knits work)
[21:59] <jam> then combines them together to create a single string per text
[21:59] <jam> then breaks them back up again into lines
[22:00] <jam> It *might* only hold the reference to one at a time
[22:01] <jam> so you get 2x the mem of a single text, but not 2x the mem of all texts
[22:01] <lifeless> indeed
[22:02] <lifeless> I think its size(tree) + size gzip-records-for-group-size
[22:14] <lifeless> jam: standup?
[22:14] <lifeless> poolie: ^
[22:14] <jam> I was wondering if poolie and/or spiv were around today, but I believe spiv is away
[22:15] <lifeless> poolie is
[22:18] <spiv> jam: yeah, I'm away this week (despite my habit of hanging around on IRC...)
[22:20] <bpierre> hi
[22:21] <jam> lifeless: poolie doesn't seem to be answering, how about if I start it and just call you
[22:22] <lifeless> sure
[22:25] <jam> oh, I should actually mention the other big problem with _get_lf_split_line_list is that get_lines is capable of allowing similar texts to re-use the same actual strings
[22:26] <jam> but that code will force them to be unique strings
[23:00] <flacoste> i'm trying to write a script that uses bzrlib to extract some information from the current branch
[23:00] <flacoste> is there some high-level document to explain the major operations
[23:00] <flacoste> for example, how do I get the branch associated with the current working directory
[23:00] <lifeless> flacoste: there is stuff on the wiki about the api
[23:00] <lifeless> flacoste: and the programmers guide too
[23:00] <flacoste> lifeless: i've looked around, but nothing at that level
[23:01] <flacoste> the HACKING file seems more about process than anything eles
[23:01] <lifeless> flacoste: can you describe the level you are looking for?
[23:01] <flacoste> task-oriented
[23:01] <flacoste> or the major API
[23:02] <flacoste> i read the plugin documentation
[23:02] <flacoste> but it only describes the metadata or plugin structure
[23:02] <lifeless> there is http://bazaar-vcs.org/Classes which is a conceptual overview of the most important object
[23:02] <flacoste> that might be interesting
[23:02] <flacoste> i looked at the api doc
[23:02] <flacoste> but it's hard to grasp where are the handles into the framework
[23:02] <lifeless> and http://bazaar-vcs.org/WritingPlugins
[23:03] <lifeless> and http://bazaar-vcs.org/Integrating_with_Bazaar
[23:03] <flacoste> bingo
[23:03] <flacoste> that last one is what i was looking for
[23:03] <flacoste> exactly what I was looking for
[23:03] <flacoste> thanks a lot!
[23:03] <beuno> and, it's in the bzr tree as well
[23:04]  * beuno hasn't updated that in a while...
[23:06] <lifeless> flacoste: anything you need added or spend time figuring out is a bug in some form
[23:06] <lifeless> flacoste: 'pydoc bzrlib.foo' should always be reasonably useful as well
[23:07] <flacoste> ok
[23:07] <lifeless> (need added - I am referring to docs about stuff)
[23:09] <flacoste> yep
[23:12] <flacoste> any quick way to determine if a working tree doesn't contain any change?
[23:12] <flacoste> or do I have to check all of treedelta attributes?
[23:12] <flacoste> has_changed()
[23:12] <flacoste> ?
[23:12] <lifeless> yes
[23:12] <lifeless> actually changes_from is an old api
[23:13] <lifeless> most things use iter_changes now
[23:13] <lifeless> tree.iter_changes(tree.basis_tree())
[23:13] <flacoste> which is undocumented
[23:13] <lifeless> its very much documented :)
[23:13] <flacoste> well, not according the apidoc
[23:13] <lifeless> pydoc bzrlib.tree.Tree.iter_changes
[23:13] <flacoste> on startship mwh at least
[23:14] <lifeless> oh ugh, that isn't showing up
[23:14] <lifeless> let me see
[23:14] <lifeless> its a doc bug
[23:14] <lifeless> pydoc bzrlib.tree.InterTree.iter_changes
[23:14] <flacoste> ok
[23:15] <flacoste> and btw, "Integrating with Bazaar" says: There are two methods for comparing trees: changes_from and iter_changes. iter_changes is more regular and precise, but it is somewhat harder to use
[23:15] <flacoste> the last part doesn't especially makes we want to look :-)
[23:15] <lifeless> it lies :)
[23:15] <lifeless> anyhow
[23:16] <lifeless> if you want to know what commit considers a no-change, you have to do a commit; if you want to know if there are no changes that diff would show, len(list(iter_changes)) == 0 will do it
[23:16] <lifeless> if you want what status does, you need to check len(tree.get_parent_ids()) == 1 and len(list(iter_changes)) == 0
[23:17] <lifeless> flacoste: (what are you trying to do?)
[23:17] <flacoste> find the files i need to lint
[23:17] <flacoste> either the ones modified in the working tree
[23:18] <flacoste> or if the working tree is clean
[23:18] <flacoste> all modified files from the submit: target
[23:18] <lifeless> ok
[23:18] <lifeless> filter iter_changes for objects with the file_kind[1] element == 'file'
[23:19] <lifeless> e.g.
[23:19] <lifeless> for change in iter_changes:
[23:19] <lifeless>     if change[2] and change[6][1] == 'file':
[23:20] <lifeless>         lint(tree, change[0])
[23:20] <flacoste> change[0] is?
[23:20] <lifeless> [2] is the content_changed flag, [6] is the kind tuple, and [0] is the file_id
[23:21] <flacoste> lint needs a file path
[23:21] <lifeless> lint() is a python function
[23:21] <lifeless> :)
[23:21] <flacoste> right :-)
[23:21] <lifeless> tree.id2path(file_id) will give you a relpath
[23:21] <flacoste> cool
[23:21] <lifeless> tree.abspath(tree.id2path(file_id)) will give you an abspath
[23:21] <lifeless> change[1][1] is also the relpath
[23:22] <lifeless> so you could do lint(tree, change[1][1])
[23:22] <lifeless> asssuming you did
[23:22] <lifeless> iter_changes = tree.iter_changes(other_tree)
[23:22] <flacoste> for the record, i agree that this api is harder to use :-)
[23:22] <poolie> hello
[23:22] <lifeless> change[1][0] is the path in other_tree, change[1][1] is the path in tree
[23:23] <flacoste> a lot of magic numbers in here
[23:23] <lifeless> flacoste: we'd like to use named tuples, but they are soooo slooooow
[23:23] <flacoste> i understand why you are using it
[23:23] <lifeless> hi poolie
[23:23] <flacoste> but in the integration story, that concerns isn't that important
[23:24] <lifeless> flacoste: true enough; changes_from will remain supported for a long time I think, there is little motivation to remove it, and as you say its easy for simple things to use it
[23:24] <flacoste> great, and thanks for getting going!
[23:26] <poolie> jam, ilfeless, today i was planning to at least make info and reconfigure deal with stacked branches
[23:26] <poolie> i'm more sure i can get that done today than i am for michael's bug
[23:30] <jam> poolie: can't you just revert spiv's change?
[23:30] <jam> I'm pretty sure you diagnosed it correctly.
[23:31] <jam> Also, you should note that abentley also hit the bug and reported a dupe
[23:31] <poolie> ok
[23:31] <poolie> yes, i'm also going to revert the caching bug
[23:31] <poolie> i was referring to some of the stacking related ones
[23:31] <jam> ah, ok
[23:31] <poolie> what are you up to for the rest of this week?
[23:31] <jam> I'm open to suggestions, but I was going to try to work more on the CHK code
[23:32] <lifeless> jml: ping if you're around
[23:32] <jam> starting with making sure things always preserve canonical form
[23:33] <spiv> +1 for reverting my caching hack, FWIW.
[23:33] <jam> (atm, I don't believe unmap() does, and I think map() can also fail if the node's size changes dramatically.)
[23:33] <spiv> (I really should teach irssi not to highlight my name in work-related channels when I'm on leave...)
[23:33] <jam> spiv: I'm amazed at how responsive you are to a tiny pink number :)
[23:34] <jam> I at least get an audible notification
[23:34] <jam> anyway, I'm done for tonight. Catch you guys later
[23:38] <poolie> markh, i'll ping our admin people again
[23:38] <markh> poolie: thanks
[23:40] <poolie> markh, thanks for fixing up the compiler on kerguelen
[23:41] <poolie> did you build 1.10rc1, or should i?
[23:41] <markh> np - the full vs2008 is still installing actually
[23:42] <markh> I haven't actually built anything on that box yet - it sounds like John would prefer to wtick with mingw - although I also suspect bug 303941 is related
[23:46] <markh> poolie: did you or john make the existing ones?
[23:46] <poolie> john
[23:51] <Peng_> lifeless: How large were the search indexes for Python?
[23:51] <lifeless> Peng_: dunno the script delete's them :)
[23:51] <Peng_> Oh, right.
[23:52] <lifeless> indexing it manually, tell you in 6420 seconds
[23:53] <Peng_> Hmm, if it takes 6420 seconds, and uses 700 MB of RAM, it could actually be cheaper to download prebuilt indexes.
[23:59] <lifeless> 08:06 < lifeless> 50,746876,33720.086226
[23:59] <lifeless> 08:06 < lifeless> 500,727064,6420.87136602
[23:59] <lifeless> 08:06 < lifeless> 1000,819836,4832.82598305
[23:59] <lifeless> 08:06 < lifeless> 2000,806848,3699.43931794
[23:59] <lifeless> 08:06 < lifeless> 2500,708820,3237.27468991
[23:59] <lifeless> 08:06 < lifeless> 3000,736232,3597.21533608
[23:59] <lifeless> so we have tradeoffs