[00:02] <lifeless> mwhudson: ui api changes
[00:02] <lifeless> mwhudson: silentuifactory is generally regarded as testing only so if you're using it in production you may need to fix it.
[00:03] <mwhudson> lifeless: all i was doing is calling run_bzr
[00:03] <mwhudson> but ok
[00:03] <mwhudson> anyway, i cribbed some code to set a ui factory and it works now
[00:03] <lifeless> mwhudson: oh, so the default 'call run_bzr' breaks now? I'd really like it if you file a bug about that.
[00:04] <mwhudson> lifeless: yes; ok
[00:06] <mwhudson> lifeless: https://bugs.edge.launchpad.net/bzr/+bug/499637
[00:09] <jelmer> poolie: No idea, sorry
[00:10] <jelmer> in general, CIFS shares should have the same semantics as NTFS drives
[00:21] <poolie> mwhudson: it does mean something to me
[00:21] <poolie> mwhudson: it means that you're calling code that wants to do an output stream but you've asked it to be silent
[00:21] <poolie> so you have to make up your mind :)
[00:21] <poolie> or fix one of these things
[00:22] <mwhudson> poolie: i haven't asked for it to be silent; that's the default
[00:22] <poolie> spiv: bug 495023 is nice :)
[00:22] <lifeless> poolie: I think you misread the no idea comment, it was from jelmer
[00:22] <lifeless> poolie: and I think SilentUI should eat an output stream :)
[00:22] <poolie> lifeless: no i didn't
[00:22] <spiv> poolie: if by nice you mean "signals are die die die" :)
[00:23] <spiv> s/are/argh/
[00:23] <spiv> (weird typo!)
[00:24] <scorp007> how do I change the submit branch that shows up in bzr info?
[00:24] <lifeless> poolie: ok
[00:24] <poolie> :)
[00:25] <lifeless> poolie: ah I see, it made sense to the earlier comment ;)
[00:25] <lifeless> scorp007: via bzr submit
[00:25] <scorp007> oh
[00:26] <scorp007> there's no such command? you mean send?
[00:27] <lifeless> yes
[01:02] <lifeless> poolie: and boom, it lands
[01:37] <lifeless> james_w: I've blogged about getting started with bzr-builddeb
[01:41] <lifeless> http://radar.oreilly.com/2009/12/the-best-and-the-worst-tech-of.html
[01:42] <lifeless> I love the quote about scrum-as-practiced :)
[02:40] <spiv> Launchpad should announce new merge proposals in this IRC channel.
[02:50] <mwhudson> spiv: statik has a thingummy that does that
[02:50] <mwhudson> (it works off email i guess)
[02:51] <spiv> Yeah, something email triggered would do I suppose.
[02:51] <spiv> I don't want to look after an IRC bot, I want someone else to do all the hard work :)
[02:53] <mwhudson> i suggest you talk to statik then
[02:53] <statik> yo
[02:53] <mwhudson> !
[02:53] <statik> all i had was a procmail rule the spit text at radix's publishbot
[02:54] <statik> niemeyers mup supports the same interface
[03:54] <mwhudson> poolie: where does make_uifactory_for_stream  live?
[03:54] <mwhudson> oh hang on, maybe the checkout i'm grepping is out of date
[03:54] <poolie> actually make_ui_for_terminal
[03:54] <poolie> in bzrlib.ui
[03:54] <mwhudson> ah ok
[03:54] <poolie> you know what i mean :)
[03:54] <mwhudson>     ui.ui_factory = ui.make_ui_for_terminal(
[03:54] <mwhudson>         sys.stdin, sys.stdout, sys.stderr)
[03:54] <mwhudson> doing this seems to work
[03:55] <mwhudson> (i cargo culted that from some where else)
[04:03] <poolie> jml, still around?
[04:34] <jml> poolie, yes.
[04:48] <Viper550> okay, used explorer to make a trunk "repository" on my hard drive for something, how do I push it up to lp?
[06:16] <poolie> lifeless: first test against testtools trunk and it fails with an AttributeError :/
[06:17] <lifeless> poolie: ugh :( pastebin ?
[06:18] <poolie>     self.exception_handlers.insert(0,
[06:18] <poolie> AttributeError: 'TestAdd' object has no attribute 'exception_handlers'
[06:19] <Peng> Oh? In what, lp:bzr?
[06:19] <lifeless> poolie: that indicates you have an old testtools version
[06:20] <lifeless> poolie: definitely not trunk, or 0.9.2
[06:20] <poolie> it does look like it
[06:20] <poolie> i'm pretty sure i have trunk
[06:20] <lifeless> python -c 'import testtools; print testtools.__file__'
[06:20] <poolie> ah maybe i have jml's old trunk
[06:21] <poolie> i thought you were going to check the version?
[06:26] <poolie> https://code.edge.launchpad.net/~mbp/bzr/trivial/+merge/16525
[06:26] <poolie> bit of a bug in lp that this can happen
[06:28] <lifeless> that what can happen?
[06:28] <poolie> that i can do 'bzr pull' in a checkout of testtools trunk, but not get what's the new trunk
[06:28] <lifeless> yes
[06:28] <poolie> this can be seen as a bug in putting the owner into the url
[06:29] <lifeless> if jml had moved the branch you would have gotten an error
[06:29] <poolie> right
[06:29] <lifeless> I consider the bug to be bzr storing the resolved branch though
[06:29] <spiv> Well, there can be more than one bug :)
[06:29] <poolie> anyhow
[06:29] <lifeless> spiv: true, but I *like* owner in url :P
[06:29] <poolie> does it?
[06:30] <lifeless> spiv: I'll agree to 'side effect'
[06:30] <poolie> i guess it does, though it's possible i just used the full url originally
[06:30] <poolie> anyhow
[06:30] <poolie> i am glad this is in
[06:30] <poolie> i'd like to tweak the display to show errors as they happen
[06:30] <poolie> and that's better done not specific to bzr
[06:30] <lifeless> poolie: yes, bzr branch lp:foo -> parent will be bzr+ssh://b.l.n/foo/~bar/baz
[06:30] <poolie> assuming it can be merged
[06:31] <lifeless> poolie: so, errors showing as they happen - change bzr's reporter to not use the 'current global ui factory' and instead cache the ui factory it is started with.
[06:32] <poolie> ok
[06:32] <poolie> that sounds good
[06:32] <lifeless> poolie: tests running with silent ui are hiding reporting of things via note() - I saw this, but its an orthogonal change to the root class
[06:32] <poolie> what's the connection?
[06:32] <poolie> ah
[06:34] <lifeless> if you run with --parallel=fork, the global ui isn't ever changed, and the current encoded behaviour can be seen. With a normal run, things get masked.
[06:34] <lifeless> poolie: btw you can use the testtools packages in the beta ppa - or install the subunit releases ppa and get subunit and testtools from there.
[06:35] <poolie> i know
[06:35] <lifeless> poolie: I'm happy for you to run from trunk of these dependencies, just want to be sure you know its optional.
[06:35] <poolie> but i may actually patch them
[06:35] <poolie> so (barely) slightly easier to start with branches
[06:35] <lifeless> poolie: sure. They both have bzr packaging branches, so you can patch with packages too :)
[06:36] <lifeless> poolie: fwiw I run from packages on them, regardless of patched-or-not, it just works out easier overall, I think.
[06:37] <poolie> definitely helps by the time there are binaries
[06:40] <lifeless> Someone next year I'll do the 'include the failed test work area' patch
[06:40] <lifeless> using the addOnException TestCase api to add a tarball detail
[06:41] <lifeless> s/Someone/Sometime/
[07:04] <lifeless> poolie: well, I find it has a bunch of benefits; I find out about things that would make packaging harder (such as files not included in the tarball) early;
[07:04] <lifeless> I don't need to remember to set the python path
[07:04] <poolie> true
[07:04] <poolie> ok, maybe i'll build from them
[07:04] <lifeless> and I don't need to futz with a local python install getting in the way in the future.
[07:04] <poolie> k
[07:05] <poolie> signing off soon
[07:07] <lifeless> see you in the new year
[07:17] <spiv> Ok, I'm off too.
[07:22]  * lifeless sniffs
[07:23] <lifeless> I can't tell from here
[07:23] <lifeless> Peng: new test dependency
[07:23]  * Peng nods
[07:35] <lifeless> Peng: its in lucid, or the bzr-beta-ppa
[07:36] <Peng> I've got it from source.
[07:43] <lifeless> kk
[07:55] <Fleabag> hi
[08:11] <Peng> I like playing with --parallel, so I already needed it anyway. :P
[08:11] <Peng> Besides, I don't run the test suite much.
[08:19] <lifeless> Peng: :P
[08:22] <Peng> I should probably RTFM, but: subunit is a superset of testtools, right? And bzr now always depends on testtools, but only uses subunit for --parallel, right?
[08:22] <lifeless> subunit is orthogonal to testtools
[08:22] <Peng> It doesn't depend on testtools?
[08:22] <lifeless> it does
[08:23] <lifeless> so its a superset in the same way that bzrlib is a superset of testtools :)
[08:23] <Peng> Heh, okay.
[08:24] <lifeless> subunit is: a protocol definition, serialiser in [languages], parser in [languages] and command line filters for the protocol.
[08:29] <Peng> Oooh.
[08:36] <lifeless> e.g. see libcppunit-subunit-dev - link that in and use it as your test reporter, and you can use subunit-filter,subunit-stats, subunit-tags etc with your favourite cppunit using test suite.
[08:36] <lifeless> and even subunit-diff
[08:51] <ronny> lifeless: is there any buildin sheduling  in subunit
[08:51] <ronny> (i.e. choosing what tests get executed)
[08:52] <lifeless> ronny: no, but it encourages an idiom of having unique ids for tests, and you can use subunit-ls to turn a stream into a \n separated list of test ids
[08:52] <lifeless> which works very will with runners that support choosing based on test id (such as bzr, or zopes test runner)
[08:53] <lifeless> ronny: however, the python 'subunit.run' module can select tests with whatever granularity you give it. It would be appropriate for that module to gain a --load-list feature, I think.
[08:54] <lifeless> ronny: (wouldn't help non-python runners, but would be convenient for python folk)
[08:55] <ronny> lifeless: im thinking in terms of 2-way communication in ad-hoc networks
[08:57] <lifeless> ronny: subunit itself is unidirectional, but it should play nice in larger systems that do 2-way stuff (an example of which is vilas patch to bzr selftest --parallel to feed small chunks to the worker processes)
[08:57] <ronny> at least thats what we want to build for py.test and possibly others
[08:57] <lifeless> ronny: sure, I'd be delighted to see subunit as part of that
[08:58] <ronny> lifeless: does it have separate message lines for collect/discover and run?
[08:58] <lifeless> it doesn't have the first two concepts
[08:59] <ronny> then there is little use for it
[08:59] <lifeless> I think thats a premature opinion
[08:59] <lifeless> for several reasons
[09:00] <lifeless> firstly, subunit passes things it doesn't understand through, so you can embed it in other protocols without needing special out-of-band signalling
[09:01] <lifeless> secondly, setup and control of a test process is a very different problem to machine readable output from the test process; its the latter that subunit provides (and pretty nicely now, I think).
[09:02] <lifeless> lastly, setting up a remote process isn't a test protocol problem, its a remote execution problem, and there are plenty of tools to do that today, so I don't see why you'd want to write it again :)
[09:02] <lifeless> the other test protocols around:
[09:02] <lifeless> pandokia
[09:02] <lifeless> tap
[09:03] <lifeless> junit-xml
[09:03] <lifeless> none of them provide for setting up a remote process
[09:03] <lifeless> (pandokia in aggregate does, but not in its test description format)
[09:05] <ronny> hmm
[09:05] <ronny> i suppose i really ought to take another look
[09:06] <ronny> discovery/feedback will be an important part tho
[09:06] <lifeless> I never said it wasn't important :)
[09:06] <lifeless> what do you mean by feedback
[09:06] <lifeless> you said collect/discovery before
[09:07] <ronny> lifeless: test nodes report the tests they discover, the node manager gives feedback on if they should run it
[09:07] <lifeless> ronny: why do it that way?
[09:08] <ronny> the set of tests that gets run depends on the platform/environment
[09:08] <lifeless> sure
[09:08] <lifeless> but that doesn't imply chatty protocols
[09:10] <ronny> lifeless: well, parallelize test-runs over a ad-hoc network and it suddenly gets handy
[09:11] <ronny> something needs to keep track of what tests had been executed
[09:11] <lifeless> ronny: here is a different way: master node calculates all tests, inspects for machine requirements, partitions by available machines and their info
[09:12] <ronny> thats a lot more tricky than just letting things happen and react according to that
[09:13] <lifeless> anyhow.. here is how you can do the approach you have in mind with subunit easily
[09:14] <lifeless> from the node send "available: id\n" to advertise a test that can be run
[09:14] <lifeless> on the node read "run: id\n" to run a test, and EOF  to shutdown the node
[09:15] <ronny> yes, thats along what i was thinking
[09:15] <ronny> lifeless: feel like adding that as optional extension to subunit, so runners for other languages can add it?
[09:16] <lifeless> on the master, hook each nodes output up to either a subunit.ProtocolTestCase or subunit.TestProtocolServer (if you are running twisted or asyncore you'll want the second)
[09:16] <ronny> lifeless: we'll most likely be using execnet at least for the setup
[09:16] <lifeless> to hook it up, use
[09:17] <lifeless> parser = ProtocolTestCase(stream, passthrough=extra)
[09:17] <lifeless> where extra is a closure with a write method,
[09:17] <lifeless> that write method will get called with "available: id\n" and any other extensions you have.
[09:18] <lifeless> and to kick if off with ProtocolTestCasse, do run(masterresultobject)
[09:18] <lifeless> using the TestProtocolServer is slightly different, but not much.
[09:18] <lifeless> you need to arrange to call lineReceived for it.
[09:19] <lifeless> ronny: are you saying 'reserve the token "available" so that other folk doing similar things might choose the same token'?
[09:19] <ronny> lifeless: yes
[09:19] <lifeless> ronny: If so, I'm happy to note that your project is doing this in the subunit docs
[09:19] <ronny> also the token run
[09:19] <lifeless> ronny: subunit won't see the token run at all
[09:20] <lifeless> ronny: subunit is unidirectional
[09:20] <ronny> lifeless: just as note in the docs, so other folks know the feedback protocol
[09:20] <lifeless> sure
[09:20] <ronny> well, actually run and skip
[09:20] <lifeless> ronny: why would you need skip ?
[09:21] <lifeless> ronny: only tell it to run things you want it to run :)
[09:21] <ronny> lifeless: then the collect/run parts would have to be async
[09:22] <lifeless> I don't see the connection.
[09:23] <lifeless> ronny: so, I think a document describing what you're doing and how it hangs together would be great; that could be either included in subunit, or referenced from subunits docs, depending on how you write it and what focus you put in it.
[09:23] <lifeless> ronny: one thing I've been considering doing is making subunit easier to install with e.g. pip or easy_install.
[09:24] <lifeless> ronny: I mention this in case ease of install comes up for you.
[09:24] <ronny> lifeless: please do that, we'll most likely use virtualenvs
[09:27] <ronny> lifeless: as far as i remember various testrunners execute tests as they find them, and dont collect the whole suite before starting test runs
[09:27] <lifeless> ronny: only nose does that
[09:27] <lifeless> ronny: you can use a lazy loader to do that in any unittest runner that can run a callable (e.g. via the test_suite idiom)
[09:29] <ronny> thats why a skip directive would be helpfull
[09:29] <lifeless> ronny: sorry, I still don't follow
[09:29] <ronny> just report what you find as you go, and get feedback on if you should run the tests
[09:30] <lifeless> ronny: yes, I get that, but I don't see why you need a skip directive on the control side
[09:30] <ronny> i dont like having to guess the dont cases
[09:31] <lifeless> seems like a waste to me, but sure, I can see how it would work
[09:31] <ronny> i want to have a simple sync loop along while test=find_next() { report; read action; if action { run }}
[09:32] <lifeless> I think that would be very slow
[09:32] <lifeless> I'd do
[09:32] <lifeless> tests = find_all()
[09:32] <lifeless> advertise_tests(tests)
[09:32] <lifeless> to_run = (read all run: commands)
[09:32] <lifeless> tests.filter(to_run)
[09:32] <lifeless> run_tests(tests)
[09:33] <lifeless> well, with the last three lines in a loop
[09:33] <ronny> lifeless: i dont want to tell them all to run at a time
[09:33] <lifeless> read one or more run commands, execute, look for more
[09:34] <lifeless> ronny: sure, but that is orthogonal to discovering them all at once, isn't it ?
[09:34] <ronny> i like more granular events tho
[09:34] <lifeless> ronny: I have some experience with this, having done --parallel and --parallel=ec2 for bzr; you really don't want to be waiting for network latency on each test
[09:35] <ronny> hmk
[09:35] <lifeless> if you have enough tests that multi machine parallelisation is worth doing, per test latency will kill your performance.
[09:35] <lifeless> unless your tests are several times slower than that latency
[09:37] <ronny> hmm, well, mine probably are, but other are most likely not
[09:44] <ronny> lifeless: i just discovered that mine and holgers mindmodels rather differ (his already solved the latency stuff, i suppose other issues as well)
[09:45] <lifeless> well, mail me :) or t-i-p, or something :)
[09:47] <ronny> lifeless: yes, i'll get my mindmodel fixed, then i suppose start something on tip
[11:52] <Kamping_Kaiser> hi all, sorry if this is covered in a faq:
[11:53] <Kamping_Kaiser> can i pull in a file from a repository which *does not* share a common ancestor with my current branch?
[11:53] <Kamping_Kaiser> (keeping history)
[12:00] <spiv> Kamping_Kaiser: you can merge in an entire, unrelated branch.  bzr in general can't track revision history when cherrypicking just parts of revisions (like single files rather than all changes)
[12:02] <Kamping_Kaiser> spiv: the branch is 1 script + a README, as long as the merge doesn't eat my existing README that would be fine for me.
[12:03] <spiv> Kamping_Kaiser: cool
[12:03] <spiv> Kamping_Kaiser: the trick then is "bzr merge -r0..-1 ../unrelated_branch
[12:03] <spiv> "
[12:03] <Peng> Kamping_Kaiser: The README will probably conflict. Anyway, even if it does get eaten, nothing's set in stone until you commit; you can just revert it.
[12:04] <spiv> it'll probably give a path conflict about the README file; they'll both be there (one will be README, the other README.moved, probably)
[12:04] <Kamping_Kaiser> spiv: if i understand that correctly, from revision 0 until latest revision?
[12:04] <Peng> Kamping_Kaiser: Uh-huh.
[12:05] <spiv> you can 'bzr mv' and/or 'bzr rm' things before committing of course to make sure they are how you want them.
[12:05] <Kamping_Kaiser> Peng: re README, noted, I'll try and see what happens.
[12:05] <Kamping_Kaiser> Conflict adding file README.  Moved existing file to README.moved.
[12:05] <spiv> Kamping_Kaiser: right.  The zeroth "revision" is in a sense a common ancestor for all branches :)
[12:05] <Kamping_Kaiser> *grin*
[12:06] <Kamping_Kaiser> I'm interested that the existing readme is moved, rather then the new one.
[12:07] <spiv> Yeah, I'm not sure why that choice was made.  Possibly a coin toss came up heads rather than tails when the implementer had to choose ;)
[12:08] <Kamping_Kaiser> hehe.
[12:08] <spiv> I must admit I tend to find it backwards to my expectations most of the time too.
[12:08] <Kamping_Kaiser> I'll resist the urge to pontificate about what I think shoul happen instead, since I won't be offering patches ;)
[12:09] <spiv> Kamping_Kaiser: you can always file bugs or post to the list :)
[12:09] <spiv> Anyway, I'm off to bed.  I'm glad that that merge seems to have worked for you.
[12:10] <Kamping_Kaiser> thanks for that, sleep well
[13:12] <rubbs> Morning
[13:54] <Viper550> okay, I got a local repository. I'm using Windows. How would I push it up to Launchpad?
[14:04] <rubbs> Viper550: are you trying to contribute to a specific project?
[14:04] <Viper550> yeah, trying to bring it up to my project
[14:05] <rubbs> what is your project's name.
[14:07] <Viper550> lp:~viper550/bbesque/platypus
[14:07] <Viper550> I can explain the name "platypus" though :P
[14:09] <rubbs> no need... just a sec, and I can help you out.
[14:12] <rubbs> ok, so you've got a branch you want to push to the bbesque project. The simplest way to do that is to say "bzr push lp:~viper550/bbesque/branch-name" where branch name is whatever you want (platypus I think is what you got).
[14:12] <rubbs> you will need to set up some ssh keys and get them working with pagent
[14:12] <rubbs> do you know how to do that?
[14:12] <rubbs> I could help you out with that if you don't
[14:13] <Viper550> dunno
[14:13] <rubbs> k... do you have putty installed?
[14:14] <rubbs> if not go here: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html and download the link under "A Windows installer for everything except PuTTYtel"
[14:15] <Viper550> done
[14:15] <rubbs> once you have the putty suite installed, you need to generate some ssh keys.
[14:16] <Viper550> puttygen?
[14:16] <rubbs> yep
[14:17] <rubbs> https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair?action=show&redirect=CreatingAnSSHKeyPair
[14:20] <rubbs> let me know when you are ready for more info.  I'll brb.
[14:21] <Viper550> done
[14:23] <Viper550> rubbs: done the pagent part
[14:35] <rubbs> Viper550: sorry about being away for so long.
[14:36] <rubbs> so if you've added your keys to pagent and added the key to launchpad you should be able to just push to the location. like this: bzr push lp:~viper550/bbesque/branch-name
[14:37] <Viper550> can it be done through a GUI?
[14:37] <rubbs> yes
[14:37] <Viper550> okay...how? I got Bazaar Explorer open with my local branch
[14:37] <rubbs> I'm looking up exatly how to do it... shouldn't take me more than a sec
[14:39] <rubbs> Viper550: when you push, you should be able to just put "lp:~viper550/bbesque/branch-name" into the "location" text field
[14:40] <Viper550> bzr: ERROR: Parent directory of bzr push lp:~viper550/bbesque/platypus does not exist.
[14:41] <Viper550> wait whoops
[14:41] <Viper550> "You have not informed bzr of your Launchpad ID"
[14:41] <rubbs> Oh, k... sorry forgot that step myself. just a sec I'll find out where yo uset that
[14:43] <rubbs> under settings -> credentials
[14:43] <rubbs> you need to have an entry like this:
[14:43] <rubbs> [Launchpad]
[14:43] <rubbs> host = .launchpad.net
[14:43] <rubbs> scheme = ssh
[14:43] <rubbs> user = patrick-regan
[14:44] <rubbs> er... sorry others out there, forgot to pastebin
[14:45] <jelmer_> rubbs: Running "bzr lp-login patrick-regan" should create that for you
[14:46] <rubbs> jelmer_ I know, but he was asking on how to do this with bzr explorer
[14:51] <LeoNerd> Is it possible to define an alias command including a shell fragment? e.g. I'd love to define   bzr diffstat =>  bzr diff | diffstat
[14:55] <Viper550> yay got it
[14:57] <rubbs> Viper550: cool glad you got it working. it should be easier from now on
[14:57] <rubbs> come back if you have any other questions.
[14:58] <Viper550> thanks :)
[15:00] <rubbs> np
[15:03] <rubbs> LeoNerd: I don't think that's possible
[15:03] <rubbs> LeoNerd: you could alias that at the shell level though
[15:06] <LeoNerd> Yeah, I know... but doing it in bzr itself would be cute :)
[15:07] <rubbs> LeoNerd: agreed. I pretty sure it's not possible (at this point) though.
[15:08] <LeoNerd> Ahwell.. no great problem..
[15:29] <LaserJock> quick question: how do I set my commit email address on a directory basis?
[15:30] <LaserJock> can I do it from the command line or do I have to mess with ~/.bazaar/locations.conf
[15:35] <rubbs> LaserJock: use the --branch option on the whoami command
[15:35] <rubbs> see "bzr help whoami" for more info
[15:49] <LaserJock> rubbs: ah, I thought I could just be in the dir and run bzr whoami
[15:49] <LaserJock> rubbs: switching to an actual branch in the dir and using --branch solved the mystery :-)
[15:49] <rubbs> LaserJock: good to hear that helped.
[15:50] <rubbs> the problem with whoami working on the dir level only is that you have to go out of a branch then to set it globally.
[15:50] <rubbs> that and most people use the global email for most/all of their projects.
[15:50] <rubbs> but I can see where you came up with that...
[15:51] <rubbs> I'll see about the documentation... Maybe somethign needs to be clarified.
[15:54] <LaserJock> rubbs: I guess I was going by "if there was a branch right here what would it use?"
[15:57] <rubbs> LaserJock:
[15:58] <rubbs> er... LaserJock: I see. I'll look into that
[17:26] <LaserJock> does olive-gtk visualize the relationship between branches in a repo?
[17:28] <rubbs> LaserJock: not as well as qlog or explorer (which uses qlog).
[17:28] <rubbs> LaserJock: qlog is part of the qbzr plugin
[17:38] <LaserJock> oh dang it, how do I make a file I just did a bzr add to untracked again? I haven't committed yet
[17:39] <jpds> LaserJock: bzr remove --keep $file
[19:03] <beuno> I forgot how much I liked bzrlib
[19:03] <beuno> 90% of the time it's already solved a problem I'm trying to solve
[19:18] <lifeless> \o/
[19:18] <lifeless> merry christmas beuno
[19:18] <beuno> hey lifeless
[19:18] <beuno> merry christmas to you
[19:19] <beuno> even more so considering you're in the future
[19:19] <lifeless> -> plane to catch  :) ciao
[19:20] <beuno> lifeless, have a great flight
[19:20] <mneptok> Manny Krramer!
[19:48] <jwhitley> is there an equivalent of git-filter-branch for bzr?  I can fast-export/fast-import, of course, but it'd be nice to stay in bzr if possible.
[19:49] <jwhitley> use case: I have a repo which I've tried to deliberately keep fairly small.  I now realize that some time ago I inadvertently committed some directories with contents much larger than I'd like.
[19:49] <rubbs> jwhitley: so really you just want to strip out some stuff from your history?
[19:49] <jwhitley> It happens to be practical to rewrite the repo history (it's a personal and private repo, so far), FWIW.
[19:49] <jwhitley> rubbs: yes, precisely.
[19:50] <rubbs> just a sec... someone yesterday was asking the same thing. I'll look through my logs and see what the best answers where
[19:50] <jwhitley> lovely, thanks.
[19:53] <rubbs> jwhitley: http://irclogs.ubuntu.com/2009/12/21/%23bzr.html check the post from 20:40 (time) on. I think that may be what you're looking for
[19:55] <jwhitley> rubbs: outstanding, just what I needed.  thanks!
[19:56] <rubbs> np
[22:35] <chromakode> hey bzr folks, are "oh no my repo is broken" inquiries acceptable here?
[22:35] <chromakode> I am a bzr noob who upgraded a lp: branch, and managed to break it somehow.
[22:36] <chromakode> le google is not currently turning up useful advice.
[22:37] <chromakode> ah, you know what? I think I followed some bad bug report advice and changed a stacking branch to a non-stacking format
[22:39] <gutworth> how is it broken?
[22:39] <maxb> chromakode: If you explain more about what exactly you did and what's broken, someone here can probably help
[22:39] <chromakode> thanks. didn't want to bug you if this was an inappropriate channel
[22:39] <chromakode> any operation [upgrade,check] fails with "RepositoryFormatKnitPack4 ... is not a stackable format."
[22:40] <chromakode> trying `push --overwrite` yields "(Bazaar pack repository format 1 with rich root (needs bzr 1.0)) is not a stackable format"
[22:40] <gutworth> what's bzr info?
[22:41] <maxb> stacking was added in 1.6, aka KnitPack5
[22:41] <chromakode> I believe my original sin was running `bzr upgrade --rich-root-pack lp:myrepo`
[22:41] <chromakode> (lp:myrepo was 2a, I believe)
[22:41] <chromakode> gutworth, bzr info returns the same "(Bazaar pack repository format 1 with rich root (needs bzr 1.0)) is not a stackable format"
[22:41] <maxb> and stacked?
[22:41] <chromakode> maxb, yes.
[22:42] <maxb> is this a public branch?
[22:42] <chromakode> public how so?
[22:42] <chromakode> it's on launchpad: lp:~chromakode/drizzle-interface/dbapi
[22:42] <chromakode> so, my local branch was in a repo
[22:42] <vadi21> I remember there being a "bzr release" command... but apparently I'm mistaken. What is the proper command name?
[22:43] <chromakode> and I think what happened was that I needed to upgrade my repo. however, I googled and saw the `bzr upgrade --rich-root-pack lp:myrepo` command, which probably borked my remote format
[22:44] <maxb> chromakode: Launchpad has a rather peculiar way of storing branches - it has a public and a writable copy. So it might be simplest for you to simply branch the public copy, which is still intact
[22:45] <maxb> If you try accessing it over http, you'll end up at the public copy, since http branch access is unauthenticated
[22:45] <vadi21> got it, bzr export
[22:52] <chromakode> maxb, I think my local branch is in order, but it seems like any operations on the lp branch will break. should I just throw out the lp branch using the web interface, and remake it?
[22:53] <maxb> chromakode: Either that, which will wipe metadata such as bug<->branch links, or subscriptions, or, you could delete just the branch files using an sftp client, and re-push
[22:54] <chromakode> maxb, sounds good. so, just for the learning experience, my fault was downgrading the repo to a non-stacking format?
[22:54] <maxb> Sounds like that
[22:54] <maxb> Though one could say it's bzr's fault for not shrieking loudly and refusing
[22:55] <chromakode> I might claim that if I wasn't a nice user ;)
[23:05] <igc1> morning
[23:31] <AfC> Does bzr-git do git SSH URLs?
[23:31] <AfC> I tried the URL I was given [ ssh://<username>@git.gnome.org/git/gtk+ ] and Bazaar gave me a helpful error message about how I had to use bzr+ssh:// as the protocol
[23:32] <AfC> So then I tried git+ssh and it didn't work.
[23:32] <AfC> So presumably my answer is "no" but perhaps I'm missing something?
[23:35] <RAOF> AfC: It does, yes.
[23:35] <RAOF> I forget quite how I managed to make it happen, though.
[23:36] <poolie> hi all
[23:36] <RAOF> AfC: I'd guess you'd be after a URI of the form git+ssh://git@gitorious.org/~raof/banshee/gapless-work.git
[23:37] <AfC> RAOF: Hm. I thought I'd tried that.
[23:37] <poolie> afc: looking at the code, git+ssh should work
[23:39] <AfC> poolie: ok, thanks!
[23:39]  * AfC tries again
[23:41] <AfC> Ok, so I have no idea what happened there. I did
[23:41] <AfC> $ bzr branch git+ssh://afcowie@git.gnome.org/git/gnote/ master
[23:41] <AfC> and it worked
[23:42] <AfC> so... well, er
[23:42] <AfC> thanks?
[23:42] <AfC> :)
[23:42] <AfC> [I had previously tried with the gtk+ URL and it crashed]
[23:42] <AfC> [though I also tried a git:// URL and that crashed too]
[23:43] <AfC> [so I'm guessing someone fixed something and did a release and got it into the PPA? Either way, thanks!]
[23:52] <RAOF> Now all bzr-git needs is a way to specify non-master branches!