[00:05] I wasn't; I tried --all, and it didn't show up there either [00:06] Well, if it doesn't show up in --all, it's not a dead; it's an ancestor of some other rev. [00:06] Did you commit after that update? [00:06] I did [00:06] because it still showed the change packages [00:06] so I thought they were still there [00:06] Well, then that's why it's not a head :p [00:07] ok; is there still a way to fix it? [00:07] Well, they ARE there. [00:07] I know what the comments are, or at least some specific keys in them [00:07] would that help? [00:07] So, let's step back; what state of affairs do you want to end up with, and why is that different from the current? [00:08] I want to end up with the branch I had before I: bound to another branch, updated, and committed [00:08] and the reason it's different is that the branch I had had some new changes that should have been pushed to the branch I accidently bound to [00:09] OK, well they're there now. Does it matter that they're there via a merge rather than pushed onto the lefthand ancestry? [00:09] but that's just it; they aren't there [00:09] bzr status -v lists all the "pending merges", but none of the changes are there [00:09] the new files are missing, the changes are reverted [00:10] no backups [00:10] this represents 4 days of work; you can understand why I'm a little agitated about it =] [00:10] .... [00:10] Something doesn't add up. [00:10] that's what I thought [00:10] If you commit'd, there won't be pending merges sitting around, because they won't be pending any more (being committed) [00:10] I uncommitted [00:11] Before or after you unbound? [00:11] but that is why I committed; I thought that even though I bound to another branch (the one I branched off of) and updated, that the changes would still be there, just waiting to be committed [00:11] here, let me tell you the whole sequence: [00:11] They would be. [00:11] bzr branch [00:11] bzr unbind [00:11] [00:12] bzr commit [00:12] bzr merge [00:12] bzr bind [00:12] bzr update [00:12] bzr status -v (at this point, files are gone, but still shows the pending merges) [00:12] [00:12] bzr commit (thinking that since the pending merges show, the files are still there) [00:12] (they aren't) [00:12] bzr unbind [00:13] bzr uncommit [00:13] there I stand [00:13] So, the remote end still has that commit you made? [00:13] yes [00:13] presently [00:13] Which has all those revs in its ancestry. [00:14] the local should have all the revs in ancestry, since I was unbound when I did them [00:14] the remote does not [00:14] The remote does if you committed a merge of them while you were bound to it. [00:14] but that commit doesn't seem to have sent any files [00:14] because when I updated, the files and changes all magically disappeared [00:14] Stipulating that, it will still have sent the revs. [00:15] I'll check the remote log [00:15] You can't (barring minor magic) stuff around a rev without stuffing around its ancestors. [00:15] let us hope that I am no magician; give me a sec to dig a bit [00:16] Unless you tried to (which means at the least you dug up and did the push via writing code against bzrlib), you didn't. [00:16] nope; it acts as if the commit I made (Despite the claimed "pending merges") was a no-file merge [00:17] Forget files. Look at the revs. [00:17] it's as if the update erased all my changes, but somehow didn't erase the "pending merges" [00:17] I'm looking at revs [00:17] Are you using -n0 on log? [00:17] there is a rev with the message I used on the commit, but none of the other ones are there [00:17] I am not [00:17] one sec [00:17] ahh, that looks more promising [00:17] give me a sec to try a revert [00:19] So you can use that to find the revid, and use pull to swap yourself around to that state. [00:20] I'm a bit suspicious of ending up with no files changes though. Barring big bugs, merge wouldn't quietly do that given reasonable assumptions about prior states. [00:20] I will try that [00:20] thank you [00:20] yeah; that's why I'm so confused [00:20] I thought I'd tried this before and it worked as I expected [00:20] Generally, either suggesting the merge you did earlier was botched, or you ran something like 'revert .' after the update. [00:20] I can guarantee that was not the case; I built after the merge, and then I did a bind and an update; all the changes went away [00:21] this is bzr 1.18.1, incidently [00:21] I don't suppose it's a public branch? [00:22] it isn't [00:25] If you can pastebin a 'log -vn0' from before the point where you initally branch'd up through that last commit, we may be able to make some guesses as to what happened when. [00:25] But that may expose more info than you want. Probably doesn't matter in itself, would just be informative. [00:30] give me a few minutes; I did find the files I need (thank you!) and I need to restore the branch so someone else can use it [00:31] I'd do 3 times: [00:31] 1) Preserve the existing (broken in aggregate, but containing all necessary pieces) state of the main branch by branch'ing it somewhere local [00:32] 2) 'fix' it by using pull/push/something to reset its head to the state prior to that (poking at log should reveal it to you) [00:32] 3) Do the same to 'your' branch [00:32] Then you're in a state to move forward, and you have a copy of the b0rkenness for analysis. [00:32] I'm just going to revert and then commit [00:32] so the history is intact [00:33] That... doesn't some like what you want at all. [00:33] sound [00:33] ... it gets all my files back where I want them; [00:33] why is it not what I want? [00:33] Well, it leaves a big ugly lump in your history, for one. [00:34] And are you sure what you're reverting to is what you should be? The weird state you ended up in suggests things awry. [00:34] I'm testing the build, but it looks like it is all restored [00:34] there is just one extra revision that somehow reverts it all back to before my work [00:34] if I revert back one sub-revision, it works fine [00:35] Well, it's your codebase. [00:35] hehe [00:35] From where I sit, there are only two states I'm confident are good: the remote branch before it got hit with the commit of that update pivot, and your local branch before your merge of the remote. [00:36] Everything after that, I question. So if it were me, I'd back up to those two places and try going forward from there again. [00:37] You're sitting in front of more info about the code than I am, so if you're confident in that first merge, you can try going forward from there instead. [00:38] yeah, I'm looking over a full diff to make sure [00:38] I'd be very down on going forward from after that second merge though; just reverting the files and commiting a new rev on top will lose any annotations at the least. [00:41] Anyway, I must off. I'm on serious plus time for sleep. [00:43] I appreciate your help [00:43] it was a lifesaver [00:45] verterok: hi [03:08] kfogel: i really wasn't feeling guilty [03:08] i was just saying thanks [03:09] poolie: oh, I know; my first line there was just a joke. I knew you'd already seen the joke, but this is open source, so there's always more audience for the same joke :-). [03:09] Year of the Linux Desktop ;-) [03:14] verterok: hi [03:14] RenatoSilva: hi [03:15] RenatoSilva: your patch for redstone xmlrpc is already fixed in 1.1.1 :) [03:15] verterok: did you see my comments to you here yesterday? [03:16] RenatoSilva: nope, crappy network connection [03:16] verterok: you mean redstone guys have applied the fix? I see no status change in SF [03:17] verterok: I think you have heard of the blackout here, that's why I was disconnected [03:18] RenatoSilva: a different patch, but the same fix [03:20] verterok: I saw you have merged the changes, with them I could run all the tests successfully (0 errors/failures) in mvn, eclipse and in hudson [03:21] verterok: 1.1.1 is the version in the winXP repo here (I'm in Ubuntu now), but isn't it the same version since we beginned to work on this? [03:22] verterok: I mean, I've got the impression that 1.1.1 is the unpatched version [03:23] RenatoSilva: I did checjkut from their svn [03:23] *checkout [03:24] verterok: ok so it's not 1.1.1 right. I was testing yesterday: the 1.1.1 version causes test errors, when I replace it with the patched version, the errors dissapear [03:26] verterok: it's weird but I was testing a few minutes ago, and now I'm getting errors (1 or 2) in winXP regarding file access/permission, both in eclipse and mvn [03:26] RenatoSilva: I think that's my fault [03:27] I changed a call from getCanonicalPath to getPath in the TestsConfig class [03:28] verterok: that is, no errors/failures yesterday, but one or two errors today :( One thing different I've done is that I've updated bzr-xmloutput with the latest version from trunk (I think it was in rev 101 and I pulled 6 revs or so). Would that be the cause? [03:29] verterok: hm, I don't remember if the test success was with the getPath stuff merged [03:29] RenatoSilva: it's one line change, revert it ;) [03:31] verterok: I was trying now to run the tests in Ubuntu, but I can't. The deb package from apt repo is 0.8.3, but I get errors with that version [03:32] RenatoSilva: yes, it's quite old [03:33] verterok: I tried to replace it with trunk, but failed. It's easy in windows, you just replace/update the xmloutput folder. Here in Ubuntu it's not, can't get the plugin loaded by bzr, it seems that there are external metadata invloved. I tried to install the deb, and replace the dir with trunk, but didn't work either :( [03:33] verterok: so you have uncommitted the getPath change? [03:34] verterok: it is still there: I've done [03:34] RenatoSilva: not yet [03:34] s/I've done/http://bazaar.launchpad.net/~verterok/bzr-java-lib/encoding-and-test-fixes/revision/215 [03:35] you'll have to uncommit twice right? that will break my branch , right? (because I've merged that revision) [03:36] no, I already merged your branch [03:37] but my branch have merged yours [03:37] RenatoSilva: I'll resolve the conflict :) [03:38] hum, to undo the chnage you won't uncommit it, you'll do a new commit to get back to getCanonicalPath(), right? [03:38] RenatoSilva: I changed that because I'm having probles with a path containing: รณ [03:39] RenatoSilva: right [03:40] * RenatoSilva suffers of the uncommit syndrome [03:42] verterok: let me go back to windows, I'll change that line and see if the tests pass. I'll rollback the xmloutput too [03:54] verterok: back in winxp [03:54] verterok: yesterday: http://img195.imageshack.us/img195/2136/testsok.png [03:55] verterok: when I go back to getCanonicalPath, I get 5 errors [03:56] ouch [03:56] verterok: if I keep getPath, I get only 1 error [03:56] RenatoSilva: I'm getting errors in linux with getPath [03:57] verterok: this one? http://steppenwolf.selfip.net/hudson/job/bzr-java-lib%20%28encoding%20and%20tests%20fixes%29/org.vcs.bazaar.client$bzr-java-lib/16/testReport/org.vcs.bazaar.client/BazaarClientTest/testAnnotate/? [03:58] RenatoSilva: yeap [03:59] it's the same string except for the leading /home in the actual version [04:01] verterok: do you know how to install the trunk version of bzr-xmloutput in Ubuntu? That way I could also run the tests in *nix, and check the errors [04:02] so simple in win, but not in linux [04:02] RenatoSilva: first unintall the package [04:02] already unisntalled it [04:02] RenatoSilva: and after that: mkdir ~/.bazaar/plugins; cd ~/.bazaar/plugins; bzr branch lp:bzr-xmloutput xmloutput [04:07] verterok: nice! I'll try that [04:07] verterok: I've continuously uncommitting the recent changes in xmloutput's trunk [04:08] verterok: getting different ammount of errors on each [04:08] RenatoSilva: the hudson instance is using xmloutput trunk [04:08] * RenatoSilva uncommitting till find any working rev [04:09] RenatoSilva: what errors are you getting? [04:14] verterok: reverted a few changes and didn't get it working, let me go back to tip and show you the error [04:14] verterok: why don't you use subunit2junitxml in http://steppenwolf.selfip.net/hudson/job/bzr-xmloutput/lastBuild/testReport/ [04:15] lifeless: good point, actually the bzr-xmloutput job isn't configure yet, I was trying to use pyjunitxml [04:15] verterok: you're using xmloutput trunk in hudson? then it may something with my local machine, just passed all tests there: http://steppenwolf.selfip.net/hudson/job/bzr-java-lib-xp%20%28encoding%20and%20tests%20fixes%29/21/ [04:16] verterok: bzr selftest xmloutput --subunit | subunit2junitxml -o tests.xml [04:16] lifeless: oohhh, nice! [04:17] * verterok update the job config [04:17] you'll need python-junitxml, subunit-0.0.1 installed [04:18] lifeless: is there a package/ppa? [04:18] its all in karmic [04:18] and yes, there is a usbunit ppa or two [04:18] even better! :) [04:22] verterok: with mvn I get 1 error: http://pastie.org/694861.txt [04:22] lifeless: I can't find pyjunitxml :/ [04:22] verterok: O arquivo j\xe1 est\xe1 sendo usado por outro processo. == the file is already being used for another project [04:23] verterok: * by another proecess [04:23] RenatoSilva: yes, that's weird..the same test fails all the time? [04:23] verterok: let me run again [04:24] verterok: apt-get install python-junitxml [04:24] lifeless: yes, it can't find it [04:25] checking [04:25] I may not have managed to get it synced to ubuntu before release [04:25] verterok: different error now! org.vcs.bazaar.client.xmlrpc.XmlRpcCommandException: Permission denied: "C:/DOCUME~1/renato/CONFIG~1/Temp/bazaar_client_tests658081888924229416/working_copies/unknowns/.bzr/branch/lock/held": [Error 5] Acesso negado [04:25] lifeless: oh, ok. I can use the debian deb :) [04:26] RenatoSilva: yes, looks like a race condition...but we don't use threads..so this is weird [04:26] verterok: do you hold open multiple locks? [04:27] lifeless: I don't open locks :) [04:27] lifeless: xmloutput starts a long running xmlrpc service, and bzr-java-lib sends requests (commands) to it [04:27] lifeless: plain bzr CLI commands [04:28] lifeless: the xmlrpc service just use some hacks to get the output but it basically calls run_bzr [04:29] verterok: man, that's crazzy, it was working perfectly yesteday. What I did to cause this? [04:30] verterok: tested the getPath, and xmloutput, didn't work [04:30] RenatoSilva: did you updated bzr/xmloutput/python/anything? :) [04:30] verterok: well I've installed AVG9, can't see anything else new I've done [04:31] verterok: as I said I've pulled the latest changes (5 or 6 revs) from trunk in xmloutput [04:31] RenatoSilva: what's AVG9? :) [04:32] verterok: but I uncommitted them till get to the latest merge you did from my fixes, and I get errors still [04:32] verterok: anti-virus :) [04:32] RenatoSilva: I think there are some issues with anti-virus and bzr...but I'm not sure [04:32] verterok: man, the errors are random [04:32] lifeless: do you know? ^ [04:33] verterok: I'm running in eclipse, I had 1 error, now I have 3 errors [04:33] antivirus does ten to interfere [04:34] verterok: des any process (bzr/python) is started with another user by any chance? [04:34] RenatoSilva: nope [04:38] oh, can't turn AVG off :( [04:38] verterok: did you get that deb? [04:38] lifeless: I'm waiting the upgrade to finish [04:39] :P [04:40] verterok: yeah, it didn't hit ubuntu for some reason. its in unstable and testing [04:43] verterok: deactivated AVG and win firewall, but still getting erros :( [04:43] verterok: random errors :( [04:44] hmm, that's weird [04:44] :( [04:45] verterok: org.vcs.bazaar.client.xmlrpc.XmlRpcCommandException: unknown command "C:\Arquivos de programas\Bazaar\bzr.exe" [04:45] verterok: also access denied [04:50] how can it tell C:\Arquivos de programas\Bazaar\bzr.exe is unknown, but just sometimes [04:54] <_Andrew> heya [04:54] verterok: still failing :P [04:54] _Andrew: hai [04:54] lifeless: yeap [04:59] lifeless: https://pastebin.canonical.com/24652/ [04:59] ooops, wrong pastebin, sorry [05:00] lifeless: http://pastebin.ubuntu.com/316584/ [05:02] verterok: I can read both :P [05:02] lifeless: I know...but you know, I should use public pastebin :) [05:03] verterok: can you branch lp:pyjunitxml [05:03] sure [05:03] and run python -m subunit.run junitxml.test_suite | subunit-stats [05:04] lifeless: all good [05:04] bahhhh [05:04] * lifeless hates datetime [05:05] lifeless: the utcnow() is the offending bit :) [05:05] well [05:05] subunit should be calling time() [05:05] what subunit version did you end up with ? [05:06] actually, do this: [05:06] lifeless: 0.0.2-1 [05:06] bzr selftest --subunit xmloutput | grep -v 'time:' | subunit2junitxml -o tests.xml [05:07] ok [05:07] if that fixes it, please file a bug on pyjunitxml [05:08] lifeless: yeap, it worked now [05:08] so subunit in bzr generates Zulu timestamps [05:08] utc == zulu, but python is DAFT [05:11] verterok: \o/ looks nice [05:12] :) [05:12] lifeless: thanks! [05:12] anytime ;) [05:12] show the u1 folk:P [05:12] lifeless: already did it to lucio ;) [05:13] <_Andrew> I want to know if it's possible to force people to update for the the repo they cloned from. The reason I ask this is because we want "trunk" and then "live" branches but we want people contributing to trunk in a centralized fashion [05:13] verterok: heh, I didn't see it on the channel ;P [05:13] lifeless: a while back :) [05:13] _Andrew: update for ? [05:14] <_Andrew> ah sorry [05:14] lifeless: Bug #481119 [05:14] Launchpad bug 481119 in pyjunitxml "TypeError while running bzr selftest --subunit | subunit2junitxml" [Undecided,New] https://launchpad.net/bugs/481119 [05:14] <_Andrew> I meant when people push to trunk force them to update first? [05:14] verterok: yes but it wasn't working before ;) [05:14] good point :) [05:14] _Andrew: set the append_revisions_only config setting [05:14] <_Andrew> ok [05:19] <_Andrew> Sorry I'm confused about this option [05:19] <_Andrew> When I init with it in "trunk" and 2 people clone trunk [05:19] <_Andrew> person one pushes to trunk, and then person 2 does the same thing.. [05:20] <_Andrew> Does that mean person 2 will be forced to update first? [05:21] yes [05:22] <_Andrew> sweet [05:22] mwhudson_: http://steppenwolf.selfip.net/hudson/job/bzr-xmloutput/ [05:22] <_Andrew> That's exactly what I need [05:23] mwhudson_: you can click on the test grapho too, to get details === mwhudson_ is now known as mwhudson [05:27] lifeless: I'm adding pylint ;) [05:28] is there a lugin, or just via shell commands? [05:29] lifeless: via shell, but there is the Violations plugin, that knows how to read pylint output [05:31] verterok: maybe the errors are because of the branch format of xmloutput you've upgraded to? [05:32] I'm afraid of installing bzr 2. Should I? [05:32] does bzr 2 work just fine with old branch formats? [05:32] RenatoSilva: yes, you should :) using 2a is a pleasure [05:32] RenatoSilva: yes [05:33] verterok: I've installed xmloutput 0.8.4 using the installer, checking if the errros are at least constant [05:34] verterok: what is better in the new format? just faster? [05:35] RenatoSilva: speed is one of bug advantages [05:35] *big [05:36] what other advantages? did you get any trouble after upgrading? [05:36] the errors here are still random, but not the same errors I had before [05:37] RenatoSilva: no, I'm using it in every new project..and plan to move bzr-eclipse/java-lib to it in the near future [05:37] verterok: I get an error when branching ~/bzr-xmloutput/encoding-fixes-388300 :( because of the branch format. It is a stacked branch :( [05:38] RenatoSilva: yes, you need to use the new format, or avoid stacking [05:38] maybe that error should not happen [05:38] I don't know how to avoid stacking [05:38] or migrate a stacked branch [05:39] RenatoSilva: neither me, I never did it :/ [05:39] verterok: afaik you just can't [05:39] avoid stacking [05:40] RenatoSilva: I can put a tarball somewhere if you need to get trunk [05:40] guys, if I create a stackied branch and the main one gets upgrated to the new format, is it possible to recover the stacked branch? [05:41] verterok: I want to get my old branch, it's totally broken now :( [05:41] verterok: not sure why but I can bzr branch trunk [05:42] just like bzr 1.18 can handle the new format [05:42] RenatoSilva: did you tried doing the upgrade in lp? [05:42] can it? [05:42] RenatoSilva: bzr upgrade --2a lp:~/bzr-xmloutput/encoding-fixes-388300 [05:42] verterok: you mean a command pointing directly to the lp copy? [05:43] RenatoSilva: I upgraded xmloutput, bzr-hudson/jira like that [05:43] verterok: but 2a is availablr only in bzr 2 right? will install and try. What I don't understand is why we can branch the 2a branch with bzr 1.18, I tought it would not be possible [05:44] RenatoSilva: bzr upgrade --help [05:44] that should show you the supported formats [05:45] 2a is there, weird [05:45] if 1.18 already supports 2a, then what's the point of bzr 2? [05:45] I thought it was just the branch format [05:49] verterok: installed bzr 2, it comes with xmloutput 0.8.5, but where is the SimpleXMLRPCServer.py? [05:49] RenatoSilva: it should be included...right? [05:50] RenatoSilva: I don't know much about the win-installers [05:50] it's not there, let me run the tests [05:51] * verterok heads to bed [05:51] RenatoSilva: if SimpleXMLRPCServer.py is missing, please file a bug in bzr about the broken xmloutput in the installer [05:52] ok, see you, I'll try to fix things here [05:52] RenatoSilva: I need to sleep a few hours, seeya later! [05:52] RenatoSilva: bzr 2 changed the default format to 2a; 2a was supported for a while before bzr 2.0 [05:52] see you :) thanks [05:52] RAOF: ok [05:52] later all! [05:52] lifeless: http://steppenwolf.selfip.net/hudson/job/bzr-xmloutput/violations/ [05:53] james_w: btw, upgrade bzr-build* to 2a :) [05:57] <_Andrew> um [05:58] <_Andrew> When I use --append-revisions-only to init a branch and then clone it to branch1 and branch2. If I push a change up to trunk in branch1 and then do to same in branch2 it complains that the branches have diverged rather then force me to update [06:00] <_Andrew> Is there anyway to prevent the branches from diverging due to users forgetting to update beforehand ? [06:00] Anyone has any idea of what could be causing these errors? http://pastie.org/694933.txt [06:01] unknown command "c:\Arquivos de programas\Bazaar\bzr.exe" ??? [06:01] Access denied ??? [06:02] _Andrew: no, people can do strange things ;) [06:03] verterok: the pylint output is harsh [06:04] pyflakes with the lazy imprt patch would be better [06:06] <_Andrew> There's no way to do that you mean? [06:06] <_Andrew> because it's creating problems in the office [06:08] pylint is really great at producing masses of output [06:10] yay for pyflakes [06:11] anyone invoved with win installers? where is xmloutput/SimpleXMLRpcServer? [06:15] <_Andrew> ah... [06:16] <_Andrew> so I figured I am doing this wrong [06:16] <_Andrew> My developers need to do bzr checkout... not bzr branch or clone [06:16] maybe [06:17] that has potential pitfalls of its own [06:17] <_Andrew> That way they can't screw up and make their own branches that need merging [06:17] <_Andrew> oh really? [06:17] merging isn't a bad thing [06:17] <_Andrew> What are the problems? [06:18] imvho the result of doing 'bzr up' in a bound branch with local changes is a bit confusing [06:21] <_Andrew> ah [06:21] <_Andrew> The problem is that we need to do this way otherwise people keep screwing up the trunk branch [06:22] <_Andrew> They try to push without updating then get confused with the merge process [06:22] <_Andrew> Then there are tons of conflicts [06:22] well, if they ever do a "commit --local", they'll have the same problem [06:23] and those conflicts can occur with 'bzr up', too [06:23] <_Andrew> you're right about that === abentley1 is now known as abentley [06:47] * RenatoSilva is grrrrrrr with random test errors [06:55] anyone with bzr + mvn+ up-to-date winXP? [06:55] I would like some help with testing a LP branch [07:52] RenatoSilva: what particular problem? [07:54] poolie1: do you have the logs there? I pasted some links. Basically --random-- errors when testing bzr-java-lib [07:54] what do you mean by testing the branch? [07:54] poolie1: errors about access denied, bzr.exe not found (showing the correct path) [07:54] i didn't see the logs [07:54] poolie1: unit testing [07:54] running tests located in that branch? [07:54] poolie1: you'd have to branch bzr-java-lib [07:54] what's the url? [07:55] poolie1: lp:~verterok/bzr-java-lib/encoding-and-test-fixes [07:56] poolie1: no [07:56] poolie1: ~renatosilva/bzr-java-lib/encoding-fixes [07:56] they're almost the same [07:59] poolie1: I've got one specific test method running, and randomly failing/passing [07:59] poolie1: then I've got the .bzr.log for each case separately [07:59] paste the log url again pls? [08:00] poolie1: the only relevant diff is that the success log has new lines, no error info in the failing log [08:02] poolie1: http://pastie.org/695026.txt [08:03] sorry i really have no idea about this [08:03] better ask gg or someone [08:03] poolie1: the bzr log there is the success log, with the new lines that are supressed when the test fails (see the '>>>>>>>>>') [08:04] poolie1: ok will show that to Guillermo [08:05] poolie1: but did you get the branch? [08:05] would appreciate if someone could test bzr-java-lib [08:05] in winxp [08:06] poolie1: the only thing I can think of is that the win updates have introduced the problem [08:06] poolie1: it was working yesterday! http://img195.imageshack.us/img195/2136/testsok.png [08:08] what I think is so weird is: how can I get access denied errors? [08:09] I wonder if it's rather related to the new 2a format [09:09] ooh scary : bzr: ERROR: exceptions.KeyError [09:13] jam i don't understand the cover letter of https://code.edge.launchpad.net/~jameinel/bzr/2.1.0b4-update-by-delta-bug/+merge/14628 [09:20] quicksilver: LOL [09:30] good night all [09:30] lotzman, hey? [09:30] i'd almost rename the role but it might be too obscure [09:57] poolie: ooh, I've lost your joke. Night. [09:57] * bialix interesting why poolie joking from me? [10:03] hi GaryvdM [10:03] Hi [10:04] I'm working on the qrevert changes - I found a few other issues. [10:05] bialix: I just experienced the qadd/select all bug, but I have not looked into it yet. [10:05] GaryvdM: ok [10:05] GaryvdM: re qrevert changes: I think "Forget pending merges" will be good label, is not? [10:06] GaryvdM: I'm planning to finish off encoding patch from naoki [10:06] I don't know. I've not thought about, I'm just looking at the behaviour side of the design [10:07] bialix: cool [10:07] that's ok, we can polish labels later [10:08] I found interesting bug with our qsubprocess last night [10:08] it's related to get_boolean [10:08] I've already committed fix, but it seems we should be aware about the places where we trying to send strings with \n inside [10:09] ok [10:15] GaryvdM: I want to move cmd_qsubprocess to subprocess.py [10:15] they are closely related and depend each from other [11:25] can I raise an exception "softer" than BzrCommandError? BzrCommandError says "bzr: ERROR: Commit cancelled", given that the user cancelled the commit, I don't see that as an ERROR, just a message [11:27] <_Andrew> anyone know why my "trunk" doesn't update when I commit changes to it? [11:27] _Andrew: what do you mean with "update"? [11:27] <_Andrew> eh, sorry. I mean doesn't show files I add [11:28] <_Andrew> say I bzr init trunk [11:28] <_Andrew> then bzr checkout [11:28] <_Andrew> If I change files in my checkout and commit it doesn't update the files in the trunk dir? [11:32] If the trunk is across a remote protocol, it won't. Remote protocols don't touch the working tree. [11:32] _Andrew: if you commit in a bound checkout the changes will go back to the bound branch, but you will not see those changes in the other working trees, including the one you checked out from. Try to update the trunk [11:35] <_Andrew> what if multiple people update the trunk? [11:35] <_Andrew> Will that screw it up with different users doing bzr update on the same folder? [11:35] Perhaps the better question is whether you really need a WT with that branch. [11:37] <_Andrew> I think this plugin does what I want. https://code.launchpad.net/~bzr/bzr-push-and-update/trunk [11:38] That just automates running the update. [11:41] <_Andrew> Can't I just add a hook script then? [11:41] That's what push-and-update is :p [11:43] <_Andrew> ah [11:43] <_Andrew> That's what I thought [11:43] <_Andrew> Then I should use that [11:44] Generally, though, I'd tend toward just whacking the WT in the first place. No reason to have it there. [11:50] <_Andrew> WT? [11:51] hi, I'm using bzr 2.0.2. One of the repos I'm using at Launchpad switched to format 2a, so I think I need a new shared repo with this format. I'm trying both bzr upgrade and (on another box) bzr init-repo --2a and new branching. But I'm having some problems [11:52] _Andrew: Working Tree. [11:52] I'm using the MySQL and MariaDB trees, and both new bzr branch lp:maria and convert of old shared repo is impossibly slow. Running for > 4 hours now and only 20000/59443 revisions transfered [11:52] <_Andrew> ah [11:53] knielsen: I'm pretty sure MySQL isn't in 2a yet, so if you're branching it into a 2a repository it's going to convert on the fly. Which takes a long time. [11:53] any suggestions for a better way to be able to access format 2a branches from the same shared repo as MySQL/MariaDB? Or do I just need to let it run for however many hours? [11:53] knielsen: (and will probably make you incompatible with upstream, as I don't think they're using rich-root repos) [11:53] Why do you want to share a repo across projects without any common history anyway? Seems kinda pointless. [11:54] fullermd: hm, bummer. So I'll need to use two different shared repos then it seems? One for projects with old format and one for new format? [11:54] Well, I generally just use a different shared repo for each project. There's no gain in it when there's no history to share. [11:54] Hi, I am struggling to decide whether I should recommend Bazaar or Mercurial to my workplace - can anyone point me to anything they think I should read? [11:55] problem is that then you have to work in completely different subtrees... but ok, I can probably manage thanks for suggestion [11:55] Well, I do anyway. There's ~/work/projfoo and ~/work/projbar and so on... [12:05] <_Andrew> Where do I put hooks on the server side? [12:05] <_Andrew> in the .bzr dir in a working copy? [12:06] <_Andrew> .bzr/plugins ? [12:10] No, plugins either get installed in the system-wide lib dir or per-user ~/.bazaar/plugins/ [12:11] Some may have to be enabled in branch.conf, some don't. [12:11] But in the case of push-and-update, server side is irrelevant; it runs from the client side. [12:13] <_Andrew> Everyone is has their own branch on one machine [12:13] <_Andrew> on** [12:13] <_Andrew> maybe I can just enable the plugin system wide? [12:34] maxb: http://doc.bazaar-vcs.org/migration/en/why-switch-to-bazaar.html [12:37] hmm, Bazaar Explorer looks nice.... not for me, but could be a great selling point for the less technical Windows users === mrevell is now known as mrevell-lunch [12:41] maxb: what's most important for your workplace? [12:42] hmm, many things. I care most about having a vcs with good support for a code-reviewing feature-branch based workflow [12:43] that's very broad [12:43] hg" all branches in one repo [12:43] bzr: every branch in separate directory [12:43] for many people this is show stopper [12:44] code review: depends on the system you will use [12:44] it seems like Review Board supporting both hg and bzr [12:45] retvield? maybe supports bzr, I've commented on the patch for bzr support while ago, but hg should be there already 'cause it's google choice [12:45] hg can be used in a very bzr-like manner too - you just treat every hg repository like you would a bzr branch [12:45] Windows users? TortoiseHg rules out bzr [12:45] unless you see Bazaar Explorer as better tool [12:46] maxb: hg can be as bzr, but bzr cannot be as hg with branches [12:46] unless you *call* Bazaar Explorer as better tool [12:46] Indeed, one of my concerns about bzr is what to do with branches whose fate is never to be merged into trunk, but whose history must be kept [12:47] (e.g. mainenance / cherry pick / failed feature branches) [12:47] maxb: recently on SO was question about such branches, hg book seems to suggest keep such branches in separate repos [12:47] SO ? [12:48] stackoverflow [12:48] * maxb googles [12:48] maxb: http://stackoverflow.com/questions/1672487/mercurial-why-would-you-maintain-separate-branches-versions-of-software-in-separ [12:51] Indeed. At which point Mercurial's "advantage" of being able to stash such things in a single repository then evaporates [12:51] maxb: even if you don't need Bazaar Explorer there is still hidden power ready for you: QBzr [12:52] On the other hand, hgwebdir rather beats loggerhead in good listing of many branches [12:52] it seems so [12:53] every tool has it's power and lower [12:55] I'm surprised at the bzr benchmarks in GaryvdM's links, I thought hg was faster [12:56] maxb: although I'm addicted to bzr, I can't say honestly that bzr is much greater than hg. There is places where hg clearly better, and there is places where bzr is clearly better. It depends what is most important for you, that's what I think about bzr vs hg comparison [12:56] * maxb ponders attempting to bzr->hg the launchpad repository for a subjective speed test [12:56] maxb: actually there is no big and comprehensive benchmarks for bzr 2a format [12:56] yet [12:57] http://doc.bazaar-vcs.org/migration/en/why-switch-to-bazaar.html claims to be benchmarking the firefox repository under bzr 2.0.0 [13:02] I can't comment those numbers, maybe igc can [13:14] <_Andrew> can anyone point me in the direction of a simple post commit hook script? [13:17] stackoverflow guy is wrong ; SVN uses branches to define tags, not the other way [13:17] Branching is cheap in SVN so they overloaded it's use to create tags instead of doing it the way CVS does [13:18] DVCS systems actually go back to the CVS way of labelling a specific revision albeit on a global basis and not per-file [13:21] I would say that the folder-per-branch vs one-folder-with-all-branches thing is only a showstopper for those people who don't bother thinking about things... === mrevell-lunch is now known as mrevell [13:32] awilkins: you're right, but many people don't bother even thinking [13:32] _Andrew: in which sense? [13:32] <_Andrew> oh geeze nevermind === kklimond- is now known as kklimonda [13:43] Grr @ _Andrew === mbarnett` is now known as mbarnett [15:28] has nobody noticed that the guy-with-hat avatar in the bzr docs is extremely phallic? [15:30] Tak: hmm, what about bzr logo then? [15:32] Well, if that's phallic, it's a phallus in need of some corrective surgery... [15:35] bailix: http://bazaar-vcs.org/stuart [15:36] oh - know - that must be something else [15:36] GaryvdM: :-) [15:37] tortoise in attack? [15:38] GaryvdM: it seems I'm missing your joke [15:38] No - joke, I was confused [15:38] tak: who are you talking about? [15:40] GaryvdM: perhaps http://doc.bazaar-vcs.org/bzr.2.0.2/en/user-guide/using_gatekeepers.html [15:40] gatekeeper in the brown hat [15:41] Oh - ok [15:41] yes, that === andreas__ is now known as ahasenack [15:44] GaryvdM: thanks [15:44] "We have .NET and Objective-C bindings in progress" <= anyone know where I can find more info? [15:46] Tak: Objective-C I believe it's what pilky doing [15:47] and the other? ;-) [15:47] bzr gui from mac [15:47] .NET? [15:47] I dunno [15:47] it should be something about integration of bzr into MS Visual Studio' [15:47] or maybe what Martin (rar?) doing [15:48] Martin's work on Iropython and jython [15:49] someone called? [15:49] Tak: where's that quote from? [16:05] bialix: Re: bug 481254 - I think we will have to try just reproduce it our selfs. [16:05] Launchpad bug 481254 in qbzr "qdiff failed with "out of memory" error while processing 73 MB file" [Medium,Confirmed] https://launchpad.net/bugs/481254 [16:18] bialix: Re: bug 481254 - I think we will have to try just reproduce it our selfs. [16:18] Launchpad bug 481254 in qbzr "qdiff failed with "out of memory" error while processing 73 MB file" [Medium,Confirmed] https://launchpad.net/bugs/481254 [16:19] GaryvdM_: feel free to ask more questions, I can work as translator proxy [16:19] Vologymyr (Casufi) is not very good in English [16:20] bialix: no more questions to the user - I'm sure that it is not to hard to reproduce, and to fix, I will need to reproduce it my self. [16:20] bialix: just need time... [16:20] as usual :-) [16:28] GaryvdM_: ping [16:28] any idea what's this: QLayout: Attempting to add QLayout "" to QWidget "", which already has a layout [16:28] got while testing naoki's patch [16:30] Hi all [16:31] I'm having problems using basic auth over https, when the same branch accessed over http works fine with the same authentication.conf [16:31] Any hints? [16:32] bialix: When you init a layout, you pass it a parent widget. This sets the widgets layout to the layout you just init__ed [16:32] bialix: you can't do that more than once. [16:32] GaryvdM_: I see [16:32] * GaryvdM_ => tv [16:32] GaryvdM_: QtGui.HBoxLayout() w/o parameters fix this [16:34] naoki: ping [16:57] question from our sysadmin: "can I just add two random files into a bzr branch on VPR09 which having any checkout" [16:57] "I just have one file I need to add from a random server" [16:57] sans VPR09, heh [16:57] $REMOTE_SERVER more like [16:59] phinze: I think you are asking if you can add a file to a branch, without that branch having a checkout/working directory? [16:59] No [16:59] GaryvdM_: -nod- [16:59] yeah i thought that was the case... figured it was worth a double-check though [16:59] thx [17:12] Pilky: it's from http://doc.bazaar-vcs.org/migration/en/why-switch-to-bazaar.html#plugins-and-bzrlib [17:12] (sorry, called away) [17:35] bialix: I want to write a pyqt like interface for source-highlight-qt. (http://srchiliteqt.sourceforge.net/) [17:40] oh bialix not here :-( [17:49] hi all - I'm trying to break a lock on Launchpad, but bzr is giving me this: bzr: ERROR: Unsupported protocol for url "lp-46125520:///~sitecmd-developers/sitecmd/trunk/.bzr/branch/lock" [17:54] not to worry, fixed by removing the numbers and :/// from that [17:54] vxnick: Thats a known bug. Rather do this: bzr breaklock lp:~sitecmd-developers/sitecmd/trunk [17:54] GaryvdM_: thanks, figured that out eventually :) === menesis1 is now known as menesis === deryck is now known as deryck[lunch] === GaryvdM_ is now known as GaryvdM [21:30] jml: I'm popping over to the coffee shop for brekkie, if you want to join me Ihave some testtools refactoring to show & tell on. === abentley1 is now known as abentley === cyphermo1 is now known as cyphermox [22:45] I just tried to do a merge with 1.18.1 and got: bzr: ERROR: bzrlib.errors.ObjectNotLocked: _KnitGraphIndex(CombinedGraphIndex()) is not locked [22:45] This is a merge from a remote pack repo into a local pack repo. === abentley1 is now known as abentley [22:52] mkanat: fixed in 2.0.1 I think. [22:52] spiv: ^ [23:01] lifeless: Yeah, upgrading fixed it, thanks. [23:03] It sure does get peaceful 'round here when everybody's off sprinting :p [23:05] I was wondering. :-) [23:10] mkanat, lifeless: I certainly fixed a bug like that, not sure if it includes that case or not. [23:11] spiv: It seems to have fixed that case. [23:11] Cool. [23:11] spiv: He said upgrading fixed it! Take the credit! [23:11] "Oh, yeah, I totally fixed that. In my sleep. Drugged up on morphine." [23:13] lol