[02:15] Is there any way to undo a commit? [02:19] bzr uncommit [02:40] lifeless: thanks [02:55] uh [02:55] 1) are there any loggerhead maintainers in here? (or should I ask in #lp or #lp-dev) [02:56] I filed about 2-3 bugs and they're still filed "NEW" [02:56] loggerhead is a little light on maintainers at the moment [02:56] ok [02:56] here is as good as any place [02:56] uh, I also filed a bug on LP and a bug on bzr. [02:57] how long ago ? [02:57] uh [02:58] lifeless: April [02:58] and they're still new ? thats unusual [02:58] url? [02:58] lifeless: er whoops, thought it was new [02:59] lifeless: er, the bzr one has had progress [02:59] lifeless: the LP one I believe is "New" [02:59] do you know the number? [02:59] lifeless: er, it's Triaged. There's been a tag, but that's it [02:59] there are lots of lp bugs :) [02:59] https://bugs.launchpad.net/launchpad-registry/+bug/569356 [02:59] Launchpad bug 569356 in Launchpad Registry "The download background "sliding door" needs more width. (affected: 1, heat: 3)" [Low,Triaged] [03:00] This one seems a very, very easy one to fix [03:00] But yeah, the two Loggerhead ones are the ones that I hate the most [03:03] I wish loggerhead had more devs [03:03] :) [03:22] lifeless: me too [03:23] thumper: do you have any ideas about where we can find them? [03:24] thumper: could lp-code start owning it again, perhaps? [03:24] lifeless: while I'd love to, we don't have any development time to invest [03:24] lifeless: we're already letting things slip [03:28] thumper: is that because your team size changed, or your accepted too much work, or something else? [03:29] lifeless: primarily team size [03:29] sounds like something that should, in principle, be fixed. [03:29] eventually. [03:32] maybe [03:33] parly it requires someone who cares about the project [03:33] definitely [03:33] I guess I see the lp-code team as that in the sense that its deployed in LP :) [03:33] maybe thats not enough. [03:34] no it is not enough [03:34] we don't really use loggerhead [03:35] sure, we have it deployed on LP [03:35] but I really don't use it that often [05:11] Git user's question about BZR: I want to branch my current branch, then commit that new branch back to my server while I work on an experimental feature [05:11] How would I do this? [05:14] bzr branch . ../new; cd new; bzr push $server_url [05:14] or just bzr push $server_url, and then keep working [05:14] if you want to let trunk move on for a while, you might instead do [05:14] bzr branch . ../new; $work_in_new_for_a_while [05:15] bzr merge ../new; bzr commit -m "merge in some progress"; bzr push [05:16] That worked! Thanks :) [05:16] anytime [05:28] jelmer: ping [06:32] Hello? [06:34] hi [06:46] Hey lifeless [06:47] I wasn't paying attention to the chat. You still here? [06:47] passing through from time to time [06:47] its roughly dinnertime here [06:48] Gothca. About 1:45 AM here (US EST/EDT) [06:48] I do have a quick question for you if you have a moment. [06:48] sure; in general just ask your questions [06:49] in this medium, someone will usually answer eventually [06:49] Would I easily be able to change my repository style once it's made? [06:49] what do you mean by style ? [06:50] feature branch, colocated, shared repo, etc. [06:50] sure [06:51] the only thing that isn't easy to change is the /format/ - which you shouldn't need to be concerned with at this point [06:51] If I need to, I'm confused on how to do this as... [06:51] so just go ahead and play [06:51] 1) I forgot what I chose when setting it up... [06:51] ...and 2) not files are listed on the seerver. I am not sure if this is normal. [06:51] bzr branches and repositories store their files in .bzr/ [06:51] *no files [06:52] yeah, I looked in the .bzr folder on the server [06:52] its a form of database. So your source code is only present on your workstation [06:52] this is normal [06:52] no files are readable...I'm assuming they're all compressed/packed [06:52] ah, OK. [06:52] what would I do in a case in which I wanted the files to be accessible? [06:53] well it depends on why [06:53] for instance [06:53] if you want to deploy to a web server; use the bzr-upload plugin [06:53] if you want to browse the files and history with a web browser, use loggerhead [06:53] ah, I'm assuming that would update the bzr db and upload the file as well? [06:54] bzr-upload works without the .bzr database [06:54] for security [06:54] it uses a very small record of whats been uploaded so that it can only upload changed files [06:54] right, but where would it keep revisions? [06:55] bzr-upload ? it has them on your source branch, wherever that is - normally your workstation. [06:55] ah, OK, so it won't make a .bzr dir on the server for security reasosn, only locally...OK, that makes sense [06:56] collaborating on your source code, and deploying it to a webserver are very different tasks [06:56] agreed [06:56] does this help? I realise I haven't answered the direct question :) [06:57] yeah, it helps...I was just shocked as I didn't see any files on the server...just a bit concerned about things being compressed [06:58] figured that I would need to do something different for webdev, but the doc explains it about 80%...I may have missed something [06:58] if you ssh into your server [06:58] and run 'bzr log -p' you'll see all your patches going back to the start of your history [06:58] (run that in a branch on the server) [06:58] Also, I'm assuming that all revisions are copied to clients as well? [06:59] in their .bzr dirs? [06:59] when you do 'bzr branch server localdir' , it copies all the history by default [06:59] My main concern was that if the server got hacked/fubared, I'd be SOL [06:59] there are options that you can pass to copy less than everything (--stacked, specifically) - but its not the default. [06:59] I do Pull via the GUI, so I'm assuming it gets all the revs [07:00] yes [07:00] Good, everyone's up to date and can do a restore if needed [07:00] (unless you made the branch stacked - but I don't think bzr explorer has an option to do that) [07:00] and the restore will rebuild all the revisions...sweet [07:00] so Bazaar == RAID, lol [07:01] RAIR. Blood RAIR. [07:01] * fullermd licks his lips. [07:01] 0_\ [07:02] Anyway, thanks again lifeless [07:02] I'd be happy to write some docs/tutorials [07:04] Still here? [07:09] yes [07:10] OK. When I was having my teammate setup bzr, I had him pull our branch from the repo I setup. [07:10] bzr prompted him to turn the dir he was putting the files into a repo. I told him to select No, as there seems to be issues with doing that. [07:11] Why would you want to turn the local dir into a shared repo? [07:14] Whoops, back. [07:15] hi all ! [07:15] hey vila === vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.1.1 is out | bzr 2.1.2 is having binaries built for it [07:16] BlindWolf8: 'shared' in shared repo refers to 'between branches' not 'between users' [07:16] BlindWolf8: so you want that to make switching between branches fast and efficient [07:16] BlindWolf8: The repo is where revisions are stored. Once you start having multiple branche of the same project, using a shared repo means all common revisions are stored only once [07:17] in a common .bzr dir? [07:17] BlindWolf8: yes [07:17] one .bzr dir for the history, one .bzr per branch, but without history === radoe_ is now known as radoe [07:18] the branch ones get their history from the repository .bzr dir [07:18] then what does each .bzr dir store for each branch? [07:19] the branch configuration, the revision id of the branch's most recent commit and the tags for the branch [07:21] Before, you mentioned that if I wanted to do webdev, it wouldn't upload the revsision history. What if I wanted to regardless? [07:22] vila: you've been credited, btw. [07:23] BlindWolf8: Me ? Credited ? Argh, what did I do wrong again ? :) [07:23] lol [07:24] BlindWolf8: bzr-upload aim is to maintain a remote working tree *without* its history, if you want to update a remote working tree whenever its history change, you want the bzr-push-and-update plugin (which requires bzr on the server and an ssh access IIRC) [07:25] the two plugins work from a different set of constraints and address different needs [07:26] Thanks for that info. All of this is very helpful. [07:30] By the way, why would someone want a checkout when they can just bind a branch? [07:32] BlindWolf8: Don't summon fullermd .... [07:32] BlindWolf8: a checkout *can* be configured to use a branch on a remote server without any history stored locally [07:33] Who dares invoke the Great and Powerful fullermd?? [07:36] fullermd: someone wanting clarifications about checkouts and bound branches :-P [07:36] :-P [07:42] First, you must pass the Seven Trials of Courage. [07:42] Hey Matt, we're going to incur your wrath [07:43] so anyways.... [07:44] binding a branch to a dir makes bzr more like Perforce, which is the first VCS/SCM I used [07:48] As far as I know, I've got this: http://wiki.bazaar.canonical.com/StandaloneTree [07:49] on the server, anyways [07:49] the clients/workers have the same thing, but they have a full revision history (Heavyweight Checkout) [07:50] the files are also viewable/changable on their machines, and not sotred in the .bzr dir [07:50] (not sure what to call that...Working Tree?) [07:51] yes, see http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief [07:53] Thanks! If you guys need helps in organizing docs or making things clearer, I have a knack for that [07:55] BlindWolf8: help is always welcome, have a look at https://bugs.edge.launchpad.net/bzr/+bugs?field.tag=doc, or clarify anything you didn't understand in the actual docs :) [07:57] You guys rock! :-D [08:03] vila: https://code.edge.launchpad.net/~lifeless/bzr/loomsupport/+merge/27473 [08:04] lifeless: Updating diff... :-) [08:05] vila: pull it :) [08:09] vila: I'm going to cook dinner [08:09] vila: but I'd *love* to get this landed [08:09] vila: so if you can pp it for me, that would be most awesome [08:09] I'll pop back in a bit [08:09] lifeless: enjoy your cooking and don't worry, I *need* this patch [08:10] lifeless: (I even thought it has already landed :) [08:10] I'm out. Thanks again you guys! [08:57] lifeless: 4 tests erroring out, see mp [08:58] thank you [08:59] vila: that will be shallow [08:59] lifeless: certainly [08:59] well, hopefully :) [08:59] hello everybody [09:00] vila: they work for me [09:00] vila: disable your non-core plugins [09:01] lifeless: already done, I've kept only loom... [09:01] :!bzr selftest --no-plugins bzrlib.tests.blackbox.test_push.TestPush.test_push_smart_tags_streaming_acceptance test_switch_lightweight_directory bzrlib.tests.blackbox.test_tags.TestTagging.test_branch_push_pull_merge_copies_tags bzrlib.tes [09:01] ts.blackbox.test_tags.TestTagging.test_list_tags [09:01] bzr selftest: /home/robertc/source/baz/bzr-test-fixes/bzr [09:01] /home/robertc/source/baz/bzr-test-fixes/bzrlib [09:01] bzr-2.2.0dev1 python-2.6.5 Linux-2.6.32-22-generic-x86_64-with-Ubuntu-10.04-lucid [09:01] ---------------------------------------------------------------------- [09:01] Ran 4 tests in 1.207s [09:01] OK [09:01] !paste [09:01] For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic. [09:03] http://paste.ubuntu.com/449550/ [09:04] vila: Heya [09:04] vila: With whom should I discuss performance of the gcc-linaro branches? [09:05] lifeless: and even without loom: running 5(?) tests, failed 3 :-/ [09:05] lool: here should be fine, filing a bug report tagged udd, about the slow checkouts will be even better [09:06] lool: not finished replying to your emails, but you can try --hardlink too for branch and checkout [09:06] vila: Would you think it's something fixable, or will we always suffer from the size of history + size of the tree? [09:07] vila: In my experience, the CPU was maxed for long periods of time during the lenghty operations, not I/O [09:07] lool: I suspect it's more a tree size bug than an history size one [09:07] (I'm on SSD BTW) [09:07] Can you guys please help me with setting custom merge app in bazaar explorer? I tried "d:/Program Files/Beyond Compare 3/BComp.exe" %r %b %t %o but I am getting "Error while running merge tool (code 0)" but did not see what it is actually trying to run in the log [09:07] I got worse performances for massive IO on SSD than on 7200rpm HDs [09:08] lool: ^ [09:08] vila: BTW what is the udd tag for? Does it cover code imports or is it just for package imports? Cause here it's a code import branch, not a package import one [09:08] lool: it's for Ubuntu Distributed Dev [09:08] vila: Ok; I have a relatively unreliable I/O indicator in my panel which showed modest amount of I/O, and CPU maxed out, so I didn't blame it on I/O but it's not 100% out of the picture I guess [09:09] lool: if you use the stock performance monitor, setting Red as the color for IOWait instead of the default black will show you some interesting side-effects [09:11] vila: Yes, one CPU ws 100% busy with both IO wait and actual work [09:13] lool: try on a regular disk or use a better SSD ;-) The CPU@100% needs to be investigated, filing a bug is the best way to ensure it's not forgotten [09:14] vila: lets let pqm decide ;) [09:15] lifeless: AttributeError: 'GenericInterBranch' object has no attribute 'tags' looks unambiguous to me [09:17] lifeless: pong [09:21] vila: bug #593560 [09:21] Launchpad bug 593560 in Bazaar "Slow performance for many operations on the gcc code import branches (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/593560 [09:21] lifeless: plus you should be running 5 tests not 4, the 5th one is bzrlib.tests.blackbox.test_tags.TestTagging.test_list_tags_revision_filtering caught by bzrlib.tests.blackbox.test_tags.TestTagging.test_list_tags, are you sure !bzr use the right bzr ? [09:24] lool: first comment, I didn't noticed it earlier but using *different* projects for gcc-linaro and gcc, defeats the stacking scheme defined on lp, you'd better use the 'gcc' project itself [09:25] vila: Does it matter for the project series branches, or for the actual branches or both? [09:25] vila: when only two people are speaking pastebin is a nuisance :P [09:26] vila: I mean, I can have gcc-linaro/4.4 point at ~gcc-linaro-dev/gcc/linaro-4.4 or something like that [09:26] vila: did you pull my branch, or merge it ? [09:26] lifeless: pull [09:26] vila: aah, yes, ./bzr :P [09:26] ok will fix [09:27] lool: one stacked-on branch is defined by project on lp AFAIR [09:27] lool: it's called the devlopment focus on lp I think [09:29] vila: How would I setup my branches to tell LP that they are stacked on multiple branches of the gcc project [09:29] jelmer: it was InterBranch.pull I was pinging about [09:29] jelmer: its rather odd in trunk [09:29] vila: IOW that ~gcc-linaro-dev/gcc/linaro-4.4 is stacked on lp:gcc/4.4 and same for 4.5 [09:29] lool: you wouldn't, why do you want to do that ? [09:29] vila: the gcc development focus is the trunk vcs-import [09:30] lifeless: Well, gcc development results in yearly releases with relatively lots of changes in 4.4 and 4.5 branches, we're mostly going to work on 4.4 and 4.5 branches as a baseline, maintaining forks basically [09:30] lool: I don't think you want to do that on lp (nor that you can), either you define branches in the gcc project or you define a development focus in gcc-linaro (the former sounds better to me) [09:30] the gcc focus of development correctly points at trunk which is always where most development is going on [09:30] lool: sure, but you can have all the history in lp:gcc, so that stacking is always efficient [09:31] vila: Oh I did define a development focus on gcc-linaro [09:31] vila: I had to chose a branch, so I picked the 4.4 one [09:31] lifeless: You don't have history of the 4.4.x and 4.5.x commits surely? [09:31] lool: wrong :) Then your push for 4.5 needs to carry all the missing revisions [09:32] lifeless: They are backports at the patch / SVN level upstream, but from bzr pov, they are entirely separate branches [09:32] lool: no, all the imports are from the same master svn repo, the revisions are shared [09:32] lool: nevertheless, we can, with cron, get all the content into one branch. [09:32] vila: It's true, but 4.4 and 4.5 will differ significantly, and most of the work will happen in 4.4 right now; if I setup 4.5 as dev focus, I will miss the 4.4 revs when pushing 4.4 based branches [09:33] lool: its 3 lines of python and a pear tree [09:33] lifeless: awesome, that sounds like something we would want [09:33] lool: stacking is an approximate thing, don't aim for perfection. [09:33] lool: 1 years dev on a 25 year old tree is peanuts [09:33] you'll have many more issues that aren't related to how much is/isn't shared in stacking. [09:33] we're working on that at the moment. [09:35] vila: fixed [09:35] vila: missing .source [09:35] lifeless: So how would I ask for this cron to be setup, or are you saying that it's probably not going to gain much? [09:36] vila: I've changed development focus to gcc-linaro/4.5 now [09:37] lool: r1 = bzrlib.repository.Repository.open('lp:gcc-linaro/devfocus'); r2=bzrlib.repository.Repository.open('lp:gcc-linaro/4.4'); r1.fetch(r2) [09:37] lool: repeat as needed [09:37] you need to import bzrlib.repository [09:37] and bzrlib.plugin [09:37] and do bzrlib.plugin.load_plugins() [09:38] cute [09:38] separated concerns ftw [09:39] lool: yup, lifeless proposal is the best solution for your case, this way you can load your devfocus branch with whatever you want and pushes will benefit [09:39] vila: So you were arguing earlier that we should use the gcc project for this stuff instead of the gcc-linaro one, is this still useful if we push revisions like above? [09:39] lool: and you won't have to think about which of trunk, 4.4 or 4.5 is the best starting point [09:39] lool: it woud model it more accurately in launchpad [09:40] vila: I should probably load the devfocus branch of gcc-linaro with the gcc/trunk /4.4 and /4.5 revs too, shouldn't I? [09:40] lool: but really, do what makes sense to you [09:40] lool: no, doesn't matter anymore [09:40] lool: if you start with trunk, the later ones should be almost covered [09:41] vila: So the trunk vcs-import contains all the 4.4 and 4.5 revisions because it's the way bzr svn operates? [09:42] lool: I don't thin kit's related to svn or vcs-import but most of the history of these branches is the same one [09:43] lifeless: still one failure if I use the loom plugin: ERROR: blackbox.test_switch.TestSwitch.test_switch_lightweight_directory -> TypeError: run() got an unexpected keyword argument 'directory' most probably on loom itself ;) [09:45] vila: yes, trunk breakage with decorated command [09:45] vila: please review, its nearly bedtime [09:45] vila: my problem to have tests passing [09:45] vila: also, a suggestion for lool's bug: ask for data, always ask for data ;) [09:47] lifeless: .bzr.log ? I was typing an additional comment ;) [09:48] calgrind [09:48] logs are nice [09:48] callgrind is heaven [09:48] lifeless: tests pass without the loom plugin, review time [09:49] vila: a meta comment for you: I think your priorities are the wrong way around there; its up to the submitter and PQM to care about tests. [09:50] vila: better to review, and *then* note that its got issues, than to put the review back - it breaks the flow up more. [09:51] lifeless: sure, especially when the submitter run the full test suite before submitting ;-) [09:52] lifeless: I have flexibility on the naming of the real branches; I chose to create a gcc-linaro project to host tarballs in the future, then it seemed logical to have gcc-linaro/xxx branches [09:53] lool: I think lp would traditionally model that as gcc/linaro-4.5 as the series, which can host tarballs just fine. [09:54] IIUC, the fact I pushed the "series" branches to /gcc-linaro namespace means they were not stacked on gcc and I payed a price for that, however because I've set the focus of dev to one of these branches, people pushing to gcc-linaro branches wont pay much [09:54] lool: OTOH if you want to be able to say on a bug, 'fixed in linaro gcc 4.5, still open in fsf gcc 4.5' then you must have a separate project at the moment. [09:54] lifeless: Don't I need ownership of the gcc project for that? [09:54] lool: no [09:54] lool: anyone can create series, or at least they are meant to be able to. [09:54] Yes, we want to track the bugs separately [09:55] the fsf bugs are not tracked in Launchpad though [09:55] Well they are tracked by Launchpad as remote bugs in upstream bugzilla [09:55] right [10:10] lifeless: Why can you remove InterToBranch5 now ? Did something change or was it an error to introduce it at the time ? [10:10] vila, lifeless: Hmm one thing I'm thinking could impact performance very badly is ecryptfs [10:11] I'm using ecryptfs on my whole $HOME; it caused issues in the past with things such as sparse files, but performance was overall comparable to before using that in my experience [10:12] I should try on another system [10:15] lifeless: ha, bug #593515, but why didn't your mp reference that ?? [10:15] Launchpad bug 593515 in Bazaar "InterToBranch5 not used? (affected: 1, heat: 6)" [High,Confirmed] https://launchpad.net/bugs/593515 [10:16] lifeless: approved [10:20] vila: thanks [10:20] lool: just get callgrind stats [10:20] they should show up stat() if stat time is relevant [10:21] or sha1time, if ecryptfs breaks stat fingerprinting [10:25] vila: you haven't set merge:approve ;) [10:27] lifeless: pff, patch pilot noob... [10:31] vila: no worries, I shall train you :) [10:32] hehe, cool [11:38] lifeless: I ran an "enrich-gcc-linaro-repo" script, took 6mn41s on the first run and 18s on the second run, seems to have done some useful stuff on the first run, so was definitely a good idea, thanks [11:39] Will cron it now [11:43] Hmm I should create a separate account with a separate bzr key [11:49] I wonder how to tell bzr to use a separate launchpad login + ssh key for a single run [11:56] Overriding BZR_HOME is fine, but ssh won't use $HOME, and I can't find a way to pass random args to ssh from bzr [11:56] ln -s .ssh somewhere ? [12:00] lool: ssh can handle multiple ssh keys to offer, you know :) [12:00] lool: just have the right one on your keyright/passwordless/whatever [12:32] lifeless: Hmm right, I can just offer the key all the time [12:33] problem is user name actually, not key [12:33] it's the unix user I should be using === mrevell is now known as mrevell-lunch [13:15] Is there GUI(s) which let you browse repositories without branching/checking out? (not counting HTTP/WWWeb) === mrevell-lunch is now known as mrevell [14:13] bzr branch bzr+ssh://example.com/ [14:13] bzr: ERROR: gnomekeyring.IOError: [14:13] W.T.F... === IslandUsurper is now known as IslandUsurperAFK === beuno is now known as beuno-lunch === IslandUsurperAFK is now known as IslandUsurper === beuno-lunch is now known as beuno === bac` is now known as bac === Meths_ is now known as Meths === JayFo is now known as JFo [19:27] hi! can someone please point me out to a documentation on BranchReference's? [21:16] jelmer: anything I can do to help with lp:480102? [21:16] I saw you had marked it 'inprogress' over the weekend [21:19] bug 480102? [21:19] Launchpad bug 480102 in Bazaar Subversion Plugin "assert len(tview) == tview_len (affected: 12, heat: 98)" [High,In progress] https://launchpad.net/bugs/480102 [21:20] TresEquis: one thing that would really help is a trivial python script that reproduced the issue so we can put that into the bzr-svn testsauite [21:31] jelmer: ugh, I really don't understand how to provoke the error in a nice testcase-ish way [21:32] TresEquis: well, any help reproducing that error in the simplest way possible would be appreciated [21:33] I know that it appeared to be true that the "blob loader ID" for the failing file in the failing revision was somehow pointing to the older revision [21:33] so that when the patch was applied, the resulting file didn't match the checksum for the current transaction [21:35] I just don't know the mechanics well enough to guess how that might occur [21:36] right [21:36] so I know it has something to do with merges [21:49] I don't know if it is significant, but there is a 'bzr:ancestry:v4' property which shows up in the tree at the point of the apparently-successful merge [21:49] the one after which the later transaction touching the same files blows up [21:50] also, svn:mergeinfo shows up at that point [22:02] mkanat: I pushed a possible fix for bug 586122 for you [22:02] Launchpad bug 586122 in Meliae "scanner core dumps on loggerhead trunk + python 2.6.2 (affected: 1, heat: 5)" [Undecided,New] https://launchpad.net/bugs/586122 [22:02] Can you test it out and let me know? [22:02] jam: Awesome! Yes, I will check it out. [22:02] jam: It might be a bit later today; the Bugzilla freeze is tomorrow, so I'm a little busy. [22:03] mkanat: No rush on my part, everything works here :) [22:03] jam: Okay. :-) [22:32] hi jam [22:33] hi lifeless [22:34] i did a merge, but i am getting : 6 conflicts encountered. at the end [22:34] is the merge done? [22:35] assad: you need to fix the conficts, 'bzr resolve' them, and commit [22:35] assad: you need to fix the conficts, 'bzr resolve' them, and commit [22:39] lifeless: somehow you managed to gather more resources than me, even though I'm fully capped (on all resources right now). [22:39] I guess you managed to upgrade something faster than me? (and thus spend more resources?) [22:39] anyway, you now outrank me in bym [22:40] TresEquis, to fix the conflicts i have to copy the code from the "to be merged with" branch? [22:42] assad: it's a judgement call [22:42] you have to figure out what the right course is for each case where there are conflict markers [22:43] and then riun all your tests to be sure you didn't blow it [22:43] resolving conflicts in the test code is for extra bonus points [22:43] jam: I don't know - how do I tell that? [22:44] lifeless: on the bottom, your toon comes before mine, indicating you outrank me [22:44] jam: I have 3/6 lvl 10 goos; and been having a back n forth war with some naively defended person who attacks me and gets 3/4 twigs max [22:44] then I go wipe their entire base out ;P [22:44] lifeless: you in Kiwiland now? [22:44] TresEquis: Yup [22:44] lifeless: hmm, maybe it is the extra twigs [22:45] I've got 6 lvl 10 goos, and a couple other lvl 10 items [22:45] but I haven't been warring as much :) [22:45] jam: it might be the fighting giving xp [22:45] also, it takes 3x the build time before a resource repays itself [22:45] (so a 3-day build time takes 9-days before it produces more) [22:46] could be [22:46] I've fought a little, but not a lot [22:46] mordred@camelot:~/src$ bzr whoami [22:46] bzr: ERROR: Connection closed: [22:47] lol [22:47] mtaylor: I assume you are in a checkout? [22:47] jam: nope [22:47] just in a normal directory [22:47] jam: TresEquis I'm in chch, if you're familiar with nz [22:47] mtaylor: is $HOME a checkout? [22:47] jam: nope [22:47] mtaylor: are you lying ? [22:47] you could run with -Derror [22:47] lifeless: not to my knowledge [22:48] lifeless: not except from reading maps [22:48] mtaylor: bzr info -v [22:48] lifeless: mordred@camelot:~/src$ bzr info -v [22:48] bzr: ERROR: Connection closed: [22:50] file a bug - we need a way to help people debug this. [22:50] secondly, look in .bzr/branch, ../.bzr/branch etc [22:55] lifeless: searched all the way up the tree - no .bzr dirs anywhere [22:57] mtaylor: that is extremely odd [22:57] mtaylor: strace bzr [22:58] lifeless: found it - there is an .svn dir [22:58] lifeless: which is causing bzr-svn to vomit [22:58] mtaylor: oh right, of course [22:58] mtaylor: so, the bug is 'connection errors don't signal why we were making them' [22:58] or something [23:02] lifeless: ok. [23:03] assuming that that is actually the entire output you've been pasting [23:03] lifeless: or also - bzr whoami should perhaps not need to connect to anything? [23:03] lifeless: yes [23:03] whoami can be configured by the branch [23:03] checkouts can reference an external branch [23:03] so no, whoami was doing the right thing [23:04] we could add a whoami --global or something [23:04] but you'd still not be able to commit where you were ;P [23:04] lifeless: nah - I think you were right before - hinting at the bzr-svn cause would be the right thing here [23:26] lifeless: any objection to just backing out testtools r70 when the unicode traceback work is finished? [23:27] mgz: why? it seems clearly less broken than it was [23:27] mgz: I'd be happy to have something less broken than it wsa and is [23:27] well, because you're enhancing wrong code there [23:28] actually, I think it's worse than that [23:31] Python 3 does the right thing (the exceptions are always unicode), and Python 2 needs the input fixing, not a per-str()-call fixup [23:32] hardcoding UTF-8 there is the wrong place at any rate, needs to happen in subunit if you want it, otherwise you break the normal output with say, unittest [23:33] so, subunit with multipart attachments already generates unicode exception objects [23:33] r70 in testtools is to *handle* that [23:33] okay, I know it was to fix a current issue [23:34] but I'm interested in what needs to change when testtools is only creating _StringException objects with unicode args [23:35] as long as we're using a fixed traceback module [23:35] and a subunit with the patch to make unicode string exceptions for non-multipart attachments [23:35] and the matching XXX fixed to encode in utf8 explicitly for non-multipart serialising [23:35] then we shouldn't ever be calling __str__ on a StringException [23:36] okay, great, that's what I'm aiming for [23:36] and if we're not calling __str__, then it shouldn't matter [23:36] uhm [23:36] actually, it will matter [23:37] if someone with a different TestResult uses the standard traceback module. [23:37] right, this is the case I worry about [23:37] they will run into precisely the same brokenness, unless __str__ *works* [23:37] I currently am testing testtools internals with the unittest runner [23:37] r70 will break those tests [23:37] and this is the upstream Exception.__str__ bug in python2.x [23:37] mgz: no, r70 will fix it. [23:37] no, this is er... the second pass [23:38] testtools is formatting the exception [23:38] hmm, I've two uk people timesharing me [23:38] and unittest is stringifying the _StringException for the output [23:38] I'll retire, this can wait. [23:38] which is broken. It should be unicodifying [23:39] right, but it's a broken case that comes up, bzr currently does the same I believe [23:39] the question is, when someone asks for an insane thing, do we: break; encode to their default; encode to utf8; something else [23:39] yup. [23:39] hi there mgz, lifeless [23:39] hey poolie [23:39] mgz: I'm happy to change it to 'use their console encoding' or something, once your patch lands and that is feasible. [23:40] so, looked at like that, it boils down to r70 picking "always utf-8" and my compat one doing "ascii and questionmarks" [23:40] hi poolie [23:40] where the right thing will be to change it to use unicode till it actually hits the console/whatever other output method [23:40] mgz: right [23:40] mgz: back in 2 minutes [23:44] How does one remove a folder from bazaar control? [23:44] mgz: back [23:46] How does one remove a folder from bazaar control? [23:46] BitSprocket, 'bzr rm --keep' [23:46] note that this will propagate to other checkouts as a deletion of that folder [23:47] Thanks poolie. It's a private project so no worries. That won't delete any of my files right? [23:47] Said differently, I want to keep the files, just remove version control. [23:48] that's what --keep does [23:48] Sweet, thanks! [23:48] you might then want to do 'bzr ignore THING' to avoid it being re-added in future [23:48] np [23:49] Does that apply to subdirectories/files as well? [23:49] Or do I have to do them manually? [23:50] ...looks like it took care of it recursively for me... [23:56] Well, it doesn't look like it worked after all. What am I missing?