[00:00] <yacoob> *tap*tap* is this thing on? :)
[00:03]  * fullermd notes that in his years of running theatre tech, there was a standing order that tapping microphones was cause for finger-breaking...
[00:04] <yacoob> luckily this doesn't work yet over tcp/ip 8)
[00:05] <fullermd> I know.  Insufficient future-proofing   :(
[00:05] <maxb> I've never had cause to use bzr over smb, but that error does sound like that might be the problem.
[00:06] <yacoob> there's bug 31006, but *somehow* it was working for me before (with bzr 1.6 or so)
[00:06] <ubottu> Launchpad bug 31006 in bzr "dirstate file locking doesn't work on smb mount on osx - bzr add, bzr status, and bzr commit fail over a SMB share (dup-of: 98836)" [High,Confirmed] https://launchpad.net/bugs/31006
[00:06] <ubottu> Launchpad bug 98836 in bzr "[MASTER] "OS locks must die" - dirstate file write locks exclude readers and limit portability" [High,In progress] https://launchpad.net/bugs/98836
[00:07] <yacoob> RRrright.
[00:07] <yacoob> my repo was pack-0.92
[00:08] <yacoob> it works with that format
[00:08] <yacoob> it very much doesn't with 2a
[00:08] <maxb> It's breaking in even more esoteric ways for me
[00:09] <yacoob> le sigh.
[00:09] <yacoob> no love for this bug since 2009/09/29
[00:11] <yacoob> and I've foolishly said 'bzr upgrade' on my shared repo. Yay.
[00:11] <yacoob> no way to downgrade, right?
[00:17] <yacoob> ok, 'bzr upgrade' performed on a shared repo did... weird things. Topmost .bzr is no longer there, and I can't run 'bzr info' in that directory anymore
[00:17] <yacoob> exactly *one* of the repos below got converted from pack-0.92 to 2a
[00:18] <yacoob> and that directory got 'backup.bzr' directory
=== timClicks is now known as timClicks_away
[01:05] <lifeless> yacoob: the dirstate code doesn't change from pack-0.92 to 2a
[01:06] <lifeless> yacoob: something else has altered
[01:06] <lifeless> yacoob: it also doesn't impact repositories at all, only working trees
[01:07] <yacoob> lifeless, interesting. But I've just verified that 'bzr push' from my local machine to a directory mounted via smbfs will work when format is pack-0.92, and fail with 2a
[01:08] <yacoob> both locks and oplocks seem to be there
[01:08] <lifeless> file a bug then
[01:09] <yacoob> I'll do that tomorrow I think. Kind of sleepy now :)
[01:31] <fossrox> hi guys!
[01:31] <fossrox> I've noticed a problem in documentation: http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/introducing_bazaar.html
[01:32] <fossrox> link: Bazaar Quick Start Card - a one page summary of commonly used commands.
[01:32] <fossrox> Not found: http://doc.bazaar.canonical.com/bzr.dev/en/quick-reference/quick-start-summary.svg
[01:32] <fossrox> thanks in advance guys!
[02:20] <dOxxx> good evening
[02:21] <lifeless> hai
[02:21] <dOxxx> any mac users around that would be willing to try installing the bzr 2.0.4 package I just built?
[02:21] <dOxxx> I'd like to have some verification other than my machine before I upload it to the bzr release page
[02:28] <dOxxx> Anyway, if there is anybody here that's willing, try it here: http://launchpad.net/bzr-mac-installers/2.0/2.0.4/+download/Bazaar-2.0.4-1-desktop.pkg
[02:28] <dOxxx> I'll be doing the same for the 2.1.0rc1 installer
[02:33] <dOxxx> a clean build of the mac installer takes like 25 minutes :(
[02:34] <dOxxx> 90% of it is pyqt I'm sure
[02:59] <MTecknology> Any ideas what causes this to happen? No handlers could be found for logger "bzr"
[02:59] <dOxxx> MTecknology: context?
[02:59] <MTecknology> It's only happening when I try to do bzr pull from www-data user
[03:00] <MTecknology> dOxxx: I found out what'
[03:01] <MTecknology> s wrong... typo
[03:02] <MTecknology> maybe not...
[03:02] <MTecknology> Could be an environment thing :S
[03:04] <dOxxx> looks like it might be bug 503886
[03:04] <ubottu> Launchpad bug 503886 in bzr/2.0 "Server logging errors are hard to debug" [Medium,Fix released] https://launchpad.net/bugs/503886
[03:05] <dOxxx> you may want to try the newly released bzr 2.1.0rc1 or 2.0.4 which have a fix for making it easier to see what the error on the server is
[03:05] <dOxxx> but I would hazard a guess that your ~/.bzr.log cannot be accessed as the www-data user
[03:06] <dOxxx> on the server
[03:19] <MTecknology> dOxxx: looks like that user can access that fiel
[03:19] <MTecknology> dOxxx: but deleting it removed the error - thanks
[04:03] <lifeless> oh hai, it is the internets
[04:03] <fullermd> I made you an internets, but I eatered it.
[04:04] <lifeless> I'm in your router eating your packetz?
[05:10] <dOxxx> good night all
[06:14] <micahg> hi, how do I merge in a branch with no common ancestor?
[06:17] <Peng> Um, IIRC "bzr merge -r 0..-1 /path/to/branch".
[06:17] <Peng> I don't remember if there are any caveats.
[06:17] <Peng> That may do a cherrypick and drop the actual revision information...
[06:17] <Peng> I know what you want is _possible_, I just don't remember exactly how. :P
[06:17] <micahg> Peng: worked, thanks
[06:18] <micahg> or maybe not...
[06:18] <micahg> it moved the directory :(
[06:18] <micahg> now I have debian and debian.moved
[06:22] <micahg> peng: ^^
[06:39] <Peng> micahg: Uh-huh. If both branches have directories named "debian", it's a conflict/.
[06:41] <micahg> Peng: what do I do?
[06:42] <RAOF> Resolve the conflicts?  IE: work out what's different in debian & debian.moved, work out what you want in debian/, and then delete debian.moved.
[06:42] <RAOF> meld is a good tool for the task of producing the debian/ you want from debian & debian.moved
[06:43] <micahg> k, so it'll still have the history from the new branch if I do that?
[06:43] <RAOF> Yes.
[06:43]  * micahg wishes winmerge was ported to linux
[06:44] <RAOF> It's called *meld* :)
[06:44] <micahg> RAOF: I've tried meld in the past unless 1.3 is a new version
[06:44]  * micahg will try it now
[06:44] <micahg> indeed
[06:45] <micahg> they seem to have made some improvements :)
[06:45] <RAOF> Looking at the screenshots I can find for winmerge, it looks almost exactly like the meld I know & love.
[07:15] <micahg> RAOF: so, I moved what I want into the debian dir, but the diff seems to show that everything's changed?
[07:15] <micahg> did I want to go the other way?
[07:30] <RAOF> micahg: I'm not 100% sure what you've done, so I'm not sure.
[07:30] <micahg> I added the files from debian.moved that I wanted to debian
[07:30] <micahg> but now bzr diff shows evrything different
[07:30] <micahg> was I supposed to merge into debian.moved instead>
[07:32] <RAOF> debian.moved will be the debian directory of the branch you tried to merge *into* the current branch (ie: if you ran bzr merge $TARGET then debian.moved will be the debian dir from $TARGET).
[07:32] <RAOF> You should end up with just a single debian directory by merging the changes you want from debian.moved into the files in debian.
[07:32] <micahg> debian.moved was the original dir
[07:34] <RAOF> I might have it the wrong way around, then.  From memory, it's the directory from the thing that you're trying to merge from that gets renamed in a conflict.
[07:34] <micahg> RAOF: bottom line though is I want to move the new stuff into the old dir?
[07:35] <RAOF> Yeah.  At the end, you want the debian/ directory to contain the stuff that you want.
[07:35] <micahg> RAOF: did that, but I still have issues
[07:35] <micahg> so I need to move the stuff from debian to debian.moved and then delete debian and rename debian.moved?
[07:36]  * micahg fires up meld again trying to get this right
[07:37] <RAOF> I'm not totally sure what your issues are.
[07:38] <RAOF> I'm pretty sure that it doesn't really matter how you end up with the debian/ directory, though.  Moving stuff from debian.moved => debian, or moving from debian=>debian.moved & then renaming debian should be equivalent.
[07:41]  * micahg is very lost
[07:41] <RAOF> Let's try and help me work out precisely what's happening :)
[07:42] <micahg> I'm running bzr merge -r 0..-1 TB3 into TB2
[07:42] <RAOF> In your current tree, you've got debian and debian.moved.  You've taken all the changes from debian.moved that you wanted & applied them to debian, so debian/ is now what you'd like in your final tree.
[07:42] <micahg> this creates a debian dir of tb3 contents and debian.moved of tb2 contents
[07:42] <micahg> I moved what I wanted into debian
[07:43] <micahg> bzr diff shows everything is diffferent
[07:43] <RAOF> By “everything”, what do you mean?  Can you pastebin the output of bzr diff?
[07:44] <micahg> it removes and adds the files
[07:46] <micahg> I can;t even do bzr diff on one file
[07:54] <RAOF> Can you pastebin the full diff?  I'm having difficulty visualising what's happening
[07:56] <micahg> no, it's 24k lines
[07:57] <micahg> RAOF: ^^
[08:03] <RAOF> Ow.
[08:03] <RAOF> I'm not really sure what's happening, sorry.
[08:05] <RAOF> I'll try to make a simple analogue of what you're doing locally; see if I can wangle it.
[08:07] <micahg> RAOF: you can reproduce, branch thunderbird-3.0.head and thunderbird.head from code.lp/thunderbird
[12:15] <abli> Hi! How can I 'join' different projects? I.e. merge all versions from one into the other, if they don't have a common ancestor? 'bzr merge' works only if there is a common ancestor, merge-into plugin ditto; fastimport plugin apparently wants to replace the full version history instead of tacking it at the end.
[12:22] <Peng> abli: "bzr merge -r 0..-1 foo" should work.
[12:24] <abli> Ok, I'll try that.
[12:25] <Peng> Possible side effects include unhappiness, maiming, and death. or not.
[12:33] <abli> It appears thats what I was looking for. Thanks!
[12:34] <Peng> \o/
[14:22] <goneri> Hi, I did a svn→bzr transition and now I've a broken branch that don't share revision with trunk. This branch starts when the svn branch had been created. So now Bzr can't merge this branch in trunk since there is no shared references. Is there a way to edit the initial revision of my branch?
=== khmarbaise_ is now known as khmarbaise
=== Adys_ is now known as Adys
[16:15] <mobodo> when I do 'bzr export --format="zip" - myDirectory', I got nothing, but if I do 'bzr export --format="tgz" - mDirectory', it works
[16:16] <mobodo> also, zip to a file instead of stdout works
[16:37] <Colonel-Rosa> morning, does anyone know of a bzr netbeans plugin?
[16:37] <Colonel-Rosa> If not, I'll head the advice found on the wiki and clone the hg plugin and see what I can do
[16:37] <Colonel-Rosa> heed*
=== fossrox_ is now known as fossrox
[18:19] <keithy_> hi whats the statuse on nested tree support?
[18:28] <The_User> Hi! Is there anything like "svn (up|co) -N" in bazaar?
[18:34] <The_User> In svn you can do a checkout this way without downloading all the contained files and subdirectories, you use "svn up" without "-N" to download them completely.
[18:41] <jpds> The_User: bzr update|checkout ?
[18:42] <The_User> jpds: yes, but without downloading all sub directories
[18:52] <The_User> ??
[20:04] <mobodo> could somebody confirm something for me? I think "bzr export --format=zip - " is broken
[20:05] <mobodo> with tar/tgz/tbz2 it works fine (export to stdout), but not with zip
[20:05] <mobodo> just want to check if it's my installation that's broken or bzr
[20:05] <mobodo> (export to a file works, it's just to stdout that's broken)
[23:03] <fullermd> The_User: (hours later) No, the working tree (or revisions thereof) is always entire.
[23:03] <The_User> fullermd: okay :
[23:03] <The_User> D
[23:04] <fullermd> Now, that's no theoretical boundary to only _checking out_ parts of it.
[23:04] <fullermd> But certainly anything dealing with history has a revision's full tree as its smallest component.
[23:05] <fullermd> And there's no implementation of checking out part of a tree.  The 'view' support can sorta let you post-facto treat a full checkout as if it were partial, but that doesn't help you   :)