[00:00] <bialix> poolie, jam: how mysql team working with mainline?
[00:00] <malibu> show a pastebin of what?
[00:00] <jam> bialix: they don't
[00:00] <bialix> jam said their branches are bushy
[00:00] <jam> they don't worry about a separate mainline
[00:00] <jam> sorry, a "specific mainline"
[00:00] <poolie> malibu: is this on windows or unix?
[00:00] <jam> but it doesn't seem to be a problem
[00:00] <malibu> client on windows, server on ubuntu
[00:01] <bialix> jam, poolie: theoretical questions: if bzr will have command-line option to not generate dotted revnos but show merged revisions -- does it will help?
[00:02] <malibu> bialix: Here is my output:  http://pastebin.com/m634fe87e
[00:02] <bialix> if dotted revnos is source of slowdown, then show only revid for merged revs might help?
[00:02] <jam> bialix: it depends if you continue to preserve the merge info
[00:02] <jam> if you want the "show merges just before the revision which merged them and after the one that did not"
[00:02] <jam> it doesn't help
[00:03] <poolie> bialix, the main problem i know of with our approach is this, that numbering them is either slow or needs to be cached
[00:03] <poolie> though, i do think we need to do more to help people work well with undisciplined developers
[00:04] <jam> poolie: so there are other options, like 'date sorted'
[00:04] <bialix> IIUC jam trying to say dotted revnos is part of problem?
[00:04] <poolie> jam: just a flat list, sorted by date?
[00:04] <poolie> it could be worthwhile
[00:04] <jam> bialix: dotted revnos + merge  sorting requires loading the whole graph
[00:04] <jam> poolie: right
[00:05] <bialix> jam: and only merge sorting?
[00:05] <jam> bialix: no merge sorting
[00:05] <jam> sorry I should revise
[00:05] <bialix> if only merge sorting
[00:05] <poolie> bialix: as we're going through history, we want to see whether a revision should be shown as 'merged by r100'
[00:05] <jam> merge sorting requires loading the whole graph
[00:05] <igc> morning
[00:05] <jam> while we do that, we compute dotted revnos
[00:05] <poolie> doing this requires checking whether it was merged by any previous revision
[00:05] <jam> hey igc
[00:05] <poolie> hi igc
[00:05] <igc> hi jam, bialix, poolie
[00:05] <jam> good to see you
[00:05] <bialix> ok, thx for explanation
[00:05] <jam> I've got a couple questions for cvs2bzr + fast-import
[00:06] <igc> jam: fire away
[00:06] <bialix> igc: hi
[00:06] <jam> igc: With just copying the cvs2bzr-example.options, I ended up getting a 'commit per branch' to "create the branch"
[00:06] <jam> which is necessary in svn, but obviously not bzr
[00:07] <bialix> jam: so hg have natural sort order based on the order revisions come into repo?
[00:07] <jam> bialix: it is 'topological sorted'
[00:07] <jam> but yeah
[00:07] <jam> when merging it fetches some revisions
[00:07] <jam> that is the order
[00:08] <lifeless> bialix: and in hg the sort can be different between different repos
[00:08] <bialix> jam: ok, understand
[00:08] <bialix> lifeless: I see
[00:08] <poolie> i wonder if it is strictly guaranteed to be topo sorted
[00:08] <bialix> so mainline concept in bzr is also about achieving consistency between different similar barcnhes?
[00:08] <poolie> if they ever get a ghost-like condition that may be broken
[00:09] <lifeless> they have a single file - the 'revision revlog', which is indexed by integers - the 'insertion order' in the repo.
[00:09] <jam> igc: is there a way to disable it?
[00:09] <poolie> bialix: yes, i think if you have two mirrors of the same conceptual branch, they should have consistent numbering
[00:09] <bialix> poolie: AFAIK hg does not support ghost
[00:09] <poolie> i don't think that is guaranteed true in hg
[00:09] <igc> jam: I don't know whether that behaviour is controlled by options or just core cvs2fastimport behaviour. I suspect the latter
[00:09] <jam> igc: so the problem with what I'm converting
[00:09] <lifeless> their log and other operations that show ordering just start at revno=len(revisions.revlog), then count down.
[00:09] <jam> is that they seem to create a lot of branches from the same rev
[00:10] <jam> so the repo has 200+ branches, and like 100 are off of one rev
[00:10] <lifeless> poolie: its not guaranteed true in hg; two branches with the same tip can have different revnos
[00:10] <lifeless> both for the tip, and for antecedents
[00:10] <poolie> right
[00:11] <bialix> poolie: word "mainline" in the real life is about railroads? highways?
[00:11] <igc> jam: the guy to ask is Michael Haggerty
[00:11] <jam> igc: so we might just do trunk only conversions, but we'll see
[00:12] <bialix> all dictionaries I've looked so far is rather confusing about this term
[00:12] <igc> jam: bzr-fastimport itself looks for unique heads and only creates branches for those
[00:12] <igc> jam: well it's meant to at least
[00:12] <jam> igc: well, cvs2bzr is creating fake commits for the branches...
[00:12] <jam> though perhaps it only looks that way because I was just converting part of a module?
[00:12] <jam> not sure
[00:13] <igc> jam: ok, that that certainly sounds like something we want fixed in cvs2bzr
[00:16] <bialix> poolie: may I ask last question? do you read UQDS document from divmod.org?
[00:16] <poolie> bialix, yes, from railroads
[00:16] <poolie> or heroin ;-)
[00:17] <poolie> http://en.wiktionary.org/wiki/mainline
[00:17] <bialix> poolie: does it true to say their workflow is roughly equivalent to mainline paradigm?
[00:17] <poolie> bialix: i have a while ago, let me look
[00:17] <lifeless> bialix: they are dealing with svn :P
[00:18] <poolie> i think that's broadly the type of flow that bzr encourages though
[00:18] <bialix> lifeless: yes, but they insist on having a lot of feature branches
[00:18]  * bialix will omit heroin meaning in the article
[00:19] <bialix> fullermd also said mainline comes to bzr from Arch, is it correct?
[00:21] <bialix> igc: how your experiments with windows installer?
[00:22] <igc> bialix: it's my top priority this morning - just scanning email first
[00:22]  * bialix going to sleep, see ya later
[00:23] <bialix> poolie, jam: thanks for help
[00:29] <zsquareplusc> someone have experience with bzr on sf.net? is it possible to store several, unrelated branches there (sub-projects)?
[00:31] <jelmer> poolie: yeah, sure
[00:57] <poolie> lifeless: any comments on bug 424797?
[00:58] <poolie> sorry bug 429747
[01:00] <spiv> Good morning.
[01:01] <spiv> poolie: I have hpss userdir expansion working now
[01:02] <spiv> poolie: It's working nicely in manual testing, I have two small things left to do before submitting it,
[01:04] <spiv> poolie: a) change chroot.py to reuse the path filtering decorator, because it's very similiar; b) add some testing for the uglier bits of the ~ expansion logic (and for the way it is glued into serve_bzr)
[01:04] <poolie> hello spivvo
[01:04] <poolie> cool
[02:20] <poolie> lifeless: do you think you fixed bug 403322 implicitly with the delta fixes?
[02:35] <lifeless> poolie: I doubt it
[02:58] <SamB> jelmer: where is the new bzrtools package ?
[03:06] <naoki_> I'm currently translating user guide to Japanese.
[03:06] <naoki_> Some document assume default format is not rich-root.
[03:07] <naoki_> filtered_views.txt: Bazaar's default format does not yet support filtered views.
[03:08] <naoki_> svn_plugin.txt: Note that using the ``default-rich-root`` option to ``init-repo`` is important
[03:27] <lifeless> jam: are you around ?
[04:05] <lifeless> igc: The batching that fast import does
[04:05] <lifeless> igc: does it hold more than 1 inventory in memory?
[04:05] <igc> lifeless: yes
[04:06] <igc> lifeless: up to 10 from memory
[04:06] <lifeless> igc: are they Inventory or CHKInventory objects ?
[04:06] <igc> it's a cache of configurable size
[04:06] <lifeless> as in, are they what the repository creates, or a separate object?
[04:07] <lifeless> igc: I'm [still] working on analysing the memory use from the fast import that hit the wall
[04:07] <lifeless> igc: so far I've determing taht there are several hundred 90K long containers in the memory dump
[04:07] <igc> lifeless: I'd need to check. What the repo creates I believe
[04:08] <lifeless> igc: did you see the gzip stuff I cc'd you on?
[04:08] <igc> lifeless: bzr_commit_handler builds deltas and gets the new inventory back from the layer below IIRC
[04:08] <igc> lifeless: yes. looks interesting.
[04:09] <lifeless> igc: ok
[04:10] <igc> lifeless: I'm hoping to get back on to fastimport bug fixing next week
[04:10] <lifeless> I'm fairly sure something is leaking, and 914662 is the ref list length, which is unlikely to be coincidental
[04:10] <lifeless> (900K, not 90K :P)
[04:10] <igc> lifeless: this week I'm still fighting windows installers
[04:10] <lifeless> yup
[04:16] <lifeless> mmm, I am again reminded of why I dislike ORM's. :(
[04:48] <cody-somerville> whats the name of that branch option that makes it so that you can only append to a branch
[04:49] <cody-somerville> ie. it prevents the scenario where you branch, commit, merge parent, and then push to parent overwriting it
[04:53] <fullermd> cody-somerville: append_revisions_only
[05:06]  * igc lunch
[05:48] <SamB> jelmer: oh, and it looks like bzr 2.0 packages should conflict with bzr-doc ?
[06:25] <igc> out for a medical appointment - bbl
[06:37] <lifeless> poolie: did you get my draft yesterday?
[06:49] <poolie> hi
[06:51] <bialix> igc: ping
[06:54] <bialix> igc: the problem with win32event has no simple solution. you have to build full installer with tbzr on kerguelen to see the real result
[06:54]  * bialix bbl, I'll read irclogs
[07:34] <vila> hi all
[07:55] <poolie> vila: hi
[07:55] <poolie> are you looking at all at the issue of conflicts caused by deleting directories containing ignored files?
[07:56] <vila> all the issues I don't know, but all the conflicts including those of this type certainly
[07:59] <vila> poolie: do you still plan to review shell-like tests ? I have some improvements already done on top of the pending patch...
[08:03] <vila> poolie: including a better execution model, globbing, 'rm' command
[08:03] <vila> poolie: and counting :)
[08:06] <poolie> vila, maybe i'll do it now
[08:06] <vila> ok
[08:08] <WanderNauta> Hi.
[08:08] <WanderNauta> I'm new to version control, and I have a question.
[08:09] <poolie> vila, can you help me triage the New bugs?
[08:09] <poolie> not all right now, just a few a day
[08:09] <WanderNauta> After going through some basic tutorials, it looked like with Bazaar, you need to run a command for every file you add.
[08:09] <WanderNauta> Is there some option that looks for changed/new/removed/moved files automatically?
[08:09] <vila> poolie: sure
[08:11] <poolie> WanderNauta: 'mv --auto' and then 'add' with no arguments will add the new files
[08:17] <bialix> poolie: is it possible to have simple fix for setup.py merged to 2.0.0?
[08:19] <bialix> poolie: this one: https://lists.launchpad.net/bzr-windows/msg00149.html
[08:19] <bialix> it's required only for bzr.exe
[08:19] <WanderNauta> @poolie Thanks.
[08:19] <bialix> if you don't think it suitable before release, I don't bother to prepare merge request
[08:20] <bialix> and bonjour vila
[08:21] <poolie> hi bialix
[08:21] <vila> hi Alexander
[08:21] <bialix> hi poolie, again
[08:21] <bialix> hi Vincent
[08:22] <poolie> bialix: it looks reasonable to me
[08:22] <bialix> so I'll do the merge request now
[08:24] <bialix> igc: around?
[08:24] <igc> bialix: hi - just got back
[08:24] <bialix> hi
[08:24] <bialix> hi igc
[08:25] <bialix> have problem with your build recipe
[08:25] <igc> bialix: feel free to change it
[08:25] <bialix> igc: http://pastebin.com/m63eea6fe
[08:25] <bialix> it blow up on bzr-explorer
[08:26] <bialix> Error: Abort uninstalling, because of pending local changes.
[08:26] <bialix> bzr st in explorer/trunk branch is clean
[08:26] <bialix> igc: am I missing something?
[08:27] <bialix> I've got this error while running make as of revno 15 over existing build-win32
[08:27] <bialix> sidnei: are you here?
[08:27] <bialix> something wrong
[08:27] <bialix> I did not see this before
[08:28] <igc> bialix: I suspect it's a problem but not one I know how to solve
[08:28] <bialix> are you adding uninstall action?
[08:28] <igc> bialix: I certainly don't understand how the uninstall actions hang together, why they exist, what they do, etc.
[08:28]  * bialix trying to remove build-win32 and starting from scratch
[08:29] <igc> bialix: I think that will work but ...
[08:29] <igc> it may be quicker to go into build_win32 ...
[08:29] <bialix> everything worked for me at weekend
[08:29] <igc> and then into explorer/trunk
[08:29] <igc> and then run pull manually
[08:30] <igc> bialix: I've been doing something like that instead of digging into the uninstall stuff
[08:30] <bialix> vila: do you remember yesterday we talked about wt format?
[08:31] <vila> bialix: yes, you think you can fix it ?
[08:31] <bialix> branching over http works fine
[08:31] <bialix> do you know why?
[08:32] <bialix> I've just found that my 2.0.0 branch was cloned from http://bazaar.launchpad.net/~bzr-pqm/bzr/2.0.0/ and it was in correct wt format
[08:32] <bialix> maybe that branch has actual wt?
[08:32] <bialix> but bzr info -v http:// does not say so
[08:32] <vila> bialix: no idea, except that http use VFS
[08:33] <bialix> igc: I've removed build-win32 and still have the same problem
[08:34] <bialix> igc: that said that now I'm unable to build installer at all
[08:34] <bialix> igc: you'd better disable this uninstall stuff
[08:34] <bialix> igc: err, wait
[08:34] <igc> bialix: I'm not sure what to do - I never touched the unistall stuff
[08:35] <igc> bialix: I really think we need sidnei to help us here
[08:35] <bialix> no, EPEBKAC
[08:36] <bialix> it seems working, I've ran wrong command
[08:36] <bialix> working now after deleting entire build-win32
[08:44] <bialix> poolie: https://code.launchpad.net/~bialix/bzr/2.0.0-setup.py-qbzr-deps/+merge/11767
[08:51] <igc> bialix: I'm heading off for the day sorry
[08:52] <bialix> igc: bye
[08:52] <igc> bialix: please ping sidnei if the installer still has issues. Hopefully he can help us get them sorted
[08:52] <bialix> he's from South America?
[08:54] <bialix> igc: stuff seems to working now, from scratch
[08:55] <poolie> heading home soon
[08:57] <poolie> bialix: is it at all possible jam would object to it?
[08:57] <poolie> i don't expect so
[08:57] <poolie> bialix: yes, sidnei is in brazil i think
[08:57] <poolie> Rio Grande del Sul?
[08:57] <poolie> see https://edge.launchpad.net/~sidnei
[08:57] <bialix> poolie: I think everything is possible
[08:57] <poolie> :)
[08:58] <bialix> poolie: eta fro 2.0 final?
[08:58] <bialix> poolie: eta for 2.0 final?
[08:58] <poolie> soon, maybe tomorrow
[08:58] <poolie> i'd like to see if we can do the web site first but maybe we can freeze the code, get that up, then announce it?
[08:58] <bialix> poolie: this fix is not strictly required, as I've mentioned in revision commit message
[08:59] <bialix> poolie: it will be very nice to have it, but not critical
[09:09] <spirov92> hey guys. If I have 2 branches of a website-one on my machine and one on the server- and want them to have different database config files, how do I do that? do I just not version them?
[09:09] <Coke> Hi! I'm using sftp as proto on a server a long long time ago in a galaxy far far away, but it's rather slow. The process of commiting 30-50k worth of text takes about 1m, including connecting and uploading. Is there a faster/better protocol?
[09:10] <Coke> spirov92: usually you don't have site or user specific configurations in the repos
[09:10] <spirov92> ok, thanks
[09:11] <spirov92> so how do I exclude a file from versioning without deleting it?
[09:13] <Coke> spirov92: bzr ignore <filename>
[09:13] <Coke> or pattern
[09:15] <spirov92> I did bzr ignore application/config/database.php..
[09:16] <spirov92> "These files will continue to be version controlled unless you 'bzr remove' them."
[09:16] <spirov92> and when I modify the file and do bzr diff, it shows the changes
[09:33] <vila> spirov92: bzr rm <file> --keep
[09:33] <vila> grr, gone
[09:35] <Coke> Odd.
[09:36] <Coke> I think ignore should do whatever it takes to actually ignore the file
[09:36] <Coke> OR they should rename it to "ignore-maybe"
[09:36] <Coke> it's counter intuitive and unproductive with the extra step of removing the file
[09:48] <jelmer> SamB_XP: there is a bzrtools package in experimental
[09:48] <jelmer> SamB_XP: bzr-doc ?
[11:30] <fullermd> vila: It's quite unfair of you to not be getting errors   :|
[11:30] <vila> fullermd: yeah, so totally unfair :-/
[11:31] <fullermd> MP maybe?  My 7.x box is 2-core, and 8.x is 4-core.  It doesn't seem overly likely that that would matter, would it?
[11:31] <fullermd> The tests are sequential...
[11:32] <vila> MP leading to revision not found, wow, you're truly desperate :)
[11:32] <vila> my VM is 4 cores
[11:33] <fullermd> I can't imagine how it would, since (a) any given test is sequential, and (b) it's so stupidly perfectly repeatable.
[11:33] <fullermd> But yeah, desperate   :p
[11:33] <LarstiQ> f00f bug?
[11:34] <fullermd> That was lockups, not VCS horkage   :p
[11:34] <fullermd> (and bzr _better_ not be doing floating point division, either...)
[11:35] <vila> endianess ?
[11:35] <fullermd> We're all little-endian.
[11:35] <vila> sadly, yes
[11:35] <vila> just checking
[11:36] <fullermd> I wonder if anybody IS running bzr big-endian.  SPARC I guess.  AIX guys maybe?  Isn't RS/6000 big-endian.
[11:36]  * LarstiQ has retired his ppc :(
[11:37] <vila> RS/6000 is power-era old I believe, so probably
[11:37] <vila> I have a BeBox...
[11:37] <fullermd> First *nix system I adminned was an RS/6000.  The scars are still quite visible.
[11:37]  * fullermd twitches.
[11:37] <vila> Pff, SunOS was worse I'm sure
[11:38] <fullermd> SunOS was a dream, relatively   :p
[11:38] <vila> ouch :)
[11:38] <vila> I did UUCP sendmail !
[11:38] <jelmer> moin *
[11:39] <fullermd> I certainly don't believe you have some magical data corruption causing tests to _pass_.  That would be nuts.
[11:39] <fullermd> And I know I don't causing them to fail.  It wouldn't be near so deterministic, and anyway I have ECC memory and ZFS with SHA256 block checksums.
[11:39] <fullermd> (if my data goes, I intend to KNOW about it)
[11:40] <vila> zfs...
[11:41] <fullermd> Timing issues?  Wouldn't be deterministic.  System libraries?  Ours should be near enough as no difference.
[11:41]  * fullermd frowns.
[11:42] <vila> racing issues with zfs sounds worth checking
[11:44] <fullermd> What race?  All it does is read the .py_ files.
[11:45] <vila> fullermd: if I knew I wouldn't want to try
[11:45] <fullermd> Temp files are gone so fast they'll never hit disk, and even if they did, they'd be read back out of the buffer cache.
[11:45] <fullermd> (and anyway, my /tmp is plain old md-backed UFS)
[11:45] <vila> all the tests run in /tmp
[11:45] <vila> md-backed ?
[11:46] <fullermd> Memory filesystem, swap backed (but it never needs to hit the swap)
[11:46] <fullermd> (well, memory block device actually)
[11:46] <vila> hmm, I didn't set that for freebsd, but I use it for jaunty
[11:48] <fullermd> Ordering?  No way, I can run any of them individually and get the same failure.
[11:49] <vila> !!!
[11:53] <fullermd> I guess I'll have to find time at some point to sit down with one of them and try single-stepping   :(
[11:53] <vila> fullermd: I'm trying to see if one is simpler than the others
[11:54] <fullermd> Well, the first one on the list is probably the obvious choice.
[11:54] <fullermd> blackbox.test_info.TestInfo.test_info_standalone
[11:54] <fullermd> I think the rest are per_whatever's, so there are lots of formats to loop through.
[11:54] <vila> blackbox tests are hard to debug because of the redirections (not all though)
[11:55] <vila> pfff, talk about LOCALIZATION DEFECT, seen the test in question ?
[11:56] <vila> 433 lines...
 sorry for yelling
