[03:06] <jlf> hi #bzr, i'm trying to populate a local emacs repo as described at https://savannah.gnu.org/bzr/?group=emacs -- after rsyncing from the savannah repo, doing `bzr checkout' in the branch directory results in `bzr: ERROR: A control directory already exists: "file:///Users/jlf/emacs-bzr/trunk/".'.  does anyone have insight?
[03:07] <lifeless> you may want --lightweight ?
[03:07] <lifeless> I think thats special cased.
[03:12] <jlf> same result -- [jlf@bix] ~/emacs-bzr/trunk [1428]$ bzr checkout --lightweight -> bzr: ERROR: A control directory already exists: "file:///Users/jlf/emacs-bzr/trunk/".
[05:48] <AfC> I just had someone tell me Bazaar isn't a proper distributed version control system.
[05:48] <AfC> {sigh}
[05:50] <AfC> Not that I'm usually inclined to argue in comment streams, but where do you even start replying to something like https://plus.google.com/113426423446646532879/posts/eAfWc7q6Zgu
[06:02] <spiv> AfC: I see what you mean.
[06:04] <spiv> I'm not sure an argument would be productive there either, but you can go at least one more round under Charles' Rules of Argument if you really want ;)
[06:11] <bob2> after using hg for 3 months, oh man :(
[06:11] <bob2> holy confused model batman
[06:14] <spm> AfC: http://xkcd.com/386/ lol, and walk away. not even worth the pain of trying to correct that.
[06:26] <lifeless> wow, they don't understand what distributed means do they
[06:32] <AfC> spm: yeah, but this was an otherwise smart guy. I'm getting annoyed to see him harshing on bzr so much
[06:32] <spm> heh
[06:32] <AfC> spm: this is like the third or fourth post.
[06:32] <AfC> spm: I figure it's time people pointed out to him he's a bit off-base
[06:33] <AfC> spm: guy's an experienced GTK hacker, and admittedly they were some of the first git adopters, but, still
[06:34] <spm> masking his true irritation(s) with bzr via these messages perhaps? - in that, it's fine to dislike, even for irrational reasons.
[06:35] <AfC> I guess. But the "I hate branches because they're not real branches" thing shows the usual impedance mismatch
[06:35] <spm> heh, yes.
[06:36] <AfC> (which has been going on ever since Bazaar used the word "repository" to mean something other than what everyone else thought it meant)
[06:36] <spm> I'd blame lifeless for doing that, myself. rightly or not. it's always his fault.
[06:36] <AfC> spm: oh, I did, don't you worry
[06:36] <spm> haha
[06:40] <lifeless> AfC: what does everyone else think it should mean?
[08:04] <mgz> morning
[08:37] <AfC> lifeless: it *does* mean "central repository" for everyone else. We talked about this at code con many years ago.
[09:08] <AfC> He's at it again https://plus.google.com/113426423446646532879/posts/1BP8YtuiUjC
[09:11] <gmarkall> AfC: I just get a "post not found" message
[09:11] <AfC> gmarkall: hm, maybe you need to be in his extended circles. I'll follow you on g+
[09:11] <gmarkall> I was curious to see what he's saying, but got the same with your earlier link and assumed it had been deleted
[09:12] <AfC> gmarkall: what's your g+ page?
[09:13] <gmarkall> AfC: thanks - its https://plus.google.com/u/0/103909627907661974392/posts (i think)
[09:14] <AfC> That git has become the dominant system, fine; that bzr has various corner cases that it breaks down, fine. But constantly bagging it for fun makes me angry
[09:14] <AfC> gmarkall: [curious if you can see it now, or whether you have to circle me back]
[09:15] <gmarkall> AfC: I can't see it yet, and I can't see your page because you only recently circled me, I think - which page is yours?
[09:16] <mgz> sometimes people just want to gripe, not get solutions :)
[09:16] <AfC> gmarkall: https://plus.google.com/u/0/104216419012637157644/posts maybe?
[09:16] <AfC> mgz: yeah, but this sort of thing shouldn't be unchallenged. If we won't stand up for bzr, we might as well pack it in
[09:16] <mgz> (that post worked for me once I'd logged in, as I seem to have someone who has AfC who has the guy circled)
[09:17] <AfC> mgz: you won't win *him* over, but there are LOTS of people who will be reading his posts, and they should benefit from someone sticking up for Bazaar.
[09:19] <mgz> I do agree, but it also becomes feeding the troll at a certain point...
[09:20] <AfC> mgz: well, as it stands now, Bazaar is a "serious junk tool". Hope that's ok with everyone.
[09:21] <gmarkall> still can't seem to see it... ah well
[09:22] <AfC> What amazes me is pondering what on earth Matthias could have done to get himself backed into such a corner.
[09:22] <lifeless> AfC: so this guy is an ass apparently ?
[09:22] <AfC> I mean, sure, if you're hacking on emacs, there are a few things you need to be wary of, but for 98% of projects, Bazaar just works.
[09:22] <AfC> lifeless: he didn't used to be :(
[09:22] <AfC> lifeless: sorry
[09:23] <lifeless> AfC: his reply to me is /nearly/ an ad-hominen
[09:23] <AfC> yeah
[09:23] <AfC> I'm going to have a word with his boss
[09:24] <mgz> I await the followup g+ post where he says 'whoops, sorry everyone, I tyoped the branch name' or something
[09:25] <AfC> mgz: heh
[09:26] <AfC> mgz: if he'd tell us what actual branch he was aiming at, we could see the history, and pretty rapidly get a sense of what class of roadblock he's run afoul of.
[09:27] <AfC> mgz: but you're right, clearly he doesn't want any help
[09:27] <lifeless> its probably private
[09:28] <AfC> lifeless: point
[09:28] <AfC> Usually it's something like monster binary files committed or not using a shared repository at .. or (as you said) not committing merges or reverting after uncommit or...
[09:28] <lifeless> ah, someone had a word with him.
[09:29] <lifeless> not quite sure he understands, but has toned down.
[12:22] <tbf> sorry if i already asked and forgot again, but how do tell "bzr shelve" to show the magic "e" option for splitting chunks?
[12:22] <tbf> (using bzr 2.5.1)
[12:38] <tbf> ok: https://bugs.launchpad.net/bzr/+bug/708716
[12:38] <tbf> now only need to figure out what "config change_editor" is
[12:40] <tbf> ok. just "vim" doesn't seem to be a good setting
[13:02] <mgz> tbf: I have "change_editor = vimdiff -of @new_path @old_path"
[13:07] <tbf> mgz, thank you. let's see if that works for me
[13:17] <tbf> hmm. also different from "git add -p" or "git commit -i".
[13:17] <tbf> well. guess i'll just resurrect my old svn habit, something like: bzr diff > patch; bzr revert; vim patch
[13:28] <mgz> right, but you can stick other things in there instead, I'm not sure what's closest to just editing the diff directly
[15:07] <Lelak> Hi!
[15:08] <Lelak> Is there someone who could help with a smart server problem?
[15:09] <Lelak> I already asked on https://answers.launchpad.net/bzr/+question/205362 but no answers till now.
[15:11] <Lelak> Actually I know the cause, but I don´t know how to resolve
[15:11] <Lelak> =(
[15:15] <Lelak> is anyone there?
[15:20] <mgz> Lelak: there's no simple answer, basically you need to not commit large binary files
[15:21] <mgz> the problem you'll have is that was done a while back, which now makes normal commits break
[15:23] <Lelak> mgz: thank you very mutch for your interaction!
[15:23] <Lelak> :)
[15:23] <Lelak> much
[15:23] <mgz> so, one way forwards is to create a new shared repo (without trees), branch all non-borked branches using the repo into it, and then branch the last good rev of the borked branch
[15:24] <mgz> then replay the newer changes sans giant binary files
[15:26] <Lelak> mgz: if I understood well, I will need to create a new shared repo and rebranch all 'good' branches from theold repo?
[15:27] <Lelak> I was trying to tweak the .bzr/reposity folder (15GB) to make it smaller
[15:27] <Lelak> do you think this is a good Ideas and less work?
[15:28] <mgz> poking around inside .bzr/repostory isn't safe, and won't fix your OOM issue
[15:29] <mgz> you need to excise the revisions that included big binary files, but not damage history you care about
[15:29] <mgz> the easiest way to do that is by starting from a new shared repo
[15:33] <Lelak> thanks mgz. I see. Do you know a way to find on wich branches are located this big binary files?
[15:33] <Lelak> so I can exclude them on the new repo?
[15:34] <mgz> hm...
[15:34] <jlf> good morning #bzr, is it possible to generate changelog entries for as-yet-uncommitted changes?  i see that `bzr log' has a --gnu-changelog option, but `bzr status' does not.
[15:35] <mgz> I'm not sure we have a tool that makes it easy, but basically anything that if you try to branch to a temporary location makes a giant repo. really you want the specific rev too so you can rewrite it
[15:36] <mgz> jlf: uncommit! :)
[15:37] <Lelak> ok. I was taking a look on the .bzr/repository/uploads folder (12GB) and there are packs with regular sizes some with 1gb.
[15:37] <jlf> mgz: will that entirely remove the temporary commit from the history or just apply a second commit that undoes the first?
[15:38] <mgz> it removes it from the branch, but keeps it in the repo in case you want to un-uncommit
[15:39] <mgz> Lelak: the issue is the packs are not segmented by branch, so some bzrlib scripting is needed to work out what changes are stored in which packs
[15:40] <Lelak> understood.
[15:41] <jlf> mgz: i see, thank you
[15:42] <Lelak> mgz: so will start to create a new repository. I have now about a 100 branches. Do you recommend any proceedure to make the migration to the new repo easyear?
[15:43] <Lelak> easier
[15:44] <mgz> hm, that probably does want scripting
[15:46] <Lelak> mgz: please, can you indicate to me any documentation where I can start understanding how bazaar scritpting works?
[15:49] <mgz> Lelak: I suggest you start by just doing a couple of branches manually
[15:49] <mgz> and I'll try and see if we've got some existing code that finds bloated branches/revisions
[15:53] <Lelak> thank you mgz!
[15:59] <Lelak> I will be back in 1hour.
[22:24] <quotemstr> bzr branch from a git repository (using git+ssh) is very slow. Is there any way to speed it up?
[22:35] <bob2> clone with git then clone with bzr?
[22:35] <quotemstr> bob2: It's CPU-bound, not network bound.
[22:36] <bob2> i'd still be surprised if git wasn't faster but ok
[22:39] <jelmer> bob2: cloning locally first basically has the same effect; either way you end up receiving a git pack first, storing that on local disk and then processing it