[00:00] I wonder why bzr allows arbitrary :aliases for branch URLs but restricts it to a hardcoded set. [00:00] The bookmarks plugin could be obsoleted by removing that restriction. [00:01] It doesn't allow arbitrary :aliases. [00:03] jelmer: we get significant performance boosts not string joining unnecessarily [00:04] lifeless: What about modifications of individual characters or slices in strings? Does that cause new objects to be created? [00:04] yes [00:05] Ah, I see where it maps those. [00:05] jelmer: "foo" -> "fbo" requires a new string to be created [with some minor exceptions only usable inside the C api] [00:05] lifeless, that's what I figured - so mmap is the only way around it? [00:05] jelmer: without writing C [00:05] hmm [00:06] poolie, obviously in a few days [00:06] I'm looking atht his with knits and gc at the moment too, you see [00:06] poolie, more text, that is :) [00:06] nice [00:06] lifeless, So I'm first going to see how far I can get without writing C extensions for dulwich [00:06] it would be really nice to keep it completely Python [00:07] some of the things I'm looking at are caching the raw texts using a LRUCache [00:07] poolie, so can we write the book at that bzr hackfest? :) [00:07] and when is that going to take place? [00:08] you can fake a mutable string with array.array('c') [00:08] _do not_ write c to modify pystringobjects [00:08] mwhudson: at what cost [00:08] (not that you were i hope) [00:08] mwhudson: of course not [00:09] lifeless: depends what you're doing, array objects support the buffer protocol so e.g. writing them to files shouldn't be significantly slower than strings [00:14] mwhudson: probably slice assignment [00:15] i think in the easy cases that's just an memcpy [00:17] * markh pipes up that the 'b' format string will turn out to be more py3k-friendly [00:19] ah yes, probably [00:19] i'm a python2 programmer, the difference between b and c confuses me :) [00:21] me too - but when porting code using 'c' and strings to py3k, it is almost *always* a simple matter of encoding it to bytes and using 'b' - while the py2k version can (optionally) avoid the 'encode' step for str() objects... [00:21] but still use 'b' as before [00:21] err - still use 'b' and work as it did before with 'c' [00:38] wow [00:38] 'b' is signed char [00:38] not 'byte' :P [00:44] That's one of those little tricks to make sure people read the docs :p [01:01] would this be the place to ask question about making a bzr mod? [01:08] leefmc: sure [01:08] lifeless: Thanks. [01:09] lifeless: Ok, well a while back i was questioning using bzr for project management, then i went down a few other roads, and finally i've come to the point where i need to make my own project management system. [01:09] Basically just synchronizing folders (with a few other things). [01:10] Now in the end, i can do this, but bzr is so capable of doing this. So i was pondering if it would be easier to make a mod for bzr so that bzr could have a repository inside a branch, or if my own solution would be needed [01:10] lifeless: Any thoughts? [01:11] I don't know quite what you mean by a repository inside a branch [01:11] lifeless: Making a repository, sit inside the directory of a bzr branch. [01:11] lifeless: ie: repo/branchA/repoB/branchB [01:12] uhm [01:12] do you want multiple branches there? [01:12] lifeless: where [01:12] branchA/repoB/branchB{1,2,3,4} ? [01:12] lifeless: repoA or repoB [01:12] well, yes, to both. [01:12] ok, so this is very different to nested trees [01:12] I think [01:13] Well, assuming i understand you.. not really. i dont see how /repoA/branchA/repoB/branchB[1,2,3] is any diff than /repoA/branchA/repoB/branchB [01:14] nested trees don't do repoA/branchA/repoB/branchB [01:14] they do branchA/branchB [01:14] in bzr repositories are *not semantic* [01:14] they are only storage optimisation [01:14] oh i see what you mean, yes, this is very different. I want a repository inside a branch. :) [01:15] well, you seem to want branches in a brnach [01:15] but you keep putting a repository there for some reason I don't quite understand [01:15] no, /repoA/branchA/repoB/branchB, i want repositories inside a branch, heh [01:15] because if you just wanted a repository in a branch, you wouldn't include the branchB [01:16] lifeless: Well if i have a repository inside a branch, what good is it without having branches itself? Perhaps im missing a part of bzr, but isn't there... "nothing" without a branch? [01:16] an empty repo does me no good.. heh, i want to use repoB [01:16] leefmc: right, there isn't anything without a branch, which is why I don't understand why you are asking for a repo in a branch [01:16] hence branchB [01:16] rather than a branch in a branch [01:16] leefmc: *why* do you want repoB to exist [01:17] lifeless: heh, i was hoping i didnt have to go this far :p, but ok. [01:17] This is about project management. [01:17] seriously, why not branchA/branchB{1,2,3} [01:17] im typing [01:17] My need is to have projects be uploaded to a central server, so i can download them from any computer, work on them, then upload, etc. [01:17] Not really revisioning [01:18] Now each project can often have programming projects, some are design, etc. [01:18] Really a project is very generic in my eyes. [01:20] So now with that said, i was hoping to avoid some trouble and use bzr + mod to make this happen. Otherwise im writing a small app for python to scan directories and synchronize everything, etc. [01:20] Now as far as a branch of a branch.. well i dont really want one project polluting another.. I mean, i've never delt with sub branches, but i cant name a branch "pytest" then, because another project might have that heh [01:21] half of my projects have the generic "trunk" for a branch. [01:21] I'd end up naming every branch as "project_name-subproject_type-somename" heh [01:22] In the end, im guessing i'll end up writing a python script :o, you didnt seem to jump up and say "oh its super easy!" so im guessing its easier to go with a custom app of my own. :o [01:22] lifeless: So thanks for the discussion :) (I swear i've had this with you before though haha) [01:22] igc: I've read the log thread; totally at a loss so far - skype if you're awake would be good [01:23] I've actually discussed this very same core problem.. 3 times in this channel? Cept now instead of trying to find an easy side-step to the problem, i just need to get it done right heh. [01:23] leefmc: well, I'm trying to understand [01:23] leefmc: and I don't - if they are things you can just version, just doig 'bzr init' in each 'project' and then using multi-push and multi-pull should be enough [01:24] stop mucking around with 'repositories' - None of your explanations mentioned repositories, so clearly you don't need them [01:24] Well, it IS super easy. You just put it there. But it doesn't DO much of anything. [01:24] lifeless: I thought you needed a repository to have branches/ [01:24] I mean, you can put a unix domain socket inside a branch too. Doesn't mean bzr does anything with it. [01:24] leefmc: NO, repositories are *not semantic* they are totally unecessary [01:25] lifeless: Hmm, so wtf are they for? [01:25] leefmc: they are what bzr stores its history data in [01:25] lifeless: So.. what history is not needed? [01:25] leefmc: if you have many branches of the same code, using a repository to let them share their storage is more efficient [01:25] leefmc: if you haven't manually created a repo, bzr creates one when it needs it [01:26] leefmc: they are where your history lives. They can [as an entirely optional optimization that can be useful in some cases] sometimes be shared between branches. [01:26] leefmc: but unless you have multiple branches of the same thing you never need to think about repositories [01:26] leefmc: and you don't have that, from what you are saying [01:26] lifeless: Well.. i do, what if i duplicate a branch of code? [01:26] leefmc: then you have two branches [01:27] leefmc: At heart, every Working Tree has a Branch and a Repository. In more advanced layouts they are not in the same place, but in simple cases [ie, starting out] they are co-located. [01:27] lifeless: In otherwords, what do you mean by "multiple branches of the same thing"? [01:27] leefmc: you can have as many copies of a branch around as you care to have [01:27] leefmc: multiple branches of the same thing on the same machine [01:27] bzr branch A B [01:27] lifeless: Ie, i dont want to run into a problem of bzr "deciding it needs a repository" [01:27] leefmc: there aren't any [01:27] leefmc: I think your problem is that you are thinking about repositories; stop doing that [01:28] leefmc: and it will all become much simpler [01:28] lifeless: Well im only thinking about them because they are the problem, and you just mentioned that bzr will decide if it needs one or not. [01:28] leefmc: humour me [01:28] leefmc: delete the concept from your head for a while [01:29] lifeless: (with hindsight I wonder if you guys wouldn't have be better off calling it "Storage" or "Revision Stash" or something; "repository" seems to carry too much baggage for people from the old world, even if it is an accurate term) [01:29] lifeless: Heh, alright, im just afraid of ended up sh*t creek heh [01:29] leefmc: you won't [01:29] leefmc: because Branches are *the key concept* [01:29] leefmc: Bazaar never leads you up shit creek. That's what makes it different. [01:29] AfC: "basket" was championed. [01:30] fullermd: anything. Doesn't matter. Just not "repository" (again, with hindsight) [01:30] lifeless: So can i have this directory structure? "/brA/brA.A /brA/brA.B /brB/brA.A /brB/brA.B" with no problems? [01:30] yes [01:30] alright, sounds good, i'll give it a shot :) [01:31] fullermd: too late now. [01:31] fullermd: and nothing wrong with telling people they need to learn the current (ie, this project) actual definition of a term. [01:31] Yea in the quickstart, iirc, repos are added, and i always assumed they were done so for a good reason heh.. i never even would have fathomed that repositories are useless.. heh [01:32] So there is no case where i could find myself missing a repo? [01:32] leefmc: they're not useless. They're just something that is internal, and you don't need to think about it right now. [01:33] AfC: Heh, not thinking about something "right now" scares me, when it is the core structure of hundreds of projects i am converting. [01:33] AfC: Thats like not bothering to figure out what an extra piece is. heh [01:34] leefmc: changing layout later will not harm you. Branches are the first class entities and are peers. The rest is all supporting infrastructure that comes and goes. All you need to worry about, really, is where your branches are, and where your Working Trees are. For most common uses, the two are the same. [01:34] Not arguing with you guys ofcourse, i obviously know nothing, im just trying to understand where this plays in. I keep getting hints that repos have a use, but then im told to ignore it, and etcetc [01:34] leefmc: I've told you the use, and so has AfC [01:34] lifeless: concurr [01:35] More to the point, if you DO decide to bring repos into the mix later, it's *VERY* unlikely that you'd cram them in the middle like that. [01:35] So they wouldn't affect that layer of thinking anyway. [01:35] leefmc: to reiterate: they are used internally for the historical data storage, and can be explicitly configured by users to cause multiple branches with the same history to use the same store [01:35] ... but if you don't explicitly do that, no big deal. [01:35] heh [01:35] so get on with it already [01:36] AfC: for me it will be "project_branches&trees/projectcodebranchA,projectcodebranchB,projectworkingtree" [01:36] roughly [01:37] {shrug} sounds hugely overcomplicated to me, but whatever. [01:37] AfC: It is, using bzr. [01:37] that reminds me of tlas name-schemes.. :) [01:37] * sii goes back to lurking [01:38] sii: Heh, its not a naming scheme, but i had to explain what each folder was [01:38] leefmc: look, here's what we do [and this is what is described at http://java-gnome.sourceforge.net/4.0/get/#source ] [01:38] leefmc: ~/src/java-gnome is where I collect my branches. [01:38] leefmc: *as it happens* I have done `bzr init-repo` there so that all the branches underneath it share storage [01:39] leefmc: but I could have easily skipped this [01:39] sii: Really its just a project, and that project can have code in it that needs to be versioned. The project itself is strictly for me, so thats never uploaded to servers, but the code within the project, is uploaded to launchpad/etc [01:39] leefmc: thats all fine [01:40] sii: eg: /projects/some_website/code/trunk && /experimental && /working_tree [01:40] leefmc: that will work fine [01:41] if the projects are very big you may want to init-repo projects [01:41] but if they are small as most website projects are its totally unneeded [01:42] lifeless: So if i type "bzr push" inside of /trunk it will upload to launchpad, but if i "bzr push" inside of "some_website" it will upload it to my local server. Will that local server push include /code/trunk && /working_tree ? [01:43] i assume yes.. but i just figured i'd ask heh [01:44] leefmc: no it won't, because trunk and working_tree are different branches [01:44] leefmc: multipush will I think [01:44] argh :o [01:46] The point being, that i dont wanna push unfinished/committed code of /trunk to launchpad, so i just push my project to my local server. I dont want to have to push/pull 5 different branches everytime i change computers heh. [01:47] I really do thank you all for the help heh [01:47] leefmc: then things like ~/src/java-gnome/one and ~/src/java-gnome/two and ~/src/java-gnome/something-else are the branches. That's it [01:47] My apologies for the trouble. Im just as frustrated, trust me heh. [01:49] AfC: Yea i understand that, but in my case, i'd also be pushing java-gnome. Not to mention i dont wanna push /one to launchpad, nor any other branches if they're unfinished, so i end up pushing them to my local server aswell, which also means im giving bzr a new place to push instead of the saved location, so i have to type that in, etc. [01:50] leefmc: grab the multipush plugin and test it out [01:50] leefmc: I feel like I say this every third sentence or so [01:51] On my quickly crap made app for this, i just type one command and it syncs it all, etc. It has problems though, which is why im going all out with the next version of it, but given that i'll be scanning entire file structures and syncing, bzr is so fast for this, i was hoping i could mod it to do that. In the end i think the biggest problem here is my desire to use bzr to do something its not intended for. Its not a workflow that bzr is fi [01:51] t to use, and its not sposed to be heh [01:53] leefmc: will, it sounds like your options are a) to use Bazaar the way it's supposed to be used, or b) to write your own version control system. [01:54] AfC: Well thats the great thing, my projects are not in need of versioning, bzr was simply a bonus.. if it could work heh [01:54] Whereas, c) constantly saying what you want to do instead of keeping it simple and using the tool for what it is designed for is not an option. [01:55] AfC: Well what i want is what i want heh, if i cant use bzr, so be it heh.. But in reality, that _is_ what i was here asking about.. if bzr would work for it.. [01:55] I hope you'll chose (a). At that point, I imagine people around here will be able to help you. [01:55] AfC: Well keep in mind im not abandoning bzr for code versioning.. [01:56] AfC: Im just abandoning it for project management. [01:58] My apologies for asking such a loaded question heh, but you guys did help me find an answer, and i thank you. [01:59] Anyway, i gatta go, i'll be back later, thanks again :) [03:15] D'oh. After pulling the latest, 'bzr.dev info' fails with an error about bzrlib being too new. [03:16] st, log, pull, and other commands are fine though. [03:16] ToyKeeper: could be a plugin [03:17] Yeah, it works without plugins. [03:18] Okay, it was bzr-svn interfering. [03:20] Yay, after getting that fixed, it was really easy to make arbitrary :aliases work. [03:28] I'm not sure why you need that, can't the bookmark plugin just define things freeform? [03:30] Why bother with a bookmark plugin when 4 lines in bzrlib can do the same thing? [03:31] well [03:31] maybe its better? [03:32] Really, this does everything I've ever wanted for bookmarks: http://rafb.net/p/3OKRhr80.html [03:33] echo 'foo_location = file:///tmp/foo/' >> .bzr/branch/branch.conf ; bzr push :foo [03:35] hmmm [03:35] well, I'll let others comment [03:37] I'd imagine it would need a bit more before being acceptable... tests, code to include them in 'bzr info', and a command to set aliases. [03:38] personally, I'd really rather not have a :foo for user defined locations [03:38] just 'foo' [03:38] That would be even better. [03:38] and I don't like NAME_location as a config key [03:38] I don't either. In both cases, I just followed existing convention. [03:39] it makes iteration hard, and can clearly collide with completely unrelated plugins that choose to have something called a THING_location [03:39] well no [03:39] you followed specific case code in bzrlib that doesn't do pattern matching [03:39] and that *has* to avoid colliding with user URL's and paths because its being globally defined by the tool [03:39] neither of which are relevant to your use case: arbitrary names aliases that the user can define [03:42] parent_location and push_location are already used, at least. I'm not sure if the others follow the same pattern. [03:42] the are chosen names [03:43] if a plugin creates e.g. search_parent_location = True [03:43] then doing 'bzr push search_parent' won't try to push to a directory called 'True' [03:43] Yeah, I don't like the _location suffix either. :) [03:43] so don't use it! [03:43] :) [03:43] Also, they're not aliases that we store locations for. They're locations already stored for other reasons, that aliases were added for as a convenience. [03:44] That calls for slightly different implementation than "adding aliases" :) [03:44] If user URLs and special URLs used the same namespace, it might simplify things. [03:46] Anyway, just wanted to check how the general concept went over. [03:47] I'm dearly in favor of the general concept of "in-base user aliases". [04:55] Hello. In a merge bundle, is revision's branch nick encoded anywhere but the field? [04:56] each revision has its own nick, which is in the properties [04:56] the bundle also records the branch that the bundle is claiming to be from, but I don't think it grabs the nick of that branch [04:56] Yes. But is it encoded anywhere but the XML element? [04:57] no [04:57] I am changing the XML element, but the commit message after applying the bundle shows the old nick. [04:57] "bzr bundle-info" shows the new nick [04:57] uhm [04:58] if you change the metadata in a revision it won't propogate, bzr assumes that such data is immutable [04:58] revisions are write-once; if you want to change something you need to create a new revision with whatever changes you want made to it [04:59] the rebase plugin can help with this [04:59] but its not a common operation, so not very polished [04:59] I would presume that were it successfully changed, merge would refuse to pull the revs out of the bundle... [04:59] I want to understand what happens first. I have two theories: (a) the nick is encoded in the bundle somewhere else or (b) the old nick gets resurrected from the repository based on revision ID or something like that. [04:59] fullermd: well, properties are advisory metadata not core, so they are not checksummed like tree contents are [05:00] rousskov: its part of a revision object in the repository; if you're working with the bundle in a repo that has seen the erevision before the revision is not decoded out of the bundle - it is skipped over [05:00] lifeless, this sounds like (b). [05:01] rousskov: indeed [05:01] So I should create a brand-new repository, right? So that it has never seen the old commit messages on a private branch? [05:02] rousskov: no, you should create new revision objects rather than trying to edit existing ones [05:02] But I have too many of them. [05:02] rousskov: help me out here :) [05:03] are you talking 10^5 or 10^6 revisions [05:03] I mean I have, say, 100 commits to a private branch. I want to share those commits with the world, but I do not want to share the branch nick [05:03] is the nick the only metadata that you need to change? [05:03] Yes, the only thing I do not want to share. [05:04] ok, two things we need to discuss; first how to make sure you don't have this situation again; do you know of the 'bzr nick' command? [05:04] I could, of course, just apply a dumb patch. I would prefer to preserve the history though. [05:04] lifeless, yes, now I do. But I did not at the time. [05:04] rousskov: ok cool [05:04] now for data cleansing [05:04] this is offhand, but I think the recipe is roughly: [05:05] bzr branch source_branch clean_branch -r before:first_problem_revision [05:05] cd clean_branch [05:05] bzr nick newnick [05:05] bzr rebase ../source_branch [05:05] and it should take a few minuts [05:06] *minutes* [05:06] What is source_branch? The private branch I want to clean? [05:06] yes [05:07] Hm.. Would not before:first_problem_revision simply ignore all the changes on that branch? [05:07] thats the idea [05:08] you want a branch that starts exactly where your current branch started [05:08] then you rebase everything from it to the new branch [05:08] as I recall rebase discards the nick as it goes [05:08] but let me check [05:08] So, if you are right, "rebase" will bring back all the changes, but not the nick? [05:09] oh damn, it will preserve the nick [05:09] gimme a few minutes, I'll whip up a branch of rebase that won't [05:10] FWIW, there were no revisions on the source_branch before the problem_revision. [05:10] rousskov: oh, I was assuming it was squid [05:10] It was branched off a public branch (and all the changes should now go back to that branch). [05:11] You may assume squid, yes. [05:11] so the history of the branch is much deeper than the changes you've made - bzr doesn't record an explicit marker when you run 'bzr branch' - which is why there are revisions before problem_revision on the branch [05:11] OK. Understood. [05:13] this will take a few minutes, my machine is in the middle of a very memory heavy analysis, a little thrashing involved :P [05:13] Thank you for taking the time to help me. [05:14] no probs [05:33] nearly there [05:43] * rousskov stands by. [05:50] rousskov: I have it working but with a small caveat that is part of the current rebase UI [05:50] rousskov: I'm going to describe this, and if its ok with you we'll just go ahead, if its not I'll fix that now as well, or at least work around it [05:50] Sure, go ahead [05:50] rousskov: so the caveat is that to rewrite the revisions, rebase wants something *new* in the 'parent' branch its rebasing from. [05:51] think of rebase as moving all your work out of the way, doing a pull, then one by one replaying them back into your branch [05:51] if there isn't anything to pull it assumes it has no changes to make [05:51] (which in this case is false) [05:52] It is easy for me to commit to the dirty (or clean) branch. Is that what is required? [05:52] yes [05:52] just a 'bzr commit -m "Prepare xxx branch" --unchanged' [05:52] will do it [05:52] (don't do it now) [05:52] ^C [05:52] the effect is a single revision in the log that is rather meaningless [05:53] OK. At what point in your original process do I do an empty commit? [05:53] I'll check in a smoke test for this, push the branch and point you at the rebase plugin, and then give you a step by step [05:54] That is what I call service! [05:56] actually, we may not need that little workaround, found a command I thought existed but couldn't find for a bit :P [05:56] let me finish these tests === k4v is now known as m4v [06:14] rousskov: ok [06:14] mkdir -p ~/.bazaar/plugins [06:14] bzr branch lp:~lifeless/bzr-rebase/dev ~/.bazaar/plugins/rebase [06:15] Branched 115 revision(s). [06:15] identify the first revision before the revisions you created in the badly nicked branch [06:15] e.g. bzr log [06:16] once you've found that number: [06:16] bzr branch -r THATNUMBER badly-nicked-branch fresh-branch [06:16] cd fresh-branch [06:16] bzr nick NICKYOUWANT [06:16] bzr replay -r -1 ../badly-nicked-branch [06:17] I have some other things I need to do [06:18] I"ll check back in in 10-15 minutes [06:22] Strange: Text conflict in src/cf.data.pre [06:28] lifeless, I resolved the conflict but running "bzr rebase-continue" yields "bzr: ERROR: No rebase to continue" [06:30] Hm. You told me to replay, not rebase, so perhaps that is OK. [06:37] I see many differences between $badly and $fresh so I am guessing replay stopped at some unknown point due to a conflict. [06:42] bzr log in $fresh shows revisions up to and including $THATNUMBER [06:48] rousskov: are you sure you got the right start rev? [06:48] there shouldn't be any conflicts [06:48] It was the smallest revision with bad nick minus 1 [06:49] THATNUMBER=the smallest revision with bad nick minus 1, based on bzr log in $badly [06:49] ok [06:50] lets do rebase then, it could be something odd about replay [06:50] delete fresh-branch [06:50] bzr branch -r THATNUMBER badly-nicked-branch fake-upstream [06:50] bzr branch badly-nicked-branch fresh-branch [06:50] cd fake-upstream [06:50] bzr commit -m "Prepare DESCRIPTION branch" --unchanged [06:50] cd ../fresh-branch [06:51] bzr rebase --new-nick ../fake-upstream [06:51] What is the best way to delete fresh-branch? [06:51] rm -rf [06:52] Would not it remain in the repository? [06:52] yes [06:52] OK [06:56] rousskov: is that working better? [06:57] I am about to run rebase [06:58] Hm. Should I specify nick anywhere? [06:58] in fresh-branch [06:59] So I can leave it as-is if the $fresh directory name is OK, right? [06:59] yes [06:59] It is committing something [07:00] well thats a start [07:00] Done [07:01] Nick appears to be fixed. [07:01] cool [07:01] I'm offf for the night then [07:01] jelmer: when you get up - merge request in lp for it [07:03] lifeless, but the result is not the same branch I started with [07:03] I mean, running "diff -ur $badly $fresh" shows many differences in sources. [07:05] thats unusual [07:05] what do the changes look like [07:08] It looks like some of the changes from the trunk were not pulled in [07:08] thats weird [07:08] uhm [07:08] The $badly branch was synced with trunk a few times [07:08] jelmer: are you around [07:09] rousskov: I'd like to check a factoid or two with rebase' author [07:09] OK. Thanks for all the help so far. [07:11] I'll chat to jelmer my morning, if you can wait [07:11] I probably have to bail very soon :-( [07:11] and see if this known/expected [07:12] The missing changes have lower r number than THATNUMBER [07:12] thats extremely odd [07:12] But they were pulled into the branch later [07:12] * rousskov is not explaining well [07:13] hi all [07:13] if you could drop me a mail perhaps with a little ascii art or something [07:13] I could show it to jelmer (who is european) [07:13] in about 14 hours [07:13] hey lifeless ! Nice to cross you here ! [07:13] vila: hi, I'm just going in fact [07:13] I thought so, nice anyway :) [07:14] lifeless, If I do "bzr log" I can see my "merged from parent" message, referring to Amos changes. The original r number for Amos changes is smaller than THATNUMBER but the r number of my commit is higher. [07:14] lifeless, I will send email. [07:17] thanks [07:17] gotta run === asac_ is now known as asac === Peng__ is now known as Peng_ === asac_ is now known as asac === thekorn_ is now known as thekorn [10:51] igc: ping ping, still around by chance ? [11:20] hey vila [11:20] i'm just off myself though [11:20] hi poolie ! [11:21] poolie: still there a few minutes^W seconds ? [11:21] :) [11:42] jelmer: ping [11:44] jelmer: just an fyi, the "bzr co" on latest bzr-1.11rc1 and bzr-svn 0.5 branch hangs indefinitely [11:51] jelmer: scratch that, false alarm [14:36] bzr: ERROR: Unknown record type: '\r' [14:36] A repo suddenly cannot be bramnched, with that error. [14:36] I know it worked a few pushes ago. [14:36] The local repo is fine. All I've ever done with the repo is to push things to it over ssh. [14:37] Anyone recognize it? Google found a bug with a similar problem (though a different character for the unknown record type). [14:37] scode: can you grab the backtrace out of ~/.bzr.log? [14:37] This is with bzr 1.9 (server) and 1.10 (clien). [14:37] what was the bug number? [14:37] james_w: checking [14:37] james_w: 304848 [14:37] bug 304848 [14:38] Launchpad bug 304848 in bzr ""Unrecognised container format" after push" [High,Incomplete] https://launchpad.net/bugs/304848 [14:38] james_w: Hold on,w ill find a paste bin for the trace. [14:40] james_w: http://paste.lisp.org/display/73633 [14:40] this is over ssh? [14:40]