[00:58] Hi! Quick question here. I've historically ran one large depot in svn, with multiple projects inside of it. I'm thinking of splitting them each into their own repositories - is there a 'smart' way of doing this, so as to keep revision history? [00:58] bzr svn-import will may just do the right thing [00:59] it will depend on how your svn repo is structured [00:59] Sorry, I should have specified - I've currently bulk imported them into a bzr repo [00:59] using svn-import ? [00:59] Yes. [00:59] and it didn't identify the branches for you ? [00:59] So I've got one giant repo with allm y changes from svn (Yay svn-import!), and I'd rather not lose them as I break them into smaller repos. [01:00] Well, I didn't do my svn repo as branches. It was more just a series of directores inside of 'trunk'. [01:00] ok [01:00] well you can tell bzr-svn where the branches should be [01:00] then svn-import again, and it will split appropriately [01:01] lifeless: Is there any thing I can do the bzr depot? I've grown rather smitten with bzr and have been doing changes against it, instead of svn. [01:01] KhaZ: well, you can use bzr split, but it will still keep the older history as being one-big-depot [01:02] so if you're splitting for size reasons it won't help you, but if you'resplitting just for clarity it will do what you need [01:02] lifeless: So, say I have directories A, B, C, and I want to split them into their own depot. Are you saying it'll keep all the histories, but only branch the contents? [01:02] (i.e., I'll have branch 'A' with only contents from A, but histories from B and C as well?) [01:02] yes [01:02] because one commit back would be the big tree [01:03] what split does is essentially bzr branch your depot, delete everything except the named directory (e.g. A) and then commit [01:04] And there's no way to obliterate history in bzr? [01:04] not directly no [01:05] you could fast-export your depot then fast-import-filter it back in [01:05] Hrmm. I guess I'll have to think about this. [01:06] the fast-export approach soundslike its the closest fit to what you're asking for [01:06] (its a bzr plugin) [01:07] lifeless: Ah, neat. I'll have to check that out. [01:07] Thanks for spitballin' with me lifeless . [01:08] np [01:30] jml: around? === thumper_laptop is now known as thumper [04:25] lifeless: am now. [04:28] what would you like to see in subunit before an announcement to tip [04:28] or alternatively [04:29] what things are 'it really should have' for subunit that it doesn't [04:37] jml: ^ [04:38] lifeless: a web page with some friendly guff + documentation. [04:39] lifeless: not sure what else [04:40] lifeless: some kind of effort to integrate with nose, maybe [04:40] what would that do? [04:40] lifeless: get nose to print subunit output [04:41] ah, tell it to use a subunit TestResult? [04:41] https://edge.launchpad.net/subunit isn't sufficient guff? [04:46] bug 332770 [04:46] Launchpad bug 332770 in subunit "provide a nose extension to output subunit" [Undecided,New] https://launchpad.net/bugs/332770 [04:52] jml: with pycon coming up it seems worth trying to get a 'release' done [04:54] lifeless: I think a more friendly "how to" style document would be a good idea [04:55] jml: do you have any interest in writing it ? [04:56] lifeless: yes. [04:57] cool [04:57] lifeless: but before pycon? ... we'll see. === davidstrauss_ is now known as davidstrauss [06:58] jml: what would you expect the commands 'subunit-filter' and 'subunit-ls' to do [07:31] abentley: the --no- option stuff - was that exposing something optparse does anyway, or custom for bzr? === scode_ is now known as scode [09:26] I would like to use bzr with a workflow similar to what is often used with e.g. darcs/git, where I have my 'upstream' repository that I have branched on multiple places. I then want to commit and periodically push from all these places, but I do not want to do a bunch of merges all the time. [09:26] I have vague recollection of there being a way to do a "flat" merge that does not track the merge history to accomplish this, but I cannot find it now. [09:27] I.e., the problem isn't that I have to use "bzr merge", but rather that I do not want to litter the history with a lot of bogus merges that do not actually represent merges frmo the perspective of the workflow. [09:29] by flat merges you mean joining multiple commits into one? [09:29] or re-applying the patches from the merge branch? [09:29] scode: well, if you actually have flat history there won't be merges at all [09:36] scode: so if its just you on many machines [09:36] I want to merge the changes into my wc without bzr actually treating it like a merge. [09:37] Example workflow: [09:37] * branch to A and B [09:37] scode: you can just sit down, bzr pull, commit push etc [09:37] * add file in A, commit, push [09:37] * add file in B, commit push -> bork because I need to merge, merge, push -> upstream now has a merge in the history [09:37] scode: so if you have committed in A and B concurrently, you need to merge [09:37] lifeless: Yes, but it's very easy to forget to push , and sometimes I may not have access to do so. [09:38] scode: you ahve two choices, don't actually commit in B until you pull, or rebase [09:38] Using the rebase plugin? [09:38] yah [09:39] its how many git users avoid merges [09:39] I don't think merges are an issue myself - if you have actually done concurrent changes they just reflect reality after all :) [09:39] Well, in git I don't end up with having to merge by default at all, assuming no conflicting changes. [09:39] And definitely not with darcs. [09:40] lifeless: Well, in this case it's not very useful and just confusing to be keeping all that merge info in the history. [09:40] lifeless: Especially since the branches are not really branches workflow wise, and have no identification. [09:40] Just n random branches. [09:40] Anyways. [09:40] lifeless: Thanks! [09:41] scode: so you can also [09:41] merge --pull [09:41] (or just pull) [09:42] git doesn't have magic here - a fast forward pull is either an exact match, or a rebase, or an implicit merge [09:42] (where it merges for you) [09:42] lifeless: Yeah, but since git doesn't track merges it doesn't really matter :) [09:43] it does [09:43] In the case of darcs there's definitely no difference at least, I could be wrong about git. [09:43] scode: you mean in log? (git does track merges, exactly the same as bzr - a list of N parents to a commit object) [09:43] In the sense of not affecting revision numbers, etc since your branch is just a sequence of hashes. [09:44] Though I guess it doesn't look too nice if you ever want to check out the branching history. [09:45] I suppose what I really want in this case is simply darcs semantics. [09:59] scode: yes, darcs semantics are quite nice in some respects [10:02] jml: if you're around, I have a subunit-ls too; pondering same-branch/different-branch === beaumonta is now known as abeaumont [13:02] hi [13:33] lifeless: The hidden, automatic nature of the no- options is custom. === mark1 is now known as markh [17:47] Stupid question but something that always pisses me off with web based VC viewers: how could I checkout http://bzr.tensixtyone.com/pytikitag/files ? which is the URL for bzr ? [17:49] it's not clear [17:50] unfortunately there is no way to know, as it is possible to set up access to the branches in many ways [17:50] is there some standard or something that I could try? [17:51] well, using the same URL often works (without the "/files" bit) [17:51] but in this case it doesn't seem to === abadger_afk is now known as abadger1999 [18:55] Loggerhead trunk can now serve bzr, and gives the URL for it. === eaumontab is now known as abeaumont [21:00] Hello, in my new job I have to use svn for revision control. Being very fond of bzr I have been thinking of using bzr-svn to interact with the subversion repository. [21:01] I am whether this can cause any problems for other using the svn repository (through normal svn)? [21:01] + wondering [21:02] eg the file/revision properties that bzr-svn uses [21:03] alf, I don't think so, I know many people who use bzr-svn to interact with svn at work [21:06] hello, whats the difference between `mkdir one; cd one; bzr init .; bzr pull /some/path;` and `mkdir two; cd two; bzr branch /some/path .` [21:06] ? [21:07] beuno: Well, I am going to give it a try and hope for the best! [21:08] Is there a way for bzr-svn to record merges in logs? [21:09] I mean, to also include the logs of the merged revisions in the svn log entry [21:10] alf, I don't really know, i haven't used it myself [21:10] andresj: doesn't the second create two branches? [21:11] andresj: ah, misread, the second puts the branch in ./two/path/, the first in ./one/ I believe [21:11] hey beuno [21:11] andresj: the second will probably error, as branch creates a branch [21:12] andresj: other than that they are essentially identical [21:12] andresj: the latter can be spelt 'bzr branch /some/path two' [21:12] hey lifeless [21:12] hi james_w [21:12] alf: apparently some svn servers have a commit hook that includes diffs to file properties; bzr-svn can create noise there, but thats all [21:13] lifeless: wait what about an error with the second one? `bzr branch /some/path .` should make the current directory the branch [21:13] andresj: 'mkdir .' -> fail [21:13] andresj: 'bzr branch foo bar' does a mkdir bar [21:14] hum, really? oh but i see what you mean---so they basically do the same thing. thank you, lifeless :) [21:14] huya james_w! [21:14] andresj: the major difference is that the format won't be preserved [21:15] hold on a second, please, lifeless [21:15] (stupid old router ;P) [21:16] ok im back :) [21:16] what format wont be preserved, lifeless? [21:16] andresj: e.g. if /some/path is something non-default, like a loom, 'bzr branch' will preserve that, but doing a manual init won't. [21:17] hum... i see, i see---so ill be sure to branch instead of init, pull from now :P [21:17] andresj: http://paste.ubuntu.com/121561/ [21:21] lifeless: http://paste.ubuntu.com/121562/ ;P [21:22] andresj: heh [21:59] morning [22:00] hi igc [22:01] hi mwhudson [22:23] jml: when you get a chance, after work or so; subunit - new branch to review [22:23] lifeless: ahh right. [22:23] lifeless: so, in answer to your earlier question.... [22:23] lifeless: I'd expect subunit-filter to be a thing like grep that used higher-level subunit concepts, rather than regexen [22:24] lifeless: and I don't have a clear idea of what subunit-ls would do -- discover tests in ... what? [22:24] subunit? [22:25] jml: it outputs just their names [22:25] jml: like lsdiff outputs the files altered in a patch [22:25] ronny: https://launchpad.net/subunit [22:26] looks usefull [22:26] does the python child support things like nose? [22:27] bug 332770 [22:27] Launchpad bug 332770 in subunit "provide a nose extension to output subunit" [Undecided,New] https://launchpad.net/bugs/332770 [22:28] ronny: the python child is a unittest.TestResult [22:28] oh, sad [22:28] ronny: so anything that honours that protocol will work with subunit [22:28] i really dislike unittest tho [22:28] nose is basically unittest, last I looked [22:28] though they seem to be going slowly mad [22:28] well, it hides away the pain [22:29] lifeless: i could use a tool that can set up different envs with different versions of a tool [22:30] so i can run anyvc's unittests against all supported versions of hg, bzr, dulwich, subvertpy [22:31] jml: does testtools have load_tests support yet? or scenarios? [22:31] lifeless: spiv has a patch up for scenarios [22:31] ronny: bzr has interface tests for this purpose; we write tests to an interface and parameterise the tests [22:31] lifeless: I'm a bit suspicious of load_tests, partly due to ignorance. [22:32] lifeless: thats what i do in anyvc, too [22:32] jml: API xenophobia? [22:32] jml: its my third attempt at that problem, I think its the right one [22:32] currently i run against one version of each tool [22:32] i'd prefer to be able to run against multiple versions [22:33] jml: I'd be happy to discuss [22:33] ronny: right, so test parameterisation setting python paths; and subunit to get a fresh interpreter for each, ftw [22:33] lifeless: it's possible. everything else in testtools (IIRC) is things that have been used in more than one project. [22:33] [modulo grammar] [22:34] lifeless: but likewise, am happy to talk about it later. [22:34] jml: load_tests is simply a hook for TestLoader, between implicit discovery and actual use. [22:34] lifeless: i'd like to have a way to pass the parameters as something like pkg_resource requirements or something, and setting up a custom virtualenv for each [22:35] ronny: yes, that would be trivial glue on top [22:35] the parameters would be in your scenario definitions [22:36] your external test case proxies would turn those into virtualenv however you want to do that [22:39] lifeless: sounds nice [22:39] lifeless: hmm, the protocol seems confusing, does it have any base? [22:42] lifeless: got a bnf gramar or something like that? [22:42] spiv: ping [22:43] ronny: not really, it was designed to be primarily human readable [22:43] oh :( [22:43] ronny: I can whip up a BNF at some point; its nearly a BNF anyhow in the README [22:43] lifeless: pong [22:44] spiv: what is the mechanism by which pack-names is refreshed when the autopack rpc is used? [22:44] spiv: streaming push needs the same thing [22:44] lifeless: bzrlib/smart/packrepository.py [22:45] lifeless: the verb just relies on _pack_collection.autopack() to DTRT [22:45] spiv: I mean on the client [22:45] Oh, right [22:45] self._real_repository - how does it see the new pack [22:45] is there a 'refresh thyself' method I can call from RemoteSink ? [22:45] self._real_repository._pack_collection.reload_pack_names() === Daviey_ is now known as Daviey [22:46] I die a little every time [22:46] That line in remote.py is preceded by a comment saying that perhaps the automatic retry logic will make that unnecessary... [22:47] spiv: it doesn't [22:47] spiv: for streaming push [22:49] spiv: because no file IO errors occur, we just have a new pack that the real repo does not know about [22:49] Ah, yeah. Unless an autopack did occur, of course. [22:50] But not in the general case. [22:51] :!./bzr --no-plugins selftest branch_implementations.*Remote [22:51] passes [22:51] lifeless: another thing i dont get is that obsession with xunit [22:51] ronny: reusable code is good [22:52] lifeless: but xunit isnt exactly nice in python [22:53] unittest is somewhat fugly [22:53] but that was barely even a transliteration of xUnit [22:53] py.test makes my want to cry [22:54] 1:1 transliterations never end well :( [22:54] lifeless: dont ever support it [22:54] doctest has caused enough grief that we should sue the author [22:54] 'crimes against humanity' [22:54] these insane fuckers dont deserve support ;P [22:54] i think when it comes down to the ugly details of testing "real" code things like "xunit offends my sensibilities" go flying out of the window [22:55] py.lib and py.test are damn messed up [22:55] spiv: so coordination call? [22:55] lifeless: sounds good [22:56] skype or pots [22:56] either's fine with me [22:56] i wouldnt mind unittests so much if unittest keept the tests more readable and used pythonic patterns [22:56] eh unittest i mean [22:57] the problem is, it works, so we are stuck with it [23:02] I really enjoy py.test... but doctests drives me crazy [23:03] santagada: py.test is only fun till it breaks things [23:03] then it wil lbe impossible to debug it cause of the insane things in it [23:03] ronny: I only used it in pypy, so it never broke anything... [23:04] ronny: I got I little insane trying to learn how to write a plugin for it [23:04] but after you get the hang of it it is quite straightforward [23:04] I think the biggest problem is lack of real docs, about internals and all [23:05] i ditched it for nosetest [23:05] less magic more docs [23:05] lifeless: btw, how are the nose devs starting to go insane? [23:05] ronny: nosetest is cool, but less magic also mean less cool features [23:05] santagada: what do you think is missing? [23:06] the more magic is involved the harder debugging real breakages gets [23:06] specially when you assert something py.test has much more information about the variables involved [23:06] nosetest -d enables assert introspection [23:06] this is probably new [23:06] been there since ages [23:07] afair its also allmost ported to jython, ironpython and python3 [23:07] either I didn't notice it or it doesn't work like py.test [23:07] it doesnt do weird magic onless you ask it to [23:08] ronny: have you tried the one from twisted? [23:08] trial I think [23:09] yeah, behaved weird, no idea if it was my fault [23:09] im kinda allergic to the crimes twisted generates [23:09] abentley: bundlebuggy [23:09] abentley: bundlebuggy is 502ing [23:11] spiv: restarted [23:11] santagada: im thinking about writing an own one later [23:12] lifeless: why is the stream like test: thelabel\nresult: thelabel [...] [23:13] wouldnt it be enough to just pass the results [23:13] ronny: you seem very opinionated :) [23:13] mwhudson: yeah [23:13] ronny: please don't do it... create a plugin for py.test or nose [23:13] most likely for nose [23:13] i'd like it to report to a dbus location [23:14] abentley: thanks! [23:14] see, something easy to do with py.test, probably the same with nose [23:14] gtg [23:14] lifeless: it would be nice if there was a way to track extra stuff like tracebacks or stdout/stderr for the tests [23:16] ronny: the nose devs seem to be slowly adding py.test magic [23:16] ronny: I should track it more closely, because thats as accurate and precise as I can be at the moment [23:16] ronny: re: trial, trial is largely sane now thanks to jml [23:17] ronny: re: the duplication, its to catch interrupted streams [23:17] ronny: and hung tests [23:17] start, finish catches hung tests [23:18] start THING, finish THING -> catches interrupted tests (start FOO, start BAR, finish BAR, and similar) [23:19] spiv: down to 63 calls for non-stacked [23:19] lifeless: trial has been improved now by many people since I was actively working on it. [23:19] jml: I credit you with unfucking it when it was at its worst [23:19] jml: the rest is just folk understanding that it can be good [23:20] jelmer: ping [23:21] lifeless: do you see any reasonable way to hook into getting extra data like timings, stdout/stderr produced by each test and others? [23:23] ronny: sure, as long as its in the test comment area of the protocol its captured and put in the RemoteBacktrace [23:23] timings -> use the time: tag [23:23] ah, k [23:23] i'll have to get more into it [23:23] I need to add builtin generation of time: tags in the python client [23:23] for now its just defined in the protocol, for folk doing benchmark work [23:24] ronny: one of my main uses today is: [23:24] bzr selftest --subunit > tests.log [23:24] lifeless: btw, why do you leave many ways to spell some things like test vs testing? [23:24] subunit-filter < tests.log | subunit-ls > failing.list [23:25] bzr selftest --load-list failing.list [23:25] and loop [23:25] (with hacking in the middle) [23:25] woot [23:25] only loads tests that failed the previous time around [23:26] ronny: test|testing|etc etc - generous in what you accept, strict in what you emit :) [23:26] ronny: some folk are funny about what they want to see [23:28] hmm, i wonder if there is a reasonable way to deal with generator-tests [23:28] do you mean factories that create many tests? [23:28] yeah [23:29] their test id's are a bit messy in nose [23:29] for subunit it doesn't care - it doesn't require unique ids [23:29] but its the same really as bzr's test scenarios [23:29] have you seen our ids ? [23:29] no [23:29] i guess you guys just rerun the full generator? [23:30] test_merge_sorted_range_stop_include_forward(BzrBranchFormat5) [23:30] (or do you have a way to figure what part to rerun) [23:30] for loading tests do you mean ? [23:30] yeah [23:30] we generate all the scenarios and filter [23:32] It'd be possible to do better than that with the load_tests hook, if we cared. [23:32] (I think) [23:33] ie skip scenario generators that completely passed? [23:33] ronny: pass the filter into the generator [23:33] Right. [23:34] spiv: be difficult to balance filter generalism with actual skipping though [23:34] At the moment generating a scenario is sufficiently cheap that we don't care. [23:34] lifeless: yeah [23:34] lifeless: see also "if we cared" ;) [23:34] wouldnt i have to manage filtering myself then? [23:35] Well, I'd imagine we'd provide filtering by default in our TestScenarioApplier or whatever its called. [23:35] ronny: you could ignore the parameter if you didn't care [23:35] myself, I think the current solution is simple and sane [23:35] * spiv agrees with lifeless [23:39] lifeless: are there any conventions for the result metadata? [23:39] (ie the comment block) [23:39] just want to know it it would make sense to even try parsing [23:40] ronny: the python client writes the stacktrace in a way that can be reconstituted [23:40] ronny: but other languages may not - e.g. the C client could just 'SEGFAULT' :P [23:40] spiv: heh: self.assertEqual(1, autopack_calls + streaming_calls) [23:40] AssertionError: not equal: [23:40] a = 1 [23:40] b = 4 [23:40] spiv: yay for tests eh what [23:41] hmm [23:41] lifeless: :) [23:41] i really wish things like self.assertEqual(a,b) would go away for assert a==b [23:42] ronny: I like my tests to work with pyo files :) [23:45] lifeless: i kinda hate that optimazion - also - who the heck tests that way (bzr selftests are an exception thi) [23:46] spiv: I want remember_remote_is_after() [23:47] ronny: it is an odd optimisation :P [23:48] ronny: not all assertions are about equality, though... [23:49] lifeless: (not that I doubt you do want that) what for? [23:50] lifeless: the existing infrastructure for coping with different client/server versions is definitely a bit too simple. At least it isn't a bit too complex, though ;) [23:50] spiv: i dont see any reason why most of those self.assertFoo couldnt go away for just assert [23:51] spiv: after I know that streaming push works [23:51] spiv: or perhaps medium.verb_exists(verb) [23:51] ronny: grep for "def assert" in bzrlib/tests sometime [23:52] ronny: the base assertion methods on TestCase aren't so interesting [23:52] spiv: 60 and 85 now [23:52] spiv: bzr search -s assert [23:53] spiv: much more useful :) [23:53] ronny: it's the domain-specific ones that any sizeable project starts growing that really interesting. [23:55] (and actually, assert methods are kind of lame) [23:55] spiv: the ones i have seen so far use only self.assertEqual [23:55] hmm [23:56] jml: I'm thinking of dropping subunit.RemotedTestCase from the id of RemotedTestCase's [23:56] jml: thoughts [23:56] lifeless: I manually drop it in Tribunal [23:59] jml: ok, I'll nuke it tonight [23:59] lifeless: cool.