[00:01] <spiv> Good moring.
[00:01] <spiv> morning, even.
[00:20] <mkanat> It is amazing how popular a topic "I have a ridiculously large repo" is.
[00:21] <spm> mkanat: it's the old "my keyboard is bigger than your keyboard" ego thing ;-)
[00:21] <mkanat> spm: lol
[00:22] <peitschie> mornin spiv :)
[00:22] <spm> depressingly I don't get any spam about how to make my keyboard bigger tho. other things, but not keyboard. shame.
[00:22] <peitschie> lol
[00:22] <peitschie> mkanat: it may also be that bzr is just tipped the scales into "serious DVCS" ;)
[00:23] <mkanat> peitschie: I think it sort of did!!
[00:23] <spiv> spm: I'd have thought "make your monitor 20% BIGGER" would be more tempting for many?
[00:23] <mkanat> peitschie: I wonder what the trigger was! Maybe the 2a format.
[00:23] <mkanat> spiv: LOL!
[00:23] <mkanat> Well, my keyboard is probably 2000% more expensive than your keyboard.... :-D
[00:23] <mkanat> I mean, provided that you have a plain old keyboard. :-)
[00:24] <spiv> mkanat: depends on if you count the rest of the laptop that it's attached to ;)
[00:24] <mkanat> LOL
[00:24] <fullermd> My keyboard can beat up your keyboard   :p
[00:28] <mkanat> Dude, I dunnow, my keyboard is five pounds of steel.
[00:29] <peitschie> mkanat: personally it has been a maturity thing i think... bzr has now been around long enough that most companies have enough ppl that have heard of it to convince projects to move
[00:30] <peitschie> mkanat: i actually met a *new* dev the other day that uses it personally... which is an infinite number of times the number of bzr-using devs i've met b4 in person
[00:30] <fullermd> Obviously we need to setup a deathmatch.  Two keyboards enter; one keyboard leaves!
[00:35] <mkanat> fullermd: LOL!!
[00:35] <mkanat> KEYBOARD-DOME!
[00:35] <Kobaz> so i'm trying to do a bzr fast-export... and i'm getting bzr: ERROR: bzrlib.errors.KnitCorrupt: Knit KnitVersionedFiles(_KnitGraphIndex(CombinedGraphIndex(
[00:35] <mkanat> peitschie: That's pretty cool.
[00:36] <Kobaz> it exports about 100 revs out of 300ish, and then dies... is there a way to repair the repo?
[00:38] <peitschie> mkanat: it is very :).  One of the key things bzr has going for it as well I think is a strong focus on svn integration as well.  the fact that core bzr think it is important (well, core enough to have invested a lot of time in it) is a good sign... so even the current troubles is not too concerning because i know that bzr will work best with my svn repo
[00:38] <mkanat> peitschie: That's awesome. :-)
[00:38] <mkanat> Kobaz: Does "bzr check" pass?
[00:38] <peitschie> mkanat: which while not really the best result, allows me to "lead" more conservative programmers into it than jumping to a brand new repo format
[00:39] <peitschie> mkanat:... that and i like devs who get together and compare keyboard sizes :P
[00:39] <mkanat> peitschie: lol
[00:39] <Kobaz> mkanat: no it doesnt
[00:39] <Kobaz> r(Error -3 while decompressing: invalid distance too far back)
[00:40] <peitschie> Kobaz: are you windows or linux-based?
[00:40] <mkanat> Kobaz: Okay, that's probably the problem. I'm not familiar with what to do about that, but I'm guessing that poolie, jam, or perhaps some others will know.
[00:40] <Kobaz> linux
[00:40] <Kobaz> bzr 2.1
[00:40] <peitschie> kobaz: cool... no ideas from me then unfortunately :S
[00:40] <Kobaz> heh
[00:40] <Kobaz> lovely
[00:44] <Kobaz> so there's no repair?
[00:45] <mkanat> Kobaz: There probably is, we just don't know it.
[00:45] <mkanat> Kobaz: Somebody else will probably be along later who would know it.
[00:45] <spiv> Kobaz: that unfortunately means suggests the data on disk has been corrupted
[00:45] <Kobaz> hmm
[00:45] <spiv> That's an error from zlib
[00:45] <Kobaz> i guess i can just repull... it's just a copy of what's on the server
[00:46] <spiv> That would be the simplest thing to try.
[00:47] <spiv> I'd also be a little worried about the integrity and robustness of your filesystem, though.
[00:47] <Kobaz> ext3
[00:47] <Kobaz> never had a problem on this box with anything else
[00:48] <Kobaz> did a repull, it seems to be working now
[00:48] <mkanat> Kobaz: Might want to fsck just to be sure.
[00:49] <Kobaz> spiv: it might be bzr though, i had some nasty corruption problem when i tryed to do a merge a month ago... i did a merge and then it broke itself
[00:49] <Kobaz> took me a bit of playing to get it working again
[00:49] <spiv> Depending on how ext3 is configured it can result in zero-length files after a system crash.
[00:49] <spiv> Hmm, what format repo?
[00:50] <Kobaz> the old format
[00:50] <lifeless> mgz: love the stuff you're working on
[00:50] <spiv> I'd definitely suggest upgrading, for many reasons
[00:50] <Kobaz> yeah i know
[00:50] <spiv> :)
[00:50] <Kobaz> well. i am upgrading actually... switching to git
[00:50] <Kobaz> heh
[00:50] <spiv> Hah
[00:50] <mgz> lifeless: I think mostly I'm working on annoying people with better computers than me :)
[00:51] <Kobaz> we're moving to a bunch of atlassian tools, and none of them work with bazaar
[00:51] <lifeless> mgz: smaller is faster often
[00:51] <lifeless> mgz: its good stuff
[00:51] <Kobaz> and i'm very interested in all the security that gitolite supports... it's quite cool
[00:52] <Kobaz> it was so much easier to set up than the http+ssl bzr :/
[00:56] <i386> Kobaz: ping
[00:56] <Kobaz> pong
[00:57] <Kobaz> the re-pull now passes bzr check
[00:57] <i386> Kobaz: I work for Atlassian and lifeless ping'd me about bazaar support in our products
[00:57] <Kobaz> ah
[00:57] <i386> what apps are you starting to use?
[00:57] <Kobaz> Jira, Confluence, and going to start using Fisheye soon
[00:57] <i386> cool
[00:57] <i386> so you would like to see some bzr love in Fisheye?
[00:58] <Kobaz> well, we're moving to git for other reasons
[00:58] <Kobaz> if i was staying with bzr, i would
[00:58] <lifeless> Kobaz: oh :(
[00:58] <i386> aww
[00:58] <Kobaz> we're also going to use bamboo and crucible
[00:58] <i386> Kobaz: well we have good git support in Fisheye..
[00:59] <i386> Kobaz: nice I work on Bamboo
[00:59] <i386> You get the new shiny-we-just-rewrote-it Bamboo :)
[00:59] <Kobaz> nifty
[00:59] <Kobaz> hehe
[00:59] <i386> blogs.atlassian.com/devtools/2010/10/bamboo-27-beta-parrallel-builds.html
[01:00] <i386> yeah
[01:00] <i386> we still need bzr support
[01:00] <Kobaz> yeah probably
[01:00] <i386> There is a bzr bamboo plugin
[01:00] <i386> but I don't think its maintained anymore
[01:13] <jbunting> looking to get my feet wet with development...any reason not to work on bug 644990?
[01:14] <spiv> jbunting: looks like a good bug to get your feet wet with
[01:14] <spiv> jbunting: so go for it! :)
[01:16] <jbunting> spiv: alright
[01:32] <poolie> hi spiv, mkanat
[01:32] <poolie> and all
[02:43] <peitschie> hi poolie
[03:57] <cr3> is there a way to bzr builddeb without having to commit files first? ie, take the files in the cwd as they are?
[04:00] <lifeless> its the default
[04:01] <cr3> lifeless: it complains that there's no debian/changelog though
[04:02] <lifeless> you may have it configred in a nondefault mode
[07:49] <vila> hi all !
[07:51] <peitschie> hiya vila :)
[08:10] <vila> peitschie: istm we're relaying online for quite a few days which in turn means one of us spend too much time online :-P
[08:13] <peitschie> vila: :$... perhaps lol
[08:13] <peitschie> vila: i'm 9-5 + home programming... wat's ur excuse? :P
[08:14] <vila> hmm, if you're online 8hrs does that mean I'm on for 16h.... eeerk ;)
[08:14] <peitschie> mmm... possible... prolly not tho lol
[08:14] <peitschie> i was 9am - 12am yesterday :$
[08:14] <peitschie> yeck... i need a life lol
[08:15] <vila> well, it *is* a life ;)
[08:17] <peitschie> true... i must say, i don't begrudge time spent hanging out here :)
[09:19] <jlebar> How can I use bzr's patience diff as a stand-alone diff program?
[09:24] <jlebar> Ah...I figured it out.
[09:24] <jlebar> PYTHONPATH=.
[09:24] <jlebar> indeed.
[15:13] <rom1> hello
[15:14] <rom1> i have a question : is it possible to retrieve a revision that is not linked anymore to a branch, and thus, is it possible to create a branch associated with this revision ?
[15:15] <rom1> i am in a shared repository enviroment
[15:22] <fullermd> Yes, you can init a new branch in the repo, then pull that rev from itself.
[15:22] <fullermd> e.g.: bzr init foo ; cd foo ; bzr pull -rWHATEVER .
[15:22] <fullermd> (don't miss the '.' at the end)
[15:33] <rom1> fullermd : you mean that we can retrieve any revision even if it is not part of the branch log ?
[15:33] <fullermd> If it's in the repository.
[15:33] <rom1> good to know !!
[15:33] <fullermd> It's just harder to find if it's not in a branch you have around.
[15:34] <rom1> it was my next question...
[15:34] <rom1> is there a way to do it ?
[15:34] <fullermd> Well, there's probably an API to list every rev in a repository.  Then it's just a lot of reading   ;)
[15:35] <fullermd> There's a 'heads' command in the bzrtools plugin you can list to list all the heads in the repo.  That's usually the way you go about it.
[15:35] <jelmer> fullermd: Repository.all_revision_ids()
[15:35] <rom1> ok, time to do a plugin !
[15:37] <rom1> i had this concreate case : on of my users did a push with --overwrite option, removing some revisions (that are not linked anymore to any branch). Of course, he required that i revert his mistake :)
[15:37] <rom1> Thx fullermd and jelmer
[15:37] <fullermd> Yeah, that's what heads is for.
[15:38] <fullermd> Two heads, really.  One command to find the revision, and his head to smack  ;)
[15:38] <rom1> :D
[15:45] <rubbs> if only I was allowed to smack the heads of some of my devs
[15:45] <rubbs> mainly my boss :/
[15:45] <fullermd> Oh, yes, in shops of any size, walking around smacking people is impractical.
[15:45] <fullermd> You have to design in network-controllable shock electrodes to the chairs from the get-go.  It's a nightmare trying to retrofit.
[15:52] <rubbs> good to know. I'll work on that. also I think it's time to propose a new bzr command: bzr dopeslap. I think it needs to add some metadata to a revision telling everyone that so and so broke everything.
[15:52] <rubbs> similar to annotate/blame
[16:46] <Glenjamin> hey guys, is there a way to get "bzr switch" to show me what changes are happening?
[16:52] <jelmer> Glenjamin: not really; though "bzr diff -rbranch:<thenewbranch>" should tell you what the changes will be.
[16:53] <Glenjamin> would it be complicated to add "bzr update" style output into "bzr switch -v" ?
[17:01] <jelmer> Glenjamin: not really, although I personally wouldn't want to see that output by default.
[17:01] <jelmer> (I tend to switch between unrelated branches)
[17:01] <Glenjamin> mm, but -v seems a reasonable place to put it
[17:01] <jelmer> yeah, a -v seems perfectly reasonable
[17:01] <Glenjamin> my use-case is a bunch of different demos on a server. which i switch between different branches
[17:02] <Glenjamin> it's handy to know if i need to re-run migrations
[17:03] <Glenjamin> i suppose i could use pull actually, and pull --overwrite when it switch
[17:10] <abentley> jam: what happens if I specify a bzr-history-db location in bazaar.conf, and then try to use a branch that I haven't run history-db-create on?
[17:34] <GaryvdM> rubbs: You can turn on append_revisions_only on your central branch to prevent that from happening again.
[17:34] <GaryvdM> http://doc.bazaar.canonical.com/development/en/user-reference/configuration-help.html#append-revisions-only
[17:35] <rubbs> GaryvdM: oh, I was more or less just joking. I havne't had that kind of issue... yet ;) but thanks, I'll take a look at it. It might be very helpfull for when we grow.
[18:00] <vila> rubbs: I'm sure I read some man page about a lart(1) command in emacs sources decades ago but I never found it again :-(
[18:01] <vila> rubbs: there were options like --AC or --DC, things like that
[18:01] <rubbs> heh
[18:03] <vila> rubbs: if you ever found it back, just ping me ;)
[18:03] <vila> s/found/find/ ?
[18:04] <rubbs> villa: will do, but I don't use emacs so the likelihood of me finding it is small.
[18:05] <vila> rubbs: in the mean time, you can use http://www.bofh.net/man/lart.1m.html
[18:06] <rubbs> oh nice. I"m totally going to use this ;)
[18:07] <vila> rubbs: wait ! There is also: http://www.bofh.net/man/bosskill.8.html
[18:08] <rubbs> oh nice, exactly what I needed ;)
[18:08] <fullermd> Yeah, there's a pile of those sort of manpages.  Used to be a dist called 'asrpages' of them.
[18:09] <GaryvdM> vila: lol lol lol - people are looking as if I'm weird.
[18:09] <fullermd> How do they look at you the rest of the time?
[18:10] <GaryvdM> like I'm weird....
[18:10] <GaryvdM> Just right the intensity is higher...
[18:12] <vila> hehe, does this mean this is your first exposure to BOFH ?
[18:12] <vila> man, how lucky you are, you've got *hours* of laugh ahead of you :)
[18:14] <fullermd> That's one way of looking at it.  The other is to tally up the hours you've spent reading it in your lifetime, and multiply it by your hourly rate, and ask how much it costs   :p
[18:15] <GaryvdM> Reminds me of "Who Is Joe Bloggs?" - http://www.techbookreport.com/whoisjb.html
[18:17] <vila> laugh is priceless :-D
[18:17] <fullermd> Well, they're really freakin' expensive.  That's the next best thing to priceless  :p
[20:02] <Buttons840> i've added many files to my working tree (just beginning, haven't commited r1 yet), and i want to remove some of the added files; how can i remove the added files from version management without doing a revert?
[20:06] <CcxCZ> bzr remove --keep
[20:09] <lifeless> Buttons840: bzr revert filename
[20:09] <lifeless> Buttons840: will take out of revision control and leave it behind (because the original state was 'present but unversioned'
[20:10] <Buttons840> when i do a revert it takes a really long time to process (it's a large project)
[20:22] <lifeless> of a single file ?
[20:49] <mgz> GaryvdM: I'm not here yet, but if you're still around could you look at bug 663957 and see if you kno of anything relevent that changed in the -3 installer?
[20:50] <GaryvdM> mgz: hi
[20:52] <GaryvdM> so it's mysteriously fixed
[20:53] <GaryvdM> mgz: it was failing with bzr-2.2.1-(-1)setup.exe - so it may have been fixed in -2 with the msvc*.dll changes...
[20:54] <GaryvdM> mgz: The only thing different between -2 and -3 is the BE version.
[21:49] <mgz> GaryvdM: and there was nothing else different between -1 and -2? Because I don't really see how the dll thing would have affected anything.
[21:50] <GaryvdM> mgz: nothing intentional.
[21:51] <GaryvdM> mgz: between -1 and -2, the ec2 host was shutdown, and I failed to get a snapshot.
[21:51] <mgz> ;_; I hate bugs that mysteriously vanish.
[21:51] <GaryvdM> for -1, we downgraded pyqt
[21:52] <GaryvdM> So I had to do that again for -2
[21:52] <GaryvdM> I also had to install pycrypto 2.3, and paramiko with my patch
[21:53] <GaryvdM> those 2 were changed for 2.2.0
[21:53] <GaryvdM> the ec2 host was on from the build of 2.2.0 till I built 2.2.1
[21:53] <poolie> hello all
[21:54] <GaryvdM> Hi poolie
[21:55] <GaryvdM> Maybe something was done to it during that time that caused that bug, and was reverted after.
[21:55] <GaryvdM> mgz ^
[21:55] <mgz> but... but... what?!
[21:55] <mgz> I guess I'll just have to close the bug and ask him to reopen if he ever runs into it again.
[21:56] <GaryvdM> mgz Is the bug the TransformRenameFailed, or the Unprintable exception?
[21:56] <mgz> the TransformRenameFailed.
[21:57] <mgz> something is causing a permission error on rename, reproducably.
[21:57] <mgz> this generally means the process has an open handle on either the source or the target/
[21:58] <GaryvdM> a windows sdk issue seems plausible to me.
[23:01] <peitschie> mornin everyone
[23:03] <mgz> what's bug 664990 ubot5?
[23:05] <GaryvdM> Hi peitschie
[23:07] <jbunting> mgz:  mistyped that bug # :-(  it's really 644990...description is fixed now...
[23:07] <peitschie> mornin garyvdm :)
[23:07] <mgz> ehe, okay jbunting
[23:08] <mgz> "file:///C:" is not actually a valid file url.
[23:08] <mgz> or at least explorer doesn't like it.
[23:10] <mgz> jbunting: you can use --fixes lp:BUGNUM when committing to get the branch to auto link the bug
[23:10] <jbunting> mgz:  cool...i can take the other direction on handling that form
[23:11] <jbunting> mgz: would that be preferred?
[23:13] <mgz> I think so, you basically want to check that it goes ("file:///", drive letter, colon, "/")
[23:13] <jbunting> alrighty
[23:14] <mgz> (for the case without a local host name)
[23:15] <mgz> ha, can use vertical bar rather than colon, didn't know that.
[23:17] <jbunting> i didn't either...
[23:18] <jbunting> mgz: so should i change the description for the merge proposal?
[23:19] <jbunting> mgz: or just add a comment?
[23:20] <mgz> a comment would be fine
[23:21] <mgz> nits just on the last rev, you added a tab rather than spaces, and rather commenting the previous test like could just delete it
[23:21] <mgz> otherwise looks good now.
[23:22] <mgz> you could uncommit from lp: and no one would ever notice :)
[23:22] <jbunting> doh...sounds like an excellent idea
[23:24] <mgz> I have done `bzr uncommit --force && bzr uncommit --force lp:...` more than once myself :)
[23:24] <mgz> evil, but works.
[23:25] <GaryvdM> or uncommit > fix > commit > push --overwrite
[23:25] <mgz> push --overwrite scares me, I've done silly things with it in the past
[23:29] <jbunting> all fixed
[23:29] <jbunting> and yes, uncommit seems evil
[23:30] <mgz> looks good!
[23:30] <mgz> last thing that'll need doing before this can land, while I have you,
[23:32] <mgz> read <http://www.canonical.com/contributors> and follow the directions
[23:32] <mgz> if you've got any queries about what it means, feel free to ask.
[23:32] <jbunting> will do
[23:52] <jbunting> mgz: project lead address - martin.pool@canonical.com ?
[23:52] <mgz> yup.
[23:52] <spiv> Yep
[23:52] <mgz> morning to you spiv.
[23:53] <jbunting> good deal, thanks for the help