[00:25] <james_w> lifeless: is https://code.edge.launchpad.net/~james-w/testtools/discover/+merge/26994 something like what you had in mind?
[00:37] <igc> morning
[00:38] <lifeless> moin moin
[01:04] <mgz> lifeless: on the topic of testtools.run from earlier,
[01:04] <mgz> is there any good reason why it can't just be `python -m testtools`
[01:04] <poolie> hi mgz
[01:05] <mgz> and import the stuff from testtools.run in __name__ == '__main__' in __init__.py
[01:05] <mgz> hey poolie.
[01:05] <lifeless> mgz: no good reason either way
[01:05] <lifeless> mgz: I will say, I somewhat prefer testtools.run
[01:05] <lifeless> grabbing all the possible contexts as the default for testtools seems... crude
[01:06] <poolie> hi lifeless
[01:06] <lifeless> mgz: is it functional/aesthetics/other ?
[01:06] <lifeless> hi poolie
[01:06] <mgz> moving it is an easy way to fix 501174
[01:06] <mgz> *bug 501174
[01:06] <mgz> the actual code can still be in run
[01:06] <mgz> I just want to -m the package root.
[01:06] <lifeless> oh
[01:06] <lifeless> mgz: yes, I get what you want :)
[01:07] <lifeless> and its a functional difference for you
[01:07] <poolie> ah, makes sense to me
[01:07] <lifeless> mgz: sure, to make it work on 2.4 the little ugliness is ok
[01:07] <lifeless> mgz: uhm, what do you think of
[01:08] <lifeless> python -m testtools run <args>
[01:08] <lifeless> and
[01:08] <lifeless> python -m testtools.run <args>
[01:08] <lifeless> both working
[01:08] <mgz> sounds fine to me, should be easy to arg wrangle.
[01:10] <mgz> especially as the james_w branch is making the __main__ code the ideal one line
[01:10] <lifeless> I'd be happiest with that
[01:10] <mgz> ...two lines. would fit on one though :)
[01:10] <lifeless> because that way when 2.4 finally keels over
[01:10] <lifeless> we can do other stuff
[01:11] <lifeless> and if we have other front ends to add, they aren't squashed out
[01:11] <james_w> 2.4 can't do -m something.dotted?
[01:11] <mgz> nope, and I was confused too when I tried it.
[01:12] <mgz> it's not something other packages I've wanted to use have gone for, no idea about it till I was trying testtools
[01:14] <lifeless> right
[01:14] <lifeless> james_w: yes, bug in 2.4, it assumed top level module.
[01:18] <mgz> hm, might just try that now see what it looks like
[01:24] <mgz> urk, that might not be a fix, seems to only want <module>.py not <module>/__init__.py
[01:24] <lifeless> ah
[01:24] <mgz> will just have to note in the documentation I guess.
[01:24] <lifeless> so really not supporting modules :)
[01:30] <mgz> poolie: ericmoritz was talking about calling Feature.available() because he wanted to skip if a feature *was* present
[01:31] <mgz> but that wasn't the right test anyway.
[01:33] <mgz> ah, whoops.
[01:33] <poolie> igc1, hi there?
[01:33] <mgz> guess I should repeat that, though not very important
[01:34] <mgz> poolie: ericmoritz was talking about calling Feature.available() because he wanted to skip if a feature *was* present
[01:34] <mgz> but that wasn't the right test anyway.
[01:36] <poolie> oh ok
[01:36] <poolie> hm, perhaps we should define an inverse feature then
[01:36] <poolie> but that would be ok
[01:50] <Stavros> hello
[01:50] <Stavros> i had revision 20 on repo A, worked on repo B up to revision 40, bound B to repo A and all my revisions past 20 are gone
[01:50] <Stavros> how can i get them back?
[01:53] <Stavros> hmm, they are on B
[01:53] <Stavros> that's odd
[02:24] <lifeless> spiv: poolie: I think, on reflection, that any inheritance from Branch/Repository etc in remote.py is actually harmful, not beneficial
[02:24] <spiv> lifeless: hmm
[02:24] <spiv> lifeless: one of those two don't inherit
[02:25] <lifeless> yes
[02:25] <spiv> lifeless: and it's increasingly causing problems too
[02:25] <lifeless> and we've been muttering that it should
[02:25] <lifeless> I'm thinking it shouldn't more and more as I address this loom bug
[02:25] <spiv> So inheriting in remote.py: not great.  Not inheriting: also not great.
[02:25] <spiv> I wonder what the solution is.
[02:25] <lifeless> consider sprout
[02:25] <lifeless> what we want is:
[02:25] <lifeless>  - no VFS for the default case
[02:26] <lifeless>  - VFS if the smart server can't do what the branch needs
[02:26] <lifeless>  - ideally smart in all cases
[02:26] <lifeless> sprout is currently a method on e.g. Branch
[02:26] <lifeless> we define sprout on RemoteRepository
[02:27] <lifeless> not on Branch
[02:27] <lifeless> and because of that Branch.sprout doesn't copy loom data across
[02:27] <lifeless> I discussed a structured approach with poolie
[02:27] <lifeless> but I'm not entirely happy with how it felt
[02:27] <spiv> I think we haven't got sprout right in terms of which objects are responsible for the various parts of it.
[02:28] <spiv> And the trouble with Remote + loom is a symptom of that.
[02:28] <lifeless> it might be better with an Inter
[02:28] <lifeless> and be on the format object
[02:28] <lifeless> so it could do self._format._ensure_real()
[02:29] <lifeless> self._format.sprout(...) and that lookup on the ...
[02:29] <lifeless> anyhow, I think I'm going to:
[02:30] <lifeless> sorry, sec
[02:31] <poolie> lifeless, i think those base classes should become abstract
[02:31] <poolie> many of them iirc have a lot of historical stuff near the top of the class hierarchy
[02:31] <lifeless> poolie: I agree but I think that that is perhaps orthogonal
[02:31] <lifeless> and that we should look for reuse in the Remote* hierachy through composition or something
[02:32] <lifeless> thoughts on moving sprout from Branch to BranchFormat ?
[02:32] <lifeless> its only use of self is self.copy_content_into
[02:32] <lifeless> which the format could happily call
[02:33] <lifeless> and we have [at least for now
[02:33] <lifeless> ] established free access to Format objects for bzrdir components
[02:34] <spiv> lifeless: reuse through composition sounds like a very plausible idea to me
[02:37] <poolie> let's say complementary
[02:37] <poolie> i think if you need to make them composable perhaps you need to move them out of the base class
[02:37] <poolie> anyhow, hooray for cleaning it up
[02:45] <lifeless> well I don't know how much cleaner it will be
[02:46] <lifeless> did either of you have thoughts on the proposed move of sprout ?
[02:46] <poolie> ah
[02:46] <poolie> to the BranchFormat base class?
[02:52] <lifeless> from Branch to BranchFormat
[02:52] <lifeless> where differences exist
[02:53] <lifeless> I propose to put it on appropriate BranchFormat subclasses
[02:53] <lifeless> and on RemoteBranchFormat, we can then delegate to the actual Format
[02:53] <poolie> sorry for the lag
[02:54] <poolie> so you'll call effectively source_branch.format.sprout(to_transport)?
[02:54] <lifeless> yes
[02:55] <lifeless> for compat
[02:55] <lifeless> we can leave Branch.sprout in place, deprecated
[02:55] <poolie> and why is this better?
[02:55] <lifeless> and it would call that as self._format.sprout(self, to_transport)
[02:55] <lifeless> because we know the format of remote branches even if we haven't done _ensure_real on the Branch
[02:56] <lifeless> so we can run the right code for looms without triggering VFS for regular branches
[02:59] <poolie> hm
[02:59] <poolie> i kind of see the problem you mean
[03:00] <poolie> i think the public api that makes sense is probably branch.sprout(to_transport)
[03:00] <poolie> i don't see why the caller would want to work in terms of the format
[03:00] <spiv> In short: sprouting needs to take the format into account, and making the format responsible for sprouting takes care of that?
[03:00] <lifeless> uhm
[03:00] <poolie> now behind the scenes there are some issues about perhaps not yet knowing the remote format
[03:00] <lifeless> so sprout as currently defined sprouts to a to_bzrdir
[03:00] <lifeless> which is, I think ok
[03:01] <poolie> ok
[03:01] <lifeless> it needs to:\
[03:01] <lifeless>  - make a new Branch in the bzrdir, which is a little complex.
[03:01] <lifeless>    - it might be the same as the source format
[03:01] <lifeless>     - or there might be some magic kick in to ensure it supports something that the default doesn't
[03:01] <lifeless>  - it needs to copy the metadata from the source branch across
[03:02] <lifeless> if you look at branch.py, at sprout
[03:02] <lifeless> you can see that its ~15 lines
[03:02] <lifeless> only one of which calls self.*
[03:03] <lifeless> thats not a very strong argument, but its data
[03:03] <lifeless> secondly, ideally, the copying of metadata would be a multimethod
[03:03] <lifeless> on source,target
[03:04] <poolie> right
[03:04] <lifeless> and we can for such source, targets either use the Branch objects or the BranchFormat objects
[03:04] <lifeless> now, BranchFormats are the unique things on disk
[03:05] <lifeless> we guarantee that there are unique network strings for any given format, we don't guarantee that for Branch subclasses
[03:05] <lifeless> its possible to use the same Branch class, parameterised, to handle two different Formats
[03:05] <lifeless> I don't know if we use that, but that was part of the goals in the early design
[03:05] <lifeless> so perhaps it wouldn't work now and we should discount it
[03:06] <poolie> as i've said before there seems imperfect separation between formats and branch classes
[03:06] <poolie> ah
[03:06] <poolie> one could have a branch class that delegates absolutely everything to its format and could be used with every format
[03:06] <poolie> i'm not sure why that would be useful though
[03:07] <lifeless> that would be an extreme
[03:07] <lifeless> Formats are factoried for Branch objects
[03:07] <lifeless> so a BranchFormat can *parameterise* a Branch with appropriate delegated objects
[03:07] <lifeless> on construction
[03:07] <poolie> conversely i suppose we could have a branchformat that actually knows nothing about the format other than its name and what Branch class implements it
[03:07] <poolie> right
[03:07] <lifeless> right, thats the other extreme
[03:08] <poolie> i don't feel there is a clear principled statement of where we go between those extremes
[03:08] <lifeless> now, I guess I'm saying that right now, sprout feels more like an interaction between the formats
[03:08] <poolie> and it's not consistent between the two of them
[03:09] <lifeless> poolie: to me, disk management code should go in formats (or in objects the formats supply), and model code should go elsewhere
[03:09] <poolie> (changed pilot->spiv)
[03:09] <lifeless> spiv: wearing the pilots-get-interrupted hat, perhaps you could do the followup on the release
[03:10] <lifeless> the execution-of-announcements etc, if the binaries are all copacetic
[03:10] <lifeless> [the topic change reminded me]
[03:10] <poolie> basically agree about that, though probably i'd like it to be objects that are plugged into the branch
[03:10] <poolie> ah
[03:11] <poolie> so i still think in terms of the public api, the user has a "branch _this_ to _here_"
[03:11] <lifeless> poolie: 'it'? 'like it to be'
[03:11] <poolie> " disk management code should go in formats (or in objects the formats supply)"
[03:11] <lifeless> poolie: ok, so 'disk management code should be in objects that are plugged into the branch' ?
[03:11] <lifeless> poolie: you have an implied 'and not the formats' there, right ?
[03:12] <poolie> i think doing code that amounts to self.format.get_something(self.transport) is a bit weird
[03:12] <poolie> where self is a branch
[03:12] <lifeless> I think thats true
[03:12] <spiv> poolie: thanks
[03:12] <poolie> however doing at startup, self.tag_manager = self.format.get_tag_manager(self.transport) feels a bit less weird
[03:12] <lifeless> If delegating like that, i'd write it as self.format.get_something(self)
[03:13] <poolie> perhaps you could propose some text suitable for the architecture overview that describes what you think the split should be between branch/repo/wt etc and their formats
[03:13] <lifeless> poolie: separate objects for separate concerns is good too - tag manager is a great example of splitting that out
[03:13] <lifeless> I sure can
[03:13] <poolie> mm
[03:13] <lifeless> I want to get looms working first
[03:14] <lifeless> but I'll put a doc refresh right under that on the stack
[03:14] <poolie> for example is all the knowledge about a disk format going to be in the format, or in a class that the format knows about and provides to the branch, or is it going to be in parallel hierarchies, etc
[03:14] <poolie> ok
[03:14] <poolie> so let's talk for a bit about fixtures?
[03:14] <poolie> we might propose a merge into testtools that adds fixtures such that
[03:15] <poolie> the test scope cleans up the fixture
[03:15] <poolie> people are encouraged to put reusable setup into a fixture class, not into setUp() or the test_()
[03:16] <lifeless> http://pastebin.com/Nxkpz8Tp
[03:16] <lifeless> this is an in progress patch I have
[03:16] <lifeless> which uses a fixture concept heavil
[03:16] <lifeless> y
[03:16] <spiv> lifeless: Ok, I'll take a look at release followup, although I doubt if I'll get to that today.
[03:16] <lifeless> with a focus on composition
[03:17] <poolie> heh
[03:17] <poolie> i'm coming to really dislike Command pattern in python
[03:17] <poolie> i wouldn't veto this just because of that
[03:17] <lifeless> poolie: I'd love to see a small patch for testtools to aid with fixture use and definition, though I think its really very small and likely to bikeshed until we have some wider experience with it
[03:17] <lifeless> poolie: I don't see this as Command
[03:18] <lifeless> poolie: I see it as Composite, if you want to name it
[03:18] <poolie> MirrorProposed, i mean
[03:18] <lifeless> oh
[03:18] <lifeless> well thats me following suit on the lp plugin style
[03:18] <poolie> it's 90% overhead compared to just having a function
[03:18] <poolie> and it seems to harm refactoring rather than helping it
[03:19] <lifeless> other bits of the lp plugin do this, and I wanted to fit with the style in that area
[03:19] <poolie> ok
[03:19] <poolie> but "if not now, when?"
[03:19] <poolie> i'm just mentioning it because i see it now
[03:19] <lifeless> when its fully automatically testable ;)
[03:19] <lifeless> fair enough
[03:19] <poolie> set a good example rather than following a bad one :)
[03:20] <lifeless> I'm not enamoured of it either :>
[03:20] <poolie> i'm glad we agree :)
[03:20] <poolie> igc liked the netflix slides too
[03:20] <lifeless> cool
[03:20] <lifeless> so, I'd love it if you had a think about what I do with fixtures in that patch
[03:20] <lifeless> its not perfect, but I think it communicates where my thinking is at
[03:20] <poolie> hm
[03:21] <poolie> why is manyfixtures useful?
[03:21] <lifeless> and thats the sort of thing I'd want to encourage with a testtools patch, wearing my testtools patch reviewer hat
[03:21] <poolie> just faster than calling useFixture repeatedly?
[03:21] <poolie> does testtools have a list?
[03:21] <lifeless> testing-in-python
[03:21] <lifeless> which is perhaps not appropriate
[03:22] <lifeless> jml: ^ we should revisit that
[03:22] <lifeless> poolie: I don't know (multifixtures) it seemed like a good idea at the time; because many fixtures might want to group a few bits together.
[03:23] <poolie> i'd like to get my thoughts a bit more straight before posting there perhaps
[03:23] <lifeless> poolie: I'm sure its not right, I'm also not sure its wrong.
[03:23] <lifeless> back to sprout
[03:23] <lifeless> I feel a little hamstrung
[03:23] <lifeless> should
[03:23] <lifeless>  - move it to BranchFormat
[03:23] <lifeless>  - just accept the VFS overhead of doing it in-place
[03:24] <poolie> this is because you want to have the same RemoteBranch but it will have a different BranchFormat if the remote thing is actually a loom?
[03:24] <lifeless> I don't want to move it to BF and leave a forwarding method, because if the *contract* is on Branch, RemoteBranch can't safely forward unconditionally.
[03:24] <lifeless> yes
[03:24] <poolie> why not?
[03:25] <poolie> i mean why can't it safely forward unconditionally?
[03:25] <lifeless> because SvnBranch.sprout might not forward\
[03:25] <lifeless> so RemoteBranch.sprout, with the real branch being an SvnBranch, wouldn't do the right thing anymore
[03:25] <poolie> sorry, got to go, back in about 60m
[03:25] <lifeless> ok I'm going to go drop my PC for repair
[03:25] <lifeless> should be ~same
[03:25] <lifeless> ciao
[06:02] <poolie> igc, re test fixtures
[06:02] <poolie> * "[Launchpad-dev] New feature in Launchpad TestCase base class"
[06:02] <poolie> * https://code.launchpad.net/~mbp/bzr/testsubjects/+merge/24188
[06:02] <poolie> * https://code.launchpad.net/~mbp/bzr/fixtures/+merge/25337
[06:02] <willmarshall> BZR first-time user question!
[06:03] <spiv> jelmer: you set a merge proposal to Queued.  PQM isn't using the queue in LP atm, you need to use the email method.
[06:03] <poolie> http://www.mail-archive.com/launchpad-dev@lists.launchpad.net/msg03226.html
[06:03] <poolie> spiv it's an easy mistake to make because feed-pqm still lets you queue them
[06:03] <willmarshall> In git, if I have changes I want to store but don't want to commit to my main branch - I can do git branch mynew branch, work in that branch, then commit that branch to my git server and do a merge later
[06:03] <poolie> we should disable it in the client
[06:03] <willmarshall> How would I do the same thing in bzr - spawn a new branch, push that branch to the bzr server
[06:04] <spiv> poolie: right
[06:04] <poolie> willmarshall:
[06:04] <poolie> bzr branch . ../otherthing
[06:04] <poolie> cd ../otherthing
[06:04] <poolie> bzr merge --uncommitted ../firstthing
[06:04] <willmarshall> poolie: Yah - but that's just local branches on my dev box
[06:04] <poolie> or alternatively if you just want to store it temporarily and not commit it, 'bzr shelve'
[06:04] <willmarshall> I really need to push this branch to the bzr server so others can also work on it
[06:05] <poolie> willmarshall, well, then commit in otherthing and push it to the server
[06:05] <poolie> you need to push them separately
[06:05] <willmarshall> without pushing it to the branch we're deploying from, cos it breaks stuff
[06:05] <poolie> or as a third alternative use bzr-colo which is more like git colocated branches
[06:05] <willmarshall> poolie:
[06:05] <poolie> push it somewhere different
[06:05] <willmarshall> Ah! So bzr doesn't quite work like git, and I am confused?
[06:05] <poolie> it's not quite like git; i'm not sure if you're confused :-)
[06:06] <willmarshall> The manual for bzr seems to be telling me that if I do bzr branch myrepo ./somedir
[06:06] <willmarshall> And then work on that branch, commit and push
[06:06] <willmarshall> My changes won't be in a new branch on the server
[06:06] <poolie> willmarshall, they'll be in a separate branch on the server if you push them to a separate branch
[06:06] <willmarshall> unlike in git, where branches have names and you can push to different branches in the same place
[06:07] <willmarshall> Ok
[06:07] <poolie> right, normally in bzr each directory has only one branch
[06:07] <willmarshall> How do I spawn that branch on the server?
[06:07] <poolie> unless you use bzr-coro
[06:07] <poolie> *bzr-colo
[06:07] <willmarshall> Oh! So this is is more svn-like?
[06:07] <poolie> a bit, but it's not exactly like svn either
[06:07] <willmarshall> Ok
[06:07] <willmarshall> Gotcha
[06:07] <willmarshall> bzr-colo sounds like what I need
[06:07] <poolie> normally if you have bzr+ssh://server/repo/trunk
[06:08] <poolie> then you can just do "bzr push bzr+ssh://server/repo/otherthing"
[06:08] <lifeless> poolie: ah, you're back
[06:08] <lifeless> poolie: so, I think I'm just going to move it around and see how it feels
[06:08] <poolie> by all means
[06:08] <spiv> lifeless: +1
[06:08] <poolie> i really think that document would help
[06:08] <lifeless> poolie: I think it will too
[06:08] <poolie> it may help you and it will almost certainly help with review and with making things more consistent in future
[06:08] <poolie> we don't want people moving different aspects at random
[06:09] <lifeless> poolie: I'll be thinking about it all the time I'm moving stuff
[06:09] <lifeless> oh
[06:09] <willmarshall> poolie! Awesome. That worked
[06:09] <lifeless> and my games machine - cpu heatsink was /way/ loose
[06:09] <poolie> huh, funny coincidence
[06:09] <willmarshall> Thank you very much
[06:09] <poolie> np will
[06:09] <lifeless> attached properly and its apparently fine now
[06:09] <poolie> lifeless, is it scorched?
[06:10] <lifeless> poolie: appears not; thermal protection in i7 is pretty good I'm told
[06:10] <poolie> great
[06:10] <poolie> how did they get it to reattach properly? remove it and re-add thermal pad?
[06:10] <lifeless> nope
[06:10] <spiv> Hammer? ;)
[06:10] <lifeless> just twisted the thumbscrews, pushed firmly till they went clink
[06:11] <lifeless> I'd been afraid to really push hard here, and not sure of the mechanics inside the plastic heads
[06:11] <lifeless> apparently its like plaster screws
[06:11] <lifeless> with a inner than locks open, and the original install [probably] never got it quite open enough to lock in place
[06:12] <lifeless> back in .au I had been seeing thermal warnings from time to time, just figured it was linux slackness
[06:12] <lifeless> but now, no warnings at all
[06:12] <poolie> likewise
[06:12] <poolie> how strange
[06:12] <poolie> this makes me wonder if my machine could be fixed by just re-seating it, but perhaps at this point it really is scorched
[06:13] <lifeless> what cpu was/is it ?
[06:13] <poolie> E6600 Core2
[06:13] <lifeless> so the question would be if intel's thermal protection changed much from there to i7
[06:13] <lifeless> well worth trying, I'd say
[06:13] <poolie> i might call and ask then
[06:45] <Bigcheese> Is there really no solution to the memory problem when branching large subversion repos?
[06:45] <Bigcheese> I need to branch from llvm, which has 105k revs. I'm already on a 64bit machine.
[06:50] <lifeless> bac: have you tried doing batches, like - branch -r 5000 source target; cd target; bzr pull -r 10000; bzr pull -r 20000 etc ?
[06:50] <lifeless> bah
[06:50] <lifeless> Bigcheese: ^
[06:51] <lifeless> sorry bac
[06:51] <Bigcheese> heh
[06:51] <Bigcheese> That's what I'm doing now, and it works, it's just going to take for ever with how small I have to increment.
[06:52] <lifeless> what size are you incrementing in ?
[06:52] <Bigcheese> Even one revision uses all 2 gigs of ram...
[06:52] <Bigcheese> 100 right now.
[06:52] <lifeless> thats surprising
[06:52] <lifeless> are you perhaps using the root of the svn repo, rather than one specific branch?
[06:53] <Bigcheese> I'm checking out trunk.
[06:53] <Bigcheese> So no, just one branch.
[06:53] <lifeless> thats very odd
[06:53] <Bigcheese> Well, 1000 seems to work.
[06:53] <lifeless> could you file a bug, its not meant to use that much memory :)
[06:54] <Bigcheese> There's already one filed :P And it's talked about everywhere on the internet :P.
[06:55] <lifeless> uhm
[06:55] <lifeless> memory issues are a hydra
[06:55] <lifeless> I find assuming that a previous bug 'x used lots of memory' is rarely a good indicator.
[07:04] <Bigcheese> Searching the bug DB I've found at least 5 of the exact same thing. One even mentions you :P.
[07:08] <lifeless> thats likely
[07:08] <lifeless> we've had many causes of too much memory
[07:08] <lifeless> some are large files
[07:08] <lifeless> some are cache misuse
[07:08] <lifeless> some are too many strings
[07:08] <lifeless> to answer the question about whether there is a fix, we need to figure out what particular 'uses lots of memory' bug you have
[07:08] <lifeless> so - for starters, what bzr version and bzr-svn versions do you have?
[07:10] <Bigcheese> how do I check the bzr-svn version?
[07:10] <lifeless> bzr plugins
[07:11] <Bigcheese> http://codepad.org/1ToCN8jN
[07:13] <lifeless> bzr 2.1.2 reduces memory consumption for some operations
[07:13] <lifeless> might be worth trying
[07:13] <Bigcheese> Is that only availible via source?
[07:13] <lifeless> what platform?
[07:14] <Bigcheese> Windows 7 x64
[07:14] <lifeless> I can't see a 2.1.2 binary on https://edge.launchpad.net/bzr/+download yet
[07:14] <lifeless> so yes, looks like source only
[07:15] <lifeless> spiv: ^ btw may be a fast task to do the release - just send email :P
[07:17] <Bigcheese> Thanks, I may try that if I this breaks again.
[07:17] <Bigcheese> It's finally working 10k at a time,
[07:17] <Bigcheese> So that's not too bad.
[08:22] <spiv> lifeless: might be fast, but we're done for the day.  Will have to look tomorrow.
[08:23] <spiv> lifeless: thanks for the idea
[08:23] <lifeless> spiv: sleep well
[09:06] <parthm> mgz: ping
[09:07] <bouncingzip> indeed I did apparently.
[09:07] <bouncingzip> do I bother looking up how to ghost myself on this network...
[09:09] <mgz> parthm: hi
[09:09] <parthm> mgz: thanks for the patches :)
[09:11] <mgz> it's your own fault for copying all those loops, 's like waving a red flag to a pedant like me :)
[09:12] <mgz> I'll see if I can get to doing unicode support at some point too, though there aren't any great options on that
[09:12] <parthm> mgz: yes. :) performat_output looks good to me. should are apply it or are you planning to change something else.
[09:12] <mgz> if it doesn't regress anything for you, land it
[09:13] <parthm> mgz: ok. i cool. i will try it out.
[09:13] <mgz> I'd be interested in if it's done anything bad to the profile in the cases I mentioned though
[09:13] <mgz> tried to keep stuff doing what it was doing before, but did change a few things
[09:14] <parthm> mgz: yes. i will try that. you patch is well timed, we get bug #590589 fixed as bonus :)
[09:15] <mgz> was trying not to make anything slower in that branch so the follow-on speed up was still a win.
[09:18] <parthm> mgz: UnicodeDecodeError for 'bzr grep ff' on mysql repo http://pastebin.com/JGfwXbk5
[09:18] <mgz> doh!
[09:19] <parthm> mgz: maybe line.decode(file_encoding, 'replace') can fix it? i can do that here.
[09:19] <mgz> did I forget the "replace" on one of the lines?
[09:19] <mgz> you're ahead of me.
[09:19] <mgz> I... forgot it on all of them?
[09:21] <mgz> too much moving things around, the (four) places I added that 's not really correct, but it's the simplest for the moment
[09:21] <parthm> mgz: np. works fine now. updated on the four locations.
[09:22] <mgz> guess I need to try harder to make a test that'll consistently fail on that as well
[09:23] <GaryvdM> Hi all.
[09:23] <parthm> mgz: at least we have some unicode tests now :) ... i should have added them in the first place. thanks for putting them in.
[09:23] <parthm> GaryvdM: hi
[09:23] <mgz> morning gary.
[09:24] <GaryvdM> I have a corrupted dirstate file, an the branch has uncommited changes.
[09:24] <GaryvdM> Bug #450047
[09:24] <GaryvdM> Any recomendations on how to recover.
[09:25] <parthm> mgz: tested on emacs and mysql. works nicely. -Fi bug is also fixed. Yay!
[09:28] <mgz> no smart ideas here gary. branch from somewhere else and copy over the working tree?
[09:29] <GaryvdM> Ok - I mv .bzr/checkout .bzr/checkout.bck, and then did a checkout, and the files with changes show up as conflicts.
[09:31] <mgz> resolve --take-this then? (or -other which ever the right way round is)
[09:32] <GaryvdM> This is on  a server. Only have bzr 2.1 :-(
[09:33] <mgz> hm. annoying.
[09:34] <parthm> mgz: for the fast-path patch there are two conflicts (same code) http://pastebin.com/swn9BN7Y .. should i just change that as mentioned in the paste?
[09:34] <mgz> yup, that's the right resolution
[09:35] <parthm> mgz: ok. cool. i am thinking of making a 0.4 release after this. -Fi seems like a serious enough bug. what do you think?
[09:35] <GaryvdM> Ok - emergency over. Thanks mgz.
[09:35] <mgz> moving the decode onto the line above to make the merge simpler was what made me forget the 'replace'
[09:37] <mgz> parthm: could do, but no rush, only do it if you've got the time anyway
[09:38] <mgz> I'm not that confident of all my changes, but getting them out is a pretty sure way of shaking out ugs
[09:38] <mgz> +b
[09:38] <parthm> mgz: shouldn't take long to me the release. and with the -Fi issue fixed, its definitely better than 0.3 :)
[09:39] <parthm> mgz: fast-path is also merged. thanks.
[09:40] <mgz> there are some line ending annoyances still to wrangle over there
[09:40] <mgz> essentially, if people are stupid enough to use mixed, or mac, line endings, strange things may happen to them
[09:41] <mgz> I reduced the change a bit to make it safe for landing though
[09:41] <parthm> mgz: ah. ok. ... so do you think i should wait? anyway, the changes are on lp:bzr-grep so if someone want to use the latest thats always possible.
[09:42] <parthm> we could do a 0.4.0 in a few days it you want to try something.
[09:43] <mgz> no, but I think you might have to start wondering about what someone wanting the line numbers containing "a" in a file like "\r\r\na\n\r\r\na" should get
[09:43] <mgz> str.splitlines does (\r\n \n \r) -> \n and text mode does (\r\n \n) -> \n
[09:44] <mgz> but bzr doesn't help you out at all (in a default setup at any rate)
[09:44] <mgz> and the regexp engine doesn't like unexpected \r
[09:45] <parthm> mgz: yes. i suppose i will file a bug for this an explore it for a later release.
[09:47] <parthm> mgz: bug #591147
[09:48] <mgz> it's a pain, as just using \n is and should be the right thing
[09:49] <parthm> mgz: Yup. i suppose majority of software is about compatibility issues :)
[09:54] <mgz> anyway, away for me.
[09:55] <parthm> mgz: bye
[12:16] <ronny> hi
[12:16] <ronny> how can i disable bzr's lazy importer?
[12:21] <ronny> bummer, its not possible
[12:46] <RayChandlerIII> Does anyone know of a general guide on the idea of feature branching?
[12:50] <parthm> RayChandlerIII: do you mean in context of setting up bzr repo structure?
[12:52] <RayChandlerIII> parthm: Yes. I've setup a repo however I am having a hard time adding files or pulling revisions, or checking anything out. I am used to SVN and have have decided to switch to bazaar after reading your "why switch" guide. ;)
[12:52] <RayChandlerIII> but I am not familiar with feature branching
[12:53] <RayChandlerIII> there is also no wikipedia article on the topic and google turn up a bunch of stuff on HG
[12:53] <parthm> RayChandlerIII: in bzr each branch is its own directory. you can set up a shared repo using 'bzr init-repo foo-repo'. inside dir foo-repo, you can have trunk and other branches.
[12:54] <parthm> this way all branches with share history in the repo (less disk space used).
[12:55] <RayChandlerIII> so each branch can be its own repository?
[12:55] <parthm> RayChandlerIII: You have two options, you can create a branch using 'bzr init foo'. in this case branch and repo are the same (foo).
[12:57] <parthm> or if you have a large history, you can 'bzr init-repo foo-repo ; cd foo-repo; bzr init trunk; cd trunk ; <hack on trunk> ; cd .. ; bzr branch trunk fix-123; cd fix-123 ; <hack on fix>'
[12:57] <parthm> in the latter case all history is in 'foo-repo'.
[12:57] <parthm> RayChandlerIII: http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/shared_repository_layouts.html
[12:58] <parthm> RayChandlerIII: if you are starting a project from scratch 'bzr init' is simpler.
[12:58] <RayChandlerIII> And this would use a distributed model?
[12:58] <RayChandlerIII> <-- Is new at this.
[12:58] <parthm> RayChandlerIII: bzr supports multiple workflows.
[12:59] <parthm> Yes, bzr is distributed, so there is no "central" repo technically ... its only policy.
[12:59] <luks> RayChandlerIII: you should not worry much about the layout of branches/repositories when you are starting
[13:00] <luks> you can switch between them very easily
[13:00] <parthm> RayChandlerIII: Yes, what luks said. You have the option of changing/adapting your workflow later.
[13:00] <RayChandlerIII> So why can I not add files to the repository or check out a working directory?
[13:01] <RayChandlerIII> I have a reposistory with a trunk.
[13:01] <luks> you are working with branches
[13:01] <luks> forget repositories for now
[13:01] <RayChandlerIII> ok
[13:01] <RayChandlerIII> forgotten
[13:02] <RayChandlerIII> hmm
[13:02] <RayChandlerIII> still not clicking
[13:02] <RayChandlerIII> ok lets try this...
[13:02] <luks> could you explain what exact problems are you having?
[13:02] <RayChandlerIII> luks: have you worked with subversion>
[13:02] <luks> yes
[13:02] <parthm> RayChandlerIII: http://doc.bazaar.canonical.com/bzr.2.1/en/tutorials/tutorial.html covers the basic workflow in case you haven't looked at it.
[13:03] <RayChandlerIII> parthm: will check it out. Thanks.
[13:03] <RayChandlerIII> luks: In subversion if I start a new project I create a repo then check it out to a working directory
[13:03] <RayChandlerIII> I then modify that working directory
[13:03] <RayChandlerIII> merge changes from the repo to my local machine
[13:03] <RayChandlerIII> then commit the changes
[13:04] <RayChandlerIII> Compare what I just sayed to how you do it in Bazaar
[13:04] <RayChandlerIII> better question.
[13:04] <luks> the best answer to that is to read the tutorial
[13:04] <luks> there are basics you will need to know
[13:04] <RayChandlerIII> luks: the one that parthm linked to?
[13:05] <luks> yes
[13:05] <luks> the basic idea is that there is no difference between a repository no a server and your local machine
[13:05] <luks> once you get how that works, it will be easy to do anything more advanced
[13:06] <RayChandlerIII> Ok. Thank you for the help and your time. Let me take a look at the tutorial
[13:17] <RayChandlerIII> Ok...
[13:18] <RayChandlerIII> I think I understand it now. ;)
[13:18] <parthm> RayChandlerIII: cool :)
[13:32] <RayChandlerIII> brb
[16:14] <al-maisan> Hello there! Does somebody recall the name of the tool that allows one to filter a diff/patch i.e. to exclude changes to particular files?
[16:14] <Kinnison> Presumably you're referring to filterdiff(1)
[16:15] <Stavros> hello
[16:15] <al-maisan> Kinnison: thanks a million! That was the tool I had in mind!
[16:15] <Stavros> when i switch to a colocated branch, will my uncommitted changes be shelved in the workspace automatically, or do i have to commit first?
[18:36] <bilalakhtar> Hi there, people. My bzr is progressing very slowly during Finding revisions: Inserting stream. How many steps are after this? Is this the last step in branching a branch hosted on lp?
[19:08] <GaryvdM> Hi all
[19:08]  * GaryvdM was looking for jam
[19:35] <maco> someone has a branch on lp, and i merged their branch into trunk and push that to lp... and it doesnt show them in the revisions thing. did i do something wrong?
[20:05] <GaryvdM> maco: Launchpad may take a few minutes to reflect changes to branches
[20:10] <maco> GaryvdM: the new revisions are there, im just wondering if its supposed to show the name of the person who did the merge or if there's a way to have the revision from the branch the merge came from be what shows
[20:20] <GaryvdM> maco: code.launchpad.net only shows the mainline, but if you drill into the merged revisions with bazaar.launchpad.net (or with something like bzr qlog), you will see the original committer.
[20:22] <maco> GaryvdM: oh. ok
[20:22] <maco> GaryvdM: thanks
[20:26] <Lo-lan-do> Hi all.  What to do when I get "error: Error -3 while decompressing data: incorrect data check" errors?
[20:26] <Lo-lan-do> (bzr 2.1.2 on Debian sid)
[20:26] <jelmer> hi Lo-lan-do
[20:27] <Lo-lan-do> Hi jelmer :-)
[20:27] <jelmer> Lo-lan-do: no idea, perhaps jam will have an idea when he shows up
[20:27] <jelmer> Lo-lan-do: btw, did you see that we've made some progress on roundtripping support?
[20:27] <Lo-lan-do> I hope so, because I can't commit to the repository now :-/
[20:28] <Lo-lan-do> I've seen some commits on bzr-git, yes, which gave me hope :-)
[20:29] <jelmer> the performance is still pretty pathetic for 'bzr git-serve', but it does work with the roundtripping code
[20:30] <jelmer> Lo-lan-do: when we get a new cache format for bzr-git in place that is based on bazaar pack files it should be better
[20:31] <Lo-lan-do> Great :-)
[20:33] <effie_jayx> hey guys, with regards revision numbers after a merge
[20:34] <effie_jayx> lets say I have some old code with rev nº 128 and I need to merge some of that stuff into 150
[20:35] <effie_jayx> I merge changes to 128 but that makes rev nº 129
[20:35] <nailuj24> if you merge 150 into 128, it'll be 129. if you do it the other way round, it'll be 151 (as far as i know)
[20:35] <effie_jayx> I am sorry If I come out as a bit of a noob but truth is I come from using mercurial with a bunch of abusers that do not handle merges as they should :P
[20:36] <effie_jayx> nailuj24: would it make sense to pull from another branch to get revisions to 151 and then resolve conflicts
[20:36] <effie_jayx> ?
[20:37] <nailuj24> what i'd do is to go into 150, and pull the 128. then you'll end up with 151 i think
[20:37] <effie_jayx> nailuj24:  shall try that
[20:37] <effie_jayx> thanks
[20:38] <Lo-lan-do> If you pull, then you get the same version number as what you pull.
[20:38] <effie_jayx> Lo-lan-do: good to know, not what I need
[20:38] <nailuj24> oh, didn't know that
[20:39] <Lo-lan-do> But anyway, pulling won't work in your case, since you have local changes not present in the remote branch.
[21:00] <jelmer> abentley: did you just tag the nested-trees-feature bug with udd?
[21:02] <abentley> jelmer, yes.
[21:03] <rowinggolfer> My project is 714 revisions in, but I intend I am radically altering the folder hierarchy..  is there any reason why starting a fresh tree is a bad idea?
[21:04] <Lo-lan-do> rowinggolfer: Apart from losing history?
[21:05] <rowinggolfer> Lo-lan-do, the changes are so dramatic that bzr diff shows nada...
[21:06]  * Lo-lan-do shrugs
[21:07] <Lo-lan-do> bzr annotate on files might still be useful later on, but if you don't care, that's your call :-)
[21:08] <rowinggolfer> Lo-lan-do, thanks for your input... I will keep the history
[21:08] <rowinggolfer> only downside is bigger branches for folks I guess
[21:25] <dan> hi
[21:25] <dan> can someone link me to some documentation on how to get started with bzr?
[21:26] <rowinggolfer> http://doc.bazaar.canonical.com/latest/en/mini-tutorial/
[21:26] <rowinggolfer> dan ^^
[21:28] <dan> ta!
[21:42] <lifeless> moin
[21:42] <Lo-lan-do> G'day
[21:45] <jelmer> lifeless: ping
[21:46] <jelmer> I mean
[21:46] <jelmer> 'morning lifeless
[21:47] <jelmer> lifeless: Is there an easy way to see what tests failed from the bzr pqm output?
[21:52] <lifeless> jelmer: grep for error: and fail:
[21:52] <lifeless> jelmer: there is a pending fix to pqm waiting on losa deployment to make it better
[21:52] <jelmer> lifeless: ok
[21:52] <jelmer> lifeless: Yeah, it was easier to find earlier - glad to hear it's a known issue.
[23:38] <jelmer> lifeless: unfortunately the error message
[23:38] <jelmer> is:
[23:38] <jelmer> _StringException: lost connection during success report of test 'bzrlib.tests.per_branch.test_last_revision_info.TestLastRevisionInfo.test_non_empty_branch(BzrBranchFormat4)'
[23:39] <jelmer> and the error doesn't fail locally
[23:39] <lifeless> newz2000: so, that means one of two things
[23:39] <lifeless> either the output was on stderr (should be at the top of the log)
[23:40] <lifeless> or it was mangled so that the end of the test couldn't be read :(
[23:40] <lifeless> I'll see if spm has time to do the upgrade when he surfaces
[23:42] <jelmer> lifeless: thanks
[23:43] <lifeless> jelmer: try with no plugins perhaps
[23:46] <jelmer> lifeless: I can't reproduce the error myself, but it happens in bzr's pqm
[23:49] <lifeless> yes, I'm suggesting trying with no plugins as a start
[23:49] <lifeless> in case a plugin is fixing it
[23:49] <lifeless> it's unlikely to be that specific test
[23:50] <lifeless> progress bars break subunit regularly