| 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:02 |
| nbjayme | thanks i'll have a look at it. | 03:03 |
| lifeless | bzr whoami will let you test if its set | 03:03 |
| nbjayme | it worked! thanks so much, lifeless. | 03:08 |
| lifeless | my pleasure | 03:09 |
| === doughnut42 is now known as eugeneoden | ||
| === moquist__ is now known as moquist | ||
| mrooney | Is an export slower than a checkout? | 05:57 |
| mrooney | It seems to be, I am wondering I should be using a checkout and removing the .bzr dirs? | 05:58 |
| juanje | Hi, guys, anyone here know about bzr-svn? | 09:48 |
| juanje | I got a weird issue.... | 09:49 |
| juanje | http://pastebin.ubuntu.com/150006/ | 09:49 |
| juanje | Error says something about bugs fixed, but just two of them | 09:50 |
| 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:51 |
| juanje | this happens in both, but the status is still "Fix Released", so doesn't seem so... | 09:52 |
| 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:54 |
| speakman | hi folks! | 09:58 |
| 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? | 09:59 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| speakman | oh, i see | 10:08 |
| wgrant | And rebase is also very inconvenient if your branch is public. | 10:08 |
| speakman | point taken; rebase isn't a very good idea | 10:09 |
| 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:10 |
| 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:11 |
| LarstiQ | bob2: no, they're not | 10:12 |
| lifeless | bob2: lp branches are the same as anywhere else -its configurable | 10:13 |
| bob2 | LarstiQ: its not? | 10:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| juanje | speakman: http://bazaar.launchpad.net/~freemix-dev/freemix/head/changes/16.1.6 | 10:17 |
| 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:18 |
| speakman | But also; a simple merge is nothing of value itself; it's what's merged what's interesting for the log | 10:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| bob2 | "merged foo bar baz from Jelmer" | 10:23 |
| 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:25 | |
| 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:26 |
| speakman | Then don't use the switch ;) | 10:27 |
| 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:32 |
| 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:33 |
| jrydberg | lifeless: how's performance these days? | 10:36 |
| 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:40 |
| bob2 | --development? | 10:41 |
| speakman | You would make GvR rethink his choice of Mercurial ;) | 10:41 |
| jrydberg | lifeless: cool. how is it on large trees? | 10:44 |
| 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:45 |
| speakman | lifeless: sent a blueprint just to not let it be forgotten: https://blueprints.launchpad.net/bzr/+spec/merge-commit-reuses-log :) | 10:48 |
| lifeless | speakman: we don't really get driven by blueprints | 11:32 |
| lifeless | speakman: either file a bug, or write some code :) | 11:32 |
| johnf | LarstiQ: you about? | 11:42 |
| LarstiQ | johnf: nish | 11:43 |
| 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:44 |
| 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 | 11:45 | |
| 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:43 |
| lifeless | OllieR: doesn't really matter | 12:44 |
| OllieR | lifeless: the bzr help page says - "Purpose: Create a shared repository to hold branches." | 12:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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. | 12:58 |
| lifeless | fullermd: well, signed revisions prevent that - data deletion is much more likely a vector | 13:19 |
| SamB | why is bzr/bzr-svn asking me for a username+password to access https://freedos.svn.sourceforge.net/svnroot/freedos/freecom ? | 13:29 |
| SamB | hmm, at least if I just hit enter it works fine ... | 13:30 |
| SamB | jelmer: any idea? | 13:30 |
| OllieR | SamB: it doesn't ask for a username/pass for me ... | 13:31 |
| OllieR | for bzr branch or via http (browser) | 13:33 |
| 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:34 |
| 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:35 |
| === You're now known as ubuntulog | ||
| fullermd | lifeless: signed revs would only help in very limited circumstances. | 13:42 |
| jelmer | SamB: latest bzr.dev / bzr-svn 0.6 ? | 13:49 |
| jelmer | SamB: sf is probably requesting authentication for POST requests | 13:50 |
| SamB | jelmer: yeah, latest | 13:50 |
| 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) | 13:51 |
| jelmer | SamB: should be fixed now (0.6 branch) | 14:05 |
| === mtaylor_ is now known as mtaylor | ||
| rocky | hrm, i need something a little higher level than a Transport to munge with security :/ | 16:58 |
| 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... | 16:59 |
| 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:00 |
| 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:01 |
| rocky | at the Transport level, i have no notion of the working tree | 17:02 |
| rocky | which is a problem | 17:02 |
| 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:12 |
| rocky | didn't think repos could have working trees | 17:13 |
| jelmer | rocky: sorry, was away for a bit | 17:15 |
| jelmer | rocky: ah, yeah | 17:15 |
| 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:16 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| === beuno_ is now known as beuno | ||
| 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:26 |
| 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:29 |
| 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:32 |
| 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:33 |
| vila | haaa, yeah, of course | 17:34 |
| 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:42 |
| 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:43 |
| 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:44 |
| jam | and now the --dev6 is being more strict about only allowing 8-bit strings | 17:45 |
| 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:00 |
| 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:01 |
| jam | (make pretty) | 18:02 |
| jam | and the report_inventory_contents is passing some bad paths | 18:02 |
| jelmer | jam: hmm | 18:04 |
| jelmer | jam: the bit that is failing is in the (file_id, basename) -> file_id map | 18:04 |
| 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:05 |
| 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:07 |
| jelmer | beuno: I mean, what bug are you referring to? | 18:08 |
| * beuno seraches for the bug # | 18:08 | |
| 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:09 |
| 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 |
| ubottu | Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Critical,Confirmed] https://launchpad.net/bugs/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:10 |
| jelmer | beuno: probably better to ask spiv, I have no idea about that bug | 18:12 |
| 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:13 |
| jelmer | jam: r2852 | 18:15 |
| jam | jelmer: bzr-svn trunk? | 18:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:24 |
| 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:25 |
| jelmer | abentley: hi | 18:41 |
| jelmer | abentley: I thought there was a noticable speed differences between trees and inventories, is that not true? | 18:42 |
| abentley | There should not be. | 18:51 |
| 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:56 |
| 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:57 |
| jelmer | s/use/do/ | 18:58 |
| jelmer | anyway | 18:58 |
| 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:00 |
| abentley | jelmer: It's remapping file-ids, right? | 19:01 |
| 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:02 |
| 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:03 |
| jelmer | abentley: what would that do to unversioned files in directories that are removed using the inventory_delta? | 19:04 |
| abentley | jelmer: inventory deltas only affect the inventory, not the filesystem. | 19:05 |
| abentley | do all the file-ids change when you dpush, or only the ones for recently-added files? | 19:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| abentley | You could actually use a TreeTransform for this. In fact, I think you could use WT.revert. | 19:11 |
| abentley | Though I guess that would revert any uncommitted changes. | 19:12 |
| 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:14 |
| abentley | And it will calculate the inventory delta for you. | 19:18 |
| abentley | And apply it, of course. | 19:18 |
| 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:46 |
| pygi | rocky, what, you :p | 19:50 |
| rocky | =P | 19:50 |
| pygi | rocky, did you thikn of new things?:D | 19:51 |
| pygi | think* | 19:51 |
| 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:52 |
| pygi | rocky, and what kind of difference do you see between bzr branch url and Bzr Path URL? | 19:53 |
| pygi | rocky, and did you fix it for 1.13? | 20:01 |
| rocky | pygi: sorry stepped away a sec... trying to do per-branch security | 20:20 |
| rocky | no groups support yet | 20:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| jelmer | rocky: sorry, I'm not familiar with the http bzr smart server | 20:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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 | 20:36 |
| * rockstar curses at pygi for turning his tab blue | 21:15 | |
| pygi | rockstar, :P | 21:15 |
| === lamont` is now known as lamont | ||
| lifeless | rocky: you can't distinguish in the wisgi layer, you have to use the smart request layer to tell | 22:00 |
| lifeless | rocky: transport is overly low, many smart verbs are not directly transport related | 22:01 |
| 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:07 |
| 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:12 |
| rbriggsatuiowa | thanks | 22:16 |
| rbriggsatuiowa | thanks | 22:16 |
| lifeless | spiv: ping | 23:30 |
| rocky | lifeless: yeah so now i'm doing a combination of transport level and wsgi layer level | 23:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!