[00:51] hello. i was wondering if it is possible to do 'daggy fixes' using bzr? [00:58] poolie: you around? [01:17] hey all [01:18] i am wroking with a SVN repository that I branched with bzr-svn. I have been working succesfully, but when I bzr merge, commit, push it seems to overwrite any log of the real commit (everyone else is using svn as per normal) [01:18] jskulski, see the bzr-svn FAQ [01:20] jelmer:: thanks [01:38] is there some way to share *uncommitted* changes with someone that's better than "bzr diff" and doesn't involve me committing them? They're incomplete/broken, so I want to avoid committing. [02:45] mzz: "bzr merge --uncommitted" *might* work remotely. [02:45] mzz: You might also be able to rig something using shelves. E.g. "bzr shelve" the changes and then rsync/scp the files over. Or something. [02:45] Peng_: mmm, but only if the branch I'm trying to merge from is accessible remotely by the other user, so that wouldn't really work here. [02:45] mzz: There are probably better ideas, but I don't know them. :D [02:46] Peng_: (perhaps other people would just commit for this case) [02:46] if this was my own code I'd just use commit and uncommit, because I'd be pretty sure the bogus revision wouldn't "escape" after I uncommit it. [02:46] err, if both branches were on systems I control, I mean. Or something like that. [02:47] the goal here was to share a very incomplete change with someone else, and they found a pastebinned diff a little hard to read and apply. [02:48] he wanted me to push the change to launchpad, but pushing a known broken branch to launchpad seemed like a bad idea. [02:48] mzz: Personally, I'd commit it, with a message explaining that it's half-complete and currently broken. [02:48] mzz: Hmm, didn't think of Launchpad. I push things to my server and kind of mirror them on LP as an afterthought. Huh. [02:48] mzz: Still, you could push it up in a separate branch, maybe even in +junk, with a name and/or description that explains it. [02:49] Peng_: I actually have my own http server to push to too, just trying to work like I don't, since it may become a less convenient option in the future. [02:49] I hope it doesn't become less convenient. :D [02:49] yeah, I guess a +junk branch is just the best option available and I should be less anal about only pushing commits I think work (it's actually not like I never commit broken code, I just try not to do it *intentionally* :) [02:50] Heh [02:50] Pretend you didn't notice? :D [02:50] (that it doesn't work) [03:42] OK PEOPLE EMERGENCY [03:42] just kidding [03:42] I'm going to be away from coding headquarters and would like to code, however I need to be able to work on multiple branches [03:43] I can clone the master branch, but then do I have to clone all the branches manually? [03:43] I did bzr clone bzr+ssh://.../path/to/master master [03:50] sohail: What do you mean? You want to get copies of a bunch of branches at once, without having to run "bzr branch" 17 times? [03:51] Peng_, I don't even know what I should be doing, branching or cloning [03:51] and yes, I'd like to basically have exactly the same setup as I have on my desktop [03:51] (all the branches) [03:52] sohail: Welll...I'd probably just use rsync. [03:53] sohail: There are plugins that help with this, but I can't remember their names. multi-pull is one. [03:53] Peng_, then how would I push back, just rsync back? [03:53] is that safe? [03:59] sohail: At that point, I'd use bzr pull. [03:59] sohail: Err, push. [03:59] Peng_, how does it know where to push back? [04:00] oh I'd tell it [04:00] man this is confusing.. [04:00] sohail: ...Didn't think of that. Yeah, you'd have to set up locations.conf or pass the location to push. [04:03] I think my brain is not advanced enough for bzr [04:24] oh Peng_ one more thing, I recall I was told NEVER to do bzr push on the branches because bad things happen [04:24] so I guess I can't bzr push can I? [07:29] sohail: What what? when does bzr push do Bad Things? [08:24] where can I find the source code for bzr start-xmlrpc? [08:24] and for rpc processings in general [08:24] one is returning :not well-formed (invalid token): line 1, column 255 [09:11] hi! Is there a way to get $Id:$ kind of things inside bzr files, apart from using 'bzr version-info' ? [09:12] domas: I'm not sure if it's fully supported yet, but that's one of the purposes of the content filtering stuff added starting in version 1.14. [09:13] * domas eyes http://bazaar-vcs.org/KeywordExpansion [09:14] right [09:23] wuuu hooo === jml changed the topic of #bzr to: Bazaar version control system | 1.16.1 released 26th June, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | Birmingham sprint is *on* [09:26] I don't think I can sprint all the way to Birmingham. Even if I was in good shape, there's the ocean... [09:26] Sorry, bad joke. [09:26] Carry on. [09:27] :) [09:39] gnublade, http://pqm.bazaar-vcs.org/ [10:15] 'mutter' is for general debug log, right? [10:16] Just recently upgraded to latest bzr - now my lp repository gives "bzr: ERROR: short readline in the readvfile hunk." if I try to create a local branch - people with 1.13 (in jaunty) don't seem to be having any issues. [10:17] Does anybody have any clue about what I should try next? Existing local repositories do the same thing, so I though a fresh branch might fix it, but doesn't seem to help :( [10:21] ferrouswheel, I'm going to search launchpad for that error message [10:22] I think that's been fixed now. [10:22] It's definitely in progress, at the very least. [10:22] https://bugs.edge.launchpad.net/bzr/+bug/360476 [10:22] Ubuntu bug 360476 in bzr "short readline in the readvfile hunk on smb mount" [Medium,Confirmed] [10:23] Yeah, unfortunately it's not on a smb mount... although I guess it could be a broader bug that's been named wrong. [10:23] (unless LP use it... which I guess would be highly doubtful!) [10:31] what's weird is that "bzr pull" works on the local repo, but "bzr update" gives the same error as branch. [10:57] FYI, the problem I was having was due to a corruption from a not cleanly unmounted drive. :( [11:17] Eh. I guess I'm glad there wasn't a bug in bzr, but I hope ferrouswheel was able to recover his/her/its data. [11:55] gnublade1: bug 249919 [11:55] Launchpad bug 249919 in bzr "should have an example of -c usage on diff" [Wishlist,Confirmed] https://launchpad.net/bugs/249919 [11:58] bzr-svn incompatible with google code? [11:58] bzr: ERROR: subvertpy.SubversionException: ("REPORT of '/svn/!svn/bc/272': 200 OK (http://jrfonseca.googlecode.com)", 175002) [11:58] mgedmin: sometimes. google code is a funny svn server implementation [11:59] That's a new one for me, though. [12:01] 175002 is the ever helpful ERR_RA_DAV_REQUEST_FAILED. [12:01] fwiw [12:10] LarstiQ: bug 213185 [12:10] Launchpad bug 213185 in bzr "tag conflicts do not change exit code" [Medium,Confirmed] https://launchpad.net/bugs/213185 [12:14] git-svn accepts that repository, but then kills me with merge conflicts when trying to rebase later [12:24] mgedmin, Not sure about that one [12:25] mgedmin, 157002 is a generic "Request failed" return code in Subversion [12:25] you can try yourself with bzr branch http://jrfonseca.googlecode.com/svn/trunk/xdot xdot-bzr [12:25] or I could go to launchpad and look for bug reports... [12:27] full traceback: https://bugs.launchpad.net/bzr-svn/+bug/395482 [12:27] Ubuntu bug 395482 in bzr-svn "can't bzr branch from google code" [Undecided,New] [12:28] mgedmin, this looks like a problem in the google svn server [12:28] mgedmin, try running "svn log -r272:1 -v http://jrfonseca.googlecode.com/svn" [12:29] you'll see the same error [12:29] fun [12:29] svn log -r2 -v http://jrfonseca.googlecode.com/svn fails [12:29] all other revs appear to be normal [12:31] the web view gives a 404 for that revision: http://code.google.com/p/jrfonseca/source/detail?r=2 [12:32] * mgedmin looks for a way to report bugs in googlecode.com, in vain [12:38] mgedmin, Actually, it might be a bug in the way a particular reply is handled in libsvn [12:38] mgedmin, so it might be worth reporting and attaching a packet trace [12:55] moin [13:04] jelmer, hello :) [13:04] jml, Hey [13:04] jml, How's the sprint going? [13:04] jelmer, pretty good. [13:05] jelmer, at least I'm getting stuff done that I've wanted to do for ages :) [13:06] jelmer, wish you could have made it. [13:06] jml: Cool, what are you working on? [13:07] jelmer, using launchpadlib in the launchpad plugin [13:07] jml: ah, neat [13:07] jelmer, first command implement: bzr lp-mirror [13:07] implemented, rather [13:08] now I want to do interactive commit [13:16] of course, I'm going to fix launchpad first :( [13:27] jml: You know there's a bzr-interactive plugin? [13:28] Peng_, yes. [13:28] OK :) [13:28] Peng_: it seems to consist of shelf1 files copied from bzrtools [13:28] Peng_: with a couple of bugs filed against it that would be solved if it was shelve2 based [13:29] I used to use hg's interactive commit plugin, as a substitute for shelves, but I've never actually done it in bzr. :D [13:29] Well, maybe once, but not recently. [13:43] bzr push --remember refuses to change the push branch [13:43] it says Value "bzr+ssh://bazaar.launchpad.net/%7Emgedmin/gtkeggdeps/trunk/" is masked by "bzr+ssh://fridge/home/mg/www/gtkeggdeps/bzr/" from locations.conf [13:43] what on Earth does that mean? [13:44] hm, I have a ~/.bazaar/locations.conf with interesting contents [13:44] it says ##push_location:policy = norecurse [13:44] without the ##, I mean [13:44] I haven't seen that one before [13:46] I assume I had an unfortunate interaction with bzr-svn (since the parent dir of my bzr branch is in svn), and probably applied some workaround to make it work a long time ago [13:46] and now the long-forgotten workaround is biting me [14:00] is there a way to ask bzr to try to opportunistically push my changes to the parent branch after every commit? [14:00] bzr bind kinda does that, but it insists too strongly [14:00] I don't want the commit to fail if I'm offline [14:00] and I'd like to be able to ^C if the push is too slow [14:01] but have the commit committed locally without any further interaction [14:01] iirc amanica wrote something for that [14:03] can't find it right now [14:03] mgedmin, 'bzr ci && bzr push' would one way to do that. [14:04] mgedmin, but I don't think bzr has something built in. [14:05] jml: What does lp-mirror do? [14:05] jelmer, requests that launchpad mirror the branch now [14:05] ooh [14:05] jelmer, Launchpad needs a new method on its API for it to be fully useful though [14:06] jelmer, I'm writing that new method right now :) bug 395076 [14:06] Launchpad bug 395076 in launchpad-code "API for getting a branch by URL" [High,Triaged] https://launchpad.net/bugs/395076 [14:17] kfogel, hello [14:18] jml: hey! [14:28] ...I totally didn't know there was a "bzr mkdir" command. [14:30] Peng_: me either! [14:31] ouch [14:31] why do you hate me so, bzr! [14:31] I do bzr push lp:myproject; I do bzr bind; I edit some files; I try to commit, it tells me of a divergence and tells me to bzr up; I run bzr up and I get a conflict of some kind [14:31] now I've no clue what's happening in my working dir or what to do [14:43] ah, what I did was bad: bzr push remote; bzr add newfile; bzr commit; bzr bind remote; edit file; bzr commit -> divergence detected! [14:43] shouldn't that bzr bind have pushed my local changes to remote? === vxnick-AFK is now known as vxnick [14:44] if that's a bug, I've got a typescript file demoing my problem [14:47] afaik, it shouldn't [14:49] jml: do you remember what my $PWD was when you walked over to me? [14:49] nm [14:54] https://bugs.launchpad.net/bzr/+bug/395514 has the exact sequence of commands [14:54] Ubuntu bug 395514 in bzr "bzr push; bzr add; bzr ci; bzr bind; bzr ci -> weird conflict of a branch with itself" [Undecided,New] [14:58] aaargh data loss [14:58] :( [14:59] bzr revert --forget-merges or something else I did trying to untangle the mess resulted in that file disappearing [14:59] ah, bzr revert file3.txt [14:59] deleted it [14:59] wtf [14:59] revert means "give me what was there before" [14:59] it was there before [14:59] it was committed, ffs [15:00] mgedmin: you're bound now, right? [15:00] mgedmin: the revision is still in your repository [15:00] at least I have the full contents (both versions) in the terminal scrollback [15:00] I unbound as soon as it bit me [15:00] mgedmin: try `bzr heads --dead-only` [15:01] * jml wonders why bzr hates mgedmin so much [15:01] then you can pull -r revid:relevantrevid [15:01] because I'm impatient and don't read docs [15:01] it's supposed to be intuitive and easy to use and forgiving, right? right? [15:01] mgedmin, it is. [15:01] mgedmin, ... supposed to be. [15:01] and if I believed that, you'd sell me a bridge, right? [15:02] nah, bazaar is fine, it just needs a few more years to mature [15:02] to make a fool-proof system you need years of stress-testing by fools like yours truly [15:03] mgedmin, I think that bound branches in particular need to have more love [15:03] * mzz is confused about what happened there [15:04] mzz: https://bugs.launchpad.net/bzr/+bug/395514 has the exact sequence of commands [15:04] Ubuntu bug 395514 in bzr "bzr push; bzr add; bzr ci; bzr bind; bzr ci -> weird conflict of a branch with itself" [Undecided,New] [15:04] yeah, I was just reading that [15:04] I would've expected it to complain when you ran that bind [15:05] so would I [15:05] either push or tell me that the branches aren't identical [15:05] I expected it to push [15:06] mgedmin, well, I can reproduce that error locally [15:06] there was https://bugs.launchpad.net/bzr/+bug/43744 [15:06] Ubuntu bug 43744 in bzr "bzr bind should just bind, not push" [Medium,Fix released] [15:06] which says that bzr bind no longer pushes, but it also talks about warning the user, which never happened [15:08] so bind should warn [15:08] and that conflict error should be a *lot* more helpful [15:08] since following the instructions can lead to data loss. [15:10] so afaict its suggestion to run "update" is backwards [15:10] I should mention that [15:10] afaict running "bzr push ../bazaar-hates-me-again" after the "bind" makes it work [15:11] running "bzr up" at that point is confusing at best, and "bzr push" complains about no push location being set [15:13] bzr heads: unknown command "heads" [15:13] mgedmin, you need bzrtools for that [15:13] in fact running "bzr push ../bazaar-hates-me-again" after "commit" fails (and tells you to run "update") works [15:16] I expected doing the (failing) commit with --local and then running "bzr up" to work too, but that also gives a weird conflict. [15:37] gnublade1: https://lists.ubuntu.com/archives/bazaar/2009q3/060216.html === gnublade1 is now known as gnublade === Xavura is now known as Xavura-busy [16:09] hi guys, i'm trying to build the latest bzr on windows - it was working before but now i'm getting errors about missing zdll [16:09] presumably there's some new dependancy i'm missing? [16:11] oh wait, i can just use the binary dist can't I >.< [16:12] Glenjamin: libz has recently become a dependancy. But yes, you can use the binary installer :) [16:12] real men build their own binary ;) [16:12] heh, i tried! [16:12] :D [16:13] also, what is the recommended method for installing on OS X? [16:13] i'd go with the binary [16:13] i was hoping to play with bzr-svn and qbzr on my work computer [16:14] Szilveszter announced some minutes ago that he released a binary for leopard [16:14] https://launchpad.net/bzr/1.16/1.16.1 [16:14] excellent [16:15] also, is there any way to get the windows installer to make a bzr.py file in the Scripts dir? [16:15] I am currently installing bzr by using MacPorts which his horribly outdated - so I had to patch the portfiles manually [16:15] it only makes bzr and bzr.bat - but i have .py on my pathext [16:15] i tried installing bzrtools using ports, it managed to install graphviz from source including all dependencies [16:16] yeah, but bzrtools ist out-of-date as well (1.13) [16:16] If only those MacPort maintainers would apply my patches o.O [16:17] yeah, so after it downloaded compiled and staged about 15 dependencies, it didnt run >.< [16:17] easy_install wasnt having any of it either [16:17] hehehe :) [16:18] also on linux i've found easy_install installs bzr and bzrtools as separate eggs, so the plugin doesnt get placed inside bzr [16:21] yes [16:21] * LarstiQ stabs easy_install in the face [16:22] amusingly the windows install is the least painless [16:22] except on ubuntu with root i suppose [16:22] hrm? [16:23] setup.py build_ext -fi doesn't suffice on linux? [16:23] "make" is shorter. :D [16:23] oh, sure [16:23] "setup.py install" is fine [16:23] but you have to download and unpack [16:23] or that [16:23] because easy_install fails [16:23] and on windows I have to download and click through the installer [16:23] I fail to see the problem [16:24] also, on linux you should have it packaged for $yourfavoritedistro [16:24] assuming i have root, yeah [16:24] ah, there's that. [16:25] it'd be much easier if you didnt keep updating so often :p [16:25] Glenjamin: not that you need to install bzr to use it [16:25] time to have another go on the mac [16:25] it runs quite acceptably as pure python straight from the tarball, just a bit slower with the extensions not built [16:25] 2a repos will also use more disk space without the C extensions. [16:26] and it runs with no dependencies other than a recentish python if you don't need sftp [16:26] ah, I didn't know about that one [16:26] Probably not much or anything, but some. [16:26] The Python version of groupcompress is limited to line-based deltas, while the C version is not. [16:27] I hope the recent glitches with the release tarballs missing c files have been worked out then [16:27] has much work been done with the smart server since 1.10? [16:27] mzz: Heh. [16:27] Glenjamin: ...Yes. [16:27] Glenjamin: Define "much". [16:27] Glenjamin: skim the release notes [16:27] will do [16:28] Glenjamin: ISTM a lot of the hpss changes have to do with stacking and the 2a disk format. If you're not using those, the changes are less relevant. [16:28] i had a bit of a go at getting a web interface + authentication + smart server going a while back [16:28] didnt really get anywhere [16:28] * mzz is tempted to go with "meh, just use launchpad" for that one [16:29] * Peng_ is happy with Loggerhead + bzr+ssh + bzr+http. [16:29] Peng_: streaming push though [16:29] I occasionally use bzr+ssh, haven't bothered with bzr+http [16:29] bzr+ssh is pretty neat in that it even works pretty well on windows using plink + pageant last time I tried [16:30] LarstiQ: Ah, good point. There are some nice new features, huh? :) [16:30] mzz: For a client, bzr+http needs nothing. [16:30] yep [16:30] I run it on my server for fun. Mostly dogfooding, I guess. [16:30] Peng_: I'm usually not a client, and for small branches plain http suffices [16:31] mzz: Especially since I use plain CGI, so the startup time diminishes the efficiency benefits. [16:31] Someday somebody's going to do something weird and a bzr-smart process will take out my poor little VPS. :D [16:33] gah [16:34] the whitespace decoding bug in bzrtools still hasnt been fixed :( [16:34] Whitespace decoding bug? [16:35] on vista the tab completion throws a unicode decode exception because string.whitespace contains a non ascii character [16:35] Ah, fun. [16:36] i reported it months ago, its been repreoduced by multiple people, and has a fix [16:40] oh wow, the mac installer worked perfectly [16:55] why is bzr transfering so much data? i've just done a pull, 4 MB were transfered, but only 3 files were updated. [16:56] LoRe: one answer could be (depending on the transport and the format), is that it needs to first read the indices to find out what to get [16:59] LarstiQ: ic, thanks [17:02] LoRe: you can try -Dtransport and -Dhpss for some more detail [17:04] anyone know which version of the svn development libraries i need for subvertpy? (for bzr-svn) [17:04] LarstiQ, https://bugs.edge.launchpad.net/bzr/+bug/238776 [17:04] Ubuntu bug 238776 in bzr "Confusing error message if ssh login fails while using lp url" [High,Confirmed] [17:04] Glenjamin: the ones matching your subversion library. [17:04] Glenjamin: ideally 1.6, but 1.5 should work too [17:05] ty [17:14] Hell, 1.4 works... [17:16] Peng_: it does, but it is rather suboptimal [17:17] as i'm doing this [17:17] i'm stuggling to remember why i didnt just use the windows installer for the whole lot [17:18] LarstiQ: Well yeah. === umontabea is now known as abeaumont [17:31] has anyone had problems opening a transport that uses http basic auth? [17:32] Glenjamin: nafaik, can you be more specific? [17:32] auth['user'] is None gives a key error on line 1921 in the http transport lib [17:33] 1291 even [17:34] i've only reproduced it with svn so far, on mac and windows [17:34] i dont know of a bzr branch behind http auth [17:36] Glenjamin: is that a svn url I can try against? [17:36] jml: when you're done, got a change that could possibly benefit with a test, or should I just bang it into another email? [17:36] this particular one is VPNed i'm afaid [17:41] gnublade, another email, I think... === jml changed the topic of #bzr to: Bazaar version control system | 1.16.1 released 26th June, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | Birmingham sprint is gone for a real ale or two === ddaa1 is now known as ddaa [19:30] hmmm [19:36] sorry for (temporarily) removing subvertpy from the bzr ppa === Xavura-busy is now known as Xavura [20:15] anyone know what's going on in http://launchpadlibrarian.net/28691173/buildlog_ubuntu-karmic-i386.subvertpy_0.6.7-1~ppa1~karmic1_FAILEDTOBUILD.txt.gz ? [23:27] james_w: looking at it now [23:31] james_w: http://groups.google.com/group/nose-users/browse_thread/thread/ab603fb160cc2d9c seems relevant ("ython-nose is fully broken in ubuntu karmic alpha 2 and I'm not able [23:31] to understand why. " [23:33] james_w: or more specifically, https://bugs.edge.launchpad.net/ubuntu/+source/nose/+bug/389942 [23:33] Ubuntu bug 389942 in nose "python-nose is broken with python 2.6.3-dev" [Undecided,New] [23:34] sigh, reporting as I go [23:35] james_w: upstream nose bug: http://code.google.com/p/python-nose/issues/detail?id=276 [23:36] james_w: I'm willing to live with subvertpy not working on karmic till someone fixes nose or python itself