[05:22] <sarcasticCat> Does bazaar have some equivalence functionality as GIT Blame?
[05:50] <spiv> sarcasticCat: have you tried 'bzr blame'? :)
[05:50] <sarcasticCat> lol that's that first thing I tried :P
[05:51] <spiv> What does it lack that you're looking for?
[05:55] <sarcasticCat> spiv: Uhm, there's this source file (that has been worked on by multiple people), I'd like to know who've made what changes
[05:56] <sarcasticCat> spiv: git blame would do just that. But at my place, the cvs is bazaar, and I'd like to know if bzr is capable of this
[05:58] <spiv> sarcasticCat: bzr blame should tell you that.
[05:58] <spiv> sarcasticCat: is it not doing that for y ou?
[05:59] <spiv> (you may also find GUI implementations nice, like 'bzr qannotate' from the qbzr plug, or 'bzr gannotate' from the bzr-gtk plugin)
[05:59] <sarcasticCat> spiv: Oh, ok. Yeh, it worked. (It didn't work the first time because I was at the wrong directory)
[05:59] <sarcasticCat> thanks
[05:59] <spiv> You're welcome.
[06:02] <sarcasticCat> spiv: Uhm, now I get <filename> is not versioned sometimes.
[06:03] <sarcasticCat> What might be the reason for ths? (i'm pretty sure people have made a lot of changes gradually in these files)
[06:03] <sarcasticCat> *this
[06:05] <spiv> sarcasticCat: hmm, when you try "bzr blame <filename>"?  what does "bzr status <filename>" report?
[06:05] <bob2> how sure are you that it is versioned
[06:07] <sarcasticCat> bob2: almost 100%. (This file has different blocks of code written in different styles, so it must've been written by multiple people, obviously not at the same time. So it must be versioned)
[06:08] <bob2> :/
[06:08] <bob2> er, use bzr status or bzr log to find out
[06:09] <sarcasticCat> well, bzr log would give me > 2000 lines (from 2009 till now) :(
[06:09] <bob2> bpaste.net shell session of 'bzr log somefile | head ; bzr blame somefile | head'
[06:10] <sarcasticCat> Oooh, bzr status <filename> gave me "nonexistent", which doesnt make anysense
[06:10] <sarcasticCat> I'm staring at the file right now. o_O
[06:11] <sarcasticCat> the syntax is [bzr status <path to file>] , right?
[06:11] <bob2> == not in bzr
[06:12] <bob2> (this is all the same as git btw)
[06:12] <sarcasticCat> bob2: Sorry, i'm not quite following. What do you mean by "not in bzr"
[06:12] <sarcasticCat> ?
[06:13] <bob2> the file isn't in bzr
[06:13] <bob2> or your path is screwed up somehow
[06:14] <sarcasticCat> uhm, yeah. there's a typo in it! Sorry for the noise!
[06:16] <sarcasticCat> btw, is there a way to check who first added a particular file?
[06:16] <bob2> bzr log --help
[06:16] <bob2> -> reverse -> | head
[06:17] <sarcasticCat> bob2: uhm...? reverse what?
[06:17] <bob2> ?
[06:17] <bob2> the output of log
[06:18] <bob2> prety sure it's the exact same answer as in git, just with the word 'bzr' instead of the word 'git'
[06:20] <sarcasticCat> Well, I know what the output of log looks like. But I dont see how that relates to my question.
[06:20] <bob2> ? the first commit is the one that added it
[06:21] <sarcasticCat> oh, I see what you're saying. I thought you said to do a [bzr log] (w/o the filename)
[08:11] <mgz> morning
[08:15] <fullermd> Humbug.
[12:35]  * jelmer waits for the 2.5.1 SRU tests to pass..
[12:36] <mgz> how parallel are you going?
[12:36] <jelmer> mgz: 4 I think
[12:36] <jelmer> thunderbird is also keeping one of my CPU cores busy though
[12:37] <mgz> ehehe
[12:37] <mgz> thunderbird is the antivirus of nix.
[12:37] <jelmer> what it's doing, I have no clue..
[12:41] <fullermd> Some things man isn't meant to know.
[14:05] <frathgeber> hi, all. i've been googling for an answer to this question for quite a while but can't seem to find an answer
[14:06] <frathgeber> is it possible to configure which shared repository a branch uses?
[14:06] <frathgeber> situation as follows: i have a co-located workspace in /path/to/colo and a legacy shared repo in /path/to
[14:06] <mgz> yes, but depends what you mean by 'configure'
[14:07] <frathgeber> i want to choose the shared repo location
[14:07] <frathgeber> e.g. with bzr reconfigure
[14:07] <frathgeber> or by editing .bzr/branch/branch.conf or any other configuration
[14:07] <mgz> it will just use the one closest as it climbs the directories
[14:07] <frathgeber> which break my co-located workspace
[14:08] <frathgeber> because i want my branches to use /path/to/colo/.bzr/branches
[14:08] <mgz> there's no problem having a repo in colo
[14:08]  * jelmer luncheons
[14:09] <jelmer> fsvo lunch
[14:09] <frathgeber> yes, but for some reason the branch suddenly picks up the shared repo in the parent
[14:09] <frathgeber> which obviously doesn't contain its history
[14:09] <frathgeber> so as a consequence my co-located workspace is now broken
[14:09] <mgz> jelmer, not quite yet! is there some command that will make a colo branch init a repo where it lies?
[14:09] <frathgeber> :)
[14:10] <jelmer> mgz: a bzr-colo branch or a bzr-core colocated branch?
[14:10] <frathgeber> i'm using bzr-colo
[14:10] <frathgeber> but i don't think it matters
[14:10] <frathgeber> it's related to the bug i just reported: https://bugs.launchpad.net/bzr/+bug/1005532
[14:11] <jelmer> frathgeber: that does matter
[14:11] <frathgeber> ok
[14:11] <jelmer> the way in which bzr-colo stores it branches is confusing bzr
[14:11] <mgz> frathgeber: so, in theory there's no problem with the layout you want, just some of the conversion commands are likely too zealous about sqiushing things together
[14:12] <frathgeber> jelmer: yes, i realised it's confusing bzr
[14:12] <frathgeber> and now i'm looking for a way to un-confuse bzr
[14:12] <jelmer> I would be inclined to reassign this to bzr-colo
[14:12] <frathgeber> i.e. make it use .bzr/branches as the shared repo again
[14:12] <frathgeber> instead of ..
[14:13] <frathgeber> i think what i'm really asking is: how does bzr-colo make a branch use a shared repo in a subdirectory
[14:13] <frathgeber> and how can i restore this configuration if it's broken?
[14:14] <jelmer> frathgeber: if a branch itself doesn't have a repository bzr will look upwards
[14:14] <jelmer> so if you remove .bzr/branches/foo/.bzr/repository it will start using .bzr/repository again
[14:16] <frathgeber> there seems not to be a .bzr/branches/foo/.bzr/repository
[14:16] <jelmer> if .bzr/branches/foo is a standalone branch there would be
[14:17] <frathgeber> ok
[14:17] <frathgeber> so i need to bzr reconfigure --standalone .bzr/branches/foo
[14:18] <frathgeber> oh bugger, i see what has happened
[14:18] <jelmer> frathgeber: I don't think bzr-colo branches would ever want to be standalone?
[14:19] <jelmer> shouldn't they use the repository in .bzr/branches ?
[14:19] <frathgeber> my failed attempt to reconfigure did actually delete the shared repository in .bzr/branches/.bzr/repository
[14:19] <frathgeber> they should, yes
[14:20] <mgz> right, go and eat some things jelmer :)
[14:20] <frathgeber> but my failed attempt to reconfigure it as per bug #1005532 seemed to have killed that shared repository
[14:20] <jelmer> anyway, "lunch" first.. back in 45 min :)
[14:20] <frathgeber> thanks, enjoy your lunch
[14:20]  * frathgeber just had 'lunch' a few min ago
[14:21] <mgz> frathgeber: the interesting thing for that bug is probably the steps to get into that situation
[14:21] <mgz> if you can reproduce from scratch, that would be usefulful to include steps for
[14:21] <frathgeber> yes, it actually started earlier, but i hadn't expected that that would be relevant
[14:22] <frathgeber> situation was as follows (and i think will be subject of another bug report):
[14:22] <frathgeber> co-located workspace in /path/to/colo
[14:23] <frathgeber> now i did bzr colo-checkout ../mybranch as described in the bug report
[14:23] <frathgeber> subsequently however, i rebased /path/to/colo (which in fact is also a lightweight checkout of mybranch)
[14:26] <frathgeber> actually, that should be legal, shouldn't it? rebasing a branch that has 2 lightweight checkouts shouldn't break either of them?
[14:28] <mgz> shouldn't have any impact, indeed
[14:30] <frathgeber> anyway, i noticed that bzr info in ../mybranch gave me the 'wrong' shared repo and indeed all bzr operations were broken
[14:30] <frathgeber> bzr: ERROR: Revision ... not present in ...
[14:31] <frathgeber> so i was looking for a way to point it back to the 'right' shared repo
[14:31] <mgz> right, but you're not sure which command actually broke the repo, correct?
[14:31] <mgz> for the bug report, that's what we need
[14:31] <frathgeber> correct
[14:32] <mgz> for recovery, it sounds like you want to make a fresh branch from another copy of the repo, as at some point the current one got deleted
[14:32] <frathgeber> indeed
[14:33] <mgz> possibly during recovery attempts after the layout got confused rather than at the same time
[14:33] <frathgeber> i think i had pushed everything upstream before
[14:34] <frathgeber> i've repeatedly done bzr reconfigure --standalone followed by bzr reconfigure --use-shared to figure out what actually happened
[14:35] <mgz> remember .bzr.log also records your past commands and might be useful in working out what happened when
[14:35] <frathgeber> very good point indeed
[14:36] <frathgeber> i'll have a look at that and see if it tells me sth
[14:38] <frathgeber> ah, there we go. i think i remember now what caused me to try those weird experiments
[14:38] <frathgeber> bzr reported ../mybranch was out of date, so i tried bzr up, which failed
[14:38] <frathgeber> saying 'branch has no revision ...'
[14:39] <frathgeber> mgz: i can attach .bzr.log to the bug report?
[14:40] <mgz> yup, you may want to trim it a little, but keeping a few commands before that update would likely be useful too
[14:41] <frathgeber> yeah, i found the but from where it's potentially relevant
[14:43] <frathgeber> odd, https://bugs.launchpad.net/bzr/+bug/1005532/+addcomment is broken for me, i get the generic 404 'Lost something?'
[14:44] <frathgeber> refreshing helped
[14:45] <mgz> odd, on post or get?
[14:46] <frathgeber> get
[14:46] <frathgeber> i think it was because jelmer had made a status change in the meantime
[14:46] <mgz> ah, I know what it is
[14:47] <mgz> project changed from bzr to bzr-colo and there's no redirect
[14:48] <frathgeber> ah, right
[14:48] <frathgeber> that's fair enough
[14:49] <frathgeber> i'll try to rescue my shared repo and maybe someone can make some sense from my bzr.log
[14:50] <mgz> creating a fresh branch from the bits you pushed upstream is probably easiest
[14:51] <frathgeber> yep
[14:53] <frathgeber> mid-term i'll probably switch to colo-core
[14:53] <frathgeber> when is that going to make it into the release?
[14:54] <mgz> it's in 2.5, with a few ui polish issues
[14:54] <mgz> neil was talking about making bzr-colo use the new core colo support where available
[15:00] <frathgeber> ok. where can i find documentation on core colo?
[15:02] <frathgeber> canonical.com is really slow today...
[15:02] <mgz> not sure what we have on the user-facing side
[15:02] <frathgeber> nothing obious at least :)
[17:12] <frathgeber> it seems i've lost the 2 most recent commits
[17:13] <frathgeber> now the branch is in some weird limbo and appears unusable
[17:14] <frathgeber> e.g. bzr: ERROR: Could not determine revno for ... because its ancestry shows a ghost at ...
[17:23] <jelmer> frathgeber: did you perhaps remove any of the repository directories?
[17:23] <jelmer> one repository probably has/had mroe revisions than the other
[17:24] <frathgeber> i didn't conciously remove any of the repository directories
[17:24] <frathgeber> but quite possibly one of the commands i ran did (see https://bugs.launchpad.net/bzr-colo/+bug/1005532/+attachment/3166962/+files/bzr.log)
[17:29] <frathgeber> is there anything i can do to rescue that branch? i still have the working tree and also the dirstate, so i could branch from upstream and diff to see the changes and try to re-create those 2 missing commits
[17:29] <frathgeber> is there an easier/safer way to do that?
[17:31] <jelmer> frathgeber: it's probably easiest to talk to somebody familiar with bzr-colo, I'm not entirely sure what all the colo- commands do
[17:35] <frathgeber> ok. but assuming the repository is lost (which is what i'm assuming now), do i have better options to ressurect those 2 lost commits than what i described above?
[17:37] <vila> frathgeber: yup. On the other hand, 'find . -name pack-names -print' should tell you where some repository may be hidden and hopefully recoverable (I'm here for less than ~5 minutes)
[17:38] <frathgeber> ok, will run that
[17:39] <frathgeber> alas it's gone
[17:40] <frathgeber> i'll go the manual route then
[17:40] <frathgeber> thanks for your help jelmer, mgz, vila
[19:47] <fullermd> Oh look, 2.5.1 takes lplibrarian into the hundred millions.  Yeesh.
[19:53] <jelmer> fullermd: whu?
[19:54]  * fullermd shrugs
[19:55] <fullermd> Doesn't mean anything.  Just cute.
[21:33] <dodgerblue> hello all
[21:34] <dodgerblue> do you have any idea how can i commit so i can get a partial version like <version>.1.1 ?
[21:34] <dodgerblue> or <version>.1.2?
[21:41] <bob2> why?
[21:42] <dodgerblue> bob2: i just wanna know how
[21:42] <bob2> ok!
[22:06] <wgz> dodgerblue: that happens when you commit a merge of another commit
[22:07] <dodgerblue> wgz: thanks :)
[22:11] <jave> do I need to install the "colo" plugin if I want to try colocated branches in bzr 2.5?
[22:17] <wgz> jave: nope, that's a different thing
[22:23] <jave> okay. were can I find proper docs on colocated branches?
[22:24] <jelmer> jave: there aren't any at the moment, colocated branches are still experimental in 2.5
[22:25] <jave> ah well.
[22:25] <jelmer> I think the main documentation is some emails to the mailing list at this point.
[22:25] <jave> is colo branches usable at all in 2.5?
[22:26] <jave> or should I wait?
[22:26] <jelmer> jave: I wouldn't recommend it for production use
[22:26] <jave> okay thanks,
[22:26] <jelmer> if you're working on plugins etc and want to make them ready for colocated branches then it might be worth to have a look at them
[22:27] <jave> no I just wanted to try out colo branches on the emacs repo
[22:51] <vadi2> bzr viz's UI is very broken for me in 2.5.0. I can't scroll all the way to the top of the revisions history. Does anyone else have this?
[22:53] <jelmer> vadi2: it's fine here
[22:53] <jelmer> vadi2: what version of bzr-gtk is that?
[22:54] <vadi2> 0.103.0+bzr792-1ubuntu1
[22:56] <vadi2> This is what I can scroll up to: http://i.imgur.com/i7mBv.png you can tell it's not the latest one because the arrow button is still pressable. The only way I can get to the top is via the keyboard up/down buttons - and when I switch that way, it fails to scroll, but does select the revision properly/
[23:00] <jelmer> vadi2: I would recommend filing a bug, I haven't seen any bugs about this issue before
[23:01] <vadi2> alright