| mrooney | lifeless: awesome thanks! | 00:01 |
|---|---|---|
| mrooney | my wildest dreams have true | 00:02 |
| mrooney | have come true, that is | 00:02 |
| mrooney | Actually my wildest dream would be one that functioned instantly offline by remembering info when it could | 00:04 |
| mrooney | but this will do nicely | 00:04 |
| jelmer | lifeless: so, different topic | 00:18 |
| jelmer | lifeless: you were talking about (optional) support for an index in bzr quite a while ago | 00:19 |
| jelmer | lifeless: how exactly would that fit in with the working tree? | 00:19 |
| lifeless | jelmer: remind me? | 00:22 |
| lifeless | jelmer: oh, no, I don't want an index. I think the index is a bug | 00:23 |
| lifeless | I want tagging of changes/paths in a tree, and tags supplied to operations like commit and diff | 00:23 |
| lifeless | I called these 'marks' to differentiate | 00:23 |
| jelmer | ahh | 00:25 |
| jelmer | so no staging area-like things? | 00:25 |
| lifeless | hell no | 00:25 |
| jelmer | bleh | 00:26 |
| lifeless | that leads to UI confusion and layer leakage | 00:26 |
| lifeless | look at commit -A, | 00:26 |
| lifeless | an unbreakme option if ever there was one | 00:26 |
| jelmer | you're making my job implementing a good mapping for git indexes ;-) | 00:26 |
| lifeless | being able to commit content totally unrelated to what your editor sees is a bug | 00:26 |
| jelmer | *a lot harder | 00:26 |
| lifeless | I wouldn't map it, I would give bzr running against a git tree bzr semantics. | 00:27 |
| lifeless | igc: so commit is good yeah? | 00:28 |
| jelmer | lifeless: well, I have to map git semantics to bzr semantics | 00:28 |
| === abentley1 is now known as abentley | ||
| jelmer | lifeless: that's a lot easier if bzr has a staging area :-P | 00:28 |
| lifeless | jelmer: You'll need to explain this for me, because I don't see why | 00:29 |
| jelmer | lifeless: so, what I'm trying to figure out is what "bzr add" should do in a git working tree | 00:35 |
| lifeless | jelmer: it should make sure the files are versioned | 00:36 |
| ronny | well, git add works on a "add to the content of next commit basis" | 00:37 |
| poolie | lifeless: i just filed bug 348750 quoting your mail | 00:38 |
| ubottu | Launchpad bug 348750 in launchpad-bazaar "merge proposal mail context is confusing" [Undecided,New] https://launchpad.net/bugs/348750 | 00:38 |
| poolie | i was quite confused :) | 00:38 |
| ronny | the staging area basically keeps track of the desired content changes in the whole tree | 00:38 |
| jelmer | lifeless: yeah, but that means adding the *current* version to the index | 00:38 |
| jelmer | lifeless: if the file gets changed after the add, those new changes won't be committed | 00:39 |
| lifeless | ronny: not quite, but yes, I do know what goes on here :) | 00:39 |
| jelmer | 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 |
| lifeless | jelmer: sure they will if you make sure you do the equivalent of 'commit -A' | 00:39 |
| ronny | yeah, i probably oversimplified the issue | 00:39 |
| lifeless | jelmer: as I said, I wouldn't make the index *at all*. | 00:41 |
| lifeless | s/make/map/ | 00:41 |
| poolie | jelmer IMO it should remember it as 'versioned' and then commit should build the index implicitly | 00:41 |
| lifeless | looks like poolie agrees with me :) | 00:41 |
| lifeless | poolie: 'commit -A' in git updates the index from the current disk, for paths already in the index. | 00:41 |
| poolie | there is a bit of a question of where you would keep that | 00:41 |
| poolie | is this for using bzr in a git working tree, or just committing to a git repo? | 00:41 |
| jelmer | bzr in a git working tree | 00:42 |
| ronny | one could view the index as temporary commit on top of the actual tip | 00:43 |
| poolie | 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 |
| poolie | ronny: i know what it is thanks | 00:43 |
| poolie | we just have a different model and we're trying to map them across | 00:43 |
| poolie | so, anyhow, then commit would need to re-add the files already in the index that match the commit parameters | 00:44 |
| lifeless | and back out unselected ones to the last commit state | 00:45 |
| lifeless | poolie: I think you are proposing exactly what I am | 00:45 |
| poolie | right | 00:45 |
| jfroy | 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 |
| jfroy | 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:53 |
| jfroy | *and update the branch path of a lightweight checkout of that branch | 00:54 |
| poolie | jfroy: hi, will 'bzr bind NEWLOCATION' do it? | 00:57 |
| jfroy | poolie: no, it also errors out | 00:58 |
| === emmajane is now known as emmajane_scotch | ||
| mrooney | 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 |
| mrooney | Will I get anything to improve that | 01:02 |
| spiv | mrooney: latest bzr-svn is much better than the version in Intrepid | 01:08 |
| spiv | mrooney: and it in turn requires a more recent bzr than 1.6.1-1 | 01:09 |
| lifeless | mrooney: there is a major version upgrade to bzr-svn. much goodness. | 01:09 |
| spiv | Hopefully the ~bzr PPA has the current bzr-svn package, it usually does. | 01:09 |
| mrooney | spiv: 0.5.3-1? | 01:13 |
| spiv | mrooney: yeah | 01:13 |
| === jelmer is now known as Guest68274 | ||
| mrooney | oh for the PPA dependency, do I have to manually add that for it to work? | 01:16 |
| mrooney | oh no here we go I think | 01:16 |
| mrooney | oh no! this works differently | 01:18 |
| mrooney | before if my username didn't match and I just hit enter, it would ask me for the username | 01:18 |
| mrooney | now it just changes to "None password: " | 01:18 |
| mrooney | how can I specify a username? | 01:18 |
| spiv | mrooney: I think bzr-svn uses the same authentication.conf as the rest of bzr | 01:21 |
| spiv | mrooney: bzr help authentication | less | 01:21 |
| mrooney | okay, well the None user thing seems to be a regression | 01:22 |
| SamB | I would have expected it to use subversions authentication cache ... | 01:22 |
| spiv | mrooney: or maybe you can just stick the username in the URL? | 01:22 |
| spiv | mrooney: yeah, it does sound like a regression. | 01:22 |
| SamB | just make a bug | 01:23 |
| mrooney | yes that does work if I put it in the right place! | 01:23 |
| Guest68274 | SamB: it also uses the svn authentication cache | 01:26 |
| Guest68274 | SamB: but it won't store new credentials into the svn cache | 01:27 |
| mrooney | sweet bzr: ERROR: exceptions.AssertionError ! | 01:29 |
| lifeless | mrooney: try running 'svn log URL' to get svn to cache the credentials, that used to work | 01:30 |
| mrooney | lifeless: well I got the credentials to work I think | 01:31 |
| mrooney | the AssertionError came in the middle of a branch | 01:31 |
| mrooney | multiple revisions in | 01:31 |
| mrooney | Expected <CachingRevisionMetadata for revision 5, path in repository '4c6ca7b2-8423-0410-87e0-f25a40cf7e9c'> got <CachingRevisionMetadata for revision 4, path in repository '4c6ca7b2-8423-0410-87e0-f25a40cf7e9c'> | 01:33 |
| lifeless | mrooney: interesting | 01:34 |
| lifeless | unfortunatly the bzr-svn author is asleep right now | 01:35 |
| lifeless | could you file a bug ? | 01:35 |
| mrooney | sure, against bzr? | 01:35 |
| Guest68274 | lifeless: no, I'm not :-) | 01:35 |
| lifeless | mrooney: bzr-svn please | 01:35 |
| Guest68274 | mrooney: is this bzr-svn 0.5.3? | 01:36 |
| mrooney | Guest68274: yeah, from the PPA | 01:36 |
| lifeless | Guest68274: oh, I didn't recognise you | 01:36 |
| === Guest68274 is now known as jelmer | ||
| mrooney | " svn /usr/lib/python2.5/site-packages/bzrlib/plugins/svn [0.5.3]" | 01:36 |
| mrooney | jelmer: http://paste.pocoo.org/show/109661/ | 01:39 |
| mrooney | that should be helpful I hope! | 01:40 |
| mrooney | it seems to get to roughly 30/1000 before dying | 01:40 |
| jelmer | mrooney: the repository is not public, I presume? | 01:48 |
| mrooney | jelmer: that is true :) | 01:52 |
| === abentley1 is now known as abentley | ||
| jelmer | mrooney: please file a bug | 02:01 |
| mrooney | jelmer: okay, can you give me a title for it? | 02:01 |
| jelmer | mrooney: what sort of changes do "svn log -v -r4" and "svn log -v -r5" report? | 02:02 |
| mrooney | jelmer: -r4 is a commit "manufactured by cvs2svn to create branch XX" | 02:04 |
| jelmer | mrooney: what sort of changes does it contain though? | 02:04 |
| jelmer | mrooney: file edits, file adds, deletes? | 02:05 |
| mrooney | Changed paths: | 02:05 |
| mrooney | A /branches/XX (from /trunk:3) | 02:05 |
| mrooney | D /branches/XX/CVSROOT | 02:05 |
| mrooney | and then r5 seems to be...nothing? | 02:05 |
| mrooney | jelmer: But the error doesn't appear until decently past r5, does that still make sense? | 02:07 |
| mrooney | the last number I seem to see is "copying revision 31/1000" | 02:10 |
| jelmer | mrooney: "revision without changes causes exception" would be a good title | 02:10 |
| jelmer | mrooney: bzr-svn should be warning you that you are cloning Subversion repository as branch. | 02:11 |
| mrooney | yes it is indeed | 02:11 |
| jelmer | mrooney: any reason you're cloning the repository root anyway, rather than using svn-import ? | 02:12 |
| jelmer | The latter should not trigger this bug | 02:12 |
| mrooney | I don't know, I just want to have the whole svn repos with version history | 02:13 |
| mrooney | is there a better way? | 02:13 |
| jelmer | mrooney: yes, svn-import should do that | 02:13 |
| mrooney | it says to use svn-import to get individual branches in the warning | 02:13 |
| mrooney | it doesn't recommend using that instead | 02:13 |
| mrooney | jelmer: https://bugs.edge.launchpad.net/bzr-svn/+bug/348786 | 02:14 |
| ubottu | Ubuntu bug 348786 in bzr-svn "revision without changes causes exception" [Undecided,New] | 02:14 |
| mrooney | okay I must head out for today, but I can look into svn-import tomorrow if you recommend it | 02:14 |
| jelmer | mrooney: but you're looking to import the individual branches right? | 02:15 |
| mrooney | no | 02:15 |
| jelmer | mrooney: e.g. trunk/ as a separate branch | 02:15 |
| jelmer | mrooney: branches/foo as a separate branch, etc | 02:15 |
| mrooney | I basically want a backup of the svn repository, that I can pull from each night and be up to date | 02:16 |
| mrooney | having those as branches would be nice | 02:16 |
| mrooney | so then I want svn-import? | 02:16 |
| jelmer | mrooney: yes | 02:16 |
| mrooney | jelmer: okay, I will use --incremental I guess | 02:17 |
| mrooney | since I don't want to lose it all if it fails at the 25,000th rev :) | 02:17 |
| mrooney | I am guessing that is what --incremental will get me, at a slight speed loss? | 02:18 |
| jelmer | mrooney: it's failsafe even without --incremental | 02:18 |
| jelmer | mrooney: --incremental will give you a speed improvement | 02:19 |
| mrooney | ...interesting! | 02:19 |
| jelmer | as it will remember where you left off the import | 02:19 |
| mrooney | okay, I am off for now but this has made it much further using svn-import | 02:20 |
| mrooney | at 500 | 02:20 |
| mrooney | but, it says of /23902 | 02:20 |
| jelmer | it breaks again at r500? | 02:20 |
| mrooney | no it is still going :) | 02:20 |
| jelmer | ah good :-) | 02:20 |
| mrooney | and it actually ends at 28,000 something | 02:20 |
| mrooney | and using branch seemed to notice that correctly | 02:20 |
| mrooney | so I am not sure, what that means | 02:21 |
| jelmer | mrooney: not all svn revisions will be imported as bzr revisions | 02:21 |
| mrooney | oh okay, whereas with branch they would? | 02:21 |
| jelmer | mrooney: e.g. that revision 5 won't show up in the bzr repository created this way | 02:21 |
| mrooney | hm so you lose forced commits and their messages? | 02:22 |
| jelmer | mrooney: yes, you lose commits that don't touch any of the branches | 02:22 |
| jelmer | 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:23 |
| mrooney | oh okay, well thanks for your help and good work on bzr | 02:24 |
| mrooney | good night! | 02:24 |
| jelmer | gnight | 02:24 |
| === emmajane_scotch is now known as emmajane | ||
| johnf | Has anyone ever tried using bzr bd on a cdbs based package that only has a control.in in the repo? | 04:02 |
| johnf | hmm dpkg-buldpackage doesn't work either. Maybe time to read up on cdbs | 04:03 |
| spiv | jelmer: has the escaping of / in bzr-svn revids changed recently? | 04:11 |
| spiv | 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 | 04:12 |
| === abentley1 is now known as abentley | ||
| spiv | jelmer: I'll just file a bug :) | 04:15 |
| spiv | jelmer: https://bugs.edge.launchpad.net/bzr-svn/+bug/348805 | 04:20 |
| ubottu | Ubuntu bug 348805 in bzr-svn "Incompatible change to path escaping in revision-id mapping" [Undecided,New] | 04:20 |
| lifeless | igc: ping; any chance of a reviewof my commit branch? | 04:49 |
| igc | lifeless: probably not today unfortunately - I didn't sleep last night so I'm not awake enough for a review that important | 04:55 |
| poolie | lifeless: i possibly can but i'm going to finish that mail first | 04:56 |
| igc | lifeless: I can tomorrow if no-one beats me to it | 04:56 |
| lifeless | igc: thanks | 04:59 |
| lifeless | poolie: no worries; that mail has priority :) | 04:59 |
| igc | 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:03 |
| lifeless | igc: thanks | 05:04 |
| === `6og is now known as Kamping_Kaiser | ||
| BasicOSX | pyftpdlib working nicely with python2.6, good job | 05:55 |
| lifeless | well I'm done for the day modulo interest-fiddles | 07:05 |
| vila | hi all | 07:23 |
| vila | BasicOSX: glad you like it ;-) | 07:24 |
| CBro2007 | bzr: ERROR: These branches have diverged. Use the merge command to reconcile them. | 08:09 |
| CBro2007 | I get this error when I do a "bzr pull /goldrepo" | 08:10 |
| CBro2007 | why is it saying that the branches have diverged? | 08:10 |
| CBro2007 | Is it good to use pull or should I use merge? | 08:10 |
| CBro2007 | I basically have a MAIN trunk where the gold copy of the app resides... every developer has his own FEATURE branch | 08:11 |
| CBro2007 | 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 |
| CBro2007 | should I use merge or pull? | 08:11 |
| CBro2007 | or get them to infact use... merge or pull? | 08:12 |
| bob2 | diverged = one is not a subset of the other | 08:14 |
| bob2 | ie they're not just out of sync, they have both made independent commits the other has not picked up | 08:14 |
| CBro2007 | but that will always be the case wouldn't it | 08:14 |
| bob2 | no | 08:15 |
| CBro2007 | I mean in reality developers will constantly keep committing changes to their own branch | 08:15 |
| CBro2007 | 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 |
| CBro2007 | is that what you are saying? | 08:16 |
| bob2 | no | 08:16 |
| bob2 | it will vary depends on what you and your developers do | 08:16 |
| CBro2007 | yeah but I just told you what they will do | 08:16 |
| CBro2007 | they will work on feature branches | 08:17 |
| lifeless | CBro2007: if its a feature branch they should merge from trunk | 08:17 |
| CBro2007 | and once they are happy with their changes they will tell me which rev no committed copy I should merge into trunk | 08:17 |
| lifeless | CBro2007: if its a mirror they should pull | 08:17 |
| CBro2007 | I suppose I am using a FEATURE branch then eh? | 08:17 |
| CBro2007 | so when they do a merge they would still keep their local changes yeah? | 08:18 |
| lifeless | yes | 08:20 |
| lifeless | have you experimented with merge | 08:20 |
| CBro2007 | yeah i have | 08:21 |
| CBro2007 | whats the "pending merges" | 08:21 |
| CBro2007 | ? | 08:21 |
| CBro2007 | it seems like local changes have to be COMMITTED before you can do a MERGE | 08:22 |
| bob2 | yes | 08:22 |
| lifeless | CBro2007: so you do a merge, and bzr leaves the result wwaiting for review | 08:23 |
| lifeless | you review it and commit | 08:23 |
| lifeless | and then you can continue | 08:23 |
| CBro2007 | ok cool | 08:23 |
| CBro2007 | get it | 08:23 |
| CBro2007 | its pretty cool when you get the hang of it | 08:23 |
| lifeless | we think so :) | 08:24 |
| CBro2007 | so I am thinking that the merge should work both ways - trunk to feature branch and vice versa | 08:24 |
| CBro2007 | even if they are out of synch | 08:24 |
| lifeless | yes | 08:24 |
| CBro2007 | like someone has been adding stuff to trunk directly | 08:24 |
| CBro2007 | and someone to the feature branches | 08:24 |
| CBro2007 | and we can merge all at anytime yeah>? | 08:24 |
| lifeless | 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 |
| CBro2007 | yeah | 08:24 |
| CBro2007 | and I can also merge a given revision with the -r (n) if i wanted | 08:25 |
| CBro2007 | :) | 08:25 |
| CBro2007 | soon I will be full of "bazaar life" mr lifeless | 08:25 |
| CBro2007 | hahahhaha | 08:25 |
| lifeless | :) | 08:26 |
| lifeless | vila: so, I've spun up 18-way amazon on 8-way cores for testing... its fun | 08:26 |
| vila | lifeless: isn't it :-) | 08:26 |
| lifeless | finding some interesting bugs | 08:27 |
| lifeless | did you see my doctest bug ? | 08:27 |
| vila | lifeless: I don't think so, where ? tests.parallel ? | 08:27 |
| lifeless | bb | 08:28 |
| CBro2007 | wondering if I should let developers merge their shit into trunk directly | 08:38 |
| CBro2007 | :) | 08:38 |
| CBro2007 | or have them send it to me for review first | 08:39 |
| lifeless | CBro2007: what do they do at the moment ? | 08:41 |
| CBro2007 | nothing | 08:41 |
| CBro2007 | :) | 08:41 |
| CBro2007 | I am setting up bzr so we can start to share the code | 08:41 |
| lifeless | ok | 08:41 |
| CBro2007 | and they can make changes | 08:41 |
| lifeless | so I'd say don't add policy at the same time as adding technology | 08:41 |
| CBro2007 | but don't want them putting in shit willy nilly | 08:41 |
| CBro2007 | if they merged in stuff that is shit... it would be harder for me to get rid of it | 08:42 |
| lifeless | if at the moment the way they get their code deployed is 'cp to production', then thats basically willy nilly | 08:42 |
| CBro2007 | they are not coding at the moment | 08:42 |
| CBro2007 | its just been me all this while | 08:42 |
| CBro2007 | they are going to be jumping on board to work on more features | 08:42 |
| CBro2007 | but its still going to be a learning curve for them | 08:43 |
| CBro2007 | so I would still like to review some of their work before I merge it into the GOLD copy | 08:43 |
| CBro2007 | :) | 08:43 |
| CBro2007 | I know I sound like a dick.. but hey | 08:43 |
| CBro2007 | :) | 08:43 |
| lifeless | so, in which case, you should own 'gold' and merge features you're happy with | 08:45 |
| === Bambi_BOFH is now known as Kamping_Kaiser | ||
| === eMBee_ is now known as eMBee | ||
| maxb | Does anyone know if 1.13.1 will be reaching Debian sid soon? | 09:57 |
| lifeless | vila: so, command line arg or variable, for test suite munging | 10:35 |
| lifeless | actually, | 10:35 |
| lifeless | I know | 10:35 |
| lifeless | I will do shiny long needed refactorin | 10:36 |
| lifeless | g | 10:36 |
| vila | lifeless: I'm all ears :-) Refactoring what targeting what ? | 10:36 |
| kinkie | 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:38 |
| Kinnison | I would recommend branching inside the repo and then making lightweight checkouts into /src/workspace | 10:42 |
| Kinnison | that way you get the "space" savings you're interested in, without compromising your current workflow any | 10:42 |
| kinkie | ok. | 10:43 |
| LarstiQ | also making sure not to have working trees in the repo | 10:43 |
| Kinnison | Indeed | 10:43 |
| Kinnison | a treeless repo and a separate area for lightweight checkouts is what I do for these kinds of things | 10:43 |
| kinkie | That's what I also do, but I was wondering if it was easier to do something different ;) | 10:44 |
| lifeless | vila: suite modifications, chain, like I made log | 10:48 |
| vila | lifeless: Hmm, the alternative. I'm not totally convinced by it, but I see where you're going, | 10:50 |
| vila | the main point that makes me nervous is that it means adding a 'fake' test to represent the remote suite, | 10:50 |
| vila | which I find a bit artificial, but I may be wrong and it may be the best trade-off | 10:51 |
| vila | I think it should make remote(parallelized) possible and clearer though | 10:52 |
| lifeless | vila: test suite is a composite pattern | 10:52 |
| lifeless | so a test is a suite is a test | 10:52 |
| lifeless | jml: http://pybites.blogspot.com/2009/03/unittest-now-with-test-skipping-finally.html | 10:52 |
| vila | I think it also requires that such modifications be done last rather than first | 10:53 |
| lifeless | well | 10:55 |
| lifeless | I think the ordering will be important | 10:55 |
| lifeless | if thats what you mean | 10:55 |
| vila | yes | 10:55 |
| vila | we don't want TestInSubprocess to filtered out because its id doesn't match some pattern for example | 10:56 |
| vila | 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 | 10:57 |
| vila | lifeless: your refactoring will include putting randomize_suite and exclude_tests_by_re inside that chain right ? | 11:01 |
| lifeless | vila: do you have python 2.4 handy? | 11:20 |
| lifeless | vila: if so, can you tell me if the base TestSuite has __iter__ defined in 2.4 | 11:20 |
| vila | yes | 11:21 |
| vila | in unittest ? | 11:21 |
| lifeless | yes | 11:21 |
| vila | def __iter__(self): | 11:21 |
| vila | return iter(self._tests) | 11:21 |
| lifeless | so, regarding iter_suite_tests | 11:21 |
| lifeless | I see two possible approaches | 11:22 |
| lifeless | one is to say, if we iter, and it would break it (e.g. randomising), we should pass that responsibility onto children | 11:22 |
| lifeless | by e.g. passing --random to them too | 11:23 |
| vila | you mean children == subprocess, not children == tests right ? | 11:24 |
| lifeless | yes | 11:24 |
| lifeless | the other is to say, if we iter, the container should do what it needs to | 11:25 |
| lifeless | anyhow, nearly done | 11:25 |
| vila | Or we can make two chains: one post-load and one pre-run :-) | 11:27 |
| vila | lifeless: by the way, since randomizing was introduced to exhibit isolation problems (AFAIU) I wonder if it's still needed... | 11:29 |
| vila | I found more isolation problems by running test one by one than by randomizing the order | 11:29 |
| lifeless | I have no use for randomisation, never did :) | 11:30 |
| poolie | that was the point of it | 11:41 |
| lifeless | poolie: ok, well I'm not proposing to remove it | 11:43 |
| lifeless | it fits into this refactoring fine | 11:43 |
| lifeless | vila: not quite right :P | 11:58 |
| vila | lifeless: what ? | 11:58 |
| lifeless | [6/17475 in 8s] | 11:58 |
| lifeless | Ran 6 tests in 9.021s | 11:58 |
| vila | oh, your refactoring :) | 11:58 |
| vila | I like the elapsed time, try to keep it that way :) | 11:59 |
| lifeless | so | 12:00 |
| lifeless | http://paste.ubuntu.com/138181/ | 12:00 |
| nevans | 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:02 |
| lifeless | sure, set it in ~/.bazaar/locations.conf | 12:03 |
| lifeless | vila: what do you think [there was a tiny bug, its fixed] | 12:04 |
| lifeless | two teeny bugs, fixed :P | 12:05 |
| vila | lifeless: in ExcludeDecorator ? | 12:06 |
| vila | lifeless: ignoring the details, the design sounds good | 12:07 |
| lifeless | can I claim 'refactoring, please no new tests'? :) | 12:07 |
| lifeless | vila: with this design, a plugin can do all of BZR_PARALLEL | 12:07 |
| vila | lifeless: you two bugs were caught by the actual test suire right ? | 12:08 |
| lifeless | yes | 12:08 |
| vila | s/you/your/ | 12:08 |
| lifeless | [160/180 in 45s] test_selftest.TestTestResult.test_strict_with_known_failure | 12:08 |
| lifeless | ---------------------------------------------------------------------- | 12:08 |
| lifeless | Ran 180 tests in 45.973s | 12:08 |
| lifeless | selftest selftest | 12:08 |
| vila | refactoring under test suite umbrella doesn't require new tests :-) | 12:08 |
| vila | selftest -s bt.test_selftest :) | 12:09 |
| lifeless | bb:approve then? | 12:09 |
| vila | BB:APPROVE | 12:09 |
| vila | But I don't see a way to plugin into suite_decorators | 12:10 |
| vila | provided in builtins.py ? | 12:11 |
| lifeless | yes | 12:11 |
| vila | yeah ! :) | 12:11 |
| lifeless | Command.hooks['extend_command'] | 12:11 |
| lifeless | btw | 12:12 |
| lifeless | run 'bzr selftest selftest | 12:12 |
| lifeless | note the double printing of what we're testing | 12:12 |
| lifeless | something isn't isolated correctly | 12:12 |
| vila | ECANTREPRODUCE, bzr selftest selftest --no-plugins ? | 12:14 |
| vila | reproduced elsewhere | 12:15 |
| lifeless | kinkie: just mv /src/foo/bar /src/bar | 12:16 |
| lifeless | kinkie: or whatever | 12:16 |
| lifeless | kinkie: you may want to adjust some paths in ~/.bazaar/locations.conf | 12:17 |
| vila | lifeless: mv ~/lib/python/subunit ~/lib/python/subunitxx makes the double printing disappear | 12:18 |
| vila | not pointing fingers.... | 12:18 |
| lifeless | odd.. | 12:19 |
| lifeless | vila: its printed out in builtins.py | 12:22 |
| nevans | lifeless: thanks! of course. (I walked away from the computer right before you answered) | 12:23 |
| vila | lol, I bet that sys.stdout.write is coming back to hunt you !!! | 12:23 |
| vila | via a run_bzr or in a blackbox test or something :-) | 12:24 |
| lifeless | vila: sys.stdout is wrong | 12:24 |
| vila | lifeless: I know ! But yet :) | 12:24 |
| vila | using 'print' in builtins is wrong too | 12:24 |
| lifeless | yes | 12:27 |
| lifeless | jml: so, ConcurrentTestSuite, testtools will accept, or won't. | 12:27 |
| lifeless | jml: I need to know | 12:27 |
| vila | lifeless: bzr selftest -s bt.blackbox.test_selftest.TestOptions.test_subunit | 12:32 |
| vila | either gulty or victim | 12:33 |
| lifeless | ah | 12:34 |
| lifeless | I know what it will be | 12:34 |
| lifeless | the runner is not being contained | 12:34 |
| lifeless | or something like that | 12:34 |
| lifeless | probably guilty | 12:34 |
| * lifeless points fingers at whoever reviewed the test | 12:34 | |
| vila | LOL | 12:34 |
| * vila points finger to self for still missing a test farm running isolated tests on a regular basis :) | 12:35 | |
| lifeless | do you know if its possible to have an optional option | 12:37 |
| lifeless | e.g. --parallel[=foo] ? | 12:38 |
| vila | came under discussion with jam recently: no, but we should | 12:38 |
| vila | work-around : use a magic value :-/ | 12:39 |
| vila | i.e. --parallel=0 => cpucount() | 12:39 |
| vila | lifeless: can you take http://paste.ubuntu.com/138205/ ? | 12:42 |
| vila | rhaa http://paste.ubuntu.com/138206/ | 12:42 |
| lifeless | vila: thats better, but you know what would be awesome | 12:43 |
| vila | you know I don't (yet :) | 12:44 |
| lifeless | vila: do that printing by calling something [not foo.stream.write!] on the result object | 12:44 |
| vila | 'that' ? | 12:44 |
| vila | you realized -v and progress bar prints *during* execution, right ? | 12:45 |
| lifeless | 'that' == 'testing: ...' | 12:46 |
| vila | haa, so it can tell: testing 'this' 'here' ? | 12:53 |
| vila | I was wondering about remote testing issues if you test from os1 to os2... | 12:54 |
| vila | .. cans of worms | 12:54 |
| * vila needs to eat | 12:55 | |
| lifeless | I'm off to be | 12:56 |
| lifeless | http://paste.ubuntu.com/138212/ | 12:56 |
| lifeless | d | 12:56 |
| lifeless | thats my reimagined version | 12:56 |
| lifeless | it looks better to me | 12:56 |
| lifeless | night all | 12:57 |
| blizzz | hi, i have trac installed on a ubuntu 8.10 server. i want to use trac-bzr, but i get the warning: Warning: Can't synchronize with the repository (Unsupported version control system "bzr". Check that the Python support libraries for "bzr" are correctly installed.) | 14:12 |
| blizzz | i am new to both bzr and trac, so i don't really know where to look... google search didn't help either | 14:13 |
| === thekorn_ is now known as thekorn | ||
| jam | morning vila | 14:29 |
| * blizzz found a solutiob | 14:33 | |
| jam | vila: http://paste.ubuntu.com/138325/ | 15:23 |
| === beuno_ is now known as beuno | ||
| Tak|work | jelmer: have you tried my branch of the md-bzr addin lately? | 15:28 |
| Tak|work | jelmer: also, hi | 15:28 |
| jam | vila: http://paste.ubuntu.com/138326/ | 15:29 |
| === jelmer_ is now known as Guest7470 | ||
| === cprov is now known as cprov-lunch | ||
| === AnMaster_ is now known as AnMaster | ||
| === cprov-lunch is now known as cprov | ||
| === statik` is now known as statik | ||
| SamB | Is there a good way to see what the default push target is from a (non-python) script? | 17:04 |
| asabil | SamB: using bzr info ? | 17:07 |
| SamB | hmm. | 17:07 |
| SamB | I suppose that's not much dirtier than a lot of the tricks dvc already uses ... | 17:07 |
| asabil | SamB: I think you can also use the xml-output plugin | 17:08 |
| asabil | well gtg now, ttyl | 17:08 |
| stbuehler | how can i get bzr log to show the svn revision numbers? (debian testing/unstable bzr 1.13~rc1 + bzr-svn 0.5.3 ) | 17:25 |
| Peng_ | stbuehler: It doesn't do it for revisions created by bzr. | 17:25 |
| stbuehler | another reason never to use it again -.- | 17:26 |
| stbuehler | thx for the info | 17:26 |
| stbuehler | and please update at least the docs to mention this | 17:26 |
| jelmer_ | hmm? | 17:28 |
| Peng_ | Hiya jelmer_. | 17:29 |
| jelmer_ | Peng_: what's up with lighttpd and bzr-svn? | 17:30 |
| Peng_ | jelmer_: I don't know. What he said. | 17:36 |
| jelmer_ | Peng_: 18:25 < stbuehler> another reason never to use it again -.- | 17:37 |
| mrooney | jelmer_: the svn-import seems to have been a success! | 17:37 |
| mrooney | although how do I update it, I tried doing a pull but it isn't a branch | 17:38 |
| Peng_ | jelmer_: I don't know about that. | 17:38 |
| Peng_ | Oh, he upgraded to bzr-svn 0.5! That's nice. | 17:38 |
| Peng_ | jelmer_: He has a point about documenting the revno thing. I only found out about it after asking you. Not that I read the docs anyway... :P | 17:39 |
| jelmer_ | mrooney: you can run svn-import again | 17:39 |
| jelmer_ | Peng_: well, he didn't exactly seem happy about the upgrade.. | 17:40 |
| Peng_ | Indeed. | 17:40 |
| Peng_ | I don't know anything about it, though. | 17:40 |
| mrooney | jelmer_: so it doesn't have a memory of the location, I should specify it each time? | 17:41 |
| jelmer_ | mrooney: yeah | 17:41 |
| mrooney | I basically want to run it nightly to have a backup | 17:41 |
| mrooney | okay | 17:41 |
| mrooney | jelmer_: how functional, thanks :) | 17:45 |
| sohail | hey guys, I have a versioned directory that I want ot move into its own repository, maintaining history | 19:24 |
| sohail | any ideas on how to do this? | 19:25 |
| sohail | main use case for this is that this directory is never branched and I keep ediitng branched versions by accident | 19:25 |
| nekohayo | hmm. is there a way to apply a .patch easily? Tried bzr apply and bzr patch, no luck? | 19:42 |
| Peng_ | nekohayo: What kind of patch? A regular .patch file, or a bzr bundle? For the latter, "bzr merge foo.patch"; for the former, I dunno. | 19:44 |
| nekohayo | a regular patch I guess.. I usually make patches by doing bzr diff>foo.patch | 19:45 |
| Peng_ | Why are you sending around regular patches? You've got a DVCS! Use it! :D | 19:48 |
| nekohayo | peng_ in normal circumstances yes, but someone sent me a patch by mail :) | 19:54 |
| thumper | sohail: I know it can be done, but I don't know how | 20:42 |
| thumper | sohail: perhaps jam recalls | 20:42 |
| thumper | jam: splitting a versioned directory out of a branch into its own branch | 20:43 |
| jam | thumper, sohail: So there is a hidden command 'bzr split' which effectively does this, though I think you have to be in a 'rich-root' format for it to 'just work'. | 20:43 |
| jam | The direct alternative is: | 20:43 |
| jam | bzr branch project newsubproj | 20:43 |
| jam | cd newsubproj | 20:44 |
| jam | rm * (not the dir I want) | 20:44 |
| jam | mv dir/* . | 20:44 |
| jam | rmdir dir | 20:44 |
| jam | etc | 20:44 |
| jam | sohail: but do you want to continue having this subdir in the project? Just not edit it most of the time? | 20:45 |
| sohail | jam no I want it to be totally separate | 21:04 |
| sohail | essentially, I have a "training" sub-directory which I use to store the tex sources for training sessions | 21:05 |
| sohail | don't really need to branch it. I'll look into bzr split | 21:05 |
| sohail | thanks thumper & jam | 21:05 |
| thumper | sohail: bzr split will branch it | 21:05 |
| thumper | sohail: I'm pretty sure it is just a nicer UI around what jam suggested | 21:06 |
| sohail | I guess I could just do a branch and remove everything else like you say | 21:06 |
| jelmer_ | 'evening jam, thumper | 21:07 |
| jam | hi jelmer_ | 21:07 |
| * jelmer_ just finished some performance improvements to bzr-git | 21:08 | |
| jelmer_ | it now works ok on medium-size repositories, such as the git one | 21:08 |
| Peng_ | jelmer_: Congrats. :) | 21:09 |
| thumper | hi jelmer_ | 21:09 |
| thumper | jelmer_: excellent | 21:10 |
| thumper | jelmer_: we have the bzr-git stuff landed in LP now | 21:10 |
| thumper | jelmer_: no UI yet to request it though | 21:10 |
| jelmer_ | thumper: ah, cool | 21:10 |
| thumper | jelmer_: we're going to test it over the current cycle | 21:10 |
| jelmer_ | thumper: is there some other way to request imports? | 21:10 |
| thumper | jelmer_: yes, there is an import your project button | 21:11 |
| jelmer_ | thumper: I have URLs for some small repositories that would be worth testing with | 21:11 |
| thumper | jelmer_: feel free to email them to me | 21:11 |
| jelmer_ | thumper: will do | 21:11 |
| jelmer_ | trying the kernel now >-) | 21:14 |
| jelmer_ | thumper: looks like the kernel is actually doable | 21:16 |
| jelmer_ | thumper: no huge memory usage anymore, albeit a bit slow | 21:17 |
| gnomefreak | what does bzr-builddeb do differently than dpkg-buildpackage with patch handling | 21:17 |
| jelmer_ | gnomefreak: it can set tags for you when you release | 21:19 |
| jelmer_ | gnomefreak: it provides revision specifiers in bzr for accessing debian versions | 21:20 |
| jelmer_ | (e.g. "bzr ls -rpackage:1.0-1") | 21:20 |
| gnomefreak | jelmer_: dpkg-buildpackage fails to build makes a patch fail where as bzr builddeb doesnt make it fail. same source same bzr branch | 21:20 |
| jelmer_ | it can automatically check out upstream if that's in bzr/svn | 21:20 |
| jelmer_ | gnomefreak: what does dpkg-buildpackage provide exactly? | 21:20 |
| gnomefreak | since hardy doesnt have bzr-builddeb i have no choice | 21:20 |
| gnomefreak | jelmer_: it has to be used oin hardy since i get errors about bzr-builddeb not finding module or something along those lines | 21:21 |
| jelmer_ | gnomefreak: but I mean, what patch handling are you talking about? | 21:22 |
| gnomefreak | jelmer_: dpkg-buildpackage in hardy the build fails on a patch where as bzr-bd doesnt fail at all | 21:22 |
| jelmer_ | gnomefreak: what sort of patch? | 21:22 |
| jelmer_ | gnomefreak: dpatch/quilt/cdbs/... patch ? | 21:23 |
| gnomefreak | +++ mozilla/config/autoconf.mk.in | 21:23 |
| jelmer_ | or is the packaging branch in bzr-loom ? | 21:23 |
| gnomefreak | quilt | 21:23 |
| gnomefreak | bzr-loom? | 21:23 |
| gnomefreak | all mozilla packages that we package are quilt cdbs now | 21:24 |
| jelmer_ | gnomefreak: afaik bzr-builddeb just runs a builder (such as dpkg-buildpackage), it doesn't worry about patches in debian/patches/ itself | 21:24 |
| gnomefreak | jelmer_: my point | 21:24 |
| jelmer_ | gnomefreak: does debuild work? | 21:24 |
| gnomefreak | did try it i guess i should | 21:24 |
| gnomefreak | there is the failed build http://launchpadlibrarian.net/24369029/buildlog_ubuntu-hardy-i386.lightning-sunbird_0.9%2Bnobinonly-0ubuntu3~8.04~jjv1_FAILEDTOBUILD.txt.gz on my PPA the other 2 built fine | 21:25 |
| gnomefreak | debuild fails the same way on same patch | 21:27 |
| gnomefreak | if the patch was a problem than intrepid and jaunty would have failed as well | 21:27 |
| gnomefreak | im fairly sure building bzr bzr-bd python and friends is a bit more work than i would have thought | 21:32 |
| jelmer_ | gnomefreak: sorry, no idea :-/ | 21:35 |
| * jelmer_ joins nevans in saying spiv/lifeless's work on HPSS push rocks \o/ | 21:35 | |
| gnomefreak | jelmer_: thanks i have to get back to this build. does bzr-builddeb need a version of python or any version will work? | 21:37 |
| gnomefreak | if i can get away without building all python deps than it shouldnt take too long | 21:38 |
| jelmer_ | gnomefreak: I think 2.4 (which dapper has) should be sufficient | 21:40 |
| gnomefreak | jelmer_: ok thanks ill give it a shot tonight i hope | 21:41 |
| spiv | jelmer_: thanks :) | 22:02 |
| lzhang | stacked branches in bzr | 22:04 |
| lzhang | what are they for? | 22:04 |
| Peng_ | lzhang: So you can make a branch without keeping the entire history of the parent on your disk. | 22:04 |
| Peng_ | lzhang: It's like heavyweight vs. lightweight checkouts. | 22:04 |
| sohail | jam, thumper fyi I just did it the manual way :-) | 22:14 |
| lzhang | Peng_: what's the distinction between a stacked branch and one created with the --lightweight flag | 22:14 |
| thumper | lzhang: a lightweight branch is a checkout and points to the repository and branch which are often in a different directory | 22:15 |
| thumper | lzhang: a stacked branch is one where the branch contains only the revisions that are not in the stacked on branch's repository | 22:15 |
| fullermd | There's no such thing as a --lightweight branch. That's a checkout. | 22:17 |
| fullermd | So, the difference is that one's a checkout, and the other's a branch ;) | 22:17 |
| lzhang | I see, makes sense | 22:17 |
| sohail | how do you guys back up your bzr repositories? | 22:24 |
| sohail | I'm using rsync for offsite backup | 22:25 |
| lzhang | no need, it's distributed all over the place for us | 22:25 |
| lzhang | every dev has a copy | 22:25 |
| sohail | sure but I mean for personal repositories | 22:25 |
| sohail | by "you guys" I meant "users of bzr" | 22:25 |
| lifeless | sohail: I push it somewhere :) | 22:25 |
| sohail | :-) | 22:25 |
| lzhang | oh, time machine hehe | 22:25 |
| sohail | rsync should be safe right? | 22:26 |
| lifeless | as long as noone is committing | 22:26 |
| lzhang | ya man totally | 22:26 |
| lifeless | or pushing | 22:26 |
| sohail | right now I have it distributed across 3 machines locally but I am making an offsite backup | 22:26 |
| lzhang | is there anything like svn's vendor branches for bzr? | 22:27 |
| sohail | svn does vendor branches by accident | 22:28 |
| lifeless | sohail: rsync reads the file system but isn't guaranteed to get a consistent snapshot of databases; and bzr is basically a databas.e | 22:30 |
| lifeless | sohail: which is why you can't be altering a repo when it runs and get a safe backup | 22:30 |
| lzhang | sohail: what does that mean | 22:30 |
| sohail | lifeless, so how would I push onto my server? | 22:30 |
| lifeless | sohail: 'bzr push' :) | 22:30 |
| sohail | that' sit? | 22:30 |
| lifeless | its what I do to make sure I have another copy of my code | 22:31 |
| sohail | really | 22:31 |
| lifeless | you can use rsync, just don't be committing/pulling/pushing while rsync runs | 22:31 |
| sohail | yeah I get that | 22:31 |
| sohail | I should be using anacron to schedule this too.. | 22:32 |
| * igc breakfast | 22:37 | |
| davidstrauss | We need something like this: http://www.webdesignerdepot.com/2009/03/intro-to-git-for-web-designers/ | 22:41 |
| lzhang | I say you guys need to fix up launchpad | 22:42 |
| lzhang | github is way cooler | 22:42 |
| lzhang | if you want a designer to use bzr then there has to be a gui client that looks like this | 22:43 |
| lzhang | http://versionsapp.com/ | 22:43 |
| lifeless | davidstrauss: wow, someone vomited on that web page | 22:43 |
| davidstrauss | lifeless: lol | 22:44 |
| sohail | lzhang, a designer is not going to use bzr... svn is way easier | 22:53 |
| sohail | though I guess a gooey makes it easier | 22:54 |
| lifeless | well, designers do use bzr | 23:00 |
| lifeless | so there is at least an existence proof that they do :) | 23:00 |
| wgrant | How is svn easier than bzr? | 23:07 |
| jelmer_ | wgrant: it has more polished GUI's, especially on windows | 23:08 |
| wgrant | Ah. | 23:09 |
| wgrant | But GUIs are overrated. | 23:09 |
| sohail | wgrant, you'd probably have some kind of time explaining that to a designer | 23:15 |
| lifeless | jam: do you want to talk about fetch? | 23:18 |
| lifeless | jam: also, is the commit stuff approve/tweak/whatever? | 23:18 |
| lifeless | jml: ping | 23:20 |
| jml | lifeless: pong | 23:21 |
| lifeless | so, I want to land bzr parallel test support to trunk | 23:21 |
| lifeless | poolie is happy with a [for-this-only] dependency on testtools | 23:21 |
| lifeless | or I can land the bits I wrote in evenings in bzr | 23:21 |
| lifeless | there are two classes I think have nothing to do with bzr, ConcurrentTestSuite and ThreadsafeForwardingResult | 23:22 |
| jml | lifeless: ok. so you think those should go into testtools | 23:27 |
| lifeless | I think that few people are finding 'bzrlib' when they search for python test support stuff | 23:27 |
| lifeless | have a look at this patch: http://paste.ubuntu.com/138212/ | 23:28 |
| lifeless | you can see that all the bzr machinery for achieving parallelisation is separate to these classes | 23:29 |
| jml | sure. | 23:30 |
| jml | why the startTest / stopTest around all the calls in ThreadsafeForwardingResult? | 23:30 |
| lifeless | it aggregates | 23:31 |
| lifeless | consider two threads each with a test that takes 1 second to execute | 23:31 |
| lifeless | the point of TFR is to make sure the target sees t1.start, t1.RESULT, t1.stop, t2.start, t2.RESULT, t2.stop | 23:31 |
| jml | except if one of those tests adds two errors, then the output will be a bit confusing | 23:32 |
| lifeless | yes, though calling addError twice is not well defined anyhow | 23:32 |
| lifeless | stock TestResult in verbose mode will look ugly if you do that, for instance | 23:34 |
| lifeless | sorry, TextTestResult | 23:34 |
| jml | agreed. it happens a lot in testing concurrent apps though. | 23:34 |
| lifeless | ewll | 23:34 |
| lifeless | I could make it batch until stopTest | 23:34 |
| lifeless | so stopTest would do result.start, for status in self.statii: status(result); del self.status[:]; result.stop | 23:35 |
| lifeless | bah, to clever in spelling for my own good, but you get the idea | 23:36 |
| jml | my hunch is that some people would want that, and others would want what you have in the patch. | 23:36 |
| === mario_ is now known as pygi | ||
| lifeless | I think that while unittest is unclear, but essentially implies that you should call just one status, its appropriate to stay with that | 23:37 |
| lifeless | also hav eyou seen the upstream skip stuff now? | 23:37 |
| jml | no, not yet. | 23:37 |
| jml | I've seen the Twisted bug report about it. | 23:37 |
| lifeless | http://svn.python.org/view/python/trunk/Lib/unittest.py?r1=70555&r2=70554&pathrev=70555 | 23:37 |
| lifeless | http://pybites.blogspot.com/2009/03/unittest-now-with-test-skipping-finally.html | 23:38 |
| jml | wtf is ClassTestSuite? | 23:38 |
| lifeless | exactly | 23:38 |
| lifeless | I'm rather unhappy with the patch | 23:38 |
| lifeless | but perhaps I'm just coloured by liking clear code | 23:39 |
| lifeless | anyway | 23:40 |
| lifeless | jml: what I need is 'in princple yes, this is testtools material, submit to bzr without them and we'll move testtools stuff through' or | 23:41 |
| lifeless | 'no, I'm not happy with this in the near/immediate future, put it in bzr' | 23:41 |
| jml | lifeless: in principle I'm happy with concurrency support in testtools. | 23:41 |
| jml | lifeless: so, yes. | 23:41 |
| lifeless | ok | 23:41 |
| lifeless | I'll get a branch of testtools with both of these in it; that will let us review and discuss it, and put a patch for bzrlib depending on that branch | 23:42 |
| lifeless | and I'll make any changes you need | 23:42 |
| jml | lifeless: thanks. | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!