[04:22] bzr: ERROR: Invalid url supplied to transport: "sftp://mathrick@lynx.imada.sdu.dk/home/mathrick/public_html/repo/.bzr/branches/gtk/": local urls must start with file:///, UNC path urls must start with file:// [04:22] any idea why that happens? [04:22] http://pastebin.com/V6HeubrE is a fuller output [04:23] this is on win32, and it worked before [04:23] (but the local repo and working tree has since been recreated) [04:24] also previous colo-sync-from which I used to create the repo worked fine [04:25] oh, hmm [04:25] light checkout root: . [04:25] checkout of branch: sftp://mathrick@lynx.imada.sdu.dk/home/mathrick/public_html/repo/.bzr/branches/gtk/ [04:25] this is wrong, it should be .bzr/branches/gtk [08:22] morning [08:23] i'd like to use bzr for git-based project and wonder if 'explorer' will use dpush when i push to github or i've to use cli? [08:24] what is dpush? :o [08:25] AuroraBorealis: from the help "Purpose: Push into a different VCS without any custom bzr metadata." [08:26] you can run a 'custom command' in explorer [08:26] or just use the command line if it doesn't have a explicit option to dpush [08:26] ok [08:46] i dpushed my branch to the github, but i do not see it listed at github which still shows only original braches from the forked repo [08:47] i created shared repo, pull from github. created 'feature' branch locally and pushed back to github...what am i missing or how to use 'feature branch' workflow to contribute to github project? [08:48] feature branch is just a trunk branch inside a shared repo [08:49] not a trunk branch but just some branch inside a shared repo [08:49] so you just dpush the branch to github i guess :o [08:50] right...i cloned pulled-ed github branch in order to work on it and wanted to push it back (afer commiting some fixes) [08:50] so you would probably dpush that back [08:51] but that 'new' branch (named as 'doc-fixes') was dpushed back to github, but it's not listed there :-/ [08:51] maybe it takes a minute? [08:51] hmm [08:52] wait like 20 min then try again i guess [08:52] or maybe dpush is bugged or something o.o [08:53] i believe it's something else...like some github idiosync... [08:54] hopefully jelmer or someone experienced with bzr-git & github will appear [08:55] heh. [12:11] what is the status of colo-branches in bzr? are they going to appear in 2.4? [12:21] heya, I'm new to bzr. (coming from git) and can't find out the name of the command I want to do the follow [12:21] Ive made some commits in a branch [12:21] i want to remove one of them [12:21] (like gits, interactive rebase, and not pick one of the commits) [12:21] is this possible? [12:22] in same file? [12:23] yeah [12:23] if it's not trivial, I'll just sort something out by hand [12:25] maybe you can try withe shelve [12:27] it's alright. I'll make a new branch then apply patches of the parts I do want [12:27] *new branch from master [12:28] * gour is usung fossil atm considering to switch to bzr [12:28] it's so hard trying to switch betweem RCS systems [12:28] I'm normally on git, except for one project, and I'm sure bzr is just as good, but it's nonetheless different [12:29] and that gets so confusing [12:29] especially when the same word mean different things [12:29] * gour thinks git is too complex [12:29] fortunately, there is fast-import machanism to switch [16:20] `hg clone -b 2.7 . 2.7` ...that looks a little funny [16:20] d__ed: you can use the bzr-rewrite plugin [16:21] mgz: what does that mean? [16:21] mgz: clone the branch/tag called 2.7 from the current dir to the dir 2.7? [16:22] yup. I'm not sure the way the cpython repo is structured really makes sense to me. [16:22] but then, neither does what mercurial calls branches. [16:23] can't work on bzr without a newer python now though, and no point testing against my rusty svn copy. [16:24] larstiq: getting to merging the rest of my test cleanup branch which should reduce the number of things to file bugs about for pypy support [16:25] ha... and that mercurial command did the wrong thing, created the working tree in the cwd rather than the 2.7 dir [16:25] perhaps branching into a subdir upset it. [16:26] * LarstiQ blinks [16:26] mgz: possibly :) [16:26] mgz: and yay test cleanup \o/ [16:26] ...now it's got a working tree in both dirs. probably just overwrote the no trees setting. [16:28] mgz: about things failing on pyp, as you know the multi byte codec test fails. Not very surprising considering https://bitbucket.org/pypy/pypy/src/7f593e7877d4/pypy/module/_multibytecodec/app_multibytecodec.py [16:29] heh. [16:29] mgz: I didn't manage extracting a small example from bzr to disprove Armin's assumption there [16:29] well, he's wrong [16:29] I guessed as much :) [16:30] mgz: and was hoping you could give me some pointers [16:30] the module isn't well maintained these days [16:30] but is likely to in use for anyone on a ckj terminal [16:32] various applications use streamwriters to put things on the terminal, and look at sys.stdout.encoding to create them [16:36] * LarstiQ generates a ja_JP.EUC-JP locale [16:37] ...the pypy version I have installed doesn't set sys.stdout.encoding at all, which might be why they've not got bug reports [16:37] or they've fixed that since 1.2.0 [16:38] mgz: it's None in my nightly from a couple of days ago [16:38] okay, that's the main bug then. [16:38] if pypy isn't detecting terminal encoding printing unicode just doesn't work. [16:39] * LarstiQ wonders how to test that [16:40] my terminal inteprets the utf8 back again when I think it shouldn't [16:40] print u"\xa7" # or similar? [16:41] ah, that works (as in, gives me a UnicodeEncodeError) [16:41] if it works, perhaps they've got the default locale set to utf-8 now? [16:41] ^good good. [16:42] and it does indeed work in cpython [16:43] It's likely most of the unicode related tests are being skipped on pypy then. [16:43] see bzrlib.tests._UnicodeFilesystemFeature implementation [16:43] * LarstiQ hasn't been able to run the full testsuite yet [16:44] if we can't stat a unicode name, we don't run the test, so output bugs are probably also not being exposed. [16:44] one thing I do is run useful test subsets. [16:44] mgz: I can run all the blackbox tests, off-hand I don't recall any skipped tests due to unicode feature [16:45] hm. [16:45] maybe that step now works? which would be good. [16:45] at least utf-8 would be being output correctly then. [16:46] `os.stat(u"\xa7")` on pypy 1.2.0 raises UnicodeEncodeError for me, but that may be windows only/since fixed [16:47] the `-s bt.test_` subset is quite good as an alternative to `-s bb.` [16:47] mgz: gives a UnicodeEncodeError on the nightly [16:49] so, when I get the test cleanup stuff landed, we probably want bugs filed for all the remaining failures [16:49] bweh, 10 seconds per test [16:49] mgz: yup [16:49] ugh. [16:52] * LarstiQ will make an account on bugs.pypy.org in the next weeks [16:53] mgz: thanks! [16:53] * LarstiQ goes cooking [16:53] bye! [16:54] anyone using bzr-git with github? [16:55] i wonder how to push my branch tobe visible at github, if possible or is it better to (as i did) import git repo to LP, use bzr and then just email 'bzr send' bundle to git-repo maintainers? [17:00] hm, I suspect they might prefer a plain patch. jelmer probably knows how well bzr-git works with github. [17:00] mgz: 'send' bundle has too much 'context'? [17:04] I doubt git understands the extra metadata in the bundle, they had a different method of doing the same thing. [17:05] i just wonder what's the easiest way to submit patch(es) to git-based project by using bzr [17:07] it's a good question. [17:08] I think there is bzr send --format=git now [17:10] i read the following in the manual: "They can also be useful when communicating with upstream projects that don’t use Bazaar. In particular, the preview of the overall change in a merge directive looks like a vanilla software patch, so they can be applied using patch -p0 for example." [17:10] in regard to merge directives [17:10] james_w: in 2.4? [17:11] I'm not sure when it was added [17:12] sounds good [17:16] james_w: http://bazaar.launchpad.net/~jelmer/bzr-git/send/revision/533 [18:30] * workthrick looks around for jelmer [20:22] I'm having trouble resuming my collection branch from jam's partial merges [20:23] if I merge the current version to dev it has some of the changes that have already landed, and misses the most important bits in bzrlib.tests [20:24] presumably this relates to the "Warning: criss-cross merge encountered. See bzr help criss-cross." I get [20:24] * gour played/used bzr after long time today....very pleased with it [20:24] but it's odd that the merge command lists bzrlib/tests/__init__.py [20:24] but bzr diff on that file is empty [20:25] i sent test 'bundle' with git format hoping it's possible to apply it upstream [20:25] I think maybe what jam did works on branches where he works in his normal fashion, but something in my branch history broke it? [20:26] I'm not sure what the fix is then as two partial merges are already on bzr.dev === _thumper_ is now known as thumper