[00:03] so the fetch over sftp was much quicker, the autopack not so much [00:04] spiv: sftp push taking 8 minutes and bzr+ssh being killed after 45 minutes is pretty sad making :( [00:14] mwhudson: in 1.12, if the branch was stacked, its the same code as 1.13 is doing [00:14] mwhudson: _no_ change [00:15] mwhudson: I realise its totally sad, but hey, thats why we added the streaming codepath [00:16] lifeless: no stacked branches here [00:16] * mwhudson resovles "less pointless grousing" [00:19] igc: hi [00:21] lifeless: it is a regression since InterOtherToRemote was removed; now InterPackRepo will never trigger if one end is bzr+ssh [00:22] lifeless: so even non-stacked pushes to packs suck if the server is 1.12 [00:23] lifeless: a "fix" would be to update my unmerged InterOtherToRemote hack that I did for John (that checks _is_remote_before((1,13))) to be in InterPackRepo [00:23] hi jelmer [00:24] I'd be ok with merging that too, because that with the _ensure_real_inter mess gone that hack wouldn't have to cause get_parent_map RPCs to be skipped too. [00:24] (Which was my main objection to merging the hack for John) [00:29] igc: So, I've been looking at implementing a svn-keywords filter [00:30] igc: however, I'd ideally like its value to match the value of the svn:keywords property (to avoid the need to support two settings in the future) [00:31] jelmer: ok [00:31] igc: svn:keywords however contains a comma-separated list of keywords to expand [00:32] spiv: alternatively we could add a cache when we're pushing, which we can detect [00:32] spiv: or tell people to upgrade ;) [00:32] igc: is there some way to support that atm? [00:33] igc: It looks like the current filter registration function requires a dictionary with all possible settings [00:33] jelmer: it does [00:34] jelmer: maybe we want a 'catch-all' handler as well [00:34] jelmer: basically, the current design makes it easy to ... [00:34] have different filters for different values [00:35] jelmer: but I think you want the *one* filter covering all values, don't you? [00:36] igc: yeah, having separate filters, one per keyword, seems overkill [00:37] jelmer: I don't feel it's overkill - it maps well to the eol case for example [00:37] jelmer: but it's definitely not what you need I think [00:37] igc: I don't think multiple *filters* is overkill [00:38] igc: I think having one filter for $Id$, one for $Date$, one for $SVNHead$, etc is [00:38] jelmer: right [00:39] and the current keywords filter handle all keywords from memory [00:39] it just doesn't a configurable list of which ones to expand [00:39] s/doesn't/doesn't take/ [00:44] igc: right, so a catch-all handler would basically mean registering a "fn(value) -> filterlist" callback rather than a dictionary ? [00:45] jelmer: yes, something like that [00:55] igc: ok, I'll look into that [00:56] igc: did you see my patch for lazy registration? [00:56] igc: Do you prefer an extra wrapper function or rather making the registry public? [00:59] jelmer: just now - approved [00:59] I prefer a wrapper fn (for now at least) [01:02] igc: thanks [01:09] * igc starts reviewing jam's LRUCache patch [01:44] hey I gotta quick question about the FAQ page on http://bazaar-vcs.org/FAQ#head-e6448836a60a73c1954f287ef5e928b79e3ff005 . [01:45] In section "4.1. Are binary files handled?" what are other tools that can be used to better handle binary files and or media files? [01:47] trypticon: in what way [01:47] I just wanted to know if there are better tools than bzr for handling binary files. [01:48] I'm not aware of anyone with better answers in the open source version control space today [01:49] ^distributed [01:49] humm.... So would it be a good idea to use an app like bzr for handling Binary-only files for version control? [01:49] well, plenty of folk do; it really depends on your requirements and what you mean by handling, and if your machine has the resources [01:50] like, if you are versioning 10GB database, files, you'll need 35GB of main memory, or so, to do a commit [01:50] but if you just want archiving, then maybe rsync is better and don't use version control at all [01:50] I'm trying to set up an archive of binary files (iso's. executables, etc) that I would like to be able to quickly checkout and manage. I was wondering if bzr would work for this task? [01:51] iso's may be noticably slow, (700MB is a lot to shuffle round), executables shouldn't be an issue [01:51] why would you need 35G to handle a 10GB file? [01:52] 10GB for the copy you are recording, 10GB for the basis copy to generate a diff, and python has some overhead for objet handling; doing a merge requires 3 copies, and some commits need to do a merge to generate annotations [01:52] thats assuming we manage to perfectly avoid unnecessary copies in memory [01:54] sounds to me like bzr probably isn't the tool I should be using. Humm..... [01:55] I suggest giving it a spin and seeing if it does what you need [01:55] we are improving things continually, and at some point will create drastically better handling for large files [02:00] jelmer: pong [02:00] the thing is that I need something strictly for handling binaries though. Binaries as large as 4.5gigs. I don't have any more than 3gigs on my system so I'm not sure bzr will be able to do what I want it to. Either way I will take some time and look through the site because it sounds like a great system. [02:02] trypticon: yes, I suspect you'd have some trouble using bzr for 4.5GB binaries on a 3GB memory system :) [02:06] I'll continue to research [02:07] thanks so much for your help [02:07] my pleasure, good luck [02:17] mwhudson: lp:~spiv/bzr/remote-pack-hack probably fixes your performance issue [02:17] mwhudson: as a bonus, I think it improves pushing to stacked packs on old servers too [02:17] spiv: cool [02:18] mwhudson: e.g. pushing up that branch only took 175 RPCs (1m 27s) [02:18] mwhudson: which is still much worse than a 1.13 server :) [02:18] * spiv tries with bzr.dev to compare [02:19] Oh, hmm, a test failure. [02:24] I must have not been paying attention, 1.14dev NEWS file is totally different then 1.13 [02:32] * SamB wonders if he should bother to report that bzr repo-push doesn't work on launchpad urls ... [02:35] SamB: what should repo-push do? [02:36] mwhudson: yeah, it's a bit better than bzr.dev even on this trivial branch [02:36] mwhudson: it should make a world of difference to pushing up a stacked branch with a large delta (ObNag: although still not as awesome as 1.13 on the server :) [02:37] spiv: that's coming [02:37] mwhudson: I know :) [02:37] mwhudson: just think of me as the kid in the car repeating "are we there yet?" [02:37] spiv: two can play that game [02:38] * mwhudson mumbles something about lazy inventories [02:43] mwhudson: heres one we prepared earlier [02:46] BasicOSX: yes [02:46] BasicOSX: its restier [02:47] heh, isn't that more RESTful? Anyway, how can I do a local convert of the docts into html? I got some un-restier markup and PQM hates me [02:48] make rst2html? [02:49] make docs [02:51] Or to just do the NEWS file, "make doc/en/release-notes/NEWS.html" [02:52] igc: ping [03:01] w00t! /me continues to be a bad influence: * esmerel makes a brief mention of source control in one of the book chapters, and includes bzr cuz of you [03:02] * emmajane bets that didn't make sense to anyone else. [03:03] can some people help with a quick test: go to bazaar-vcs.org and tell me if you see a search box in the top right [03:03] poolie: I do [03:03] poolie, are you fixing templates again? [03:04] I cleared cache and am still seeing a search box top right (under community and plugins) [03:05] i'm trying to help newz fix them [03:05] there's meant to be one [03:05] i don't see it, and i don't know why [03:06] poolie, which browser? [03:06] poolie: the merge of NEWS from 1.13.1 into bzr.dev with the format change was messy, think I got it, PQM is happy, but need another set of eyes looking at it [03:07] jaunty's firefox [03:07] poolie, firebug is having a hard time finding the actual markup for the search box. [03:07] ah i see [03:08] i had my account set to use his preview stylesheet, not the default [03:08] ah [03:09] the tab index is screwy because of the edit stuff being at the bottom. not that it really matters, just "point of interest" [03:18] there is an attribute for tab indexes ... or is that how the problem arises? [03:29] hello [03:30] is there any how to start with bazaar ? [03:30] tried the manual ? the wiki ? [03:31] http://bazaar-vcs.org being the latter [03:32] jelmer: I'm hearing scary rumours [03:32] jelmer: about dulwich & history [03:33] what's dulwich? [03:33] the bzr-git git implementation [03:35] and what are the scary things you've been hearing about it & history? [03:36] SamB thank you, first opensource project with documents [03:36] Stanlin: what? you've never seen documentation for an open source project before? [03:40] poolie: have you seen the Branch.open jail / ignore_fallbacks thread on the list? [03:40] poolie: a third opinion on that thread would be welcome [03:40] a bit; i'll look [03:41] poolie: we need a tie break on 'boolean flag used explicitly in the server' and 'trinary flag with 'auto' as the default' [03:41] poolie: you can nearly entirely ignore the rest of it - we're both happy with the code and its been reviewed etc [03:43] so if it was not "automatic in the server" then if some code in the server called it with "yes, open" it would run into the jail wall and fail? [03:44] poolie: unless it had explicitly opened the jail first [03:44] interesting thread... [03:45] you know it's spiv when there's a correct unicode diaresis on "naïve" [03:46] diaeresis* [03:46] * igc lunch [03:46] :) [03:46] æ surel [03:46] y [03:47] "næve"?? [03:48] diæresis [03:50] oic; maybe [03:51] i tend to only use unicode when needed [03:51] me too [03:51] I can't see any of the unicode glyphs I just typed [03:51] lol [03:52] ä [03:52] î [03:52] *anyhow* [03:52] ï [03:52] ah yes [03:52] lifeless: stop flushing your vowels in public :P [03:53] I'm in my own living room thank you very much :) [03:54] lifeless: i think you marked bug 181367 invalid [03:54] Launchpad bug 181367 in bzr "bzr update should work in a treeless bound branch" [Low,Invalid] https://launchpad.net/bugs/181367 [03:54] despite filing it yourself :) [03:54] i have an old tree that starts to fix it [03:54] should i discard it? [03:54] uhm [03:54] I'll tell you once you tie break [04:03] sent [04:04] don't mix gaol and jail :) [04:04] poolie: so, I don't think update() on a treeless bound branch is safe or sensible, you need a tree, as my last comment describes why [04:05] i agree with your reasoning [04:05] i just wasn't sure if you'd had educated second thoughts or what [04:05] if you have a branch that makes update cleaner and safer, that is good; if your goal was just to fix that specific bug - delete it [04:06] poolie: I only use gaol in the branch nick :) [04:06] spiv: still. [04:06] people may search for it [04:06] we need some fun! [04:06] This is a good moment for lifeless to say "they should use bzr search" ;) [04:06] they should use bzr search [04:06] and it should know [04:06] hee hee [04:07] anyhow, we restrained from creating commonwealth gaol in the api [04:07] that was good [04:07] so the blackbox test fell to 23 calls because it was previously opening the fallback across the wire? [04:09] it would be nicer if this was not done in per-thread state but i suppose that's the only practical way for testing [04:09] poolie: no [04:10] poolie: it was because the server was opening the fallback [04:11] poolie: and the hook to record events was getting the events generated by the server during its opening of the fallback; each of the 23 commandline client generated hpss calls that was on a branch was triggering many hpss operations in the server (to the server itself) [04:14] * ToyKeeper misses feature branches and bzr's merge-aware bisect tool [04:14] * ToyKeeper is isolating a bug with hg :( [04:17] lifeless: oh huh [04:26] poolie: so fixing third-party access requests fixes the apparent request count :) [04:26] poolie: btw, did you see jam's 'dont use =======' in news? [04:26] lifeless: yes i thought i fixed it [04:27] Hmm, not according to my copy of bzr.dev. [04:27] not in .dev, it starts with ============= Bazaar Release Notes ... [04:29] ow... my head hurts. In this hg tree, revision 1 is between r783 and r784. [04:29] fun [04:30] A bisect narrowed it down to r771 to r773, then jumped back to r491 (which apparently actually happened in-between). [04:31] I guess all I'm saying is... I love you guys. :) [04:31] cool :) [04:35] lifeless: oh ok, i changed the others but not the toplevel one [04:35] i'll change that too [04:35] though, it's odd to me that resolve thinks they're conflict markers [04:35] which should be just '======= ' [04:35] i mean it should require 7 followed by a space [04:35] I'm happy however you want to fix it :) [04:35] though requiring whitespace to be significant is a little ugly too [04:36] I mean, why not '=======\n' [04:36] * lifeless shrugs [05:23] spiv, jml, i just got [05:23] LockFailed: Cannot lock LockDir(lp-46121936:///~mbp/bzr/controlfiles/.bzr/branchlock): Transport operation not possible: readonly transport in _remote_lock_write [05:23] trying to push to https://code.edge.launchpad.net/~mbp/bzr/controlfiles using bzr.dev [05:23] i thought this was strange [05:24] lifeless: apparently cvs established the convention that there must be a space there [05:24] and some tools expect it so we had to do it too [05:24] poolie: it's a mirrored branch [05:24] ah ok [05:24] there has to be read only access to it for stacking [05:24] that's a bit unobvious but of course you're right [05:25] and um well [05:25] accessing it :) [05:25] wbn if it said "mirrored branch is readonly" but i understand [05:26] poolie: it'd still say "Cannot lock ...: Transport operation not possible: mirrored branch is read only" [05:26] can a readonly decorator be customized to complain in a specific way? [05:26] it would have given me a clue [05:27] mwhudson: sure just raise whatever you want [05:27] um and maybe refactor ReadonlyTransportDecorator to remove the duplications of that string [05:28] right, i meant the one in bzr [05:29] it would need either changing the one in bzr to allow passing in a string when it's constructed [05:29] or subclassing it [05:29] it's probably easy [05:29] i'll do the bzr bit if you're keen to do the lp bit [05:31] would it also be possible to improve the situation with lp: and no launchpad-login? [05:32] which particular situation? [05:32] so that we can get rid of the unpleasant warning in that situation [05:32] "bzr push lp:foo" without a launchpad login gives you "cannot lock ...: Transport operation not possible: http does not support mkdir()" [05:32] or similar [05:32] poolie: sure, the lp bit should be easy [05:33] I added a warning whenever lp: resolves to http to say "you haven't run launchpad-login, if you are doing a write operation it will fail" [05:33] spiv i'm just trying your stacking hack branch against lp [05:33] which is obviously not great [05:33] poolie: cool [05:33] and it's not drastically better :( [05:33] it might be a bit better? [05:34] poolie: also, you're pushing to https ? [05:35] lifeless: no, of course i'm pushing to the ssh branch described on that page [05:35] so that was, to create a new stacked branch, 404 round trips in 5m16s [05:35] a new stacked branch with a few new revisions mind you [05:35] poolie: there is no of course :) [05:35] poolie: on a small branch from bzr.dev it saved me ~10 round trips when pushing to launchpad [05:36] Which seemed about right given the small number of modified texts and new revisions in that file, and the savings were in append calls. [05:39] ok so fwiw i had 49 append calls using your branch [05:40] i'm just rerunning it with trunk [05:40] i realize even smalls improvements are worthwhile [05:41] poolie: trying to review your doc patch ....http://rafb.net/p/ML5S7O90.html [05:41] I was expecting it to be more than a small improvement. Certainly if it does fix the regression vs. 1.13 that part is a big improvement... pushing a full history with that bug would hurt! [05:41] hm that's not so good [05:42] spiv, ok for trunk it was 489 rpcs in 5m30s [05:42] igc, ok, that seems to be a bug [05:42] probably easily addressed in the makefile by setting the path [05:42] 'make docs' is fine in bzr.dev so I'm pretty sure your patch is causing that [05:42] That's a pretty substantial saving in rpcs. [05:42] yes, it probably is [05:42] because i moved the script [05:45] poolie: the rest looks fine so I'll vote tweak [05:45] spiv, it is [05:51] is there any quickguide, without launchpad marketing?? [05:53] james_w: we aren't running anything for http that's smarter than apache [05:53] ah, it has to come from the server side? [05:53] james_w: well, it might not *have* to [05:54] bzr asks launchpad to resolve lp:foo [05:54] launchpad gives it a bunch of URLs [05:54] bzr decides to use the http one since there's no launchpad-login [05:54] bzr raises confusing error [05:54] that's the rough flow. [06:04] why i need to sign up in launchpad to use bzr?? [06:04] Stanlin: you don't [06:05] well all the docs points to launchpad [06:07] Stanlin: I don't see much reference to launchpad on http://bazaar-vcs.org/ http://doc.bazaar-vcs.org/latest/ [06:09] im trying to configure a server, and give full permission to all users to do what they want... what is the best scenario in this document?? http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#personal-version-control [06:10] Stanlin: simplest is to give each user a normal system account and get the users to put their branches in world-readable directories inside their home directories. [06:11] but they want to share the same files [06:11] And have bzr and ssh installed on the server so they can use bzr+ssh:// URLs to access those branches. [06:11] should they share the same branch? [06:11] Sure, if they want to write to the same branch. [06:11] oh its simple as that? [06:12] Right. Normal filesystem permissions with users and groups basically :) [06:12] they just point to that directory ... commit and voila? [06:12] Yep. [06:12] oh nice [06:13] well ill be annoying here for a while im new in bzr thanks for the cooperation [06:13] thanks a lot [06:13] time to sleep [06:13] G'night. === Mez_ is now known as Mez [06:46] if branch ‘foo/’ has a loom, and I ‘bzr branch foo/ bar/’, should I expect ‘bar/’ to have the same loom? [06:46] 'cause it doesn't :-( [06:46] Bazaar (bzr) 1.13rc1, bzr-loom 1.4.0~bzr93-2 [06:46] bignose: if 'a' and 'a' are the same branch, clearly they will, otherwise not unless you have run 'bzr record' [06:46] bzr help loom may be useful for you [06:46] lifeless: ah. you don't yet have UTF-8 working properly? [06:46] no, it will be months [06:46] if branch 'foo/' has a loom, and I 'bzr branch foo/ bar/', should I expect 'bar/' to have the same loom? [06:46] there is something fucked deep in libx [06:46] bignose: right, you need to run 'bzr record' to record the loom, it is for the loom as a whole what commit is for a tree [06:47] okay, I have *no clue* what that command does, and the help is no help. [06:47] the loom is a stack of branches [06:47] this is versioned [06:47] when am I supposed to run it? what does it do, that I might *not* want to run it? [06:47] record records a version [06:47] generally you should run it before you branch/push to a loom [06:50] so why would I not want it run, say, every time I commit? [06:50] okay, it requires a message argument. I don't know anything useful to say in the message. [06:50] all the useful stuff goes in a commit message, but apparently this is not a commit. [06:50] an analogy may help [06:50] imagine you are using a loom for a debian package [06:50] where the bottom thread is upstream [06:50] and the top thread is 'debian' [06:51] okay [06:51] and the threads in between patch the upstream code [06:51] such that you can patch bomb what other packages might have in debian/patches straight out of the loom [06:52] the list of threads is something that we need to merge - if I merge my loom from you patches[threads] you have deleted need to be deleted in mine [06:52] so record records the list of threads - the (name, revid) for each thread [06:59] np [07:00] hi all [07:02] hi vila === abentley1 is now known as abentley [07:45] * igc dinner === stianse_ is now known as stianse [08:34] hey guys... if developers wanted to UPDATE their branches with what is in the MAIN branch or TRUNK ... do I get them to do a bzr merge or bzr pull? [08:34] Just trying to understand the difference [08:36] pull [08:42] CBro2007: If they're maintaining a mirror of the main branch, "pull". If they're developing independent branches that'll be merged into the main branch, "merge". [08:42] CBro2007: In the latter case, once they have been merged, they can use "pull", but it'll change how "bzr log" is organized. [08:43] Peng_: I created a trunk copy first and then created their branches from it... so that should be a mirror yeah? [08:43] I mean its got the exact same dir structures etc of the project [08:44] Ehhhh. [08:45] CBro2007: What's the workflow? Do you use "bzr branch trunk feature_branch", hack on feature_branch, and merge it back into trunk; or do you do stuff directly in trunk? [08:45] Yeah the branches are each developer's own branch... where they work on different features ... run it past me for a code review and I merge their changes to TRUNK [08:46] I got that part working... now I want to do the reverse.. where they synch their own branches with LATEST changes that I merged into the MAIN branch [08:46] so I think a PULL would be the best way to go eh? [08:46] Maybe for smaller changes I will put the change DIRECTLY into Trunk [08:47] and then developers can update their branches accordingly... very much like the CVS update command that developers run every day before they start work [08:49] [dchoon@onyaaltd02 dcrepo]$ bzr pull /goldRepo/ [08:49] bzr: ERROR: Permission denied: "/goldRepo/.bzr/branch-format": [Errno 13] Permission denied: u'/goldRepo/.bzr/branch-format' [08:49] Got this error when I was trying to PULL from the MAIN branch. [08:49] have to check the permissions.... [08:51] its hard to get the permissions correct [10:18] poolie, poke? [10:18] hi pygi [10:19] poolie, can I pm you? :) [10:19] or are you busy? [10:19] i am but you can [11:32] lifeless: hi [11:32] lifeless: yes, I dpushed dulwich [11:38] jelmer: why? [11:39] or are you developing it in git or something? [11:39] [it broke mirrors and people tracking it] [11:43] lifeless: yes, pushed into git so that others can contribute to it in git [11:57] jelmer: I'm not clear do you commit to it in git, or bzr? [12:01] lifeless: I personally commit to bzr then dpush [12:05] jelmer: whew :P had me worried. [12:05] jelmer: but why was a rewrite of the bzr history needed? [12:06] surely just dpushing to a git branch would make it accessible to git users? [12:06] *yawn* 11pm [12:06] * lifeless sleeps [12:13] lifeless: well, we don't have roundtripping yet in bzr-git [12:14] lifeless: dpush changes the local history [12:14] lifeless: so that it is in common with the history in the foreign vcs [12:14] lifeless: I can now pull from people who contribute to dulwich in git without problems [12:30] Hi! I'm using bzr-svn from time to time, and have a local branch for this. After the latest bzr update to 1.13, I had to update bzr-svn as well in order to support that version of the API. While pulling, bzr died with a backtrace and a "KnitCorrupt" error message. That was while operating on a shared repo for all my bzr-svn branches. Initializing a new repo and creating a fresh checkout succeeded. In the original setup, the issue can be reproduced. Do [12:31] Hint: above problem is NOT about bzr-svn per se, so don't stop reading after hitting that keyword... :-) [12:40] MvG: what bzr-svn were you running prior to that? [12:41] jelmer: jelmer@samba.org-20090202154824-ks8tepmvoam9dmpz if I'm not mistaken. [12:44] In case you want to have a look at the error message: http://rafb.net/p/kfbdrg91.html [12:53] MvG: ah, it's the bzr-svn repository itself that you can't fetch? [12:53] MvG: I doubt I can help there [13:09] night all [13:13] jam: when you're punched in, can we do a skype call? [13:25] jelmer: Sorry, missed your reply. Fetching from scratch works, only updating fails. I guess I'll file a bug report, as I haven't found a related one, and as I don't think I've done anything evil on that repo to warrant this kind of error. [13:31] Hi, [13:31] I tried to understand what the plugin loom is about [13:31] and I didn't find any resources. [13:31] Can someone tell me what this plugin do [13:32] please ? === nevans1 is now known as nevans [14:28] abentley: sorry about the delay. I've been on for a bit. Sure we can do skype [14:29] jam: np [14:31] hi [14:32] is it correct that "bzr push .." is the only way to upload changes from a branch into the "trunk"? [15:07] I would say "bzr merge" could do the trick also [15:08] but, how I understand, merge can only be used to "download" the changes, but in my case the editor wants to upload his changes.. [15:08] like you would do in svn .. [15:09] merge just pulls changes into the working tree, similar to a local edit [15:10] Yuo still have to commit those changes with bzr ci [15:11] so what is the correct way? Bind my local branch to the "server-branch" and then commit? Or maybe, merge the "server-branch" into my local branch, then bind the local branch to the server branch, and then commit? [15:13] Either works. [15:13] They're basically the same. [15:13] Depends if you want to leave it bound, or do a separate push operation [15:14] ok, I try to describe my workflow [15:17] there is a "server-repository" where the mainline of the code is stored. Know I want to add a new feature (or bugfix or whatever). For that I want to create a local branch (copy) of the mainline on the server. In this local copy I want to create a new branch with the name of the feature. Then I work on the feature branch and do local commits there. After I finished all, I want to merge thoses changes back into the server mainline... [15:17] morning vila, how goes the battle on the starward front? [15:19] jam: it's bloody and uncommitable so far, but I have good hope :) [15:30] jam: I'll get back to you once I get at least failing tests instead or erroring out ones [15:30] :) [15:30] I'm happy to chat if you want [15:31] jam: Thanks. I know that, but I need more meat first :) [16:08] hmm, how can I do a bzr push over SSH to a system where bzr is only installed in my home directory? [16:09] oh, sftp:// [16:11] MvG: have you tried running "bzr reconcile" in the repository before pulling? [16:11] jelmer: not yet, trying... [16:12] BTW: filed as https://bugs.launchpad.net/bugs/347979 [16:12] Ubuntu bug 347979 in bzr "KnitCorrupt listing _KnitGraphIndex when pulling" [Undecided,New] [16:17] jelmer: No luck with reconcile. [16:18] Ran it in the repo dir, not in a branch. Is that correct? [16:18] SamB: You can also configure the location of the remote bzr using the BZR_REMOTE_PATH environment variable or the bzr_remote_path config variable. [16:19] the config variables sounds more promising [16:19] hmm, I'd want it as a per-host option though ... [16:21] how come the usual SSH paths aren't supported? [16:22] er, I mean, how come you can't say, e.g., sftp://cs.widener.edu:devel/dosemu/ to mean ~/devel/dosemu on cs.widener.edu? [16:24] sftp://cs.widener.edu/~/devel/dosemu/ [16:24] because the colon is the port separator? [16:26] oh. there *is* an ietf draft about this, and what you say is consistant with that. [16:26] where is it documented in bzr's help/docs? [16:28]