[00:03] <jelmer> poolie: that looks like fun :)
[00:03] <jelmer> ouch, the speed and the angle in those videos looks pretty scary..
[00:05] <dcoles> Is fastimport still the best way of doing round-trip compatable mirroring of a bazaar repository to git?
[00:06] <jelmer> dcoles: fastimport isn't round-trip compatible
[00:06] <jelmer> dcoles: what do you mean exactly?
[00:06] <dcoles> I think I read some information on a Question that said bzr-git now did 'push' but maybe not in the Natty version
[00:07] <jelmer> dcoles: there is some support for it, but it's not enabled yet
[00:07] <jelmer> dcoles: however, if you're looking for functionality equivalent to fastimport, bzr-git might do that, depending on what you're looking for.
[00:09] <dcoles> A friend wants to use github for various reasons. He "migrated" the Bazaar repository in one commit. I want to be able to 1. Preserve the history and 2. Be able to pull back new revisions to Launchpad
[00:10] <jelmer> dcoles: that's a parallel import, for which we don't really have a good answer yet
[00:12] <jelmer> dcoles: I think diff+patch are really the only way of dealing with that at the moment, though perhaps others have better ideas
[00:12] <dcoles> jelmer: Yeah. I've looked at things a few times in the past (such as when I want a bazaar mirror of svn/git repos). I guess fast-export is going to have approximately the same results as a dpush would have.
[00:13] <jelmer> dcoles: dpush would work if your friend had done the export to github using dpush
[00:16] <dcoles> jelmer: Hm. Well I'm redoing the export now. I know dpush munges some revision ids - will that cause any issues for the bazaar repo? Or only branches off my bazaar branch?
[00:16] <jelmer> dcoles: it will rewrite the history of your bzr branch, so any other bzr branches of your project will appear unrelated
[00:20] <dcoles> jelmer: Right. So I'd have fun trying to pull new revisions from the launchpad repo? Unless I pushed to launchpad with --overwrite (which I'd rather avoid)
[00:20] <jelmer> dcoles: yes
[00:23] <dcoles> jelmer: Alright. Thanks for the advice.
[02:45] <AuroraBorealis> anyone have any idea how to clone a remote cvs repo so i can import it into bzr? :<
[06:43] <vila> hi all, as PP, I wish you an happy flight this week !
[06:45] <fullermd> Will there be an in-merge movie?
[06:45] <bob2> hahaha
[06:46] <vila> Inside Job ? (far-fetched ;)
[06:48] <fullermd> The Good, The Bad, and The Uncommits?
[06:48] <poolie> hi vila, jelmer, all
[06:48] <poolie> thanks vila
[06:53] <poolie> jam, hi?
[06:53] <vila> hmm, first wtf of the week, root cannot do 'ls -l' at the root of a disk ? Cannot umount it either >-/
[06:54] <fullermd> We control the horizontal; we control the vertical.
[06:55] <vila> hmm, rather, it's not that I can't it's that I get an IO error ...
[06:59] <poolie> vila, oops
[07:00] <vila> yeah, no time to investigate, will reboot (and lose all my sessions :-/)
[07:04] <vila> that was the disk where I did some fdatasync experiments so I'm totally safe am I not ?
[07:04] <vila> right, back to normal
[07:04] <poolie> backups :)
[07:09] <vila> poolie: it *is* one of my backup disks :) And also my slowest one which is why I wanted to experiment with fdatasync there to amplify the fallouts ;)
[07:09] <vila> so no critical data there
[07:21] <Anteru> Hi, what is the state on per-branch rules? The discussion in the bug (https://bugs.launchpad.net/bzr/+bug/395731) seems to indicate that .bzrmeta/rules has been decided as the location, so has this been implemented or is something still holding it off?
[07:23] <Anteru> The problem I'm facing is that I'm working on a plugin, and currently I have to set it via the global rules file, while I'd definitely like to use it for my single test branch only.
[07:26] <fullermd> vila: So we've established that fdatasync is dangerous?  ;p
[07:26] <vila> hehe, that won't be my first bet ;)
[07:27] <fullermd> Pfui.  Don't try and argue with the facts.  If correlation didn't imply causality, why would they start with the same letter?
[07:28] <Anteru> or is there some easier way to restrict a content filter plugin to a single branch only?
[07:29] <fullermd> Anteru: AFAIK there is not.  Nobody's implemented .bzrmeta/rules AFAIK.
[07:31] <bob2> facts are a well known liberal myth
[07:33] <vila> Anteru: there is a work in progress to make that easier, but only for non-versioned stuff, not sure if your plugin can deal with wt specific *config* options or if you need versioned properties
[07:33] <Anteru> Hm, allright.
[07:33] <Anteru> How hard to you expect that to be?
[07:34] <Anteru> brb, gotta reconnect
[07:38] <Anteru> vila: How complicated do you expect the per-branch rules to be?
[07:43] <vila> Anteru: bug #395731 raise a number of different issues, I don't have answers for all of them nor can I make an estimate, so my question was about whether you need versioned properties or not (non versioned *can* be addressed with config)
[07:43] <jam> morning poolie
[07:43] <poolie> hi thar
[07:45] <Anteru> vila: Ok, sounds complicated. I was looking at Mercurial's bfiles extension, and Mercurial has this per-branch setup using .hg/hgrc: http://hg.gerg.ca/hg-bfiles/raw-file/tip/usage.txt My thinking was that porting that extension over to Bazaar should be the easiest, but well ...
[07:53] <Anteru> At least their big-file extension is reasonably documented
[08:07] <vila> poolie: thanks for the updates on doc.bazaar.c.c, I usually do that while announcing but that should occur soon now (so less work for me ;)
[08:09] <poolie> Anteru: i don't know if specifically porting that code will help a lot but something broadly like that would be a good first step
[08:09] <poolie> or, perhaps, second step, you could perhaps get value out of something even smaller
[08:14] <Anteru> poolie: Just found there's a much further advanced version being prepared for inclusion into Hg back, https://developers.kilnhg.com/Repo/Kiln/largefiles/largefiles-mercurial-truncated
[08:15] <Anteru> That's based on Kiln's kbfiles, which was the reason I actually started looking into this.
[09:00] <ryanhaigh> hi all, im looking for some help with bzr explorer
[09:00] <ryanhaigh> im currently trying to set up the editors using file>accessories
[09:01] <ryanhaigh> the problem i am running into is that the editor program requires the full path to the file, and bzr explorer appears to be passing only the relative path from the branch root
[09:01] <poolie> hi ryanhaigh
[09:01] <poolie> i don't know an answer off hand
[09:06] <ryanhaigh> thanks poolie, im not sure how many people use this feature, i only found out about it today
[09:06] <ryanhaigh> and none of the defaults work
[09:06] <poolie> explorer as a whole?
[09:06] <poolie> i don't personally use it often but others do
[09:06] <ryanhaigh> no the custom editors based on file extension
[09:06] <ryanhaigh> which is a part of explorer
[09:13] <poolie> ah, ok
[09:13] <poolie> i suggest you file a bug about it and bialix or someone might be able to help you out
[09:13] <poolie> or maybe Riddell
[09:14] <poolie> it doesn't sound like it would be very hard to change if there is a gap there
[09:18] <Riddell> aye, ping me when you file a bug ryanhaigh
[09:21] <ryanhaigh> Will do Riddell, will be a while through im going to a minsite for at least 2 wks
[09:30] <ryanhaigh> thanks for taking the time to answer
[10:34] <vila> jelmer: I'm about to deploy the fix for bug #833097, including upgrading bzr-builddeb
[10:34] <jelmer> vila: ok
[10:34] <vila> jelmer: should I get the tip or stick to 2.7.7 ?
[10:34] <jelmer> vila: I'd go with tip, it shouldn't have anything dangerous
[10:35] <vila> ok, I'll try that first then
[10:45] <vila> ok, deployed and importer restarted, I'll monitor it after lunch
[10:46] <jelmer> vila: thanks for working on that update
[11:00] <vila> jelmer: np ;)
[11:00] <vila> so, no blatent failures so far (good)
[11:02] <vila> jelmer: what's the status on bug #653757 (bird's eye view) ?
[11:03] <jelmer> vila: getting close to being finished. The internals in bzr-builddeb have been updated to support multiple upstream tarballs, which was the bulk of the work. The main bit now is getting import to deal with multiple upstream tarballs and testing.
[11:04] <jelmer> vila: it's up next for me after fixing the FTBFS of various plugins in oneiric
[11:04] <vila> ha, ok, make sense (was wondering about the related commits in builddeb)
[11:04] <vila> oh cool !
[12:12] <ryanhaigh> Riddell: thought id nock it over tonight, here is the bug report
[12:13] <ryanhaigh> hope the patch is useful
[12:13] <Riddell> ryanhaigh: what's the number?
[12:13] <ryanhaigh> haha sorry forgot link https://bugs.launchpad.net/bzr-explorer/+bug/836631
[12:58] <vila> jelmer: regarding the spurious failures for 2.4.0 on hardy, Tests on the buildds are run without --parallel=fork right ? And you don't use a chroot locally right ?
[13:01] <jelmer> vila: I use a VM locally
[13:02] <vila> jelmer: k, and the tests are run sequentially in both cases ?
[13:05] <jelmer> vila: no, with --parallel=fork
[13:06] <vila> jelmer: how many processes in both cases ?
[13:06] <jelmer> vila: I'm not sure, 2 on my local machine
[13:06] <jelmer> vila: I don't know how many processors the buildds have
[13:07] <vila> jelmer: try running without --parallel locally ?
[13:07] <jelmer> vila: is there a particular reason you think that's relevant? Aren't the tests all run in their own subdirectory?
[13:08] <vila> jelmer: that may be useless, but... the failure makes no sense, so I vaguely suspect some issue in the test infrastructure that *could* lead to a file handle starvation and in this case I've seen non sensical failures in the past
[13:09] <jelmer> vila: ah, ok. I'll give it a shot
[13:09] <vila> jelmer: when you get one failure, do you get other failures as well ?
[13:11] <jelmer> vila: not necessarily
[13:11] <vila> :-/
[13:15] <vila> jelmer: sorry, not much more ideas, at worst, if the traceback is always in write_index, you can try displaying the path when getting that exception, because there is no way we create a *directory* names after an index file
[13:15] <vila> s/names/named/
[13:15] <jelmer> vila: np, thanks for thinking about it
[13:20] <vila> jelmer: I've disabled the hardy builds on babune because we require python-2.6, if you have a branch where you addressed the compatibility with 2.5 I can give it a go
[13:20] <AuroraBorealis> question: does anyone have any experience cloning a cvs repo when you only have remote access to use fast-export-from-cvs?
[13:20] <jelmer> vila: yep - lp:~jelmer/bzr/2.4-python2.5
[13:21] <jelmer> AuroraBorealis: launchpad-cscvs is the only thing I'm aware of that doesn't require local access to the CVS repository
[13:23] <AuroraBorealis> ok i'll try that
[13:23] <AuroraBorealis> 'cvssuck' and 'cvsclone' are woefully out of date and don't seem to work =(
[13:40] <vila> jelmer: http://babune.ladeuil.net:24842/view/%20High/job/selftest-hardy/483/ , 4915 failures 8-/ http://paste.ubuntu.com/677208/ is required here to properly compile the extension (which may explain a lot of the failures)
[13:42] <jelmer> vila: oh, that's interesting. I didn't need that
[13:44] <vila> which is weird...
[13:46] <jelmer> vila: well, I'm applying a whole bunch of patches and building against the cat archive
[13:47] <vila> yeah, nothing caught my eyes in this branch, are you sure the extensions are built and if yes with pyrex ? version ?
[13:48]  * AuroraBorealis sighs as he has to update this very old python script to work with python2.7 :<
[13:48] <vila> AuroraBorealis: wanna try to help jelmer debugging an issue while backporting bzr-2.4.0 to python-2.5 instead ? :)
[13:49] <AuroraBorealis> i have to leave for school in a hour and a half =P
[13:52] <vila> jelmer: http://babune.ladeuil.net:24842/view/%20High/job/selftest-hardy/485/console, only 4 failures which I suspect have to do with some subunit/testtools weirdness, but nothing looking like your failure :-/
[13:54] <vila> jelmer: retrying with only 2 procs (instead of 8), will take longer  ;)
[13:55] <jelmer> vila: the package also includes a backport of the fix for testtools
[13:55] <vila> jelmer: at least there is evidence that the failures are spurious which could help you decide if you want to disable the tests for your particular needs
[13:55] <jelmer> vila: The thing I'm actually trying to build is at lp:~canonical-bazaar/ubuntu/hardy/cat
[13:56] <jelmer> but that's a debian package, so may be harder to build on babune
[13:56] <jelmer> vila: Yeah, I'm considering that.
[13:56] <jelmer> Given this is what's being used on the buildds I'd rather be sure that it won't happen (spuriously) in production.
[13:58] <vila> yeah, good point, but a file turning spuriously into a directory... You always get the same exception right ?
[13:58] <jelmer> yes
[13:59] <vila> madness
[13:59] <vila> jelmer: upgrading the buildds to lucid is not an option ?
[14:00] <vila> jelmer: upgrading the buildds to lucid is *still* not an option ?
[14:00] <jelmer> vila: nope, not for a while
[14:00] <vila> just checking
[14:00] <vila> k
[14:02]  * jelmer restarts the build another time to see if there are different failures
[14:10] <AuroraBorealis> this is probably totally not worth it, going through all this trouble just to convert a cvs repo >.>
[14:17] <antivirtel> hello! I'm new to bazaar, and to VCSs too. I started a new project on LP yesterday. I haven't created trunk directory, and now I want to move the files to the trunk dir. Can I do that without a new commit? (Otherwise, can someone tell me what is the default dir system of a bzr repo? like in Unix: /usr,/home...)
[14:19] <jelmer> antivirtel: hi
[14:19] <jelmer> antivirtel: the directory structure is up to you, and what your project needs
[14:21] <antivirtel> aham, so the trunk is not required? If I want to make a new branch, where it will on the LP? I have no dirs upper, right?
[14:25] <abentley> jelmer: now that bzr has a "branches" command, what should happen to the bzrtools branches command?
[14:27] <jelmer> antivirtel: I'm not sure I follow; trunk is just the name of a branch
[14:27] <jelmer> abentley: its functionality is different, as it scans the filesystem rather than just asking the control directory. I can think of a few options:
[14:28] <jelmer> abentley: * rename it to "bzr scan-branches / bzr find-branches / etc"
[14:28] <jelmer> abentley: * make bzrtools decorate "bzr branches" and add a --scan option to it with the current functionality
[14:28] <jelmer> abentley: * move the current functionality into bzr core as an option to "bzr branches"
[14:29] <abentley> jelmer: I'm leaning toward the last option.
[14:31] <jelmer> abentley: works for me
[14:36] <jelmer> abentley: will you propose that as a patch to bzrlib or should I ?
[14:36] <antivirtel> ok, jelmer thanks - an other question: I have some files(static, like images; commited separately), which I don't want to put in the main branch, because it is needed for a sub-project only (but it uses the main branch's code). Can I separate it from the main branch, and place it to the "cloud", because I want to make that float with the lastest version of the main branch?
[14:46] <jelmer> antivirtel: what do you mean with cloud exactly?
[14:48] <bigjools> hey folks. Why do I need a working tree to do a merge?
[14:48] <AuroraBorealis> because what else does it do a merge with?
[14:49] <antivirtel> jelmer, if I commit something on the main branch, I want to these selected commits automatically move up, and if I want to release a new version, these commits are there... is it possible?
[14:49] <AuroraBorealis> a shared repo can contain multiple branches
[14:49] <bigjools> I have a branch with no tree
[14:49] <bigjools> not sure why it needs to be checked out to merge a different branch
[14:50] <AuroraBorealis> then its probably a 'no working tree' branch, which is usually meant to be on servers
[14:50] <jelmer> bigjools: I think in theory it could be anything that implements the treeinterface, not necessarily a working tree. In practice there are a few things that rely on disk during merge.
[14:50] <antivirtel> or jelmer I have to move these commits to a new branch and if I release one version, I have to merge the main to the sub-project?
[14:50] <jelmer> bigjools: also, disk is probably the easiest place to let the user deal with conflicts.
[14:51] <jelmer> antivirtel: what do you mean with moving the commits up?
[14:51] <bigjools> jelmer: ok thanks.  I guessed that might be the case :)
[14:56]  * vila blinks bzrtools version 1.15.0 on jubany ...
[14:57] <abentley> jelmer: I'm willing to do it, but you'd probably get it done faster.
[15:01] <antivirtel> jelmer if you visualize a branch tree (like this: http://goo.gl/yHXde) you see that if I create a new branch, and I commit there e.g. 2 times, these commits are separated from the main line. But, I want to move this branch's (like the blue colored one on the img) commits up to the top, 'cos if I want to release a new version (in the sub-project), I want to use all code, but with these static commits (like logo images etc...) ... is it possible, or it re
[15:01] <antivirtel> quire new branch and merging from the main on each release?
[15:01] <abentley> jelmer, bigjools as the source of a merge, it shouldn't need a tree.  As something you're merging into, it does, because commit only works on working trees.
[15:02] <jelmer> abentley: commit requires any tree, it doesn't have to be a working tree
[15:02] <jelmer> abentley: my understanding was the merge/treetransform had trouble doing the merge into anything but a working tree
[15:02] <abentley> jelmer: I mean the commit command.   AFAIK, that still requires a working  tree.
[15:03] <jelmer> abentley: ah, sorry. Yes, that's true.
[15:03] <abentley> jelmer: TransformPreview doesn't require a working tree.
[15:03] <abentley> jelmer: bzr-pipeline does merge and commit using preview trees, for example.
[15:04] <jelmer> abentley: but it still requires disk access doesn't it?
[15:04] <jelmer> abentley: it was my understanding there wasn't a way to do a merge fully in memory, without hitting disk.
[15:04] <abentley> jelmer: TransformPreview currently requires disk access, but it uses a temp directory, not the working tree.
[15:04] <jelmer> abentley: ah, right
[15:05] <abentley> jelmer: I have code that permits doing a merge fully in memory, but it needs a bit of polish.
[15:05] <jelmer> antivirtel: Sorry, I still don't follow
[15:05] <jelmer> abentley: ooh
[15:05] <antivirtel> jelmer no problem :) I will use new branch, and merge it from main technology
[15:05] <antivirtel> :)
[15:06] <abentley> jelmer: lp:~abentley/bzr/memory-storage
[15:17] <antivirtel> in Bazaar Exlorer, Bazaar>Work>Bind branch creates a new branch based on the current rev?
[15:18] <AuroraBorealis> no
[15:19] <AuroraBorealis> that 'binds' a branch to another branch (usually remote one)
[15:19] <AuroraBorealis> so that when you commit to the branch, then it also commits to the one you specified, keeping them in sync
[15:24] <antivirtel> aha, thanks AuroraBorealis - and can I make a new one with the BE?
[15:24] <AuroraBorealis> be?
[15:25] <antivirtel> Bazaar Explorer
[15:25] <antivirtel> :D
[15:26] <AuroraBorealis> yeah
[15:26] <Noldorin> hi jelmer
[15:26] <AuroraBorealis> i mean, i have a branch on my server, and then i 'branch' it to my computer, then bind it back to the remote one
[15:26] <jelmer> hey Noldorin
[15:26] <AuroraBorealis> so that way it acts kinda like a centralized branch
[15:27] <Noldorin> jelmer: how's co-located branch support going? :-)
[15:27] <Noldorin> jelmer: i hear 2.5b1 will be out soon...and LP support for co-located branches in coming too?
[15:34] <jelmer> Noldorin: yeah, launchpad should support importing colocated git and mercurial branches soon
[15:34] <Noldorin> jelmer: awesome...what about exporting?
[15:34] <jelmer> Noldorin: exporting too
[15:34] <Noldorin> i guess that just requires it to support colocated bzr branches
[15:34] <Noldorin> right?
[15:34] <Noldorin> i have to do the dpush manually myself
[15:35] <jelmer> yeah
[15:35] <vila> jelmer: about to EOD, but: http://babune.ladeuil.net:24842/job/selftest-subset-hardy/85/console
[15:36] <vila> jelmer: i.e. adding the missing patches (compared to cat), no failures, even with 2 procs
[15:36] <Noldorin> jelmer: sounds good. timeframe for 2.5b1 is early-mid september, right?
[15:36] <Noldorin> and launchpad when?
[15:37] <jelmer> vila: :-/
[15:37] <jelmer> vila: Thanks for running that, btw!
[15:37] <jelmer> Noldorin: Launchpad probably next week
[15:37] <Noldorin> cool.
[15:38] <Noldorin> 2.5b1 same time then?
[15:38] <Noldorin> jelmer: would that be on edge or normal LP?
[15:39] <jelmer> Noldorin: edge is no more
[15:39] <jelmer> Noldorin: I have no idea about bzr 2.5b1
[15:39] <jelmer> Noldorin: it would be production. launchpad is deploying every couple of days now, so once something lands it gets to production quickly
[15:40] <Noldorin> jelmer: oh cool....yeah, i haven't used edge in ages, so no wonder
[15:41] <Noldorin> jelmer: well the 2.5b1 milestone says september 7th i think ... :)
[15:43] <jelmer> Noldorin: ah, ok
[15:43] <Noldorin> jelmer: i will have a look at sorting out that bzr-git error i was having, now i am back from hols
[15:43] <Noldorin> mabye you can include a fix in next release
[15:43] <jelmer> Noldorin: cool; if there's anything I can help with, let me know
[15:44] <Noldorin> thanks
[15:44] <Noldorin> it will be over the next few days most likely..
[15:44] <Noldorin> jelmer: also, will LP ever get auto-dpush to git/hg branches you think?
[15:45] <jelmer> Noldorin: Personally, I think it would be more likely it would run the equivalent of "bzr serve --git"
[15:46] <Noldorin> jelmer: oh wow, i didn't know bzr had 'server' now... must have come recently. works like hg serve?
[15:46] <mgz> ...since when has the contributor agreement required printing out a pdf and scanning it back in?
[15:47] <Noldorin> well that would be cool. would still require github to auto-import though....
[15:47] <mgz> did someone decide it wasn't quite hostile enough to casual contributors?
[15:48] <jelmer> Noldorin: "bzr serve" has been present for years. bzr-git adds the --git option
[15:49] <Noldorin> oh
[15:49] <jelmer> hi mgz
[15:49] <Noldorin> jelmer: it surely came after Hg serve though... i remember trying both at one point and bzr not supporting :S
[15:50] <Noldorin> jelmer: the problem is github is not likely to get bzr importing any time soon though...
[15:50] <AuroraBorealis> the bzr serve documentation is prettymuch not existant
[15:50] <AuroraBorealis> thats probably why you have not heard about it.
[15:51] <Noldorin> ah right
[15:51] <jelmer> Noldorin: it was introduced in bzr 0.11, apparently
[15:51] <Noldorin> lies!
[15:52] <Noldorin> i remember trying it
[15:52] <Noldorin> and saying it's not supported
[15:52] <Noldorin> :S
[15:52] <Noldorin> maybe not on windows
[15:52] <Noldorin> very odd
[15:52] <AuroraBorealis> but still, someone needs to write docs for it
[15:52] <Noldorin> indeed
[15:52] <jelmer> AuroraBorealis: http://doc.bazaar.canonical.com/latest/en/user-guide/server.html
[15:53] <jelmer> but I guess it isn't really easy to find at the moment
[15:53] <AuroraBorealis> thats pretty thin :>
[15:54] <AuroraBorealis> what are the operations that are 'improved' by a smart server?
[15:54] <AuroraBorealis> there is only one option specified, are there more? etc
[15:54] <Noldorin> brb
[15:55] <AuroraBorealis> does this work for all operating systems? these are the questions i was asking myself when i was looking at this a while ago
[15:55] <jelmer> AuroraBorealis: most operations become faster when used over the smart server, but it's the same set
[15:55] <AuroraBorealis> well, i'm just saying that the doc says The high-performance smart server (hpss) performs certain operations much faster than dumb servers are capable of. In future releases, the range of operations that are improved by using the smart server will increase as we continue to tune performance.
[15:56] <AuroraBorealis> i dunno, showing the time with a smart server vs dumb server would be useful
[15:57]  * jelmer files a bug about the smart server docs
[15:57] <AuroraBorealis> and another big thing: authentication
[15:57] <jelmer> AuroraBorealis: Authentication is not yet supported using "bzr serve", only over http (or when tunneled over ssh)
[15:58] <jelmer> AuroraBorealis: that would indeed be good to mention though
[15:58] <AuroraBorealis> i read somewhere that it doesn't really want to support authentication, and to do it you just use ssh?
[16:14] <jelmer> AuroraBorealis: yep
[16:14] <jelmer> vila: hmm
[16:14] <jelmer> vila: failed again, with two different tests
[16:18] <AuroraBorealis> and jelmer, where is the bug you just submitted about the docs?
[16:21] <jelmer> AuroraBorealis: bug 836812
[16:22] <jelmer> AuroraBorealis: and bug 836815
[16:23] <AuroraBorealis> kk =)
[16:23] <jelmer> AuroraBorealis: I don't think documentation is the right place to put benchmarks
[16:24] <AuroraBorealis> it would be nice to have them somewhere, even if the docs link to them
[16:27] <jelmer> AuroraBorealis: I'd rather just mention the smart server is quicker without getting into too many times quicker it is. There are a lot of factors involved.
[16:27] <AuroraBorealis> that works
[16:27] <AuroraBorealis> point is, that documentation is a bit lacking, which someone needs to fix. i could try and see if i can improve it, but like the other thing i'm working on, i need to take time to learn about it first
[16:28] <jelmer> AuroraBorealis: M
[16:28] <AuroraBorealis> m? o.o
[16:28] <jelmer> AuroraBorealis: filing bugs about holes in the documentation is a great start, and thanks for bringing up the topic of the "bzr serve" docs here
[16:28] <jelmer> AuroraBorealis: I guess it's one of these things you don't realize if you're familiar with the code already...
[16:29] <AuroraBorealis> yeah haha
[16:40] <jelmer> abentley: will you propose a merge of the bzrtools branches code into bzrlib or should I ?
[16:42] <abentley> jelmer: probably best if you do it.
[16:42] <jelmer> abentley: sure, will do
[19:46] <ovnicraft> hello why trying to branch a project from LP i get an error about permission denied
[19:46] <ovnicraft> ?
[19:55] <ovnicraft> l login w/ bzr
[19:55] <ovnicraft> then try to branch or pull and give the error
[19:57] <ovnicraft> ?
[19:57] <ovnicraft> any help around ?
[19:57] <beuno> ovnicraft, can you pastebin the full output?
[19:58] <ovnicraft> beuno, http://pastebin.com/Kwm72xqQ after bzr pull
[20:01] <beuno> ovnicraft, and you're part of the OpenERP team?
[20:03] <ovnicraft> beuno, not but to branch i guess is not necessary
[20:03] <beuno> ovnicraft, no. What command are you using?
[20:03] <ovnicraft> bzr pull
[20:03] <ovnicraft> just to pull changes from LP i branch it before
[20:04] <maxb> You should either sort out your ssh authentication to launchpad, or fall back to using anonymous http access
[20:04] <ovnicraft> maxb, how i can use anonymous http access to branch ?
[20:05] <maxb> Change the URL to an http: rather than bzr+ssh: one
[20:06] <ovnicraft> maxb, if i pulled it via ssh it will works w/ change ?
[20:06] <beuno> so bzr pull http://bazaar.launchpad.net/%2Bbranch/openobject-client-web/6.0/ --remember
[20:08] <ovnicraft> beuno, bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/%2Bbranch/openobject-client-web/6.0/"
[20:09] <beuno> ah
[20:09] <beuno> ok
[20:09] <beuno> so the url has to be constructed differently
[20:09] <ovnicraft> how can i identify how construct the URL?
[20:09] <jelmer> ovnicraft: try "bzr pull --remember lp:openobject-client-web/6.0"
[20:10] <ovnicraft> jelmer, i think it will try ssh
[20:10] <jelmer> ovnicraft: can you access other branches over ssh?
[20:11] <ovnicraft> jelmer, no
[20:11] <jelmer> ovnicraft: Do you have a ssh key uploaded to Launchpad?
[20:11] <ovnicraft> si i dont know why? i understand projects are configured to required it
[20:11] <ovnicraft> yes i  am openerp commiter
[20:11] <ovnicraft> but in that project i dont commit
[20:11] <ovnicraft> i just want to pull
[20:12] <jelmer> ovnicraft: if you logged in use "bzr lp-login" then any access to lp: branches will try to use ssh
[20:12] <jelmer> *using
[20:12] <ovnicraft> jelmer, how i 'logout' with bzr ?
[20:13] <jelmer> ovnicraft: bzr config --remove launchpad_username
[20:14] <ovnicraft> jelmer, i get 2.1.4 version i dont get config ?
[20:14] <jelmer> ovnicraft: ah, no. It doesn't exist in 2.1.4 yet. You can manually edit ~/.bazaar/bazaar.conf though.
[20:17] <ovnicraft> jelmer, thanks !
[20:18] <maxb> It should be noted that the smart server accessible via SSH is a considerably more optimal way for Bazaar to communicate than the dumb HTTP transport.
[20:18] <maxb> For the sake of your time and bandwidth, it may still be worth fixing your SSH setup
[20:18] <jelmer> launchpad really should allow anonymous access over ssh
[20:20] <vila> jelmer: /me nods, read-only anonymous access
[20:21] <vila> jam: any issue with building the 2.4.0 windows installers ?
[22:50] <croddy> is there a FAQ i can read? i did not find what i was looking for in the answers app
[22:56] <jelmer> croddy: the FAQs should all be on the answers page on launchpad
[22:56] <croddy> thanks
[22:59] <jelmer> croddy: you're always welcome to ask here, or open a new question on launchpad
[23:32] <jderose> hi, is there a way to get the diff of a single file between 2 branches?
[23:33] <jderose> i'm trying to narrow down the changes in couchdb between natty and oneric. i know how to do this:
[23:33] <jderose> bzr diff --old=../natty/
[23:33] <jderose> but that's a 20k line diff, mostly autotools generated stuff.... but i'd like to easy look at a single file, like just Makefile.in
[23:34] <spiv> jderose: bzr diff -rbranch:../natty FILE
[23:34] <spiv> IIRC
[23:37] <jderose> spiv: ooo, fancy! thanks!