[12:29] <lifeless> moin moin AfC
[12:29] <AfC> lifeless: Gutten tag
[12:33] <AfC> So I've had it bashed into me that revisions (in Bazaar speak) are not patches (in the Darcs sense of the word) but rather state markers, which explains somewhat why attempting to cherry pick "a revision" makes no sense in bzr
[12:34] <igc> morning all
[12:35] <lifeless> hi igc
[12:35] <AfC> I am, however, still left with the ... desire ... to backport a series of patches which happen to be uniquely identified by the revision (in pseudo Bazaar speak revision-1..revision I guess)
[12:35] <igc> hi lifeless
[12:35] <lifeless> AfC: right, we have 'before:REVISION' as a way to grab the delta from the left most parent of a revision to the revision
[12:36] <AfC> and wondering how to actually articulate this. Is `bzr merge --force -r $whatever` for a series going to work?
[12:36] <AfC> before:
[12:36] <AfC> huh
[12:36] <lifeless> bzr help revisionspec
[12:37] <luks> there is also -c in 0.92
[12:37] <AfC> lifeless: I gotta tell you that that page isn't as helpful as you gentleman and ladies seem to think it is. It makes perfect sense as a reference once you already know what everything there does.
[12:37] <lifeless> oh hmm, before: doesn't give you a delta, it just gives you the -1
[12:37] <luks> which is just before:R..R
[12:37] <lifeless> luks: only in some commands
[12:39] <AfC> lifeless: although I suspect I feel that way because I still find myself fighting the definition of a revision versus the change that happens between that revision and its predecessor.
[12:41] <AfC> Ah. So `bzr diff -r before:374..374` is what I need to type when I'm mentally thinking "bzr diff -r 374"
[12:41] <AfC> Hm
[01:10] <jelmer> AfC: or "bzr diff -c 374"
[01:10] <jelmer> argh, I should read backlog
[01:10] <jelmer> never mind me
[01:11] <AfC> jelmer: :)
[01:11] <AfC> that's ok
[01:11] <AfC> I was actually about to dig to find out what -c was short for
[01:40] <lifeless> bbiab, train.
[02:55] <igc> lifeless, poolie, spiv: my plan for today is reviews, reviews, reviews
[02:56] <igc> any preferences on order?
[03:12] <igc> reviewing the Repository.is_write_locked patch now
[03:18] <lifeless> back
[03:18] <lifeless> no mail or browser for now;
[03:34] <poolie> hello
[03:34] <jml> hello poolie
[03:44] <i386> lifeless: http://wiki.mozilla.org/JavaScript:ActionMonkey
[03:45] <ubotu> New bug: #152811 in bzr "typeerror in globbing.match" [Medium,New]  https://launchpad.net/bugs/152811
[03:49] <lifeless> i386: your project?
[03:49] <i386> no
[03:49] <i386> useful for mine
[03:50] <lifeless> ah
[03:50] <i386> its basically a JIT engine for JS
[03:50] <lifeless> cool
[03:50] <poolie> hello jml,
[03:50] <poolie> i386
[03:50] <i386> due out for FF 4
[03:50] <i386> hey poolie
[03:51] <lifeless> spiv: yo
[03:51] <spiv> lifeless: yoyo
[03:52] <lifeless> reconcile performance; are you across that or want to talk?
[03:52] <spiv> lifeless: I seem to have it running tolerably quickly, at the expense of memory.
[03:53] <spiv> lifeless: (15 minutes, 700MB for bzr.dev @ revno 2000)
[03:53] <lifeless> 700MB wow
[03:53] <lifeless> thats immense
[03:53] <spiv> Yeah.
[03:53] <lifeless> where is it all going
[03:54] <spiv> That's a good question.  I haven't dug; I'm not sure how much of that is the explicit caching I do of get_text_version/get_inventory/get_parents/get_heads, and how much is lost elsewhere (the transaction?).
[03:58] <spiv> I can probably improve the memory consumption by clearing the get_text_version cache after checking a file-id.
[04:08] <spiv> lifeless: most of the memory appears to be due to holding all the inventories in memory.
[04:09] <lifeless> the actual inventories, or the summary you create ?
[04:09] <lifeless> the former is huge, the latter should be significantly smaller
[04:11] <spiv> Hmm, I was just dumbly holding onto the actual inventory.
[04:29] <spiv> Reading in ~14000 inventories takes a while.
[04:29] <spiv> Memory use seems a lot more reasonable on this run, though.
[04:31] <spiv> (Also, strace shows lots of calls to open the inventory.knit file, and to our good friend futex...)
[04:31] <lifeless> you should use the iter_inventories or even iter_inventories_delta calls
[04:33] <spiv> lifeless: I can't seem to find those
[04:39] <spiv> lifeless: memory use now down to about ~110MB.
[04:40] <lifeless> yay tuning
[04:41] <spiv> Hmm, it's creeping up a little, but I doubt it'll exceed ~130MB.
[04:41] <spiv> I think that's good enough for now.
[04:41] <lifeless> iter_revision_*
[04:42] <spiv> iter_rev_trees?
[04:43] <lifeless> probably
[04:43] <lifeless> will open the inventory knit less often
[04:43] <lifeless> and be massively faster
[04:43] <AfC> poolie: ping
[04:44] <spiv> It's down to 6m37s already with the memory consumption reduced.
[04:44] <spiv> I'll try out iter_rev_trees now.
[04:44] <poolie_> spiv: hi
[04:45] <poolie_> afc, hi
[04:45] <AfC> poolie: regarding 139478, I think we hit it last weekend when trying to do bzr push (!) ... the remote repo would suddenly stack trace and then we had to remote break-lock
[04:45] <poolie_> bug 139478
[04:45] <ubotu> Launchpad bug 139478 in bzr "UnlockableTransport running update in checkout of readonly branch" [High,Triaged]  https://launchpad.net/bugs/139478
[04:46] <poolie_> so, not with that awn branch?
[04:46] <spiv> lifeless: repo.revision_trees actually :)
[04:49] <AfC> poolie_: no, it was 0.91
[04:50] <poolie_> i mean, i presume you were using bzr on your own branch, which is unrelated to the awn window manager?
[04:54] <AfC> poolie: (correct)
[04:58] <AfC> poolie: I got him to c&p the stack trace; I'll see if I can get him to post it somewhere.
[04:58] <AfC> poolie: anyway, just FYI
[05:05] <ubotu> New bug: #152826 in bzr "order-dependent test failure in test_add_reports" [Low,Confirmed]  https://launchpad.net/bugs/152826
[05:05] <lifeless> igc: new version up
[05:07] <spiv> (and lunch)
[05:08] <poolie> thanks afc, it's useful to know it's not just that branch
[05:08] <spiv> lifeless: saved another 40s.  5m 37s/120M to reconcile ~14000 revisions now.  I think that's good enough; I'll mail the list.  Thanks for your help.
[05:08] <lifeless> np
[07:22] <lifeless> uhm seriously
[07:22] <igc> yes ...
[07:24] <lifeless> I can't see your review yet
[07:24] <lifeless> oh nope, there it comes
[08:10] <lifeless> igc: one thing comes to mind, but I don't know if the code is clean enough yet to tackle
[08:11] <lifeless> igc: which is, when code working with a pack repo encounters NoSuchFile
[08:11] <lifeless> it should:
[08:11] <lifeless>   - refresh the pack-names list
[08:11] <lifeless>  - check if the file it couldn't access is one that belongs to a pack dropped from the list since it last read it
[08:11] <lifeless>  - if not, raise
[08:12] <lifeless>  - otherwise, add new packs, and drop the dropped packs as needed
[08:12] <lifeless> this should be bounded at the pack repository layer
[08:12] <lifeless> e.g. implemented by try: blocks in knit.PackAccess, knit.KnitGraphIndex, pack_repo.create_pack_from_pack
[08:13] <lifeless> this is the sort of error we'll see if that is not done:
[08:13] <lifeless> Using saved location: sftp://rookery/~/public_html/baz2.0/integration
[08:13] <lifeless> bzr: ERROR: No such file: u'/home/robertc/source/baz/.bzr/repository/packs/7790115835933f890290c0367db37b93.pack': [Errno 2]  No such file or directory: u'/home/robertc/source/baz/.bzr/repository/packs/7790115835933f890290c0367db37b93.pack'
[08:19] <lifeless> igc: call me on my moobile in 3 minutes?
[08:19] <lifeless> ~.
[08:40] <poolie> igc: ping?
[08:55] <igc> hi poolie
[09:52] <lifeless> poolie: any luck debugging ?
[10:00] <poolie> lifeless: no breakthrough yet
[10:01] <igc> poolie: you after me earlier?
[10:01] <lifeless> does my bzr work on your data?
[10:03] <mwhudson> wow, the packs branch has some crazy revnos :)
[10:03] <poolie> no, it doesn't
[10:03] <mwhudson> "changes from 2592.1.25.2.7.1.28.1.6.1.3.1.9.2.1.3.74.1.31.3.18.1.9.1.2.1.12.1.8.1.46.1.18.1.1.2.14"
[10:03] <lifeless> mwhudson: weeeee long lived branches
[10:03] <lifeless> mwhudson: is it faster  ?
[10:03] <poolie> i think we should truncate them when they get too long
[10:04] <poolie> lifeless: i'm trying to determine if there's actually a problem on disk
[10:04] <lifeless> poolie: I would do the following
[10:04] <lifeless> with my bzr branch
[10:04] <mwhudson> lifeless: not sure yet
[10:04] <poolie> or just in loading it in
[10:04] <lifeless> grab both repos
[10:04] <poolie> i think the problem has occurred in moving data from your pack branch into my knit repo
[10:04] <lifeless> then grab the same knit object from both
[10:05] <poolie> because in my other repo, the problem is not evident
[10:05] <lifeless> set intersection to get the versions in common
[10:05] <lifeless> then compare the raw_data blocks
[10:05] <lifeless> theres an api to give you the raw gzipped
[10:05] <lifeless> data
[10:05] <lifeless> one expects them to be the same, except if you've run andrew's reconcile
[10:06] <lifeless> aarons/andrews
[10:08] <lifeless> I'm calling it a day; you should head to that bbq :)
[10:12] <poolie> have a good night
[10:16] <mwhudson> lifeless: first impressions of loggerhead w/packs performance are pretty good
[10:17] <mwhudson> seems a bit faster than knits
[10:17] <lifeless> sweet
[10:18] <mwhudson> will measure and post numbers to the list later
[10:18] <igc> bbl
[10:27] <lifeless> mwhudson: thanks!
[10:27] <lifeless> night all
[10:29] <spiv> Looks like reconciling bzr.dev takes exactly 300MB of memory.
[10:34] <poolie> hm, that's not so great
[10:34] <poolie> for larger trees
[10:37] <spiv> Yeah.  I suspect it can be better.  I'm hoping this is Good Enough for now.
[11:39] <mwhudson> hm, producing the annotate view of builtins.py with packs takes over two minutes
[11:48] <poolie> not so good
[11:48] <poolie> how about from the command line?
[11:52] <mwhudson> seems about the same
[11:52] <mwhudson> oh no, about a minute
[11:53] <mwhudson> still not exactly snappy :)
[12:13] <yogesh> hello, I have installed bzr through eclipse update manager. I am using eclipse3.1. After finishing successfully, when I go to preferences->team->bazar getting error,plug-in in " org.vcs.bazar.eclipse.ui"  was unable to instantiate class  org.vcs.bazar.eclipse.ui.bazarpreferences page
[12:31] <mwhudson> spiv: you forgot something
[12:40] <lifeless> mwhudson: expected fallout, for now
[12:41] <sabdfl> why is annotate slower with packs? is it because we no longer cache the relevant data?
[12:47] <spiv> mwhudson: oh?
[12:47] <spiv> mwhudson: oh, gar.
[01:37] <yogesh> hello, I have installed bzr through eclipse update manager. I am using eclipse3.1. After finishing successfully, when I go to preferences->team->bazar getting error,plug-in in " org.vcs.bazar.eclipse.ui"  was unable to instantiate class  org.vcs.bazar.eclipse.ui.bazarpreferences page
[01:42] <Odd_Bloke> Verterok: ^ is related to you, I think?
[03:07] <abentley> mwhudson: ping
[03:08] <mwhudson> abentley: hi
[03:08] <abentley> Did you get my mail?
[03:09] <mwhudson> oh, about loggerhead/cart integration?
[03:09] <mwhudson> yes
[03:09] <jdub> lifeless: http://www.cs.lth.se/home/Calle_Lejdfors/pygpu/
[03:09] <abentley> mwhudson: Any suggestions about the right approach?
[03:11] <abentley> I assume you want loggerhead to remain independant of Cart.
[03:11] <mwhudson> abentley: no particular feelings
[03:11] <mwhudson> abentley: yes
[03:11] <mwhudson> abentley: do you think you'll be making changes to loggerhead itself, or just plugging its views in somewhere?
[03:13] <abentley> Well, I expect to make some changes.  How much will depend on Loggerhead's data model.
[03:14] <sabdfl> where can i find the best pack branch for testing?
[03:16] <abentley> sabdfl: http://people.ubuntu.com/%7Erobertc/pack-repository.knits/ is the latest in knit format
[03:16] <sabdfl> thanks abentley
[03:16] <mwhudson> abentley: bits of the code will probably make your eyes hurt :)
[03:16] <abentley> Once you have that, there's a pack version that's more up-to-date.  But I forget where that is.
[03:17] <mwhudson> ~robertc/baz2.0/repository i think
[03:17] <abentley> But you prolly have to bootstrap with the knit version.
[03:17] <mwhudson> on the same server
[03:17] <Peng> http://people.ubuntu.com/%7Erobertc/baz2.0/repository/
[03:17] <Peng> Err, right.
[03:18] <abentley> mwhudson: Yeah, no worries.
[03:18] <abentley> I think I'll start by just importing loggerhead, and see how far I get.
[03:18] <mwhudson> abentley: let me know of any particular problems you find
[03:19] <abentley> Okay, will do.
[03:19] <mwhudson> abentley: so you're aware, i plan to redo the css and general look pretty soon
[03:19] <mwhudson> and at some point redo the templates in genshi
[03:20] <mwhudson> and maybe dump turbogears, though i'm not so sure about that
[03:20] <mwhudson> cherrpy has it's annoying bits
[03:20] <abentley> Okay.  I have mixed feelings about genshi.  I really don't like what they did with match rules
[03:20] <abentley> But the error handling is lots nicer.
[03:20] <mwhudson> and it appears to not have "being extremely slow" as a design goal :)
[03:23] <abentley> Anyhow, I should get back to work, but thanks for the chat.
[03:27] <mwhudson> abentley: no worries, sorry for not replying to the mail
[03:28] <abentley> mwhudson: no worries.
[03:32] <GaryvdM> Hi
[03:33] <GaryvdM> I've been thinking about how to solve the can't update a remote tree problem
[03:34] <GaryvdM> I put an idea together, and would like to get some opinions.
[03:34] <GaryvdM> Very brief spec here:  http://bazaar-vcs.org/DraftSpecs/RestingTree
[03:54] <sabdfl> jdub: that pygpu stuff looks awesome
[03:56] <johndo> Is there a way to have bzr include cvs style headers in files?
[03:58] <jdub> sabdfl: almost worth buying nvidia!
[04:03] <johndo> is there a way to get bzr to support ident?
[04:26] <sabdfl> abentley: once i've merged in the pack stuff from those two addresses, how do i upgrade or create a repo in pack format?
[04:28] <abentley> sabdfl: Use --format=experimental with init/upgrade/init-repo
[04:31] <sabdfl> thanks abentley
[05:12] <Solarion> pardon my ignorance, but I have the following scenario I need to make work: I have a branch of an svn repo, and a body of code (and revision history) I wish to merge into it.  How do I go about doing so?
[05:12] <Solarion> "body of code" is in bzr
[05:18] <Solarion> nobody?
[05:19] <Odd_Bloke> Solarion: You'll want to look at bzr-svn.
[05:20] <Solarion> Odd_Bloke: the svn portion is more or less irrelevant.  bzr's support of svn is supoerb.  The problem is that I want to merge in a new sub-project into a larger project, complete with its revision history.
[05:21] <Solarion> (the svn part is there for completeness, and as a wrinkle in case svn messes up. :)
[05:24] <Odd_Bloke> Solarion: OK, I'm not entirely sure what you're asking and am not familiar enough with bzr-svn to know how to go about much.
[05:25] <Odd_Bloke> If jelmer were about, he'd be the person to ask...
[05:25] <Solarion> Odd_Bloke: The foremost matter would be how to merge two disparate codebases without losing revision history
[05:25] <Lo-lan-do> Odd_Bloke: I think jelmer is hiding from me...
[05:26] <Odd_Bloke> Solarion: TBH, I'm not sure if it's possible.  _However_, I don't want to make that statement because I'm not sure.
[05:26] <Solarion> Odd_Bloke: that would make me sad.  :(
[05:27] <Solarion> hey bratsche
[05:28] <bratsche> Hi Solarion
[05:40] <Solarion> merging two disparate branches would be a nice feature, FWIW
[06:00] <ubotu> New bug: #152974 in bzr "merge should allow merging in a wholly new codebase" [Undecided,New]  https://launchpad.net/bugs/152974
[06:13] <Solarion> yeah, that one's mine.  :)
[06:33] <Solarion> So why am I getting errors from a failed operation?
[06:33] <Solarion> it only seems to happen when I have -r0..-1, as recommended in the bug
[12:00] <abdelrahman> hello
[12:00] <abdelrahman> I have a question
[12:00] <abdelrahman> can bazaar restrict access to the code by username and password?
[12:02] <jam-laptop> abdelrahman: we generally do that using the system permissions