[03:02] <nbjayme> hello all.  I have a couple of projects and each is using a different email address. How do you configure different email address on a per repository/project? (Thanks in advance).
[03:02] <lifeless> bzr help configuration - you want to set stuff in ~/.bazaar/locations.conf
[03:03] <nbjayme> thanks i'll have a look at it.
[03:03] <lifeless> bzr whoami will let you test if its set
[03:08] <nbjayme> it worked!  thanks so much, lifeless.
[03:09] <lifeless> my pleasure
[05:57] <mrooney> Is an export slower than a checkout?
[05:58] <mrooney> It seems to be, I am wondering I should be using a checkout and removing the .bzr dirs?
[09:48] <juanje> Hi, guys, anyone here know about bzr-svn?
[09:49] <juanje> I got a weird issue....
[09:49] <juanje> http://pastebin.ubuntu.com/150006/
[09:50] <juanje> Error says something about bugs fixed, but just two of them
[09:51] <juanje> I don't know if this is global issue or just because those two bugs (launchpad ones) closed are already closed but there are some comments after the closes...
[09:52] <juanje> this happens in both, but the status is still "Fix Released", so doesn't seem so...
[09:54] <juanje> I checked the logs and there are a lots of other bugs fixed, before and after those two and didn't say nothing about them
[09:58] <speakman> hi folks!
[09:59] <speakman> If i've branched a project and made some changes, and now the projects trunk has also made some changes; is there any way to pull the trunk once again and then put my changes on top of that?
[10:02] <bob2> pull in bzr implies one side is a subset of the other
[10:02] <bob2> so you need to merge
[10:02] <speakman> how about update?
[10:02] <bob2> 'update' in bzr has nothing to do with the repository or branch
[10:03] <speakman> really..?
[10:03] <bob2> it just updates the working copy
[10:03] <speakman> oh, I see! of course!
[10:03] <bob2> I'm not sure aht you're trying to do - are you concerned about the 'log' output after you merge in the trunk?
[10:04] <speakman> I prefer pulling my friends branches, yes.
[10:04] <speakman> (then they get the credits in the log output)
[10:04] <bob2> they get credit anyway - the log includes all the revisions merged or pulled
[10:04] <speakman> can't rebase do something here?
[10:05] <bob2> you're making this very hard...:)
[10:05] <speakman> bob2: yes, but it won't show unless you do bzr visualize or bzr log --long
[10:05] <speakman> :D
[10:05] <wgrant> vanilla 'bzr log' shows merged revisions.
[10:05] <bob2> bzr log -n0
[10:05] <bob2> and only as of 1.14
[10:05] <bob2> before then, bzr log showed them too
[10:05] <juanje> speakman: I usually do 'bzr pull [the_other_branch]' or 'bzr merge --pull [the_other_branch]' for that
[10:06] <speakman> Launchpad doesn't show merged revisions ;)
[10:06] <bob2> surely your own comit message is "Merge from Foo Bar", anyway
[10:06] <juanje> speakman: yes, but you have to click somewhere
[10:07] <juanje> i don't rememeber where, but you can see it
[10:07] <speakman> Doing "pull" it's a much nicer log output :)
[10:07] <juanje> that happens to me once
[10:07] <juanje> yep
[10:07] <bob2> in short: the sane, simple way is to use "merge", you could use rebase if you really wanted, but rebase has all sorts of sde effects
[10:07] <lifeless> speakman: you can use rebase; however rebase turns tested code into untested code
[10:07] <speakman> side effects?
[10:08] <speakman> oh, i see
[10:08] <wgrant> And rebase is also very inconvenient if your branch is public.
[10:09] <speakman> point taken; rebase isn't a very good idea
[10:10] <speakman> there are more than me and my friend using this lp project
[10:10] <bob2> are lp branches append only?
[10:10] <speakman> I'll just use bzr merge --pull instead
[10:10] <bob2> speakman: and since pull won't work, that's the same as 'bzr merge'
[10:10] <speakman> no, bzr push --overwrite could do whatever you like
[10:10] <speakman> bob2: exactly; do pull if I can, else merge. Easy as that :)
[10:11] <juanje> speakman: I you see this branch (http://bazaar.launchpad.net/~freemix-dev/freemix/head/revision/17) there is a merge from one branch of me, but it didn't show well. But if you click on the '16.1.6 freemix' you'll see all my revisions that were merged
[10:12] <LarstiQ> bob2: no, they're not
[10:13] <lifeless> bob2: lp branches are the same as anywhere else -its configurable
[10:13] <bob2> LarstiQ: its not?
[10:14] <lifeless> bob2: 'lp branches;
[10:14] <LarstiQ> lifeless: you don't have direct access to the lp branch.conf I don't think?
[10:14] <lifeless> LarstiQ: yes, you do
[10:15] <LarstiQ> hmmm :)
[10:15] <bob2> via sftpz?
[10:15] <LarstiQ> handediting and uploading? yuck
[10:15] <speakman> juanje: but here https://code.launchpad.net/~freemix-dev/freemix/head you won't see your changes. Launchpad should handle that better IMO, since most free software are built on credits.
[10:16] <bob2> speakman: merge commit messages should have the credit within them
[10:16] <juanje> speakman: yes, I though so, but actually are there, you can see if you click in the right place, but yes is a bit hiden
[10:17] <juanje> speakman: http://bazaar.launchpad.net/~freemix-dev/freemix/head/changes/16.1.6
[10:18] <juanje> speakman: there you can see now my commits merged
[10:18] <juanje> speakman: all the 16.1.? revisions
[10:18] <speakman> bob2: yes, that's true
[10:19] <speakman> But also; a simple merge is nothing of value itself; it's what's merged what's interesting for the log
[10:20] <juanje> speakman: actually, when there is not problem with pull, all the changes are fully integrated (with credits) in my trunk, the only problems is when I have to do merge
[10:20] <speakman> juanje: you're on to same "problem"
[10:21] <speakman> The PQM does a better job imo: https://code.launchpad.net/~bzr/bzr/trunk
[10:21] <bob2> pqm does everything as a merge
[10:22] <bob2> isn't that the opposite of what you want?
[10:22] <speakman> But If you change the commit messages to "Merged from Jelmer" etc, then it isn't that valueble
[10:23] <bob2> "merged foo bar baz from Jelmer"
[10:25] <johnf> would it make sense to anyone that bzr 1.14 now has a zlib build dependency which it didn't have previously?
[10:25]  * johnf is about to go hunting in revision log
[10:26] <speakman> How about making a certain switch to "bzr merge" which automatically reuses the log messages of the merged branch?
[10:26] <bob2> how would that work?  you might be merging a thousand revisions
[10:27] <speakman> Then don't use the switch ;)
[10:32] <lifeless> speakman: I think an option klke that mght be good
[10:32] <lifeless> I'd start with a plugin that wraps merge though, see if you can get the kinks out, then propose the logic as a patch to merge/pull --merge/whatever
[10:33] <lifeless> johnf: yes
[10:33] <lifeless> johnf: its the new compressor, we use zlib directly as well as via python
[10:33] <johnf> lifeless: cool, just wanted to check before adding the build depends
[10:36] <jrydberg> lifeless: how's performance these days?
[10:40] <lifeless> jrydberg: pretty good; the new format (beta in 1.14) is 20 times faster at a bunch of things; and 1/3 the disk space utilisation
[10:41] <bob2> --development?
[10:41] <speakman> You would make GvR rethink his choice of Mercurial ;)
[10:44] <jrydberg> lifeless: cool. how is it on large trees?
[10:45] <lifeless> jrydberg: 1.0->0.4 seconds for commit on some very large trees
[10:45] <lifeless> O(logN) scaling for tree size, diff time proportional to change size etc
[10:45] <lifeless> I have to go though, can't chat right now :(
[10:45] <lifeless> bob2: --development-rich-root
[10:48] <speakman> lifeless: sent a blueprint just to not let it be forgotten: https://blueprints.launchpad.net/bzr/+spec/merge-commit-reuses-log :)
[11:32] <lifeless> speakman: we don't really get driven by blueprints
[11:32] <lifeless> speakman: either file a bug, or write some code :)
[11:42] <johnf> LarstiQ: you about?
[11:43] <LarstiQ> johnf: nish
[11:44] <LarstiQ> johnf: we're going to pack our stuff into the car now, and leave Breakpoint in an hour
[11:44] <LarstiQ> johnf: if you have clear ideas about bzr-svn ppa, go ahead
[11:44] <johnf> LarstiQ: heh. I've just uploaded bzr and bzrtools to ppa. You want to do newest version of bzr-svn?
[11:45] <johnf> Yeah I might try the old method and if it's too much hassle use same process as bzrtools and bzr
[11:45] <LarstiQ> johnf: I can, but not today, might take a couple of days.
[11:45] <LarstiQ> johnf: k
[11:45] <johnf> thanks
[11:45] <johnf> I'll check it out
[11:45]  * LarstiQ packs
[12:43] <OllieR> say i have /srv/bzr/project1 should I be doing cd /srv/bzr bzr init-repo at the top level "above" all my projects directories or should I do bzr init-repo within each project sub directory?
[12:44] <lifeless> OllieR: doesn't really matter
[12:46] <OllieR> lifeless: the bzr help page says - "Purpose: Create a shared repository to hold branches."
[12:47] <lifeless> yes
[12:47] <lifeless> its optional though
[12:47] <lifeless> branches can be created regardless
[12:47] <lifeless> and performance will not change greatly whether you have one repo per project or one for all
[12:47] <OllieR> right the real reason for asking this is because I am trying to work out how I will setup my directory structure
[12:48] <OllieR> "New branches created under the repository directory will store their revisions in the repository, not in the branch directory." - this may make perms trickier?
[12:48] <OllieR> basicially I have /srv/bzr/private and /srv/bzr/project/
[12:48] <OllieR> correction /srv/bzr/public/
[12:49] <OllieR> so the public dir will have tree and will be accessible via http (apache) so that a user could do a checkout
[12:49] <OllieR> I would also then like to enable certain people write permissions to certain branches/projects
[12:50] <OllieR> is this just a case of chowning my bzr branch as necessary?
[12:50] <OllieR> if I do bzr init-repo then it says my revisions are stored in a repo and no the branch dir itself, well that could make permissions very difficult to setup
[12:51] <OllieR> I haven't setup a multi bzr setup like this before so really just after a bit of guidance to point me in the right direction :)
[12:53] <fullermd> Yes, you end up only really being able to set perms at repo granularity.  All or nothing.  Branch-level differences could protect against accident, but not malice.
[12:54] <fullermd> Also, if you're web serving /srv/bzr/public/ and the branches there are using a repo at /srv/bzr/, they won't be web accessible anyway since the repo can't be seen.
[12:54] <OllieR> fullermd: good point
[12:55] <OllieR> ok so essentially I should setup separate repos for each project and then I can grant commit access to trusted parties for that whole project
[12:56] <OllieR> If I had one repo for all projects then I would restrict myself to being able to grant commit access to every project or no projects which is no desirable
[12:57] <fullermd> Roughly, yah.  Comes to threat models; if you can read the repo, you can read anything in it, no matter what branch (and you can heuristically guess where branches head out at)
[12:58] <OllieR> yep so i defnitely want multiple repos
[12:58] <fullermd> If you can write to the repo, you can pretty much write OVER anything in it, so even if you couldn't change a branch's idea of the rev that's its head, you can change the contents of that rev.
[13:19] <lifeless> fullermd: well, signed revisions prevent that - data deletion is much more likely a vector
[13:29] <SamB> why is bzr/bzr-svn asking me for a username+password to access https://freedos.svn.sourceforge.net/svnroot/freedos/freecom ?
[13:30] <SamB> hmm, at least if I just hit enter it works fine ...
[13:30] <SamB> jelmer: any idea?
[13:31] <OllieR> SamB: it doesn't ask for a username/pass for me ...
[13:33] <OllieR> for bzr branch or via http (browser)
[13:34] <lifeless> SamB: try nosmart+http
[13:34] <SamB> well, that was via svn-import ...
[13:34] <lifeless> SamB: its a change in tip bzr-svn which got backed out - see the list for details
[13:34] <SamB> ah
[13:35] <lifeless> what happens is that bzr POST's to probe for a smart server
[13:35] <lifeless> and the server is giving 401
[13:35] <lifeless> which isn't strictly true, but all-the-same
[13:35] <lifeless> bzr then prompts for credentials
[13:42] <fullermd> lifeless: signed revs would only help in very limited circumstances.
[13:49] <jelmer> SamB: latest bzr.dev / bzr-svn 0.6 ?
[13:50] <jelmer> SamB: sf is probably requesting authentication for POST requests
[13:50] <SamB> jelmer: yeah, latest
[13:51] <SamB> also how come "bzr svn-import https://freedos.svn.sourceforge.net/svnroot/freedos/freecom" leaves me with freecom/freecom/{trunk,branches} ?
[13:51] <SamB> (after hitting "enter" those extra two times, of course)
[14:05] <jelmer> SamB: should be fixed now (0.6 branch)
[16:58] <rocky> hrm, i need something a little higher level than a Transport to munge with security :/
[16:59] <jelmer> rocky: are you trying to do security for stuff inside of a bzr versioned tree?
[16:59] <jelmer> rocky: or rather security on a per-branch basis?
[16:59] <rocky> jelmer: ok... let me tell you what i have and what i want...
[17:00] <rocky> jelmer: i've created this very simple http browser thing that acts like mod_svn whereby you can browse any directory whether it's bzr versioned or not .... and as you go into sub folders, if one of them is a branch, it starts displaying the branch's latest revision file listing as if it were just another directory
[17:01] <rocky> and you can go deeper into the tree whether it's a branch or not and it looks the wsame
[17:01] <rocky> *same
[17:01] <rocky> now i want to control read and write access based on a path that may or may not go into a branch's tree info
[17:02] <rocky> at the Transport level, i have no notion of the working tree
[17:02] <rocky> which is a problem
[17:12] <rocky> jelmer: for an example of what i'm doing ... take a look at http://dev.serverzen.com/bzr/  and drill down until you get to a trunk dir
[17:12] <OllieR> is it possible to convert a tree less shared repo to one with a tree?
[17:13] <rocky> didn't think repos could have working trees
[17:15] <jelmer> rocky: sorry, was away for a bit
[17:15] <jelmer> rocky: ah, yeah
[17:16] <jelmer> rocky: You're using something like Branch.basis_tree() to find the tree?
[17:16] <jelmer> rocky: or do you mean using the bzr smart server?
[17:18] <rocky> jelmer: i'm using Branch.basis_tree() for browsing the tree, yes ... but, if you browsed through you can see that it gives a bzr url ... that bzr url works against the same server, my little server is smart enough to hand bzr smart http requests to the bzr smart http server app\
[17:19] <rocky> so my little server is essentially a tree browser and a bzr smart server
[17:19] <jelmer> rocky: ah, neat
[17:19] <jelmer> rocky: yes, Transport is the wrong place for fine-grained auth
[17:19] <rocky> so now, i want to do url-based security
[17:19] <rocky> for both tree browsing and bzr smart server requests
[17:19] <jelmer> rocky: but if you let users retrieve revisions using the smart server
[17:19] <jelmer> they'll get the full tree anyway
[17:20] <rocky> i don't mind that the url-based security can only go as deep as the branch
[17:20] <jelmer> you can't let them retrieve parts of the revision as bzr doesn't support partial checkouts yet
[17:20] <rocky> actually, just discussing this has made me think i can do all of this without worrying about bzrlib's security at all
[17:21] <rocky> i can implement all security checks right in the wsgi layer if i don't care to go deeper than branch roots
[17:21] <jelmer> rocky: right
[17:26] <rocky> jelmer: i'm building this for my own use to make it easier to manage bzr servers with my ClueMapper suite ... hopefully this will be useful to others as well
[17:29] <jam> morning all
[17:29] <jam> vila: how's it going?
[17:29] <jam> jelmer: I've been having trouble trying to convert the latest python trunk branch via bzr-svn 0.5.4
[17:32] <vila> jam: as an Easter Monday ? Back from a bicycle ride, passing around before dinner ;-)
[17:32] <jam> ah, I thought you might have today off, I wasn't sure
[17:33] <vila> jam: what about you ? Neither friday nor monday ?
[17:33] <jam> vila: it isn't a governmental holiday, so no official days of from canonical
[17:34] <vila> haaa, yeah, of course
[17:42] <jelmer> jam: hi
[17:42] <jam> hey jelmer
[17:42] <jelmer> jam: What sort of trouble?
[17:42] <jam> I've been getting quite a few failures, so I'm not really sure where to start
[17:42] <jam> If I use "svn-import" it runs for a couple hours
[17:42] <jam> but then dies with:
[17:43] <jam> AssertionError: Tried registering <CachingRevisionMetadata... as parent while ... already was parent
[17:43] <jam> If I try to just convert "python/trunk" I get:
[17:43] <jam> TypeError: Bit 1 of ('2160@6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk%2F', u'Lib')...
[17:43] <jam> which means that something in bzr-svn is trying to use a "key"
[17:43] <jam> which has unicode in it
[17:43] <jelmer> jam: there's an open bug about the first issue
[17:44] <jelmer> jam: not sure about the second, can you provide some more details?
[17:44] <jam> (I don't have any idea why bzr-svn would be trying to create a file-id with "u'Lib'" as the revision id)
[17:44] <jam> jelmer: "bzr init-repo --develompent6-rich-root test; bzr branch http://svn.python.org/projects/python/trunk test/trunk"
[17:44] <jam> I have the feeling we have been silently allowing a bad file_id, revision_id combo
[17:44] <jam> in older formats
[17:45] <jam> and now the --dev6 is being more strict about only allowing 8-bit strings
[18:00] <jelmer> jam: ok, trying to reproduce now
[18:00] <jelmer> jam: I can't see any obvious places where we would be specifying wrong text revisions
[18:01] <jam> jelmer: so the backtrace is here:http://paste.ubuntu.com/150280/
[18:01] <jam> Which at least makes it looks like the code is failing
[18:01] <jam> because it has generated an exception
[18:01] <jam> which it is then trying to "prettify"
[18:02] <jam> (make pretty)
[18:02] <jam> and the report_inventory_contents is passing some bad paths
[18:04] <jelmer> jam: hmm
[18:04] <jelmer> jam: the bit that is failing is in the (file_id, basename) -> file_id map
[18:05] <jelmer> jam: that's the cache that's only provided by CHK Inventories
[18:05] <jelmer>         parent_id_basename_index = getattr(self.old_inventory, "parent_id_basename_to_file_id", None)
[18:07] <jelmer> jam: it seems reasonable that basename is a unicode string
[18:07] <beuno> jelmer, any fix yet for the AbsentContentFactory error?
[18:07] <jelmer> beuno: which error?
[18:08] <jelmer> beuno: I mean, what bug are you referring to?
[18:08]  * beuno seraches for the bug #
[18:09] <jam> jelmer: that probably does make sense. I'm pretty sure at the CHK map layer, basename would be a utf-8 string, but I could understand that we should be abstracting that away somewhere inbetween
[18:09] <beuno> ErrorFromSmartServer: Error received from smart server: ('error', "'AbsentContentFactory' object has no attribute 'get_bytes_as'")
[18:09] <jelmer> jam: ah, encoding it as utf8 makes sense I guess
[18:09] <jam> jelmer: my guess is that CHKInventory should be doing an encode before passing it lower
[18:10] <jam> though I think bzr-svn is going after it directly
[18:10] <jelmer> jam: ah, yeah - CHKInventory is indeed encoding to utf8
[18:10] <beuno> jelmer, bug 354036
[18:10] <jam> jelmer: CHKInventory._parent_id_basename_key
[18:10]  * jelmer tries with utf8
[18:10] <jam> does an encode('utf-8')
[18:12] <jelmer> beuno: probably better to ask spiv, I have no idea about that bug
[18:13] <jelmer> jam: with the encode("utf-8") it seems to work better
[18:13]  * jelmer commits
[18:13] <jelmer> (and fast, converted almost 1k revisions already)
[18:15] <jelmer> jam: r2852
[18:15] <jam> jelmer: bzr-svn trunk?
[18:16] <jelmer> jam: 0.6 branch (http://people.samba.org/bzr/jelmer/0.6)
[18:16] <jelmer> or substitute 0.6 for bzr.dev
[18:16] <jelmer> (which is a symlink)
[18:17] <jam> jelmer: so what is 0.6 vs 0.5?
[18:17] <jam> Is there a format bump in there I should be cautious of?
[18:18] <jelmer> jam: no, no format changes
[18:18] <jelmer> jam: 0.6 depends on a few new patches in bzr.dev
[18:18] <jelmer> jam: and takes advantage of some of my pending patches
[18:18] <jelmer> jam: (although it doesn't require them)
[18:24] <jelmer> jam: so, if things work linearly then I can do an import of python trunk in under two hours now
[18:24] <jam> jelmer: from what I've seen, it isn't quite linear.
[18:25] <jam> also, have you pushed up 2852?
[18:25] <jelmer> yeah, 2852 has been pushed
[18:25] <jam> k, it wasn't just a second ago
[18:25] <jam> I still don't see it
[18:25] <jelmer> should have been
[18:25] <jelmer> http://people.samba.org/bzr/jelmer/bzr-svn/0.6 ?
[18:25] <jam> hmm... I seem to have the launchpad mirror
[18:41] <jelmer> abentley: hi
[18:42] <jelmer> abentley: I thought there was a noticable speed differences between trees and inventories, is that not true?
[18:51] <abentley> There should not be.
[18:56] <abentley> jelmer: ^^ tree operations should have the same speed as an inventory operation that provides the same guarantees.  Obviously, WorkingTree.get_file_sha1 can't be as fast as InventoryEntry.sha1 (or whatever it's called)
[18:57] <jelmer> abentley: ah, thanks
[18:57] <jelmer> abentley: I'll change things to use a tree then, seems better than to use premature optimization
[18:58] <jelmer> s/use/do/
[18:58] <jelmer> anyway
[19:00] <abentley> So what's this code actually doing?  It looks like it's handling renames, but why does it assert no adds or removes?
[19:01] <abentley> jelmer: It's remapping file-ids, right?
[19:02] <jelmer> abentley: yeah
[19:02] <abentley> jelmer: Can I recommend apply_inventory_delta?  It removes the ordering constraints and avoids generating an inventory on dirstate trees.
[19:03] <jelmer> abentley: the "dpull" operation will have created an exact copy in the remote repository with the same contents but with different file ids
[19:03] <jelmer> abentley: this code changes the local working tree to use the file ids in the remote repository
[19:04] <jelmer> abentley: what would that do to unversioned files in directories that are removed using the inventory_delta?
[19:05] <abentley> jelmer: inventory deltas only affect the inventory, not the filesystem.
[19:06] <abentley> do all the file-ids change when you dpush, or only the ones for recently-added files?
[19:07] <jelmer> abentley: only the ones for recently-added files; the current remapping is suboptimal in that regard
[19:07] <abentley> jelmer: It doesn't sounds like a directory could become unversioned in update_workinginv_fileids.
[19:08] <jelmer> abentley: well, in case of the inventory delta we'd have to delete the directory with the old file-id and re-add it with the new file-id
[19:08] <abentley> jelmer: But if it did, the unversioned file would stop being mentioned in Tree.extras or anything else that lists unknown files.
[19:09] <abentley> jelmer: You would have to delete the inventory entry for the directory with the old file-id and re-add it with the new file-id.  You wouldn't need to delete the directory itself.
[19:09] <jelmer> abentley: right, that makes sense
[19:11] <abentley> You could actually use a TreeTransform for this.  In fact, I think you could use WT.revert.
[19:12] <abentley> Though I guess that would revert any uncommitted changes.
[19:14] <abentley> jelmer: The advantage of TT is that file-ids aren't authoritative identifiers.  So you can do tt.unversion(trans_id); tt.version_file('file-id2', trans_id)
[19:18] <abentley> And it will calculate the inventory delta for you.
[19:18] <abentley> And apply it, of course.
[19:46] <rocky> jelmer: hey, the only problem with defining the security layer on top of wsgi is that i cannot differentiate between a read and write bzr smart request
[19:50] <pygi> rocky, what, you :p
[19:50] <rocky> =P
[19:51] <pygi> rocky, did you thikn of new things?:D
[19:51] <pygi> think*
[19:52] <rocky> pygi: i just finished adding dir-browsing support ... you can take a look at http://dev.serverzen.com/bzr/
[19:52] <rocky> pygi: now i'm trying to fix up the security ini stuff
[19:52] <pygi> rockstar, per-repo security?
[19:52] <pygi> and groups support?
[19:53] <pygi> rocky, and what kind of difference do you see between bzr branch url and Bzr Path URL?
[20:01] <pygi> rocky, and did you fix it for 1.13?
[20:20] <rocky> pygi: sorry stepped away a sec... trying to do per-branch security
[20:20] <rocky> no groups support yet
[20:21] <pygi> rockstar, wouldn't per-repo security allow me to do say ~mario, ~rocky and stuff?
[20:21] <rocky> and the difference between branch url and path url is that you might be several levels deep in a branch so the path url will change but the branch url will ot
[20:22] <pygi> ups
[20:22] <pygi> rocky*
[20:22] <pygi> :)
[20:22] <rocky> what diff would per-repo and per-branch security do there?
[20:22] <pygi> well, I create ~mario repo, so user mario can create branches in there?
[20:22] <pygi> without need for additional configuration?
[20:23] <jelmer> jam: fwiw a python import (41k revs) now takes 7474.116 seconds here, so just a little bit over two hours
[20:23] <pygi> (even if that is called abusing repos, but oh well :P)
[20:24] <jelmer> jam: are there any plans to provide integration for the memory profiler you and mwh wrote?
[20:24] <rocky> pygi: oh yeah... that would be good to have but is still a bit separate from the security stuff i'm talking about... why would that be abusing repos?
[20:24] <pygi> rocky, cause repos are supposed to be used for branches that share similarities :p
[20:25] <rocky> ohhh right
[20:25] <jam> jelmer: right now I'm purely latency bound, on a 6 year old machine
[20:25] <rocky> yeah ;)
[20:25] <jam> so I'm not sure how long... but it should be pretty flat :)
[20:25] <pygi> rocky, SIGHUP support is in?
[20:25] <jam> jelmer: I'm not sure what integration we'll end up doing
[20:25] <pygi> or am I still to do it?
[20:25] <jam> I might tie something into 'trace.debug_memory()'
[20:26] <rocky> pygi: well, we could do it a little more like launchpad and make it so you'd do ~rocky/project1/mybranch so ~rocky would just be regular dir and project1 would be the repo
[20:26] <rocky> pygi: still waiting on you :)
[20:26] <jam> jelmer: what would *you* like to see?
[20:26] <pygi> rocky, I like that idea about ~user/project/branch
[20:26] <jelmer> jam: "bzr selftest --memprof=foo.callgrind" or something along those lines
[20:26] <jelmer> or bzr --memprof=foo.callgrind branch <...>
[20:27] <jelmer> writing out the state at the moment bzr is termiunated
[20:27] <jam> jelmer: when would you dump it? At the peak, at the end, periodically?
[20:27] <pygi> rocky, ok, you'll have sighup patch by tomorrow hopefully then
[20:27] <rocky> jelmer: any clues on how i'd distinguish between a read and write request over a http bzr smart server request? (in the wsgi layer)
[20:27] <jelmer> jam: at the end
[20:28] <jelmer> rocky: sorry, I'm not familiar with the http bzr smart server
[20:29] <jelmer> jam: at the peak would be ideal, but it's hard to say what the peak was until bzr has terminated
[20:29] <rocky> i think i may still have to go back to the transport level for that :(
[20:29] <jelmer> rocky: you might want to talk to spiv about this
[20:29] <jelmer> jam: being able to send a SIGQUIT and then easily dumping the memory profile somewhere could also work
[20:30] <rocky> spiv: ping.... :)
[20:30] <jelmer> jam: if it's just "import memprof; memprof.dump_trace('foo.callgrind')"
[20:30] <jam> jelmer: ^| from memory_dump import scanner; scanner.dump_gc_objects('foo.dump')
[20:30] <jam> at them moment
[20:30] <jelmer> jam: ah, nice
[20:31] <jelmer> jam: that's several degrees better than the other profilers I've looked at in the past
[20:31] <jam> the dump file is currently still json only
[20:31] <jam> but I have a 'runsnakerun' patch that allows it to be loaded directly
[20:31] <jam> I'd like to get it in callgrind output, but it takes some thinking
[20:31] <jam> as dump_gc_objects() is meant to be as lightweight on memory as possible
[20:32] <jam> (i think it currently costs about 20kB)
[20:32] <jam> scaling O(num_objects) hurt me with stuff like heapy
[20:32] <jam> since I had 1GB already...
[20:36] <jam> there are 2 dump functions, ATM, based on whether you want to use a set while dumping
[20:36] <jam> my test showed it took about 60MB to dump 600MB
[20:36] <jam> which is ok, but depends on your needs
[21:15]  * rockstar curses at pygi for turning his tab blue
[21:15] <pygi> rockstar, :P
[22:00] <lifeless> rocky: you can't distinguish in the wisgi layer, you have to use the smart request layer to tell
[22:01] <lifeless> rocky: transport is overly low, many smart verbs are not directly transport related
[22:07] <rbriggsatuiowa> using bzr diff --old b1 --new b2 # how do I get a list of the files that changed?
[22:07] <rbriggsatuiowa> rather than all the changes themselves
[22:12] <lifeless> rbriggsatuiowa: you need bzr st for that, but it doesn't have old and new. instead do
[22:12] <lifeless> cd b2
[22:12] <lifeless> bzr st -r branch:b1
[22:16] <rbriggsatuiowa> thanks
[22:16] <rbriggsatuiowa> thanks
[23:30] <lifeless> spiv: ping
[23:38] <rocky> lifeless: yeah so now i'm doing a combination of transport level and wsgi layer level