[00:01] <mrooney> lifeless: awesome thanks!
[00:02] <mrooney> my wildest dreams have true
[00:02] <mrooney> have come true, that is
[00:04] <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:18] <jelmer> lifeless: so, different topic
[00:19] <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:22] <lifeless> jelmer: remind me?
[00:23] <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:25] <jelmer> ahh
[00:25] <jelmer> so no staging area-like things?
[00:25] <lifeless> hell no
[00:26] <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:27] <lifeless> I wouldn't map it, I would give bzr running against a git tree bzr semantics.
[00:28] <lifeless> igc: so commit is good yeah?
[00:28] <jelmer> lifeless: well, I have to map git semantics to bzr semantics
[00:28] <jelmer> lifeless: that's a lot easier if bzr has a staging area :-P
[00:29] <lifeless> jelmer: You'll need to explain this for me, because I don't see why
[00:35] <jelmer> lifeless: so, what I'm trying to figure out is what "bzr add" should do in a git working tree
[00:36] <lifeless> jelmer: it should make sure the files are versioned
[00:37] <ronny> well, git add works on a  "add to the content of next commit basis"
[00:38] <poolie> lifeless: i just filed bug 348750 quoting your mail
[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:39] <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:41] <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:42] <jelmer> bzr in a git working tree
[00:43] <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:44] <poolie> so, anyhow, then commit would need to re-add the files already in the index that match the commit parameters
[00:45] <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:53] <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:54] <jfroy> *and update the branch path of a lightweight checkout of that branch
[00:57] <poolie> jfroy: hi, will 'bzr bind NEWLOCATION' do it?
[00:58] <jfroy> poolie: no, it also errors out
[01:02] <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:08] <spiv> mrooney: latest bzr-svn is much better than the version in Intrepid
[01:09] <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:13] <mrooney> spiv: 0.5.3-1?
[01:13] <spiv> mrooney: yeah
[01:16] <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:18] <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:21] <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:22] <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:23] <SamB> just make a bug
[01:23] <mrooney> yes that does work if I put it in the right place!
[01:26] <Guest68274> SamB: it also uses the svn authentication cache
[01:27] <Guest68274> SamB: but it won't store new credentials into the svn cache
[01:29] <mrooney> sweet bzr: ERROR: exceptions.AssertionError !
[01:30] <lifeless> mrooney: try running 'svn log URL' to get svn to cache the credentials, that used to work
[01:31] <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:33] <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:34] <lifeless> mrooney: interesting
[01:35] <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:36] <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] <mrooney> "  svn                  /usr/lib/python2.5/site-packages/bzrlib/plugins/svn [0.5.3]"
[01:39] <mrooney> jelmer: http://paste.pocoo.org/show/109661/
[01:40] <mrooney> that should be helpful I hope!
[01:40] <mrooney> it seems to get to roughly 30/1000 before dying
[01:48] <jelmer> mrooney: the repository is not public, I presume?
[01:52] <mrooney> jelmer: that is true :)
[02:01] <jelmer> mrooney: please file a bug
[02:01] <mrooney> jelmer: okay, can you give me a title for it?
[02:02] <jelmer> mrooney: what sort of changes do "svn log -v -r4" and "svn log -v -r5" report?
[02:04] <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:05] <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:07] <mrooney> jelmer: But the error doesn't appear until decently past r5, does that still make sense?
[02:10] <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:11] <jelmer> mrooney: bzr-svn should be warning you that you are cloning Subversion repository as branch.
[02:11] <mrooney> yes it is indeed
[02:12] <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:13] <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:14] <mrooney> jelmer: https://bugs.edge.launchpad.net/bzr-svn/+bug/348786
[02:14] <mrooney> okay I must head out for today, but I can look into svn-import tomorrow if you recommend it
[02:15] <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:16] <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:17] <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:18] <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:19] <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:20] <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:21] <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:22] <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:23] <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:24] <mrooney> oh okay, well thanks for your help and good work on bzr
[02:24] <mrooney> good night!
[02:24] <jelmer> gnight
[04:02] <johnf> Has anyone ever tried using bzr bd on a cdbs based package that only has a control.in in the repo?
[04:03] <johnf> hmm dpkg-buldpackage doesn't work either. Maybe time to read up on cdbs
[04:11] <spiv> jelmer: has the escaping of / in bzr-svn revids changed recently?
[04:12] <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:15] <spiv> jelmer: I'll just file a bug :)
[04:20] <spiv> jelmer: https://bugs.edge.launchpad.net/bzr-svn/+bug/348805
[04:49] <lifeless> igc: ping; any chance of a reviewof my commit branch?
[04:55] <igc> lifeless: probably not today unfortunately - I didn't sleep last night so I'm not awake enough for a review that important
[04:56] <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:59] <lifeless> igc: thanks
[04:59] <lifeless> poolie: no worries; that mail has priority :)
[05:03] <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:04] <lifeless> igc: thanks
[05:55] <BasicOSX> pyftpdlib working nicely with python2.6, good job
[07:05] <lifeless> well I'm done for the day modulo interest-fiddles
[07:23] <vila> hi all
[07:24] <vila> BasicOSX: glad you like it ;-)
[08:09] <CBro2007> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
[08:10] <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:11] <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:12] <CBro2007> or get them to infact use... merge or pull?
[08:14] <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:15] <bob2> no
[08:15] <CBro2007> I mean in reality developers will constantly keep committing changes to their own branch
[08:16] <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:17] <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:18] <CBro2007> so when they do a merge they would still keep their local changes yeah?
[08:20] <lifeless> yes
[08:20] <lifeless> have you experimented with merge
[08:21] <CBro2007> yeah i have
[08:21] <CBro2007> whats the "pending merges"
[08:21] <CBro2007> ?
[08:22] <CBro2007> it seems like local changes have to be COMMITTED before you can do a MERGE
[08:22] <bob2> yes
[08:23] <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:24] <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:25] <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:26] <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:27] <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:28] <lifeless> bb
[08:38] <CBro2007> wondering if I should let developers merge their shit into trunk directly
[08:38] <CBro2007> :)
[08:39] <CBro2007> or have them send it to me for review first
[08:41] <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:42] <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:43] <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:45] <lifeless> so, in which case, you should own 'gold' and merge features you're happy with
[09:57] <maxb> Does anyone know if 1.13.1 will be reaching Debian sid soon?
[10:35] <lifeless> vila: so, command line arg or variable, for test suite munging
[10:35] <lifeless> actually,
[10:35] <lifeless> I know
[10:36] <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:38] <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:42] <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:43] <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:44] <kinkie> That's what I also do, but I was wondering if it was easier to do something different ;)
[10:48] <lifeless> vila: suite modifications, chain, like I made log
[10:50] <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:51] <vila> which I find a bit artificial, but I may be wrong and it may be the best trade-off
[10:52] <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:53] <vila> I think it also requires that such modifications be done last rather than first
[10:55] <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:56] <vila> we don't want TestInSubprocess to filtered out because its id doesn't match some pattern for example
[10:57] <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
[11:01] <vila> lifeless: your refactoring will include putting randomize_suite and exclude_tests_by_re inside that chain right ?
[11:20] <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:21] <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:22] <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:23] <lifeless> by e.g. passing --random to them too
[11:24] <vila> you mean children == subprocess, not children == tests right ?
[11:24] <lifeless> yes
[11:25] <lifeless> the other is to say, if we iter, the container should do what it needs to
[11:25] <lifeless> anyhow, nearly done
[11:27] <vila> Or we can make two chains: one post-load and one pre-run :-)
[11:29] <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:30] <lifeless> I have no use for randomisation, never did :)
[11:41] <poolie> that was the point of it
[11:43] <lifeless> poolie: ok, well I'm not proposing to remove it
[11:43] <lifeless> it fits into this refactoring fine
[11:58] <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:59] <vila> I like the elapsed time, try to keep it that way :)
[12:00] <lifeless> so
[12:00] <lifeless> http://paste.ubuntu.com/138181/
[12:02] <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:03] <lifeless> sure, set it in ~/.bazaar/locations.conf
[12:04] <lifeless> vila: what do you think [there was a tiny bug, its fixed]
[12:05] <lifeless> two teeny bugs, fixed :P
[12:06] <vila> lifeless: in ExcludeDecorator ?
[12:07] <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:08] <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:09] <vila> selftest -s bt.test_selftest :)
[12:09] <lifeless> bb:approve then?
[12:09] <vila> BB:APPROVE
[12:10] <vila> But I don't see a way to plugin into suite_decorators
[12:11] <vila> provided in builtins.py ?
[12:11] <lifeless> yes
[12:11] <vila> yeah ! :)
[12:11] <lifeless> Command.hooks['extend_command']
[12:12] <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:14] <vila> ECANTREPRODUCE, bzr selftest selftest --no-plugins ?
[12:15] <vila> reproduced elsewhere
[12:16] <lifeless> kinkie: just mv /src/foo/bar /src/bar
[12:16] <lifeless> kinkie: or whatever
[12:17] <lifeless> kinkie: you may want to adjust some paths in ~/.bazaar/locations.conf
[12:18] <vila> lifeless: mv ~/lib/python/subunit ~/lib/python/subunitxx makes the double printing disappear
[12:18] <vila> not pointing fingers....
[12:19] <lifeless> odd..
[12:22] <lifeless> vila: its printed out in builtins.py
[12:23] <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:24] <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:27] <lifeless> yes
[12:27] <lifeless> jml: so, ConcurrentTestSuite, testtools will accept, or won't.
[12:27] <lifeless> jml: I need to know
[12:32] <vila> lifeless: bzr selftest -s bt.blackbox.test_selftest.TestOptions.test_subunit
[12:33] <vila> either gulty or victim
[12:34] <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:35]  * vila points finger to self for still missing a test farm running isolated tests on a regular basis :)
[12:37] <lifeless> do you know if its possible to have an optional option
[12:38] <lifeless> e.g. --parallel[=foo] ?
[12:38] <vila> came under discussion with jam recently: no, but we should
[12:39] <vila> work-around : use a magic value :-/
[12:39] <vila> i.e. --parallel=0 => cpucount()
[12:42] <vila> lifeless: can you take http://paste.ubuntu.com/138205/ ?
[12:42] <vila> rhaa http://paste.ubuntu.com/138206/
[12:43] <lifeless> vila: thats better, but you know what would be awesome
[12:44] <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:45] <vila> you realized -v and progress bar prints *during* execution, right ?
[12:46] <lifeless> 'that' == 'testing: ...'
[12:53] <vila> haa, so it can tell: testing 'this' 'here' ?
[12:54] <vila> I was wondering about remote testing issues if you test from os1 to os2...
[12:54] <vila> .. cans of worms
[12:55]  * vila needs to eat
[12:56] <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:57] <lifeless> night all
[14:12] <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:13] <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:29] <jam> morning vila
[14:33]  * blizzz found a solutiob
[15:23] <jam> vila: http://paste.ubuntu.com/138325/
[15:28] <Tak|work> jelmer: have you tried my branch of the md-bzr addin lately?
[15:28] <Tak|work> jelmer: also, hi
[15:29] <jam> vila: http://paste.ubuntu.com/138326/
[17:04] <SamB> Is there a good way to see what the default push target is from a (non-python) script?
[17:07] <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:08] <asabil> SamB: I think you can also use the xml-output plugin
[17:08] <asabil> well gtg now, ttyl
[17:25] <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:26] <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:28] <jelmer_> hmm?
[17:29] <Peng_> Hiya jelmer_.
[17:30] <jelmer_> Peng_: what's up with lighttpd and bzr-svn?
[17:36] <Peng_> jelmer_: I don't know. What he said.
[17:37] <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:38] <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:39] <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:40] <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:41] <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:45] <mrooney> jelmer_: how functional, thanks :)
[19:24] <sohail> hey guys, I have a versioned directory that I want ot move into its own repository, maintaining history
[19:25] <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:42] <nekohayo> hmm. is there a way to apply a .patch easily? Tried bzr apply and bzr patch, no luck?
[19:44] <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:45] <nekohayo> a regular patch I guess.. I usually make patches by doing bzr diff>foo.patch
[19:48] <Peng_> Why are you sending around regular patches? You've got a DVCS! Use it! :D
[19:54] <nekohayo> peng_ in normal circumstances yes, but someone sent me a patch by mail :)
[20:42] <thumper> sohail: I know it can be done, but I don't know how
[20:42] <thumper> sohail: perhaps jam recalls
[20:43] <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:44] <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:45] <jam> sohail: but do you want to continue having this subdir in the project? Just not edit it most of the time?
[21:04] <sohail> jam no I want it to be totally separate
[21:05] <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:06] <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:07] <jelmer_> 'evening jam, thumper
[21:07] <jam> hi jelmer_
[21:08]  * 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:09] <Peng_> jelmer_: Congrats. :)
[21:09] <thumper> hi jelmer_
[21:10] <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:11] <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:14] <jelmer_> trying the kernel now >-)
[21:16] <jelmer_> thumper: looks like the kernel is actually doable
[21:17] <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:19] <jelmer_> gnomefreak: it can set tags for you when you release
[21:20] <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:21] <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:22] <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:23] <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:24] <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:25] <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:27] <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:32] <gnomefreak> im fairly sure building bzr bzr-bd python and friends is a bit more work than i would have thought
[21:35] <jelmer_> gnomefreak: sorry, no idea :-/
[21:35]  * jelmer_ joins nevans in saying spiv/lifeless's work on HPSS push rocks \o/
[21:37] <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:38] <gnomefreak> if i can get away without building all python deps than it shouldnt take too long
[21:40] <jelmer_> gnomefreak: I think 2.4 (which dapper has) should be sufficient
[21:41] <gnomefreak> jelmer_: ok thanks ill give it a shot tonight i hope
[22:02] <spiv> jelmer_: thanks :)
[22:04] <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:14] <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:15] <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:17] <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:24] <sohail> how do you guys back up your bzr repositories?
[22:25] <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:26] <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:27] <lzhang> is there anything like svn's vendor branches for bzr?
[22:28] <sohail> svn does vendor branches by accident
[22:30] <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:31] <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:32] <sohail> I should be using anacron to schedule this too..
[22:37]  * igc breakfast
[22:41] <davidstrauss> We need something like this: http://www.webdesignerdepot.com/2009/03/intro-to-git-for-web-designers/
[22:42] <lzhang> I say you guys need to fix up launchpad
[22:42] <lzhang> github is way cooler
[22:43] <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:44] <davidstrauss> lifeless: lol
[22:53] <sohail> lzhang, a designer is not going to use bzr... svn is way easier
[22:54] <sohail> though I guess a gooey makes it easier
[23:00] <lifeless> well, designers do use bzr
[23:00] <lifeless> so there is at least an existence proof that they do :)
[23:07] <wgrant> How is svn easier than bzr?
[23:08] <jelmer_> wgrant: it has more polished GUI's, especially on windows
[23:09] <wgrant> Ah.
[23:09] <wgrant> But GUIs are overrated.
[23:15] <sohail> wgrant, you'd probably have some kind of time explaining that to a designer
[23:18] <lifeless> jam: do you want to talk about fetch?
[23:18] <lifeless> jam: also, is the commit stuff approve/tweak/whatever?
[23:20] <lifeless> jml: ping
[23:21] <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:22] <lifeless> there are two classes I think have nothing to do with bzr, ConcurrentTestSuite and ThreadsafeForwardingResult
[23:27] <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:28] <lifeless> have a look at this patch: http://paste.ubuntu.com/138212/
[23:29] <lifeless> you can see that all the bzr machinery for achieving parallelisation is separate to these classes
[23:30] <jml> sure.
[23:30] <jml> why the startTest / stopTest around all the calls in ThreadsafeForwardingResult?
[23:31] <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:32] <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:34] <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:35] <lifeless> so stopTest would do result.start, for status in self.statii: status(result); del self.status[:]; result.stop
[23:36] <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:37] <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:38] <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:39] <lifeless> but perhaps I'm just coloured by liking clear code
[23:40] <lifeless> anyway
[23:41] <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:42] <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:49] <jml> lifeless: thanks.