[00:00] i want it to be distributed with the commit its refering to [00:00] strange question... [00:00] what is ubottu written in? [00:00] and is it open source? [00:00] oh it's a supybot :( [00:00] * Spaz cries a bit, and forks back into the background [00:00] monotone can do that just fine [00:01] ronny: AIUI monotone it will do that because it syncs the entire database bidirectionally unconditionally [00:02] lifeless: its append-only - and metadata are certified key-value pairs on the revision [00:02] ronny: I'm sorry, but we don't have an existing facility. What is the monotone facility called so I can look it up [00:02] (and it can have more than one key-value pair with the same key) [00:02] ronny: What would happen when the same revision was richly-tagged in two different branches at the same time? [00:02] lifeless: certificates [00:03] Odd_Bloke: monotone's storage system is quite sophisticated, you get two tags with different certs [00:03] ronny: thanks [00:03] Odd_Bloke: thats the way fast-forward merges with branches work in monotone [00:03] i rev, n branches [00:03] ronny: http://www.monotone.ca/docs/Certificates.html <- the right place? [00:03] just n certificates with the key branch, and the branch names as value [00:04] lifeless: yeah [00:04] ronny: right, I've been through some related stuff before [00:04] lifeless: it allos to do quite cool things [00:05] ronny: I'll read this on the train after work; I wish I could offer you a precanned answer, but we don't have one [00:05] like accept only revs that have passes a set of tests on all buildbots [00:05] AFAIK neither hg nor git have precanned answers for adding-metadata like this either [00:05] lifeless: basically all mainstream dvc's have toy-level metadata [00:06] I think its a perspective thing [00:06] monotone has a very different worldview [00:06] like darcs has a different worldview [00:07] and its good to learn and consider ideas; however the challenge for bzr/git/hg in this space is that much of monotone is built up from the certificates primitive, and well, we're not. [00:13] lifeless: well, the core of it is the graph of files/revisions (i dont correctly understand it, but bzr's graph should be pretty close) [00:14] however everything thats not part of the real history of files is not in that graph, but a certificate that add information (commit messages, authors, dates, ...) [00:20] Which is to say, a rather different worldview 8-} [00:22] but much more sane and practical [00:22] A matter of perspective. Some people consider CVS more sane and practical too. [00:22] one can just limit updates by the certificates added to an revision [00:23] (ie test passes, developer approval, anything else) [00:24] Yes, but by its very nature that means that the metadata is completely divorced from the data. Two people could have the same revision, but have completely different ideas about how committed it, when it was committed, and what the log message was. [00:25] So you end up having to have conflict resolution procedures for that, and accepting the local-view issues. [00:25] you just dont have to care about that [00:25] Neither is necessarily Right, but there are different tradeoffs either way. [00:26] I'll care about whatever I wanna care about, thankyouverymuch ;) [00:26] well, its all there, and if you pull it, you keep it [00:45] The weather is getting warm enough that I'm starting to really notice it when I run the test suite on my laptop... [00:46] spiv, it's supposed to get up to 36C today [00:46] also [00:46] Yeah, I saw :/ [00:46] lucky bastards [00:46] apparently batteries getting hot in a laptop while at full charge is a leading cause of early exhaustion [00:46] in the sense of their capacity decreasing [00:47] My battery is already down to ~40% capacity, but it is about 2 years old. [00:47] so if you want to be really frugal it's better to pull them out while on ac [00:47] Hmm, maybe not quite that bad, but pretty low. [00:47] this is pretty annoying if you bump the cord though :) [00:47] Right, which I do do :) [00:48] apparently it is best to store them at about 50% charge [00:48] which is a bit hard to arrang [00:54] yah [00:54] there is a site [00:54] that has differnet battery types and storage levels === sdboyer is now known as sdboyer|blaaah [01:04] It's probably best, though, to arrange for you laptop not to oops at 100% CPU when you think it's suspended before putting it in a bag and closing the zipper. There's just nothing like the smell of singed components that comes from baking your machine in constrained CPU exhaust. [01:07] Oh, sure there is. Like the one time I put 120 volts across a 2N2222... [01:08] thats a DC diode isn't it ? [01:08] a little one [01:08] NPN bipolar transistor. [01:08] duh, yes [01:08] I need to do more electronics I think [01:09] It lasted a good quarter of a second, I figure... [01:12] What's a few extra volts between friends? [01:12] AfC: electric [01:12] Well, a few extra volts presumably means a lot of extra amps :p [01:14] After all, a transistor is just a fuse with gain... [01:16] spiv, i thought i remembered multiple occurrences of _ on the lhs of an assignment giving an error in python [01:16] but it does seem to work, at least in 2.5 [01:17] poolie: don't see why it would error, it just has to bind multiple times :) === jamesh_ is now known as jamesh [01:19] poolie: I think for _, _ in thing: [01:19] poolie: that might error [01:20] it's not a big deal [01:21] poolie: I dimly recall there being some case where than happens, but I can't seem to find it now. [01:21] So I guess it's sufficiently obscure not to matter :) [01:47] poolie: ok, I think I have only one more thing to do on the autopack branch [01:48] poolie: which is deciding what the "NotPackRepository" error on the wire ought to look like [01:48] spiv: why error? [01:48] spiv: if there is no return value, and its not a pack repo, just swallow [01:49] lifeless: well, that's a possibility. [01:49] It is an indication that at best something weird is happening. [01:49] Because it shouldn't ever be trying that verb on a non-pack repo. [01:50] Not returning an error has the advantage of being a little bit simpler. [01:51] Ok, I think I'll just not return an error, I'm happy with that. [01:51] lifeless: thanks [02:11] that's ok with me too [02:12] Ok, I've just sent the current patch to the list. [02:12] I think this version is ready for merging as-is, so please take a look and give it a BB: blessing :) [02:37] i will [02:38] spiv, you have a handful of other patches approved for 1.9 [02:38] if you're sure of them now would be a good time, while i read this [02:41] lifeless: so would there be any drawbacks to making 1.9 (the btree format) be rich-root only? [02:42] i guess conversions into it would be substantially slower as we'd have to rewrite all inventories [02:43] poolie: do the sha1's get rewritten correctly? [02:43] I still don't have a clear answer to this [02:43] when the inventories are changed when fetching into a rich root repo? [02:43] and yes, while the default isn't rich root, I think there are clear drawbacks to adding a new format that is a trapdoor for users on the default [02:43] yes [02:43] and during reconcile [02:44] I don't know the status of this; I thought it was the one remaining issue; I may be wrong and its done. [02:44] what would reconcile be doing here? [02:45] s/here/relevant to this [02:45] there are existing repositories with damaged goods [02:45] where the revision sha1 is the sha1 of a non-rich-root inventory, but the inventory is a rich root one [02:45] I have a patch I cannot land for 'check' to check the sha1's are valid [02:46] reconcile can in theory detect this specific issue by converting the repository to a non-rich-root one, serialising, and if the sha then matches, rewrite the revision object to have the current inventories sha [02:47] cannot land the patch why? because there's no reconcile code to fix up what it finds? [02:47] yeah [02:47] in fact, IMO accessing inventories should check the sha1 against the revision as a matter of course [02:47] but thats different (though still dependent) [03:09] beuno: ping? [03:15] spiv, review sent [03:16] poolie: thanks [03:21] poolie: I don't see the review anywhere? [03:21] :/ [03:22] try now? [03:24] poolie: I see it now [03:25] I just tested 'bzr pack' manually, and it's working ok over HPSS. [03:27] And that explicit raise is correct (although it maybe it'd be worth making a self._ensure_ok(response) helper like RemoteTransport uses?). [03:27] ok [03:27] please send it to pqm then [03:27] it does seem kind of buggy to me that so many of the client stubs check the response explicitly [03:27] (i may be out of date here, i know you landed something for this) [03:27] _translate_error handles responses that are flagged as errors, this is checking that a successful response doesn't have garbage (which is perhaps less useful now that error responses are clearly flagged on the wire). [03:27] ah i see [03:28] It's more interesting when the response may be one of a fixed set of values. [03:29] I think maybe that the client should be more liberal and not worry about the content of responses that it doesn't use in any way. [03:29] But atm we're pretty consistent about doing it this way. [03:31] Ok, it's with PQM. [03:31] I'm going to grab a late lunch. [03:49] when trying to push my branch(that I own)(bzr push lp:~/+junk/) [03:49] it says: bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Emichalski/%2Bjunk/vector-core/.bzr/branch/lock): Transport operation not possible: http does not support mkdir() [03:49] ... [03:50] michalski-bj: Run 'bzr lp-login your-username' [03:51] ok thanks, I think I remember doing this on my old pc, you should add these instructions to the error message [03:59] poolie: back [03:59] thanks again, gotta go, bye [04:12] Has that error message improved in a recent version? [04:15] [warren@newcaprica ldm-trunk]$ bzr diff [04:15] bzr: ERROR: [Errno 12] Cannot allocate memory [04:15] [warren@newcaprica ldm-trunk]$ bzr diff [04:15] === modified file 'src/ldm.c' [04:15] Really odd... [04:15] bzr-1.7-1.fc9.x86_64 [04:18] "Errno 12", huh? I wonder why that happens instead of a MemoryError? [04:19] Peng_: probably a C extension [04:19] Peng_: raising OSError(errno, strerror(errno)) [04:19] Oh, ok [04:19] warren: ^ [04:19] meaning? [04:20] warren: not sure about root cause; does this happen repeatedly for you? [04:20] lifeless: yes [04:20] lifeless: although not all the time [04:21] warren: there should be a backtrace in ~/.bzr.log [04:23] lifeless: http://fpaste.org/paste/8358 [04:24] hmm, I don't have a browser handy [04:24] warren: could you file a bug please? [04:24] umm, where, how? [04:24] https://bugs.launchpad.net/bzr/ [04:24] _readdir_pyx [04:25] Yay, autopack-rpc landed. [04:25] fullermd: interesting; readdir is ENOMEMing? - or - [04:25] warren: actually [04:25] warren: I bet that this is a fixed bug in 1.8 [04:25] warren: readdir has some special needs for errno handling [04:25] ok [04:25] we didn't have that correct in the first release of the readdir bindings [04:27] Seems like it. That's what errno 12 is on my system (though I'm pretty sure those vary a fair bit from system to system) [04:27] they're pretty stable for the common ones [04:40] lifeless: i'd like you to make a 1.9 branch when my current pqm job completes [04:41] approximately then anyhow [04:41] if it would be much easier you can do it now [04:41] poolie_: tell me when its ready, I've made the branch, just need pull over the top [04:41] kk [04:41] poolie_: I'm leaving for the train in < 10 minutes though [04:47] ok -> train (the 4:03 gets to town hall with at 15 to, allowing a timely walk with no crowds) [04:48] I'm looking at a similar trip, different train line :) === sdboyer|blaaah is now known as sdboyer === spm_ is now known as spm [07:04] hi all ! [07:33] * gour sent reply to 'bzr vs. git' thread [07:34] hopefull it will not turn into a [07:34] ... into a 'bzr vs git' thread [07:34] man, I can't type [07:35] i hope so too [07:35] i'll kill the thread if it does [07:35] life's too short [07:51] hi. i'm trying to set the BZR_SSH variable. how would i go about that? [07:52] on windows or unix? [07:52] win. [07:53] i created my SSH keys already and IDed myself. it suddenly then asks for BZR_SSH variable. [07:55] i'm using putty from openssh.org's site links. [07:57] getting tired of conservatives. [08:17] [08:18] newfeats: (back) what message are you getting exactly? [08:18] could you open something at http://answers.launchpad.net/bzr === poolie_ changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.9rc1 and format 1.9 | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ [08:33] poolie_: https://answers.launchpad.net/bzr/+question/49587 [08:34] newfeats: it's missing the main information, the actual error message [08:37] ok, i took a stab at it [08:37] good night though [08:38] hello :0 [08:38] :) [08:38] happy halloween === vila is now known as vila-dentist [09:56] Urgh [09:56] Bzr is eating all my RAM [09:57] PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND [09:57] 14032 wbolster 20 0 2492m 1.4g 1536 D 13 73.5 5:54.59 bzr [09:57] 2GB RAM in total [09:57] That's awesome. What the heck are you doing with it? [09:57] (Sorry, not helpful.) [09:57] just branching a repo [09:57] try for yourself: bzr branch lp:~uws/webkit-open-source/webkit.trunk WebKit [09:58] bzr 1.8 btw [09:58] PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND [09:58] No thanks. I've already got Firefox using all my RAM. [09:58] 14032 wbolster 20 0 2502m 1.6g 1520 R 100 79.8 6:22.60 bzr [09:58] Also eating all 100% of my CPU [09:59] well, one of my cores [10:01] Oh, that's your branch? [10:01] Jeepers, how large is it to cause that? [10:01] Peng_: it's huge [10:02] it's (not even up to date) mirror of the webkit svn repository [10:02] Finishing pack 5/5 [10:02] Yay. RAM usage dropped [10:02] What does "bzr info -v" do? Download the entire indexes? [10:04] Peng_: on my branch? [10:04] bzr is now eating 100% CPU in "Build phase 0/2" [10:04] whatever that may be [10:06] ai, RAM usage growing again :( [10:06] * uws waits for the OOM to kick in ;) === vila-dentist is now known as vila [10:10] uws: No, in general. I ran "bzr info -v" on your branch, and it was using a lot of bandwidth and the RAM kept growing (only to like 90 MB, but..). [10:10] What does "build phase" mean? [10:10] Oh..I guess I can check the code. :P [10:11] uws: building the working tree [10:11] takes 100% cpu for minutes already [10:11] and this is a relatively fast machine [10:12] Hmm...hasn't that been improved recently? [10:13] 1.8 is quite recent [10:13] the progress bar is halfway done and just advanced to "build phase 1/2" [10:13] * ``bzr co`` uses less memory. It used to unpack the entire WT into [10:13] memory before writing it to disk. This was a little bit faster, but [10:13] consumed lots of memory. (John Arbash Meinel, #269456) [10:13] That's more recent than 1.8. [10:14] Hm, good [10:14] Branched 29843 revision(s). [10:14] YAY! [10:14] Yay [10:19] hi. [10:22] it's been a while since I used bzr upload I don't remember how to put it through ssh I got bzr: ERROR: Unsupported protocol for url "sftp://... [10:23] or ssh:// [10:23] vila: Install python-paramiko [10:23] vila: then sftp:// ("dumb") and bzr+ssh:// ("smart") should work [10:33] oh [10:33] and for permission there is no way to have a post command that fixes them? [11:38] is ian here? [11:43] Pieter: Ian Clatworthy? [11:43] yes [11:43] it's the middle of the night for him [11:43] ah :) [12:08] aadassdfsd [12:09] spiv: aadassdfsd to you too. [12:12] Odd_Bloke: I would also have accepted "gesundheit" [12:13] if I have a 16000 path tree, is it going to be more efficient for bzr workingtree operations to have it split in to directories? [12:13] it's just a flat layout currently [12:29] james_w: I can't see why it would be any different, personally [12:31] it seemed to be taking an age to read the dirstate [12:31] it's not so bad now though, once it's reasonably up-to-date [12:31] This on Windows? [12:32] nah [12:32] I get the same ; once it's "warm" my tree of 4000 odd paths will `bzr st` in less than a second [12:32] On *nix it's rather faster though :-) [12:33] this is a rather odd tree [12:33] 16,000 files in one folder, yes, that's a little off [12:33] *odd [12:33] it's not source code or anything [12:34] just a bunch of log files [12:34] Heh, I can imagine [12:34] Why, pray tell, do you version logfiles? [12:34] Would it not be just as good to incrementally back them up? [12:34] it was Rob's suggestion, though I think I'm implementing it wrong [12:35] Since a logfile, in my experience, is not mutable once it's finished? [12:35] I think it's supposed to clear the tree after committing [12:35] Meh? [12:35] so it's instead of logrotate [12:35] I'm using it as a kind of logwatch [12:36] What, sort of "bzr commit -m "Lots of logs" ; rm * ? [12:39] hmm, can't find where Rob uses it to compare [12:40] it's on bzr-playground.gnome.org somewhere, but I think it's hidden [12:51] james_w: Oh, is it supposed to be renaming each rotated log to the same filename? [12:51] yeah, I think that's what Rob does [12:51] james_w: that way you can compare the logs to each other based on their diff (and presumably spot anomalies easier)( [12:52] Works ok as long as your diff viewer supports rules to ignore timestamps I suppose.(or if you set your log formats to omit them) [12:52] though his is in in-process, so it just writes the log, commits, and then removes it. I can't really do that, as I have four processes [12:52] james_w: How about - write log until finished, rename log to a file that ISNT in your ignore pattern [12:53] Have job that watches for new non-ignored files [12:55] yeah, that could work [12:57] I've been using it to diff my output from a program so I know if I break it (in the absence of proper unit tests /me slaps own wrist) [12:57] :-) [12:57] It spits about 9000 files so it's v. useful on that score [13:27] What are split-inventories? [13:46] don't suppose anyone's updating http://doc.bazaar-vcs.org/bzr.dev/en/release-notes/NEWS.html for the 1.9rc1 release? [14:03] is there a known winstaller for a bzr-svn that works with a newer bzr than 1.5? [14:15] Tak: Hi [14:15] Tak: I think John was looking at creating one for 1.8 last night [14:15] not sure what the status of that is [14:15] jam: ping === Spaz is now known as Black_Kittens [14:18] jelmer: hello, cool [14:19] Tak, btw, did you see my changes to monodevelop-bzr? [14:19] yeah, I'm just merging them into my branch now [14:20] I was just going to ask how things were going wrt md-bzr [14:21] I'm still waiting for a new version of monodevelop to hit debian sid :-/ [14:22] heh [14:22] that won't happen until after mono 2.0 hits [14:26] "bzr: ERROR: Repository KnitPackRepository is not compatible with repository KnitPackRepository" [14:27] Tak: One repo is --pack-0.92, one is --rich-root-pack. [14:28] Tak: And the error message has been improved, I believe. :) [14:28] * Tak waiting for new bzr to hit debian sid :-P [14:28] Oh, really? That's good. === thekorn_ is now known as thekorn [14:38] tak: there's new versions in experimental [14:51] hm @ experimental [14:56] argh, now my wc is rich-root-pack and my lp branch is an old format - how do I resolve this? [14:58] Tak: Well, you could upgrade the lp branch, or you could push your current branch to a non-rich-root repo to downgrade it (probably). [14:58] Err, wait. [14:59] Or pull it into a non-rich-root repo. [14:59] I tried to upgrade the lp branch [14:59] I dunno. *Something* like that should work, if someone didn't go and break it. [14:59] some of the other branches are rrp, so it's going to be a pita if I can't convert mine somehow [14:59] Tak: What happened? [14:59] Tak: You might have to use the full bazaar.launchpad.net URL, and you might have to use sftp [15:00] (Yes, this is a pain.) [15:00] hmm, I tried the bzr+ssh url [15:00] I'll try others [15:04] ok, it looks like it's going with sftp [15:08] success! [15:12] Great. :) [15:13] Yes, the SFTP works, I don't think the smart server does upgrades [15:14] I thought that had been added recently (1.6?), just thunking over to the VFS. But that might've been something else. [15:14] Hmm, which version is Launchpad running though [15:15] jelmer: do you have plans to upload bzr 1.9rc1 to debian experimental? [15:15] tvainika, Yeah - I just wasn't aware it was out already :-) [15:16] awilkins: 1.7.1rc1 [15:17] upgrade over bzr+ssh was added in 1.6rc2. [15:17] But I think there are issues with LP. [15:19] what's the "--strict" argument to testament for? [15:21] james_w: It seems to produce a different hash [15:21] james_w: Why this is, I'm not sure [15:22] yeah, that's what concerns me [15:22] Theory - the strict has includes the log comment [15:22] git hashes include their log comments, perhaps bzr does not by deafult [15:23] it adds in ie.revision and ie.executable to what is hashed for each ie [15:25] When I get a 'bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)' What should I check? I know there is connectivity and the user has permission (tested from another PC) [15:26] chrisob: What's the server? [15:27] an internal linux server, I dont know if thats what you mean though. I have only just started supporting users on it... [15:28] Hmm, which protocol are you using [15:28] SSH [15:29] Ok, can this machine just open a plain old shell using SSH for that user? [15:29] bzr info bzr+ssh://@ [15:29] Ah, how about - is this machine running ssh-agent with the appropriate key loaded [15:30] well it has no problem with another shell connection using ssh [15:30] i though it could be a key problem === sdboyer is now known as sdboyer|class [15:31] though i dont know where it references the key [15:31] ls [15:31] oops [15:36] chrisob: It should just choose try all the keys in the local ssh-agent against the server and see if they work for the user you are specifying [15:38] okay thought so....thanks for the help [16:16] jelmer: bzr.dev get svn://svn.twistedmatrix.com/svn/Twisted/trunk twisted-bzr-svn [16:16] bzr: ERROR: The branch svn://svn.twistedmatrix.com/svn/Twisted/trunk has no revision None. [16:16] jelmer: ^ seen that one before? [16:16] mwhudson, yeah [16:16] mwhudson, what version of bzr-svn? [16:17] jelmer: lp:~jelmer/bzr-svn/0.4/ as of a day or two ago [16:17] hmm [16:17] jelmer: i'm updating now, will try again [16:17] mwhudson, please file a bug [16:24] mwhudson, I did fix some things related to this, but more than a month ago [16:24] it's actually another exception masked by an exception handler in bzrlib/builtsin.py === lamont` is now known as lamont [17:11] jelmer: still happens with trunk everything [17:11] * mwhudson embuginates [17:19] jelmer: https://bugs.edge.launchpad.net/bzr-svn/+bug/291686 [17:19] Launchpad bug 291686 in bzr-svn "branching twisted svn fails with "bzr: ERROR: The branch svn://svn.twistedmatrix.com/svn/Twisted/trunk has no revision None."" [Undecided,New] [17:34] mwhudson, thanks [17:34] mwhudson, isn't it like 4 in the morning in NZ btw? [17:34] jelmer: i'm in london :) [17:34] ahh :-) [17:42] asmodehn: hey, I just saw your email. The change I made isn't in 1.9 AFAIK === sdboyer|class is now known as sdboyer [18:08] jam : yeah that what I realized... I am using your dev versions now to replicate what I have to ;) [18:09] hopefully it ll go to the end this time ;) [18:14] well, worst case I suppose you could use rsync [18:16] I tried that but I am not sure yet how to properly use it [18:16] but yes for now I ll keep using your dev version ;) [18:16] at least for the big transfers [18:16] 1.9rc1 for the rest I think === mark2 is now known as markh === sdboyer is now known as sdboyer|gazpacho [18:51] jam : mmm doesnt finish... hit the other bug I posted to the mailnig list :-s [18:52] asmodehn_: the ldap one? [18:54] yep [18:54] just sent another email with the end of the log [18:56] but yeah maybe I should play with rspush instead :s [18:57] so... the locking thing seems like a more significant issue that you need to resolve. [18:57]