[00:00] <samd_> jelmer: thanks, im trying to set up a personal server, i made up a upstart job to start bzr serve on boot, the upstart job executes the command "bzr serve --port=1234 --directory=/srv/bzr/repo", im able to log, branch just fine, i just cant push anything, i get the error "ERROR: Cannot lock LockDir(filtered-44592336:///quiniela/.bzr/branch/lock): Transport operation not possible: readonly transport"
[00:01] <samd_> jelmer: i can push just fine using sftp://host/project method just fine
[00:05] <samd_> i guess im missing something about authentication/permissions or something
[00:09] <jelmer> samd_: You need --allow-writes
[00:10] <jelmer> samd_: but please note that that will allow write access to anybody who can connect to that port
[00:11] <samd_> jelmer: ohh, i see, thank you very much, yeah i see that risk, so id be better be using sftp as it provides authentication, or there's a way to add authentication to bzr serve?
[00:13] <samd_> jelmer: ooo im seeing this on  the man page, it seems like authentication has to be implemented externally, thank you very much, i apreciate your help
[00:25] <doug> hulo
[00:25] <doug> where's the Right Place to put a push(commit) hook?
[00:25] <doug> especially if i'd prefer everyone i put on the server to be using it w/o additional setup
[00:26] <doug> a'la svn post-commit-hook
[00:45] <doug> mmm, a bit harder than i'd think.
[00:49] <mkanat> doug: See "bzr hooks"
[00:50] <mkanat> doug: You probably want post_change_branch_tip.
[00:50] <mkanat> doug: If you're somehow enforcing use of the smart server, then installing it globally on the server will enforce its use.
[02:59] <GungaDin> how should the output of 'bzr blame' be read?
[03:00] <spiv> GungaDin: with delight! ;)
[03:00] <GungaDin> :)
[03:00] <GungaDin> I don't really understand how to read it, to be honest.
[03:00] <GungaDin> some lines have revno.something.something name next to them..
[03:00] <GungaDin> some don't...
[03:01] <spiv> Actually, I mainly use 'bzr qannotate' (or 'bzr gannotate', I'm not very loyal...), because it's a bit more convenient to view it as a GUI format.
[03:01] <spiv> A run of lines from the same revision only have the top line marked, to keep the output a little easier to read.
[03:01] <GungaDin> my bzr doesn't understand these commands.
[03:01] <spiv> Install the qbzr (or bzr-gtk) plugins to get them.
[03:02] <GungaDin> but there is revid.x.y
[03:02] <GungaDin> what's x & y?
[03:02] <GungaDin> and why is it that bzr st -c revid doesn't indicate this file was changed?
[03:04] <spiv> Dotted revision numbers are explained here: http://doc.bazaar.canonical.com/latest/en/user-guide/zen.html#understanding-revision-numbers
[03:04] <spiv> Not sure why 'bzr st -c revid' wouldn't show a change in that case, though :/
[03:06] <fullermd> If you weren't putting in the whole revno, just the first segment.
[03:27] <michaelh1> Afternoon.  I'm looking at building the same bzr branch on three machines, each with different architectures
[03:28] <michaelh1> I want to build continousally, and throw the branches away quite often
[03:28] <michaelh1> Can I put some type of cache in the middle to cut the download time?
[03:40] <michaelh1> Ah, figured it out: run a mirror branch and branch off that
[05:17]  * spiv celebrates the netsplit by going to lunch
[11:34] <schlangen_> hey, I've messed up sth with bzr(gui?) and now I've got 3 dead heads. what shoud I do (or read)?
[11:35] <GaryvdM> schlangen_: You can merge dead heads with merge -r revid:....
[11:35] <wgrant> But, in general, dead heads are not a problem.
[11:36] <LeoNerd> E.g. every 'bzr uncommit' operation will create one
[11:36] <wgrant> They might just indicate that you've used 'bzr uncommit' at some point, for example.
[11:36] <wgrant> Right.
[11:36] <GaryvdM> I just checked, and I have 72 dead heads in my qbzr repo. I use uncommit alot...
[11:37] <schlangen_> but its my active code! I did some local commits, then an update and all my local changes where gone
[11:37] <LeoNerd> Indeed. They're not causing any damage.. They're just dead-ends in the branching path that represents your history
[11:37] <schlangen_> like here: http://srtsolutions.net/blogs/chrismarinos/archive/2008/10/24/don-t-loose-your-head-with-bazaar.aspx
[11:37] <LeoNerd> If you really care about them, you can 'bzr push' the branch elsewhere, then move the directories around. 'bzr push' will only see the live revisions, so skip over the dead ones
[11:37] <LeoNerd> All this will do is save you a bit of disk space
[11:38] <GaryvdM> schlangen_: So that can happen if you do bzr update, and then bzr revert before you commit.
[11:38] <wgrant> If you 'bzr update' with local commits, your local commits will appear as a pending merge.
[11:38] <GaryvdM> schlangen_: If they are stuff that you need, then merge them.
[11:39] <schlangen_> don't know if I did revert, maybe (new to bzr and don't really like the gui, but have to work on win for few days)
[11:39] <schlangen_> so how can I fix it now and get all my changes back to "normal" commit history?
[11:40] <GaryvdM> schlangen_: bzr merge -r revid:<revid of dead head>
[11:40] <GaryvdM> sorry
[11:40] <GaryvdM> schlangen_: bzr merge . -r revid:<revid of dead head>
[11:43] <schlangen_> ok, I'll try
[11:47] <schlangen_> GaryvdM: yay, I think it worked :D thanks
[12:35] <GaryvdM> Hi mgz
[12:35] <mgz> hey gary.
[12:36] <GaryvdM> Could you please test a build for me. I'm at home, and my windows machine is at work.
[12:37] <GaryvdM> mgz: http://dl.dropbox.com/u/4494367/bzr-2.2b4-bzrw-setup.exe
[12:37] <mgz> getting.
[12:37] <mgz> what did you change?
[12:38] <GaryvdM> Thanks. Add a windows target, bzrw.exe, so you can run bzr explorer, with out having a console window open.
[12:39] <GaryvdM> lp:~garyvdm/bzr/bzrw and lp:~garyvdm/bzr-windows-installers/bzrw
[12:47] <mgz> well, seems to work, but still need to shell execute `bzrw.exe explorer`
[12:48] <mgz> would be nicer if just had something called explorer.exe that double clicking on worked with
[12:50] <GaryvdM> mgz: The start menu/desktop short cuts should have been changed?
[12:50] <mgz> ah yes, that's fine.
[12:50] <GaryvdM> mgz: I've also had request from people who want to run bzrw qlog, or bzrw qpull...
[12:51] <GaryvdM> So I think that a generic command is better.
[12:53] <GaryvdM> I also want to get rid of tbzrcommandw.exe and tbzrcommand.exe. They tbzr should just call bzrw.exe directly.
[12:53] <GaryvdM> mgz: Thanks for testing that for me. I'm going to post to the mailing list.
[15:11] <jam> morning all
[15:13] <rubbs> morning jam
[15:22] <GaryvdM> Hi jam
[15:23] <jam> hey GaryvdM
[15:29] <GaryvdM> jam: If I have KnownGraph object, what would be the best way to do an is_ancestor query?
[15:30] <jam> GaryvdM: heads()
[15:30] <jam> head = kg.heads(x, y)
[15:31] <jam> if head == x: then y is an ancestor of x
[15:31] <jam> if heads == (x, y) then neither is an ancestor, etc
[15:31] <GaryvdM> jam: So Is it ok to be reimplementing Graph.is_ancestor?
[15:31] <jam> GaryvdM: if you look, it is just doing a heads call itself
[15:32] <jam> I think somebody was wanting a clearer statement in code
[15:32] <jam> but it is really is a single line function
[15:32] <jam> also note, that it will be more efficient than doing "is_ancestor(x, y), is_ancestor(y, x)"
[15:32] <jam> but I don't know what *you* want isancestor for
[15:34] <GaryvdM> jam: If the user has qlog open with more than one branch, an the right click, and chose say tag, I only want to show the branches for which the rev is an ancestor.
[15:35] <GaryvdM> For merge, only the branches which it is not an ancestor.
[15:35] <GaryvdM> For cherry pick, not
[15:36] <GaryvdM> for reverse cherry pick, is
[15:36] <GaryvdM> etc.
[15:37] <jam> GaryvdM: so in those cases, you can probably check across multiple branches simultaneously
[15:37] <jam> maybe not
[15:38] <GaryvdM> jam: Ah - right.
[15:38] <jam> You could tell if it was an ancestor of one of the branches, and if the branches were related, but I think it would get muddy to tell if each branch was an ancestor, etc
[15:38] <jam> however, kg.heads() is *much* faster than Graph.heads()
[15:38] <jam> the latter is known to be O(N^2)
[15:42] <_Andrew> hi, is there a way to revert all the file permissions changes in a repo? I have a bzr repository from windows and viewing it on ubuntu just shows everything as modified
[15:43] <jam> _Andrew: unfortunately, the easiest thing to do is to "bzr co --lightweight onto a non fat/ntfs partition"
[15:43] <GaryvdM> jam: A cool - kg.heads caches it's self.
[15:43] <jam> GaryvdM: yeah, though it may not actually need to. I think it was useful for annotation where you get the same requests many many times
[15:43] <jam> which was the original kg motivation
[15:43] <_Andrew> damn, thanks anyway
[15:43] <jam> _Andrew: Under Linux we trust the filesystem to report executable bit properly
[15:44] <jam> which we shouldn't, but that is how it is for now
[15:44] <jam> (it sounds like mounting -x might also help)
[15:53] <jam> GaryvdM: so are you still done with the ec2 machine for now?
[16:21] <GaryvdM> jam: Yes
[16:21] <GaryvdM> jam: Please shut it down.
[16:22] <jam> thanks
[16:22] <jam> creating a snapshot and shutting down now
[20:20] <jam> spiv: what are you doing up so early?
[20:59] <Meths> Can you make a checkout forget a push location? (without overwriting with another)
[21:06] <jam> Meths: bzr push --remember
[21:07] <Meths> Nope, that just pushed to the already stored location
[22:26] <jelmer> jam: hi
[23:41] <michaelh1> Hi there.  I'm a bit worried about the memory/CPU bzr is using - I'm doing a checkout and it's sitting at 600 MB of RAM and 50 to 100 % CPU
[23:41] <michaelh1> It's a really large branch, but still
[23:42] <poolie> this is linaro-gcc?
[23:42] <poolie> you should try with 2.2b4 if you're not already
[23:42] <michaelh1> OK.  Will do.
[23:42] <poolie> it has some memory use improvements over 2.1
[23:42] <poolie> not sure if that's in maverick yet
[23:42] <poolie> or if you're on maverick :)
[23:42] <michaelh1> Ah, this is a server so it's on Lucid
[23:43] <poolie> ok
[23:43] <poolie> we may not yet have it in the ppa
[23:43] <michaelh1> I'll be chrooting into maverick later on
[23:43] <poolie> you could build from source if you want
[23:43] <poolie> if you want file a bug tagged linaro
[23:43] <michaelh1> I'll see how 2.2b4 goes