[00:01] lifeless: awesome thanks! [00:02] my wildest dreams have true [00:02] have come true, that is [00:04] Actually my wildest dream would be one that functioned instantly offline by remembering info when it could [00:04] but this will do nicely [00:18] lifeless: so, different topic [00:19] lifeless: you were talking about (optional) support for an index in bzr quite a while ago [00:19] lifeless: how exactly would that fit in with the working tree? [00:22] jelmer: remind me? [00:23] jelmer: oh, no, I don't want an index. I think the index is a bug [00:23] I want tagging of changes/paths in a tree, and tags supplied to operations like commit and diff [00:23] I called these 'marks' to differentiate [00:25] ahh [00:25] so no staging area-like things? [00:25] hell no [00:26] bleh [00:26] that leads to UI confusion and layer leakage [00:26] look at commit -A, [00:26] an unbreakme option if ever there was one [00:26] you're making my job implementing a good mapping for git indexes ;-) [00:26] being able to commit content totally unrelated to what your editor sees is a bug [00:26] *a lot harder [00:27] I wouldn't map it, I would give bzr running against a git tree bzr semantics. [00:28] igc: so commit is good yeah? [00:28] lifeless: well, I have to map git semantics to bzr semantics === abentley1 is now known as abentley [00:28] lifeless: that's a lot easier if bzr has a staging area :-P [00:29] jelmer: You'll need to explain this for me, because I don't see why [00:35] lifeless: so, what I'm trying to figure out is what "bzr add" should do in a git working tree [00:36] jelmer: it should make sure the files are versioned [00:37] well, git add works on a "add to the content of next commit basis" [00:38] lifeless: i just filed bug 348750 quoting your mail [00:38] Launchpad bug 348750 in launchpad-bazaar "merge proposal mail context is confusing" [Undecided,New] https://launchpad.net/bugs/348750 [00:38] i was quite confused :) [00:38] the staging area basically keeps track of the desired content changes in the whole tree [00:38] lifeless: yeah, but that means adding the *current* version to the index [00:39] lifeless: if the file gets changed after the add, those new changes won't be committed [00:39] ronny: not quite, but yes, I do know what goes on here :) [00:39] lifeless: in other words, what I'm saying is it's hard to map a git index to the Bazaar working tree APi [00:39] jelmer: sure they will if you make sure you do the equivalent of 'commit -A' [00:39] yeah, i probably oversimplified the issue [00:41] jelmer: as I said, I wouldn't make the index *at all*. [00:41] s/make/map/ [00:41] jelmer IMO it should remember it as 'versioned' and then commit should build the index implicitly [00:41] looks like poolie agrees with me :) [00:41] poolie: 'commit -A' in git updates the index from the current disk, for paths already in the index. [00:41] there is a bit of a question of where you would keep that [00:41] is this for using bzr in a git working tree, or just committing to a git repo? [00:42] bzr in a git working tree [00:43] one could view the index as temporary commit on top of the actual tip [00:43] jelmer: i don't know if this is a great solution but one thing that would work would be to use the index just to keep track of which ones are versioned [00:43] ronny: i know what it is thanks [00:43] we just have a different model and we're trying to map them across [00:44] so, anyhow, then commit would need to re-add the files already in the index that match the commit parameters [00:45] and back out unselected ones to the last commit state [00:45] poolie: I think you are proposing exactly what I am [00:45] right [00:53] Hello people. Quick question: is there a command to change the name of a local branch and update where a lightweight checkout of that branch? [00:53] I have repo/A and a lightweight checkout of A in repo/sandbox. I want to move A to B (simple mv command), but I'm not sure how to switch over sandbox. switch will not operate because it doesn't find A. [00:54] *and update the branch path of a lightweight checkout of that branch [00:57] jfroy: hi, will 'bzr bind NEWLOCATION' do it? [00:58] poolie: no, it also errors out === emmajane is now known as emmajane_scotch [01:02] If I am going to attempt to do a branch of a quite large svn repos with bzr-svn, is it worth upgrading bzr on my Intrepid machine via the PPA, from 1.6.1-1? [01:02] Will I get anything to improve that [01:08] mrooney: latest bzr-svn is much better than the version in Intrepid [01:09] mrooney: and it in turn requires a more recent bzr than 1.6.1-1 [01:09] mrooney: there is a major version upgrade to bzr-svn. much goodness. [01:09] Hopefully the ~bzr PPA has the current bzr-svn package, it usually does. [01:13] spiv: 0.5.3-1? [01:13] mrooney: yeah === jelmer is now known as Guest68274 [01:16] oh for the PPA dependency, do I have to manually add that for it to work? [01:16] oh no here we go I think [01:18] oh no! this works differently [01:18] before if my username didn't match and I just hit enter, it would ask me for the username [01:18] now it just changes to "None password: " [01:18] how can I specify a username? [01:21] mrooney: I think bzr-svn uses the same authentication.conf as the rest of bzr [01:21] mrooney: bzr help authentication | less [01:22] okay, well the None user thing seems to be a regression [01:22] I would have expected it to use subversions authentication cache ... [01:22] mrooney: or maybe you can just stick the username in the URL? [01:22] mrooney: yeah, it does sound like a regression. [01:23] just make a bug [01:23] yes that does work if I put it in the right place! [01:26] SamB: it also uses the svn authentication cache [01:27] SamB: but it won't store new credentials into the svn cache [01:29] sweet bzr: ERROR: exceptions.AssertionError ! [01:30] mrooney: try running 'svn log URL' to get svn to cache the credentials, that used to work [01:31] lifeless: well I got the credentials to work I think [01:31] the AssertionError came in the middle of a branch [01:31] multiple revisions in [01:33] Expected got [01:34] mrooney: interesting [01:35] unfortunatly the bzr-svn author is asleep right now [01:35] could you file a bug ? [01:35] sure, against bzr? [01:35] lifeless: no, I'm not :-) [01:35] mrooney: bzr-svn please [01:36] mrooney: is this bzr-svn 0.5.3? [01:36] Guest68274: yeah, from the PPA [01:36] Guest68274: oh, I didn't recognise you === Guest68274 is now known as jelmer [01:36] " svn /usr/lib/python2.5/site-packages/bzrlib/plugins/svn [0.5.3]" [01:39] jelmer: http://paste.pocoo.org/show/109661/ [01:40] that should be helpful I hope! [01:40] it seems to get to roughly 30/1000 before dying [01:48] mrooney: the repository is not public, I presume? [01:52] jelmer: that is true :) === abentley1 is now known as abentley [02:01] mrooney: please file a bug [02:01] jelmer: okay, can you give me a title for it? [02:02] mrooney: what sort of changes do "svn log -v -r4" and "svn log -v -r5" report? [02:04] jelmer: -r4 is a commit "manufactured by cvs2svn to create branch XX" [02:04] mrooney: what sort of changes does it contain though? [02:05] mrooney: file edits, file adds, deletes? [02:05] Changed paths: [02:05] A /branches/XX (from /trunk:3) [02:05] D /branches/XX/CVSROOT [02:05] and then r5 seems to be...nothing? [02:07] jelmer: But the error doesn't appear until decently past r5, does that still make sense? [02:10] the last number I seem to see is "copying revision 31/1000" [02:10] mrooney: "revision without changes causes exception" would be a good title [02:11] mrooney: bzr-svn should be warning you that you are cloning Subversion repository as branch. [02:11] yes it is indeed [02:12] mrooney: any reason you're cloning the repository root anyway, rather than using svn-import ? [02:12] The latter should not trigger this bug [02:13] I don't know, I just want to have the whole svn repos with version history [02:13] is there a better way? [02:13] mrooney: yes, svn-import should do that [02:13] it says to use svn-import to get individual branches in the warning [02:13] it doesn't recommend using that instead [02:14] jelmer: https://bugs.edge.launchpad.net/bzr-svn/+bug/348786 [02:14] Ubuntu bug 348786 in bzr-svn "revision without changes causes exception" [Undecided,New] [02:14] okay I must head out for today, but I can look into svn-import tomorrow if you recommend it [02:15] mrooney: but you're looking to import the individual branches right? [02:15] no [02:15] mrooney: e.g. trunk/ as a separate branch [02:15] mrooney: branches/foo as a separate branch, etc [02:16] I basically want a backup of the svn repository, that I can pull from each night and be up to date [02:16] having those as branches would be nice [02:16] so then I want svn-import? [02:16] mrooney: yes [02:17] jelmer: okay, I will use --incremental I guess [02:17] since I don't want to lose it all if it fails at the 25,000th rev :) [02:18] I am guessing that is what --incremental will get me, at a slight speed loss? [02:18] mrooney: it's failsafe even without --incremental [02:19] mrooney: --incremental will give you a speed improvement [02:19] ...interesting! [02:19] as it will remember where you left off the import [02:20] okay, I am off for now but this has made it much further using svn-import [02:20] at 500 [02:20] but, it says of /23902 [02:20] it breaks again at r500? [02:20] no it is still going :) [02:20] ah good :-) [02:20] and it actually ends at 28,000 something [02:20] and using branch seemed to notice that correctly [02:21] so I am not sure, what that means [02:21] mrooney: not all svn revisions will be imported as bzr revisions [02:21] oh okay, whereas with branch they would? [02:21] mrooney: e.g. that revision 5 won't show up in the bzr repository created this way [02:22] hm so you lose forced commits and their messages? [02:22] mrooney: yes, you lose commits that don't touch any of the branches [02:23] however, a branch created with "bzr branch" on the repository root wouldn't be very useful in bzr and would use a significant amount more disk space [02:24] oh okay, well thanks for your help and good work on bzr [02:24] good night! [02:24] gnight === emmajane_scotch is now known as emmajane [04:02] Has anyone ever tried using bzr bd on a cdbs based package that only has a control.in in the repo? [04:03] hmm dpkg-buldpackage doesn't work either. Maybe time to read up on cdbs [04:11] jelmer: has the escaping of / in bzr-svn revids changed recently? [04:12] jelmer: I'm getting 'branches have diverged' when I try to pull Python's trunk, my disk has svn-v4:6015fed2-1504-0410-9fe1-9d1591cc4771:python/trunk:70244, but "bzr revision-info -d http://svn.python.org/projects/python/trunk" reports svn-v4:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:70601 === abentley1 is now known as abentley [04:15] jelmer: I'll just file a bug :) [04:20] jelmer: https://bugs.edge.launchpad.net/bzr-svn/+bug/348805 [04:20] Ubuntu bug 348805 in bzr-svn "Incompatible change to path escaping in revision-id mapping" [Undecided,New] [04:49] igc: ping; any chance of a reviewof my commit branch? [04:55] lifeless: probably not today unfortunately - I didn't sleep last night so I'm not awake enough for a review that important [04:56] lifeless: i possibly can but i'm going to finish that mail first [04:56] lifeless: I can tomorrow if no-one beats me to it [04:59] igc: thanks [04:59] poolie: no worries; that mail has priority :) [05:03] lifeless: I didn't publish the results without your patch. For commit, they were 4x slower from memory so the proposed code is a big win. Really well done [05:04] igc: thanks === `6og is now known as Kamping_Kaiser [05:55] pyftpdlib working nicely with python2.6, good job [07:05] well I'm done for the day modulo interest-fiddles [07:23] hi all [07:24] BasicOSX: glad you like it ;-) [08:09] bzr: ERROR: These branches have diverged. Use the merge command to reconcile them. [08:10] I get this error when I do a "bzr pull /goldrepo" [08:10] why is it saying that the branches have diverged? [08:10] Is it good to use pull or should I use merge? [08:11] I basically have a MAIN trunk where the gold copy of the app resides... every developer has his own FEATURE branch [08:11] now I want them to be able to UPDATE or SYNCH their branches with the latest changes in the gold copy as I could have merged in some other developer's features in there that everyone must have [08:11] should I use merge or pull? [08:12] or get them to infact use... merge or pull? [08:14] diverged = one is not a subset of the other [08:14] ie they're not just out of sync, they have both made independent commits the other has not picked up [08:14] but that will always be the case wouldn't it [08:15] no [08:15] I mean in reality developers will constantly keep committing changes to their own branch [08:16] ok so if a developer was working on a feature.... he shouldn't be commiting his changes to his local branch before his feature is completely done and he is ready to merge it into TRUNK? [08:16] is that what you are saying? [08:16] no [08:16] it will vary depends on what you and your developers do [08:16] yeah but I just told you what they will do [08:17] they will work on feature branches [08:17] CBro2007: if its a feature branch they should merge from trunk [08:17] and once they are happy with their changes they will tell me which rev no committed copy I should merge into trunk [08:17] CBro2007: if its a mirror they should pull [08:17] I suppose I am using a FEATURE branch then eh? [08:18] so when they do a merge they would still keep their local changes yeah? [08:20] yes [08:20] have you experimented with merge [08:21] yeah i have [08:21] whats the "pending merges" [08:21] ? [08:22] it seems like local changes have to be COMMITTED before you can do a MERGE [08:22] yes [08:23] CBro2007: so you do a merge, and bzr leaves the result wwaiting for review [08:23] you review it and commit [08:23] and then you can continue [08:23] ok cool [08:23] get it [08:23] its pretty cool when you get the hang of it [08:24] we think so :) [08:24] so I am thinking that the merge should work both ways - trunk to feature branch and vice versa [08:24] even if they are out of synch [08:24] yes [08:24] like someone has been adding stuff to trunk directly [08:24] and someone to the feature branches [08:24] and we can merge all at anytime yeah>? [08:24] to take something from a feature branch and put it in trunk, you cd to trunk, run bzr merge feature-branch, bzr commit -m "add feature to trunk" [08:24] yeah [08:25] and I can also merge a given revision with the -r (n) if i wanted [08:25] :) [08:25] soon I will be full of "bazaar life" mr lifeless [08:25] hahahhaha [08:26] :) [08:26] vila: so, I've spun up 18-way amazon on 8-way cores for testing... its fun [08:26] lifeless: isn't it :-) [08:27] finding some interesting bugs [08:27] did you see my doctest bug ? [08:27] lifeless: I don't think so, where ? tests.parallel ? [08:28] bb [08:38] wondering if I should let developers merge their shit into trunk directly [08:38] :) [08:39] or have them send it to me for review first [08:41] CBro2007: what do they do at the moment ? [08:41] nothing [08:41] :) [08:41] I am setting up bzr so we can start to share the code [08:41] ok [08:41] and they can make changes [08:41] so I'd say don't add policy at the same time as adding technology [08:41] but don't want them putting in shit willy nilly [08:42] if they merged in stuff that is shit... it would be harder for me to get rid of it [08:42] if at the moment the way they get their code deployed is 'cp to production', then thats basically willy nilly [08:42] they are not coding at the moment [08:42] its just been me all this while [08:42] they are going to be jumping on board to work on more features [08:43] but its still going to be a learning curve for them [08:43] so I would still like to review some of their work before I merge it into the GOLD copy [08:43] :) [08:43] I know I sound like a dick.. but hey [08:43] :) [08:45] so, in which case, you should own 'gold' and merge features you're happy with === Bambi_BOFH is now known as Kamping_Kaiser === eMBee_ is now known as eMBee [09:57] Does anyone know if 1.13.1 will be reaching Debian sid soon? [10:35] vila: so, command line arg or variable, for test suite munging [10:35] actually, [10:35] I know [10:36] I will do shiny long needed refactorin [10:36] g [10:36] lifeless: I'm all ears :-) Refactoring what targeting what ? [10:38] Hi guys.. a question o repository moving (if it's possible at all). I have a shared repo at /src/project/repo, containing various branches, which I check out and work on at /src/workspace. I'd like to move the shared repo up one level, to /src, to save on storage space. Is it possible to do somehow or would I have to create new branches, send -o and merge? Thanks1 [10:42] I would recommend branching inside the repo and then making lightweight checkouts into /src/workspace [10:42] that way you get the "space" savings you're interested in, without compromising your current workflow any [10:43] ok. [10:43] also making sure not to have working trees in the repo [10:43] Indeed [10:43] a treeless repo and a separate area for lightweight checkouts is what I do for these kinds of things [10:44] That's what I also do, but I was wondering if it was easier to do something different ;) [10:48] vila: suite modifications, chain, like I made log [10:50] lifeless: Hmm, the alternative. I'm not totally convinced by it, but I see where you're going, [10:50] the main point that makes me nervous is that it means adding a 'fake' test to represent the remote suite, [10:51] which I find a bit artificial, but I may be wrong and it may be the best trade-off [10:52] I think it should make remote(parallelized) possible and clearer though [10:52] vila: test suite is a composite pattern [10:52] so a test is a suite is a test [10:52] jml: http://pybites.blogspot.com/2009/03/unittest-now-with-test-skipping-finally.html [10:53] I think it also requires that such modifications be done last rather than first [10:55] well [10:55] I think the ordering will be important [10:55] if thats what you mean [10:55] yes [10:56] we don't want TestInSubprocess to filtered out because its id doesn't match some pattern for example [10:57] since we tend to flatten test suite via iter_suite_tests or things like that, not a big concern right now, but it kind of make the design more fragile [11:01] lifeless: your refactoring will include putting randomize_suite and exclude_tests_by_re inside that chain right ? [11:20] vila: do you have python 2.4 handy? [11:20] vila: if so, can you tell me if the base TestSuite has __iter__ defined in 2.4 [11:21] yes [11:21] in unittest ? [11:21] yes [11:21] def __iter__(self): [11:21] return iter(self._tests) [11:21] so, regarding iter_suite_tests [11:22] I see two possible approaches [11:22] one is to say, if we iter, and it would break it (e.g. randomising), we should pass that responsibility onto children [11:23] by e.g. passing --random to them too [11:24] you mean children == subprocess, not children == tests right ? [11:24] yes [11:25] the other is to say, if we iter, the container should do what it needs to [11:25] anyhow, nearly done [11:27] Or we can make two chains: one post-load and one pre-run :-) [11:29] lifeless: by the way, since randomizing was introduced to exhibit isolation problems (AFAIU) I wonder if it's still needed... [11:29] I found more isolation problems by running test one by one than by randomizing the order [11:30] I have no use for randomisation, never did :) [11:41] that was the point of it [11:43] poolie: ok, well I'm not proposing to remove it [11:43] it fits into this refactoring fine [11:58] vila: not quite right :P [11:58] lifeless: what ? [11:58] [6/17475 in 8s] [11:58] Ran 6 tests in 9.021s [11:58] oh, your refactoring :) [11:59] I like the elapsed time, try to keep it that way :) [12:00] so [12:00] http://paste.ubuntu.com/138181/ [12:02] I'd like to set "whoami" for all of the branches in a shared repo (vs 'bzr whoami --branch' in each individual branch)... is that easily doable? [12:03] sure, set it in ~/.bazaar/locations.conf [12:04] vila: what do you think [there was a tiny bug, its fixed] [12:05] two teeny bugs, fixed :P [12:06] lifeless: in ExcludeDecorator ? [12:07] lifeless: ignoring the details, the design sounds good [12:07] can I claim 'refactoring, please no new tests'? :) [12:07] vila: with this design, a plugin can do all of BZR_PARALLEL [12:08] lifeless: you two bugs were caught by the actual test suire right ? [12:08] yes [12:08] s/you/your/ [12:08] [160/180 in 45s] test_selftest.TestTestResult.test_strict_with_known_failure [12:08] ---------------------------------------------------------------------- [12:08] Ran 180 tests in 45.973s [12:08] selftest selftest [12:08] refactoring under test suite umbrella doesn't require new tests :-) [12:09] selftest -s bt.test_selftest :) [12:09] bb:approve then? [12:09] BB:APPROVE [12:10] But I don't see a way to plugin into suite_decorators [12:11] provided in builtins.py ? [12:11] yes [12:11] yeah ! :) [12:11] Command.hooks['extend_command'] [12:12] btw [12:12] run 'bzr selftest selftest [12:12] note the double printing of what we're testing [12:12] something isn't isolated correctly [12:14] ECANTREPRODUCE, bzr selftest selftest --no-plugins ? [12:15] reproduced elsewhere [12:16] kinkie: just mv /src/foo/bar /src/bar [12:16] kinkie: or whatever [12:17] kinkie: you may want to adjust some paths in ~/.bazaar/locations.conf [12:18] lifeless: mv ~/lib/python/subunit ~/lib/python/subunitxx makes the double printing disappear [12:18] not pointing fingers.... [12:19] odd.. [12:22] vila: its printed out in builtins.py [12:23] lifeless: thanks! of course. (I walked away from the computer right before you answered) [12:23] lol, I bet that sys.stdout.write is coming back to hunt you !!! [12:24] via a run_bzr or in a blackbox test or something :-) [12:24] vila: sys.stdout is wrong [12:24] lifeless: I know ! But yet :) [12:24] using 'print' in builtins is wrong too [12:27] yes [12:27] jml: so, ConcurrentTestSuite, testtools will accept, or won't. [12:27] jml: I need to know [12:32] lifeless: bzr selftest -s bt.blackbox.test_selftest.TestOptions.test_subunit [12:33] either gulty or victim [12:34] ah [12:34] I know what it will be [12:34] the runner is not being contained [12:34] or something like that [12:34] probably guilty [12:34] * lifeless points fingers at whoever reviewed the test [12:34] LOL [12:35] * vila points finger to self for still missing a test farm running isolated tests on a regular basis :) [12:37] do you know if its possible to have an optional option [12:38] e.g. --parallel[=foo] ? [12:38] came under discussion with jam recently: no, but we should [12:39] work-around : use a magic value :-/ [12:39] i.e. --parallel=0 => cpucount() [12:42] lifeless: can you take http://paste.ubuntu.com/138205/ ? [12:42] rhaa http://paste.ubuntu.com/138206/ [12:43] vila: thats better, but you know what would be awesome [12:44] you know I don't (yet :) [12:44] vila: do that printing by calling something [not foo.stream.write!] on the result object [12:44] 'that' ? [12:45] you realized -v and progress bar prints *during* execution, right ? [12:46] 'that' == 'testing: ...' [12:53] haa, so it can tell: testing 'this' 'here' ? [12:54] I was wondering about remote testing issues if you test from os1 to os2... [12:54] .. cans of worms [12:55] * vila needs to eat [12:56] I'm off to be [12:56] http://paste.ubuntu.com/138212/ [12:56] d [12:56] thats my reimagined version [12:56] it looks better to me [12:57]