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:02 |
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:03 |
mwhudson | lifeless: yes; ok | 00:04 |
mwhudson | lifeless: https://bugs.edge.launchpad.net/bzr/+bug/499637 | 00:06 |
ubottu | Ubuntu bug 499637 in bzr "run_bzr() fails unless you set a ui factory" [Undecided,New] | 00:06 |
jelmer | poolie: No idea, sorry | 00:09 |
jelmer | in general, CIFS shares should have the same semantics as NTFS drives | 00:10 |
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:21 |
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 |
ubottu | Launchpad bug 495023 in bzr "Interrupting commit to smart server sometimes removes files" [High,Confirmed] https://launchpad.net/bugs/495023 | 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:22 |
spiv | s/are/argh/ | 00:23 |
spiv | (weird typo!) | 00:23 |
scorp007 | how do I change the submit branch that shows up in bzr info? | 00:24 |
lifeless | poolie: ok | 00:24 |
poolie | :) | 00:24 |
lifeless | poolie: ah I see, it made sense to the earlier comment ;) | 00:25 |
lifeless | scorp007: via bzr submit | 00:25 |
scorp007 | oh | 00:25 |
scorp007 | there's no such command? you mean send? | 00:26 |
lifeless | yes | 00:27 |
lifeless | poolie: and boom, it lands | 01:02 |
=== abentley1 is now known as abentley | ||
lifeless | james_w: I've blogged about getting started with bzr-builddeb | 01:37 |
lifeless | http://radar.oreilly.com/2009/12/the-best-and-the-worst-tech-of.html | 01:41 |
lifeless | I love the quote about scrum-as-practiced :) | 01:42 |
spiv | Launchpad should announce new merge proposals in this IRC channel. | 02:40 |
mwhudson | spiv: statik has a thingummy that does that | 02:50 |
mwhudson | (it works off email i guess) | 02:50 |
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:51 |
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:53 |
statik | niemeyers mup supports the same interface | 02: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:54 |
mwhudson | (i cargo culted that from some where else) | 03:55 |
poolie | jml, still around? | 04:03 |
jml | poolie, yes. | 04:34 |
Viper550 | okay, used explorer to make a trunk "repository" on my hard drive for something, how do I push it up to lp? | 04:48 |
poolie | lifeless: first test against testtools trunk and it fails with an AttributeError :/ | 06:16 |
lifeless | poolie: ugh :( pastebin ? | 06:17 |
poolie | self.exception_handlers.insert(0, | 06:18 |
poolie | AttributeError: 'TestAdd' object has no attribute 'exception_handlers' | 06:18 |
Peng | Oh? In what, lp:bzr? | 06:19 |
lifeless | poolie: that indicates you have an old testtools version | 06:19 |
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:20 |
poolie | i thought you were going to check the version? | 06:21 |
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:26 |
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:28 |
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:29 |
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:30 |
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:31 |
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:32 |
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:34 |
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:35 |
lifeless | poolie: fwiw I run from packages on them, regardless of patched-or-not, it just works out easier overall, I think. | 06:36 |
poolie | definitely helps by the time there are binaries | 06:37 |
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:40 |
lifeless | s/Someone/Sometime/ | 06:41 |
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:04 |
poolie | signing off soon | 07:05 |
lifeless | see you in the new year | 07:07 |
spiv | Ok, I'm off too. | 07:17 |
* lifeless sniffs | 07:22 | |
lifeless | I can't tell from here | 07:23 |
lifeless | Peng: new test dependency | 07:23 |
* Peng nods | 07:23 | |
lifeless | Peng: its in lucid, or the bzr-beta-ppa | 07:35 |
Peng | I've got it from source. | 07:36 |
lifeless | kk | 07:43 |
Fleabag | hi | 07:55 |
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:11 |
lifeless | Peng: :P | 08:19 |
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:22 |
lifeless | so its a superset in the same way that bzrlib is a superset of testtools :) | 08:23 |
Peng | Heh, okay. | 08:23 |
lifeless | subunit is: a protocol definition, serialiser in [languages], parser in [languages] and command line filters for the protocol. | 08:24 |
Peng | Oooh. | 08:29 |
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:36 |
ronny | lifeless: is there any buildin sheduling in subunit | 08:51 |
ronny | (i.e. choosing what tests get executed) | 08:51 |
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:52 |
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:53 |
lifeless | ronny: (wouldn't help non-python runners, but would be convenient for python folk) | 08:54 |
ronny | lifeless: im thinking in terms of 2-way communication in ad-hoc networks | 08:55 |
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:57 |
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:58 |
ronny | then there is little use for it | 08:59 |
lifeless | I think thats a premature opinion | 08:59 |
lifeless | for several reasons | 08:59 |
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:00 |
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:01 |
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:02 |
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:03 |
ronny | hmm | 09:05 |
ronny | i suppose i really ought to take another look | 09:05 |
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:06 |
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:07 |
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:08 |
ronny | lifeless: well, parallelize test-runs over a ad-hoc network and it suddenly gets handy | 09:10 |
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:11 |
ronny | thats a lot more tricky than just letting things happen and react according to that | 09:12 |
lifeless | anyhow.. here is how you can do the approach you have in mind with subunit easily | 09:13 |
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:14 |
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:15 |
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:16 |
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:17 |
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:18 |
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:19 |
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:20 |
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:21 |
lifeless | I don't see the connection. | 09:22 |
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:23 |
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:24 |
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:27 |
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:29 |
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:30 |
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:31 |
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:32 |
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:33 |
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:34 |
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:35 |
ronny | hmm, well, mine probably are, but other are most likely not | 09:37 |
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:44 |
lifeless | well, mail me :) or t-i-p, or something :) | 09:45 |
ronny | lifeless: yes, i'll get my mindmodel fixed, then i suppose start something on tip | 09:47 |
Kamping_Kaiser | hi all, sorry if this is covered in a faq: | 11:52 |
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) | 11:53 |
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:00 |
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:02 |
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:03 |
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:04 |
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:05 |
Kamping_Kaiser | I'm interested that the existing readme is moved, rather then the new one. | 12:06 |
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:07 |
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:08 |
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:09 |
Kamping_Kaiser | thanks for that, sleep well | 12:10 |
rubbs | Morning | 13:12 |
Viper550 | okay, I got a local repository. I'm using Windows. How would I push it up to Launchpad? | 13:54 |
rubbs | Viper550: are you trying to contribute to a specific project? | 14:04 |
Viper550 | yeah, trying to bring it up to my project | 14:04 |
rubbs | what is your project's name. | 14:05 |
Viper550 | lp:~viper550/bbesque/platypus | 14:07 |
Viper550 | I can explain the name "platypus" though :P | 14:07 |
rubbs | no need... just a sec, and I can help you out. | 14:09 |
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:12 |
Viper550 | dunno | 14:13 |
rubbs | k... do you have putty installed? | 14:13 |
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:14 |
Viper550 | done | 14:15 |
rubbs | once you have the putty suite installed, you need to generate some ssh keys. | 14:15 |
Viper550 | puttygen? | 14:16 |
rubbs | yep | 14:16 |
rubbs | https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair?action=show&redirect=CreatingAnSSHKeyPair | 14:17 |
rubbs | let me know when you are ready for more info. I'll brb. | 14:20 |
Viper550 | done | 14:21 |
Viper550 | rubbs: done the pagent part | 14:23 |
=== Noldorin is now known as Noldorin2 | ||
=== Noldorin2 is now known as Noldorin | ||
rubbs | Viper550: sorry about being away for so long. | 14:35 |
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:36 |
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:37 |
rubbs | Viper550: when you push, you should be able to just put "lp:~viper550/bbesque/branch-name" into the "location" text field | 14:39 |
Viper550 | bzr: ERROR: Parent directory of bzr push lp:~viper550/bbesque/platypus does not exist. | 14:40 |
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:41 |
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:43 |
rubbs | er... sorry others out there, forgot to pastebin | 14:44 |
jelmer_ | rubbs: Running "bzr lp-login patrick-regan" should create that for you | 14:45 |
rubbs | jelmer_ I know, but he was asking on how to do this with bzr explorer | 14:46 |
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:51 |
Viper550 | yay got it | 14:55 |
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:57 |
Viper550 | thanks :) | 14:58 |
rubbs | np | 15:00 |
rubbs | LeoNerd: I don't think that's possible | 15:03 |
rubbs | LeoNerd: you could alias that at the shell level though | 15:03 |
LeoNerd | Yeah, I know... but doing it in bzr itself would be cute :) | 15:06 |
rubbs | LeoNerd: agreed. I pretty sure it's not possible (at this point) though. | 15:07 |
LeoNerd | Ahwell.. no great problem.. | 15:08 |
LaserJock | quick question: how do I set my commit email address on a directory basis? | 15:29 |
LaserJock | can I do it from the command line or do I have to mess with ~/.bazaar/locations.conf | 15:30 |
rubbs | LaserJock: use the --branch option on the whoami command | 15:35 |
rubbs | see "bzr help whoami" for more info | 15:35 |
=== pass is now known as kriss | ||
=== kriss is now known as krissn | ||
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:49 |
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:50 |
rubbs | I'll see about the documentation... Maybe somethign needs to be clarified. | 15:51 |
LaserJock | rubbs: I guess I was going by "if there was a branch right here what would it use?" | 15:54 |
rubbs | LaserJock: | 15:57 |
rubbs | er... LaserJock: I see. I'll look into that | 15:58 |
=== beuno is now known as beuno-lunch | ||
=== Linkadmin is now known as alanpee | ||
=== beuno-lunch is now known as beuno | ||
LaserJock | does olive-gtk visualize the relationship between branches in a repo? | 17:26 |
rubbs | LaserJock: not as well as qlog or explorer (which uses qlog). | 17:28 |
rubbs | LaserJock: qlog is part of the qbzr plugin | 17:28 |
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:38 |
jpds | LaserJock: bzr remove --keep $file | 17:39 |
=== weigon__ is now known as weigon | ||
=== alanpee is now known as Linkadmin | ||
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:03 |
lifeless | \o/ | 19:18 |
lifeless | merry christmas beuno | 19:18 |
beuno | hey lifeless | 19:18 |
beuno | merry christmas to you | 19:18 |
beuno | even more so considering you're in the future | 19:19 |
lifeless | -> plane to catch :) ciao | 19:19 |
beuno | lifeless, have a great flight | 19:20 |
mneptok | Manny Krramer! | 19:20 |
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:48 |
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:49 |
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:50 |
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:53 |
jwhitley | rubbs: outstanding, just what I needed. thanks! | 19:55 |
rubbs | np | 19:56 |
=== cjohnston is now known as FFEMTcJ | ||
=== FFEMTcJ is now known as cjohnston | ||
=== khmarbaise_ is now known as khmarbaise | ||
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:35 |
chromakode | le google is not currently turning up useful advice. | 22:36 |
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:37 |
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:39 |
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:40 |
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:41 |
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:42 |
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:43 |
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:44 |
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:45 |
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:52 |
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:53 |
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:54 |
chromakode | I might claim that if I wasn't a nice user ;) | 22:55 |
igc1 | morning | 23:05 |
=== igc1 is now known as igc | ||
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:31 |
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:32 |
RAOF | AfC: It does, yes. | 23:35 |
RAOF | I forget quite how I managed to make it happen, though. | 23:35 |
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:36 |
AfC | RAOF: Hm. I thought I'd tried that. | 23:37 |
poolie | afc: looking at the code, git+ssh should work | 23:37 |
AfC | poolie: ok, thanks! | 23:39 |
* AfC tries again | 23:39 | |
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:41 |
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:42 |
AfC | [so I'm guessing someone fixed something and did a release and got it into the PPA? Either way, thanks!] | 23:43 |
RAOF | Now all bzr-git needs is a way to specify non-master branches! | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!