| james_w | lifeless: is https://code.edge.launchpad.net/~james-w/testtools/discover/+merge/26994 something like what you had in mind? | 00:25 |
|---|---|---|
| igc | morning | 00:37 |
| lifeless | moin moin | 00:38 |
| 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:04 |
| 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:05 |
| 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 |
| ubot5 | Launchpad bug 501174 in testtools "Suggest alternative to python -m testtools.run for Python 2.4 (affected: 1, heat: 6)" [Critical,Triaged] https://launchpad.net/bugs/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:06 |
| 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:07 |
| 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:08 |
| 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:10 |
| 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:11 |
| 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:12 |
| lifeless | right | 01:14 |
| lifeless | james_w: yes, bug in 2.4, it assumed top level module. | 01:14 |
| mgz | hm, might just try that now see what it looks like | 01:18 |
| 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:24 |
| mgz | poolie: ericmoritz was talking about calling Feature.available() because he wanted to skip if a feature *was* present | 01:30 |
| mgz | but that wasn't the right test anyway. | 01:31 |
| mgz | ah, whoops. | 01:33 |
| poolie | igc1, hi there? | 01:33 |
| mgz | guess I should repeat that, though not very important | 01:33 |
| 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:34 |
| poolie | oh ok | 01:36 |
| poolie | hm, perhaps we should define an inverse feature then | 01:36 |
| poolie | but that would be ok | 01:36 |
| === oubiwann_ is now known as oubiwann | ||
| 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:50 |
| Stavros | hmm, they are on B | 01:53 |
| Stavros | that's odd | 01:53 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| lifeless | self._format.sprout(...) and that lookup on the ... | 02:29 |
| lifeless | anyhow, I think I'm going to: | 02:29 |
| lifeless | sorry, sec | 02:30 |
| 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:31 |
| 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:32 |
| lifeless | and we have [at least for now | 02:33 |
| lifeless | ] established free access to Format objects for bzrdir components | 02:33 |
| spiv | lifeless: reuse through composition sounds like a very plausible idea to me | 02:34 |
| 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:37 |
| lifeless | well I don't know how much cleaner it will be | 02:45 |
| 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:46 |
| lifeless | from Branch to BranchFormat | 02:52 |
| lifeless | where differences exist | 02:52 |
| 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:53 |
| poolie | so you'll call effectively source_branch.format.sprout(to_transport)? | 02:54 |
| lifeless | yes | 02:54 |
| 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:55 |
| lifeless | so we can run the right code for looms without triggering VFS for regular branches | 02:56 |
| poolie | hm | 02:59 |
| poolie | i kind of see the problem you mean | 02:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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 the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | bzr 2.1.1 is out | bzr 2.1.2 is having binaries built for it | ||
| poolie | (changed pilot->spiv) | 03:09 |
| lifeless | spiv: wearing the pilots-get-interrupted hat, perhaps you could do the followup on the release | 03:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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 | 03:25 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:45 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| Bigcheese | There's already one filed :P And it's talked about everywhere on the internet :P. | 06:54 |
| 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. | 06:55 |
| Bigcheese | Searching the bug DB I've found at least 5 of the exact same thing. One even mentions you :P. | 07:04 |
| 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:08 |
| Bigcheese | how do I check the bzr-svn version? | 07:10 |
| lifeless | bzr plugins | 07:10 |
| Bigcheese | http://codepad.org/1ToCN8jN | 07:11 |
| 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:13 |
| 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:14 |
| lifeless | spiv: ^ btw may be a fast task to do the release - just send email :P | 07:15 |
| === quicksil1er is now known as quicksilver | ||
| 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. | 07:17 |
| === radoe_ is now known as radoe | ||
| === lifeless_ is now known as lifeless | ||
| spiv | lifeless: might be fast, but we're done for the day. Will have to look tomorrow. | 08:22 |
| spiv | lifeless: thanks for the idea | 08:23 |
| lifeless | spiv: sleep well | 08:23 |
| parthm | mgz: ping | 09:06 |
| bouncingzip | indeed I did apparently. | 09:07 |
| bouncingzip | do I bother looking up how to ghost myself on this network... | 09:07 |
| === bouncingzip is now known as mgz | ||
| mgz | parthm: hi | 09:09 |
| === jfroy_ is now known as jfroy | ||
| parthm | mgz: thanks for the patches :) | 09:09 |
| mgz | it's your own fault for copying all those loops, 's like waving a red flag to a pedant like me :) | 09:11 |
| === mwhudson_ is now known as mwhudson | ||
| 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:12 |
| 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:13 |
| parthm | mgz: yes. i will try that. you patch is well timed, we get bug #590589 fixed as bonus :) | 09:14 |
| ubot5 | Launchpad bug 590589 in bzr-grep "UnicodeDecode error with -F -i (affected: 1, heat: 8)" [High,Confirmed] https://launchpad.net/bugs/590589 | 09:14 |
| mgz | was trying not to make anything slower in that branch so the follow-on speed up was still a win. | 09:15 |
| parthm | mgz: UnicodeDecodeError for 'bzr grep ff' on mysql repo http://pastebin.com/JGfwXbk5 | 09:18 |
| mgz | doh! | 09:18 |
| 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:19 |
| 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:21 |
| mgz | guess I need to try harder to make a test that'll consistently fail on that as well | 09:22 |
| 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:23 |
| GaryvdM | I have a corrupted dirstate file, an the branch has uncommited changes. | 09:24 |
| GaryvdM | Bug #450047 | 09:24 |
| ubot5 | Launchpad bug 450047 in Bazaar "AssertionError: get_next() called when there are no chars left in dirstate (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/450047 | 09:24 |
| GaryvdM | Any recomendations on how to recover. | 09:24 |
| parthm | mgz: tested on emacs and mysql. works nicely. -Fi bug is also fixed. Yay! | 09:25 |
| mgz | no smart ideas here gary. branch from somewhere else and copy over the working tree? | 09:28 |
| GaryvdM | Ok - I mv .bzr/checkout .bzr/checkout.bck, and then did a checkout, and the files with changes show up as conflicts. | 09:29 |
| mgz | resolve --take-this then? (or -other which ever the right way round is) | 09:31 |
| GaryvdM | This is on a server. Only have bzr 2.1 :-( | 09:32 |
| mgz | hm. annoying. | 09:33 |
| 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:34 |
| 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:35 |
| mgz | parthm: could do, but no rush, only do it if you've got the time anyway | 09:37 |
| 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:38 |
| parthm | mgz: fast-path is also merged. thanks. | 09:39 |
| 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:40 |
| 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:41 |
| parthm | we could do a 0.4.0 in a few days it you want to try something. | 09:42 |
| 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:43 |
| 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:44 |
| parthm | mgz: yes. i suppose i will file a bug for this an explore it for a later release. | 09:45 |
| parthm | mgz: bug #591147 | 09:47 |
| ubot5 | Launchpad bug 591147 in bzr-grep "line numbers may not be correct for mixed line endings (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/591147 | 09:47 |
| mgz | it's a pain, as just using \n is and should be the right thing | 09:48 |
| parthm | mgz: Yup. i suppose majority of software is about compatibility issues :) | 09:49 |
| mgz | anyway, away for me. | 09:54 |
| parthm | mgz: bye | 09:55 |
| === guijemon1 is now known as guijemont | ||
| === Kinnison_ is now known as Kinnison | ||
| === nlisgo_ is now known as nlisgo | ||
| === cody-somerville_ is now known as cody-somerville | ||
| === cody-somerville_ is now known as cody-somerville | ||
| ronny | hi | 12:16 |
| ronny | how can i disable bzr's lazy importer? | 12:16 |
| ronny | bummer, its not possible | 12:21 |
| RayChandlerIII | Does anyone know of a general guide on the idea of feature branching? | 12:46 |
| parthm | RayChandlerIII: do you mean in context of setting up bzr repo structure? | 12:50 |
| 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:52 |
| 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:53 |
| parthm | this way all branches with share history in the repo (less disk space used). | 12:54 |
| 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:55 |
| === oubiwann is now known as oubiwann_ | ||
| === oubiwann_ is now known as ouniwann | ||
| 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:57 |
| 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:58 |
| 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 | 12:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| RayChandlerIII | Ok. Thank you for the help and your time. Let me take a look at the tutorial | 13:06 |
| RayChandlerIII | Ok... | 13:17 |
| RayChandlerIII | I think I understand it now. ;) | 13:18 |
| parthm | RayChandlerIII: cool :) | 13:18 |
| RayChandlerIII | brb | 13:32 |
| === ouniwann is now known as oubiwann | ||
| === Pilky_ is now known as Pilky | ||
| 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:14 |
| 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? | 16:15 |
| === beuno is now known as beuno-lunch | ||
| === IslandUsurper is now known as IslandUsurperAFK | ||
| === beuno-lunch is now known as beuno | ||
| === IslandUsurperAFK is now known as IslandUsurper | ||
| 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? | 18:36 |
| GaryvdM | Hi all | 19:08 |
| * GaryvdM was looking for jam | 19:08 | |
| === al-maisan is now known as almaisan-away | ||
| === deryck is now known as deryck[lunch] | ||
| 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? | 19:35 |
| === khmarbaise_ is now known as khmarbaise | ||
| === deryck[lunch] is now known as deryck | ||
| === khmarbaise_ is now known as khmarbaise | ||
| GaryvdM | maco: Launchpad may take a few minutes to reflect changes to branches | 20:05 |
| 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:10 |
| 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:20 |
| maco | GaryvdM: oh. ok | 20:22 |
| maco | GaryvdM: thanks | 20:22 |
| === khmarbaise_ is now known as khmarbaise | ||
| 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:26 |
| 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:27 |
| Lo-lan-do | I've seen some commits on bzr-git, yes, which gave me hope :-) | 20:28 |
| jelmer | the performance is still pretty pathetic for 'bzr git-serve', but it does work with the roundtripping code | 20:29 |
| 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:30 |
| Lo-lan-do | Great :-) | 20:31 |
| effie_jayx | hey guys, with regards revision numbers after a merge | 20:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| Lo-lan-do | But anyway, pulling won't work in your case, since you have local changes not present in the remote branch. | 20:39 |
| jelmer | abentley: did you just tag the nested-trees-feature bug with udd? | 21:00 |
| abentley | jelmer, yes. | 21:02 |
| 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:03 |
| Lo-lan-do | rowinggolfer: Apart from losing history? | 21:04 |
| rowinggolfer | Lo-lan-do, the changes are so dramatic that bzr diff shows nada... | 21:05 |
| === Meths_ is now known as Meths | ||
| * Lo-lan-do shrugs | 21:06 | |
| Lo-lan-do | bzr annotate on files might still be useful later on, but if you don't care, that's your call :-) | 21:07 |
| 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:08 |
| dan | hi | 21:25 |
| dan | can someone link me to some documentation on how to get started with bzr? | 21:25 |
| rowinggolfer | http://doc.bazaar.canonical.com/latest/en/mini-tutorial/ | 21:26 |
| rowinggolfer | dan ^^ | 21:26 |
| dan | ta! | 21:28 |
| lifeless | moin | 21:42 |
| Lo-lan-do | G'day | 21:42 |
| jelmer | lifeless: ping | 21:45 |
| jelmer | I mean | 21:46 |
| jelmer | 'morning lifeless | 21:46 |
| jelmer | lifeless: Is there an easy way to see what tests failed from the bzr pqm output? | 21:47 |
| 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. | 21:52 |
| 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:38 |
| 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:39 |
| 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:40 |
| === nlisgo_ is now known as nlisgo | ||
| jelmer | lifeless: thanks | 23:42 |
| lifeless | jelmer: try with no plugins perhaps | 23:43 |
| jelmer | lifeless: I can't reproduce the error myself, but it happens in bzr's pqm | 23:46 |
| 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:49 |
| lifeless | progress bars break subunit regularly | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!