[11:57] <LarstiQ> yeah, the info tests...
[11:57] <vila> ...besides, that defect localization, so there
[12:05] <vila> fullermd: can you try with a newly created user (just to rule out some more possible leaks)
[12:05] <vila> fullermd: running a single failing test should be enough
[12:06] <SamB_XP> but what if it doesn't fail!
[12:06] <SamB_XP> then he'll have to run *another* one!
[12:12] <jelmer> SamB_XP: ^
[12:12] <jelmer> SamB_XP: there is a bzrtools package in experimental
[12:12] <jelmer> SamB_XP: there is no bzr-doc package
[12:12] <SamB_XP> jelmer: there isn't ?
[12:12] <SamB_XP> than what was that thing I had installed ?
[12:15] <jelmer> SamB_XP: "rmadison bzr-doc" agrees
[12:16]  * SamB fires aptitude up
[12:16]  * SamB wonders why his computer rebooted almost 5 hours ago, anyway ...
[12:16]  * SamB thought he'd fixed that by making it clock down when it got hot ... but could it have been a power outage of some kind ?
[12:17] <SamB> jelmer: it's from bzr ppas
[12:19] <SamB> the available versions are, uh,
[12:20] <SamB> 1.18-1~bazaar1~jaunty1 and 1.18+4684+126~9.04
[12:21] <SamB> jelmer: and I am not seeing this experimental package you speak of
[12:22]  * SamB notices that the PPA packages of bzrtools are laxly versioned
[12:22]  * SamB tries one of those
[12:23] <SamB> (er, have laxly-versioned dependencies on bzr, that is)
[12:26] <SamB> ... heck, it apparently even loads ...
[12:26] <SamB> jelmer: so, you should really sync up with the PPAs somehow ?
[12:27] <SamB> in terms of what packages are built for bzr itself ;-)
[12:42] <jam> vila: did you land the setup.py change to the bzr/2.0.0 branch?
[12:42] <jam> (morning)
[12:42] <vila> morning jam !
[12:43] <vila> pqm'ed it when I said "I'll merge"
[12:43] <vila> something wrong with it ?
[12:43] <vila> jam: I thought you had an already full plate this week...
[12:43] <jam> I haven't seen it yet, and I'm hoping to have win32 installers for them to use
[12:44] <jam> vila: looks like it is just in pqm now
[12:44] <vila> jam: was about to tell you that :-) Just in front of yours
[12:44] <jam> I guess you said "ill merge" 20 min ago
[12:45] <jam> so about right
[12:45] <jam> vila: I'm just waking up
[12:45] <vila> jam: how are things going ?
[12:46] <vila> Running [ 0% 1 test(s) ] Current test: /home/pqm/bzr-pqm-workdir/home/2.0.0/bzr
[12:46] <jam> the training and such is going fine. It's pretty informal
[12:46] <jam> vila: I'm pretty sure the status line is completely borked :)
[12:46] <vila> :-D
[12:46] <vila> too bad....
[12:46] <jam> And now that we have no "[ascii]" tests, I don't usually have a good feel for when it will be done
[12:47] <vila> jam: well, you feel it's faster at least :)
[12:47] <jam> vila: sort of... it is still something you send out and then forget about by the time you get the success/failure message
[12:54] <jam> vila: of course, while all of this is going on, igc and bialix are changing the installer, and how we build the installer, and ...
[12:54] <jam> It is all good in the end
[12:54] <jam> but painful for me
[12:55] <jam> even stupid stuff like now we depend on "doc.bazaar-vcs.org" for the pre-compiled help files
[12:55] <jam> which means I have to add the doc.bazaar-vcs.org to the hosts file so that it can be found
[12:55] <vila> :-/
[12:55] <jam> for some reason buildout is *really* slow (maybe just the machine?)
[12:56]  * vila is still slowly setting up a windows dev env as automatically as possible...
[12:57] <jam> vila: is bug 424913 a wishlist or a won't fix?
[12:59] <vila> a wishlist
[12:59] <vila> The wish is that the error message could say:
[12:59] <vila> revno 10000 does not exist, the last revision is: YYYY
[12:59] <vila> which might work as well.
[12:59] <vila> comment added there
[13:03] <jam> vila: And my point is I don't think we are going to ever do that...
[13:03] <SamB> huh, so much for multi-pull -q :-(
[13:03] <jam> the issue is where are you strict about input, because it indicates typos
[13:04] <jam> the actual desire of the person in that bug is to have resumable fetch...
[13:04] <vila> jam: you can be strict and displays an informative message
[13:04] <jam> anyway, still trying to get 2.0.0rc2 built, but I have to go get some food
[13:05] <SamB> jam: that person is me, btw
[13:05] <vila> SamB should speak with bialix who wants to implement a multi-step push/pull
[13:05] <vila> SamB: *I* know :)
[13:05] <jam> vila: imo, we should change the internal to just fetch 1k revs at a time... but certainly it can be implemented otherwise
[13:05] <vila> SamB: Let jam wake up peacefully please
[13:05] <SamB> it was so wierd to slowly realize that he was talking about me ;-)
[13:06] <vila> oops forgot a smiley there
[13:06] <vila> jam: I missed the discussion but bialix seemed to think the consensus that this will not happen, or not soon
[13:07] <jam> SamB: I don't see how any of this would block a "multi-pull -q"
[13:07] <jam> If you have a command that ones to pull a bunch of branches
[13:07] <SamB> jam: that was an unrelated statement
[13:07] <jam> have it connect, find the last revision, and then split it up
[13:07] <SamB> I said that before I noticed you had been talking about me ;-)
[13:07] <SamB> I said it because it's not all that quiet ...
[13:09] <SamB> ... even if I give it /dev/null for stdin and pass stdout and stderr through cat :-(
[13:10] <fullermd> Ew.  I'm not cleaning THAT litterbox...
[13:10] <SamB> well, I'm rather pleased that that didn't affect it
[13:10] <SamB> but displeased that it was not quiet
[13:10] <vila> SamB: file a bug
[13:11] <vila> with at least the strings that escape your humt :)
[13:11] <SamB> vila: well, I guess I'd better try the latest first to make sure
[13:11] <vila> hunt, damn it
[13:11] <SamB> my hunt ?
[13:12] <vila> track ? redirecting stind because -q does not work sounds like "output hunting" to me :)
[13:12] <SamB> oh, I thought maybe you were suggesting that I ought to look inside ...
[13:12] <vila> feel free to hunt where you see fit...
[13:13] <SamB> hmm, "push -q" with no explicit target isn't quiet either
[13:17] <SamB> okay
[13:18] <SamB> somebody seems to be trying to use my uncylclopedia account ?
[13:18] <SamB> (maybe they thought it was theirs ?)
[13:31] <jam> vila: http://pqm.bazaar-vcs.org/
[13:31] <jam> I see [ascii] tests running...
[13:31] <jam> maybe it wasn't "fixed" on the 2.0.0 branch?
[13:33] <vila> 8-) Ouch, fixed in trunk after 2.0 splitted I guess
[13:34] <vila> err, that was 8-(
[13:39] <fullermd> Isn't that intentional?
[13:40] <vila> fullermd: the typo or the [ascii] tests ?
[13:40] <fullermd> The ASCII tests.
[13:42] <vila> The constraint was relaxed because the botnet took charge.
[13:42] <vila> They have been deactivated in trunk only (jam, I just checked, still active in 2.0 and 2.0.0)
[13:43] <fullermd> Yah, but I thought I remembered it coming up in the discussion to explicitly choose conservative for 2.0.
[14:13] <lifeless> jam: lp:~lifeless/meliae/db
[14:18] <emmajane> igc, ping?
[14:18] <emmajane> igc, I'm just reviewing your changes trying to understand why you've changed a lot of the work that I'd already put into the Wiki as links for the footer?
[14:19] <beuno> emmajane, hi
[14:20] <emmajane> beuno, hey
[14:20] <beuno> emmajane, I have not caught up on all the emails
[14:20] <beuno> but, how's the web going?
[14:20] <beuno> do you need any more designer foo?
[14:20] <emmajane> beuno, I still need the buttons done. There's no photoshop file though. It's all in the branch.
[14:21] <beuno> emmajane, have you talked to Danno, is it on it's way, etc?
[14:21] <emmajane> beuno, What I emailed on Friday is the last email I sent about the project. I was travelling this weekend.
[14:21] <emmajane> beuno, and today is my first day back in the office.
[14:21] <emmajane> (which is what I said in the email...)
[14:22] <beuno> emmajane, ok, cool. Email me and CC Danno about what you need, and I'll chase it up
[14:22] <emmajane> thanks.
[14:22] <beuno> I'm off again wed-fri, but I can peak at email every now and then
[14:23] <emmajane> seems to be a common time to take off. :)
[14:23] <emmajane> are you in London now?
[14:23] <beuno> emmajane, no, Madrid. Will land in London on Sat
[14:23] <emmajane> nice!
[14:24] <beuno> well, "nice" is a very flexible word...
[14:25] <emmajane> heh. Oh dear. :/
[14:25] <beuno> I mean, what kind of country has 2 sunny days a year?  :)
[14:26] <emmajane> LOL
[14:26] <emmajane> canada. ;)
[14:27] <emmajane> England.
[14:27] <emmajane> Ireland.
[14:27]  * emmajane could go on....
[14:27] <beuno> ok, I'll rephrase
[14:27] <beuno> what kind of country that I have to go to 4 times a year...
[14:27] <beuno> :)
[14:28] <emmajane> hehe
[14:28] <emmajane> What's in Madrid that you're going four times a year?
[14:29] <beuno> London is the 4 times a year
[14:29] <beuno> Madrid has great weather
[14:29] <emmajane> ahhh, right.
[14:29] <beuno> I haven't worn shoes since I got here
[14:29] <emmajane> heh
[14:36] <vila> beuno: from Madrid to London, feel free to stop at Strasbourg :-)
[14:36] <beuno> vila, I was actually in Paris for 4 days!
[14:37] <beuno> I thought of pinging you, but it didn't look very close on the map  :)
[14:37] <vila> hehe, far closer now with TGV but still...
[14:54] <fullermd> Ah well, ports freeze beat 2.0.0.
[14:55]  * Tak <3 tgv 
[14:56] <vila> Tak: where are you from ?
[14:57] <vila> fullermd: you didn't inject 2.0rc1 ? :)
[15:26] <Tak> vila: I'm from florida
[15:36] <garyvdm> Hi bialix.
[15:36] <bialix> Hi Gary
[15:36] <bialix> how do you do?
[15:37] <garyvdm> Good and you?
[15:37] <garyvdm> bialix: If Bug 423201 is still a problem, I can talk you through debugging it.
[15:38] <bialix> garyvdm: I've made screenshots for you
[15:38] <bialix> I think you saw it
[15:39] <bialix> but then I've deleted those branches
[15:39] <bialix> garyvdm: if you think you fixed them again, it's fine
[15:40] <bialix> but I think we'd like to write some tests in some future
[15:40] <garyvdm> bialix: Yes - I fixed the one problem(that the branch is not expanded), but I was not able to reproduce the 2nd (label shows on wrong rev).
[15:40] <garyvdm> Ok - cool
[15:40] <bialix> maybe vila will be interested to help
[15:40] <garyvdm> Hmm - a test for that wont me to hard.
[15:40] <bialix> garyvdm: I have backup of that repo
[15:40] <garyvdm> *be
[15:41] <bialix> if you want I can provide you it privately
[15:41] <garyvdm> I think it is fixed..
[15:42] <bialix> garyvdm: I found that different parameters of qlog command line have different impact
[15:42] <bialix> maybe that's why you were unable to reproduce
[15:42] <bialix> garyvdm: thanks for fixing it, anyway!
[15:42] <garyvdm> bialix: Do you mean the order that branches are specified?
[15:43] <bialix> yes, something like that
[15:43] <garyvdm> bialix: The order affects what it thinks is trunk, but it should not affect the labels.
[15:43] <bialix> at least there is clearly difference between running qlog b a vs qlog over shared repo in the other bug report
[15:44] <bialix> garyvdm: this is my impression too, but sometimes I'm just don't understand what's going on
[15:44] <garyvdm> Yes - for qlog b a, trunk=b, but for qlog ., trunk=a
[15:45] <garyvdm> err - no,  but for qlog ., trunk=none, hence dates are used.
[15:46] <bialix> garyvdm: btw, one idea about missing labels
[15:47] <bialix> if you collapse merged branch tip its blue label becomes hidden
[15:47] <bialix> and it's almost impossible to know where it hidden
[15:47] <garyvdm> ok
[15:47] <bialix> garyvdm: maybe in this case we can show some hint?
[15:48] <garyvdm> or not allow you to collapse it.
[15:48] <bialix> maybe we need to show something to say: look here: something hidden inside
[15:48] <bialix> not allow to collapse? I guess it will be hard to implement, no?
[15:48] <garyvdm> No - easy
[15:49] <bialix> or something like that
[15:50] <garyvdm> bialix: I was thinking about how we add non-versioned files in qcommit.
[15:50] <bialix> and?
[15:51] <spirov92> I'm trying to do branch /htdocs/myproject/ ftp://myproject.com/ but how should I supply the username&password?
[15:51] <garyvdm> If we were to add non-versioned files immediately when the are checked, and remove added files when they are unchecked, this would give us some wins...
[15:52] <vila> spirov92: user:pass@myproject.com is the direct way, look at authentication.conf for something a bit more secure
[15:52] <spirov92> vila: thanks
[15:53] <vila> spirov92: authentication.conf is described in the doc
[15:53] <garyvdm> It would fix diff for checked non-versioned files. Checked non-versioned would be remembered.
[15:53] <vila> spirov92: bzr rm <file> --keep
[15:54] <vila> spirov92: you quit before I could replied this morning
[15:54] <garyvdm> bialix: What do you think about that?
[15:54] <spirov92> oh, thanks
[15:55] <bialix> garyvdm: hmmmmmmmmmmmmmmm
[15:55] <bialix> garyvdm: how fast it will be?
[15:55] <garyvdm> bialix: as fast a bzr add, which is instant.
[15:55] <bialix> garyvdm: me personally thinks will be much simpler to fix or internal diff behavior and teach it about planned add
[15:56] <garyvdm> bialix: I was thinking about the message template stuff too.
[15:56] <vila> spirov92: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#authentication-settings
[15:57] <vila> oh no, he's gone again :-(
[15:57] <garyvdm> vila: :-(
[15:57] <vila> bialix: since we talk about that yesterday, see what happens just now with spirov92 ?
[15:58] <garyvdm> bialix: But I think I have a solution for that now. Bouncing ideas is good.
[15:58] <bialix> garyvdm: if you think it will not slow down us (and I seriously doubt about it) then ok
[15:58] <bialix> vila: sorry? I've not watched carefully
[15:58] <vila> never mind
[15:58] <bialix> vila: but anyway excuse moi s'il vous plait
[15:58] <vila> :-)
[15:59] <bialix> garyvdm: what is bouncing idea?
[15:59] <vila> either: "Excusez-moi s'il vous plait" or "Excuse-moi s'il te plait" :-D
[15:59] <garyvdm> bialix: What I was doing now. Telling you about ideas.
[15:59] <vila> bialix: you just bounced ideas back and forth with garyvdm
[16:00] <vila> he says: "What if...", you reply "Yes, but..." etc
[16:00] <vila> the idea goes back and forth bouncing
[16:00] <bialix> vila: ok, "Excusez-moi s'il vous plait"
[16:00] <bialix> vila: my francais is definitely is not good
[16:00] <bialix> bear with me
[16:00] <vila> I do :)
[16:01] <bialix> sorry guys, a bit busy now
[16:01]  * bialix bbl
[16:07] <vila> bialix-webinar: staying connected like that is waaaaay better even if you don't reply than *not* being connected at all :D
[16:08] <bialix-webinar> vila: I guess I need 24/7 IRC proxy to be 100% accessible to you
[16:09] <spirov92> I'm trying to create a branch by ftp, but I get this error:
[16:09] <fullermd> bialix-webinar: He could hire you as a butler instead; that would work too  ;)
[16:09] <spirov92> Transport error: FTP temporary error during APPEND /var/www/html/new/.bzr/repository/upload/5jmrc2341kekjwb6e0il.fetch.Aborting. 451 /var/www/html/new/.bzr/repository/upload/5jmrc2341kekjwb6e0il.fetch: Append/Restart not permitted, try again
[16:09] <vila> not me in particular, but quite often you ask a question and leave before I or other can answer or you're not there when we want to ask you a question :-) so 24/7 is a bit high but 8-17 could be a good compromise :)
[16:09] <vila> ha spirov92 is back...
[16:10] <spirov92> yep
[16:10] <spirov92> so, can anyone help me?
[16:10] <vila> you quit before I can give you the url for the doc about authentication.conf
[16:10] <vila> spirov92: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#authentication-settings
[16:10] <spirov92> thanks :)
[16:10] <LarstiQ> spirov92: the ftp server is configured in a nasty way
[16:11] <spirov92> so, what can I do to fix it? :P
[16:11] <vila> now, Append/Restart not permitted means the server doesn't support a feature needed by bzr, 'try again' is a bit silly since there is little chance that it will change unless you can contact the admins
[16:11] <vila> spirov92: are you the ftp server admin ?
[16:11] <spirov92> no
[16:12] <vila> ask him to allow APPEND
[16:12] <spirov92> ok
[16:12] <vila> or better, ask him to install bzr and ssh so you can use bzr+ssh:// instead ftp:// you'll get far better performances
[16:14] <fullermd> Or at the least support SFTP.  It makes me weep that FTP still exists outside of very special cases   :|
[16:15] <vila> fullermd: not everybody knows how to *install* sftp you know, in some parts of the world it's not even part of the *base* system :-P
[16:16] <fullermd> Well, in some parts of the world they don't have running water either.  FTP shouldn't be given a chance to get a foothold there   :p
[16:17] <vila> hehe, I'm afraid they'll get Linux before BSD there :D
[16:18] <fullermd> I'm pretty sure every major Linux dist ships with working SFTP support these days.  So that'll tide them over.
[16:19] <vila> *support* doesn't mean installed by default, hence my initial remark...
[16:19] <vila> I wasn't joking about third world but about cheap ISPs instead...
[16:20] <LarstiQ> fixing https://bugs.edge.launchpad.net/bzr/+bug/409615 would help
[16:20] <fullermd> Oh, I'm pretty sure it does.  If it's got OpenSSH, and hasn't taken moderately serious steps to avoid it, it's got SFTP.
[16:20] <LarstiQ> well, not help against ftp actually
[16:20] <fullermd> And I don't think any of the dists ship ssh.com's ssh stuff.
[16:20] <LarstiQ> fullermd: the subsystem is disabled on a number of dists
[16:20] <fullermd> It...   what?  Why the spit?
[16:20] <LarstiQ> fullermd: that, and really cheap hosts don't give you ssh
[16:21] <vila> It's a cultural thing, people still thinks that ftp is easier to install/manage than sftp
[16:21] <fullermd> Sure, but you can give sftp without letting them have a shell.  I didn't know about default-disable though.  That sounds positively antediluvean.
[16:22] <fullermd> Plunk them lunkskulls in front of a firewall config that tries to be reasonably tight and allow FTP to work for a few days, that'll learn 'em.
[16:22] <vila> fullermd: You're preaching the choir ! It's not a technical problem :D
[16:22] <vila> Ha, I see, you're getting it and are in the concrete proposal phase now
[16:23] <fullermd> Right, that's why we choose means carefully.  Technical problems call for technical solutions; social problems call for mass murder   :p
[16:23] <vila> LOL
[16:23] <fullermd> Darwin will win in the end.  Sure, it may be a pyrrhic victory, but the 17 people left alive in the world will have a peaceful time.
[16:23]  * vila enjoy launghing again without his rib hurting, that;'s the best news of the week :-D
[16:26] <vila> well, at least for me it is :D
[16:27] <fullermd> "... so Adam said, 'What can I get for a rib?'"
[16:28] <vila> ...a good laugh ?
[16:29] <fullermd> Old joke.
[16:29]  * fullermd pulls up Google.
[16:29] <fullermd> http://www.azarajokes.com/pe-What+can+I+get+for+a+rib%3F-1400-140000-210.htm
[16:30] <vila> I was close enough...
[16:30] <garyvdm> lol
[16:33] <vila> http://www.alexshalman.com/2007/10/02/what-kind-of-woman-can-i-get-for-a-rib/
[16:33] <vila> that one is more explicit :)
[16:34] <spirov92> hey, I branch'ed a local branched to an sftp server, but only the .bzr folder is created. How do I make the actual files appear?
[16:34] <spirov92> &branch
[16:34] <spirov92> *branch
[16:34] <beuno> spirov92, bzr co .
[16:36] <spirov92> but the server doesn't have bzr. so can I do bzr co ftp://admin@mysite.com/ or something?
[16:37] <beuno> I... think not
[16:37] <beuno> spirov92, if you just want the contents, you can use the bzr-upload plugin
[16:37] <vila> spirov92: ',bzr' contains everything that is needed to create a branch
[16:38] <spirov92> beuno: yeah, that's an option too
[16:38] <vila> beuno, spirov92 " of course you can 'bzr co ftp://' but it will create a branch locally not the working tree remotely
[16:39] <vila> look at 'bzr help co'
[16:43] <naoki_> Hi.
[16:44] <naoki_> Little question about doc.
[16:44] <naoki_> 'Simple developer naming' in shared_repository_layout.txt,
[16:44] <vila> hi noaki !
[16:45] <naoki_> Does this mean only one branch per developer?
[16:46] <naoki_> hi vila.
[16:46] <vila> naoki_: where did you find that (for context) ?
[16:47] <beuno> vila, I think that's in docs/
[16:47] <vila> can't find a file named shared_repository_layout.txt there :-/
[16:47] <naoki_> yes, docs/en/user-guide/shared_repository_layout.txt
[16:48] <vila> missing 's' layouts, stupid emacs, can't fix obvious typos
[16:48] <naoki_> oh, sorry
[16:48] <vila> naoki_: not your fault :)
[16:48] <fullermd> Unless you're Richard Stallman.  Then it's totally your fault.
[16:49] <vila> naoki_: so, back to your question, no, in that layout there is no limit on the number of branches
[16:50] <vila> there is no limit to the number of levels in the hiearchy either,
[16:50] <naoki_> I get it.
[16:50] <naoki_> Thank you.
[16:50] <vila> you can, for example, add an intermediate level for groups above devs
[16:50] <vila> or even depts above groups, etc
[16:51] <naoki_> Japanese translation of user-guide is complete in near future.
[16:52] <vila> naoki_: Hurrah ! Congrats :D
[17:07] <vila> garyvdm: still around ?
[17:09] <garyvdm> hi vila
[17:10] <vila> https://code.edge.launchpad.net/~garyvdm/bzr/427773-2.0-unlock-when-limbo/+merge/11631
[17:10] <vila> garyvdm: poolie approved it but in bug comments, and I can't review it...
[17:10] <garyvdm> Ah - ok
[17:10] <vila> (I came across it while filing another bug)
[17:12] <vila> garyvdm: can you add another review request that I can use ?
[17:12] <vila> garyvdm: in that same mp
[17:12] <garyvdm> vila: Done. Here is superseded request: https://code.launchpad.net/~garyvdm/bzr/427773-2.0-unlock-when-limbo/+merge/11776
[17:13] <garyvdm> vila: Superseded because I discovered a mistake that I have fixed.
[17:13] <vila> ok, good enough, but you could have done it without... ok
[17:13] <vila> :)
[17:14] <vila> oh yes, the renamed test
[17:16] <pwolanin> Can anyone point me fo instructions for taking an existing source package in launchpad, then making my own version, and then getting it into a PPA so it will build?
[17:17] <vila> pwolanin: try #launchpad instead
[17:17] <pwolanin> ok, thanks
[17:17] <garyvdm> vila: I was not sure where to put the news entry.
[17:18] <vila> yeah, yeah, don't worry, still a work in progress, these NEWS sections in this new release branchesss
[17:18] <garyvdm> ok
[17:18] <vila> :)
[17:18] <garyvdm> vila: And Martin approved for 2.0.1, not for 2.0.0.
[17:19] <vila> I see, that's why you targeted 2.0 and that's where I will pqm it
[17:19] <garyvdm> vila: I'm not sure if 2.0.0 has been branched yet.
[17:19]  * garyvdm checks
[17:20] <vila> garyvdm: it has, I already landed a fix by bialix
[17:20] <garyvdm> Ok
[17:20] <bialix> vila: which fix?
[17:21] <garyvdm> ah lp:~bzr-pqm/bzr/2.0.0
[17:21] <vila> bzr log -l 12 lp:~bzr-pqm/bzr/2.0.0
[17:21] <vila> bialix: ^
[17:21] <vila> fix in setup for qbzr py2exe
[17:21] <bialix> limbo fix is gary work
[17:22] <bialix> ah, py2exe
[17:22] <bialix> yes
[17:22] <bialix> vila: do you saw my setup.py loader proof of concept?
[17:23] <vila> bialix: hmmm, not sure,
[17:23] <bialix> bzr-windows ML
[17:23] <vila> I saw some related mails, but I'm not sure I saw a patch
[17:23] <bialix> jam said that loading stuff from several plugins setup.py is bad idea
[17:24] <vila> yeah, I think there is some misunderstanding there
[17:24] <bialix> vila: lp:~bialix/+junk/plugins-setups
[17:27] <vila> bialix: I won't have time to look at it  today :-/
[17:27] <bialix> np
[17:28] <bialix> I don't insist
[17:28] <bialix> just a heads up
[17:28] <garyvdm> Hmmm - I passed to Merge3 base = "A" , this = "A", other ="". I expect to get out "", but I got"<<<<A[17:29] <vila> sure, remind me tomorrow if I don't give feedback
[17:31] <bialix> bye, vila, garyvdm
[17:32] <garyvdm> bye
[17:36] <vila> bye all
[18:27] <gioele> hi
[18:36] <gioele> which version of bzr-svn should one use with bzr 1.18?
[18:50] <weigon> gioele: see http://bazaar-vcs.org/BzrForeignBranches/Subversion#releases
[19:08] <gioele> argh, bzr-svn 0.6.5 has not been packaged yet in the PPA
[19:09] <zsquareplusc> is that the reason i can't make a system upgrade anymore? without removing bzr-svn anyways ;-)
[19:59] <RenatoSilva> verterok: hi, long time no merge :)
[20:04] <verterok> RenatoSilva: Hi
[20:04] <verterok> RenatoSilva: merge? oohhh the merge proposal
[20:05] <verterok> RenatoSilva: I found a weird issue, but I don't have logs in my laptop, I'll comment on the merge proposal or write  test case for it (hopefully tonight or tomorrow)
[20:05] <verterok> RenatoSilva: apologize the delay :(
[20:08] <james_w> hey verterok
[20:08] <RenatoSilva> verterok: ok np :) so you found a weird issue with the patch?
[20:11] <verterok> RenatoSilva: with the uri en/decoding
[20:11] <verterok> james_w: hey!
[20:12] <RenatoSilva> verterok: you found that manually written method weird at all or you had an specific issue?
[20:13] <RenatoSilva> verterok: iirc I had to write that method as default URL encoding doesn't do the required job... let me take a look to recall...
[20:13] <carljm> hi all - is there any way to get bzr to tell me which revision deleted a file? "bzr log thefile" just says "Path does not have any revision history." But it does, because I can "bzr revert" to an earlier revision where it exists. Do I have to bisect manually?
[20:13] <verterok> RenatoSilva: I builded the plugin with the patch and installed it, and got and error while playing with push/pull
[20:14] <RenatoSilva> verterok: hum... please let me know if you get any info/log about it
[20:15] <verterok> RenatoSilva: I need to take a look too, but I'm in the middle of a sprint ATM
[20:15] <verterok> RenatoSilva: sure :)
[20:15] <verterok> RenatoSilva: I mostly tried to work on the dependency split and bundling of xmloutput, I'll take a look to this tonight
[20:22] <RenatoSilva> verterok: http://bazaar.launchpad.net/~renatosilva/bzr-java-lib/encoding-fixes/revision/201
[20:24] <RenatoSilva> verterok: at a glance I'd say urlEncode() needs a fix, I think it won't work for non-ascii-finished strings
[20:26] <RenatoSilva> verterok: besides iirc URLEncoder.encode() also encodes ascii chars, then I had to write urlEncode() for encoding non-ascii only
[20:27] <verterok> RenatoSilva: ok, those are good news :)
[21:20] <RenatoSilva> verterok: Patch for non-ascii-ending URLs encoding: http://pastie.org/617917. Not compiled yet :)
[21:20] <verterok> RenatoSilva: :)
[21:21] <verterok> RenatoSilva: cool!. please push it to the same branch, and in the merge proposal change it status to resubmit (that way I get a mail with the updated marge proposal ;))
[21:22] <RenatoSilva> verterok: at home :) no ssh at work and no http push at lp :(
[21:22] <verterok> RenatoSilva: sure, no hurry :)
[22:44] <thefirstdude> how do I make a branch
[23:18] <jam> lifeless: I got your branch, but I haven't had any time to look at it yet
[23:18] <lifeless> jam: it has a minor bugfix for the C layer
[23:18] <jam> igc, bialix, garyvdm: I've encountered some fairly critical bugs in the qbzr/bzr-explorer on Windows that I'll be working on tonight
[23:18] <lifeless> jam: and my db work so far
[23:28] <lifeless> jam: are you still in canadia?
[23:28] <jam> lifeless: yes, I leave Thurs night
[23:28] <jam> it was extra fun to have segfault bugs in qbzr while demoing it to the client
[23:29] <lifeless> :) I was just reading that bug
[23:40] <jam> has anyone heard if/when qbzr might switch to --2a format?
[23:41] <jam> lifeless: yeah, doing some live training using Bazaar Explorer with inexperienced users was rather enlightening
[23:41] <jam> hence the... 10+ bugs I opened
[23:41] <lifeless> 20495872 nodes of the graph imported
[23:42] <jam> It also shows that we don't actively have people dogfooding Bazaar Explorer as a production thing
[23:42] <jam> lifeless: into sqlite?
[23:42] <lifeless> yah
[23:42] <jam> though... it still leaves the question of how many nodes you actually have :)
[23:42] <lifeless> 40million
[23:42] <jam> ah, so not bad, 50% there
[23:43] <lifeless> I wanted to talk to you about guis with area maps
[23:43] <lifeless> you use runsnakerun I think ?
[23:44] <igc> morning
[23:44] <igc> hi jam, lifeless
[23:44] <lifeless> hi igc
[23:44] <igc> jam: thanks for the bug reports
[23:45] <igc> jam: I'll take a look asap
[23:45] <jam> igc: I've got a fix for the critical one (segfault)
[23:45] <jam> though I have to redownload qbzr trunk because it is in a 2a repo
[23:45] <jam> lifeless: https://code.edge.launchpad.net/~jameinel/runsnakerun/memory_dump_integration
[23:46] <poolie> hello jam!
[23:46] <jam> hi poolie
[23:46] <jam> lifeless: I don't know the current state of that branch, as it was a bit hacking
[23:47] <jam> hackish
[23:47] <jam> but it worked last I checked
[23:47] <poolie> how's the trip?
[23:47] <jam> poolie: overall pretty good
[23:47] <jam> had some critical bugs that were a bit embarassing
[23:47] <lifeless> jam: I figure if I can make its queries abstract; I can generate a thunk to sqlite
[23:48] <jam> lifeless: certainly could be interesting
[23:48] <lifeless> jam: and then do a single long running analsysis/caching of aggregates in the db
[23:48] <jam> I'm curious how much you would end up loading for any given operation
[23:48] <lifeless> followed up by quick rendering and exploring
[23:48] <lifeless> jam: I'm thinking no more than 20 references deep
[23:48] <lifeless> or even 10
[23:49] <lifeless> jam: oh also
[23:49] <lifeless> jam: 'expensive references' - why do you fold them to zero rather than removing ?
[23:49] <lifeless> hi poolie
[23:49] <jam> lifeless: you mean pointing them at a null object?
[23:50] <jam> It was a "not quite sure what to do, let's try this" sort of thing
[23:50] <lifeless> poolie: I'm feeling middling; I'm going to see how it goes, if I stop thinking I'll go to bed & file a sick day thingy in the system
[23:50] <poolie> k
[23:50] <jam> It could be useful to know that this object has 100k outgoing references
[23:50] <thumper> jelmer: for updating LP's bzr-git, should we grab tip?
[23:50] <mwhudson> jelmer: same question for dulwich btw
[23:50] <lifeless> jam: funny you should mention :P - I have at least one object with 900000 references
[23:50] <lifeless> in this dump
[23:51] <jam> lifeless: probably intern dict
[23:51] <jam> that is usually the big one
[23:52] <jelmer> thumper, mwhudson: yeah, tip is best
[23:55] <lifeless> vila: are you around, by any chance?
[23:56] <thumper> jelmer: ok
[23:59] <igc> lifeless: hope you're feeling better soon