| poolie | hello | 00:02 |
|---|---|---|
| lifeless | poolie: I need more details on vila's stuff to find it | 00:16 |
| poolie | "how various commands display revisions" | 00:21 |
| poolie | and there's one about python2.6, which does have a patch that i'm about to read | 00:21 |
| poolie | you don't need to spend a lot of time on it, i think he'd just like to know people read them | 00:23 |
| lifeless | I read the former | 00:31 |
| lifeless | I'll pass on the latter for now | 00:31 |
| lifeless | spiv: btw aren't context manages 2.5? | 00:31 |
| spiv | lifeless: yeah, they are. | 00:34 |
| spiv | lifeless: but we're still supporting 2.4, so that doesn't help us much. | 00:34 |
| lifeless | spiv: yah, not to mention, like I said, I don't think they help anyhow | 00:36 |
| lifeless | spiv: because, aren't they effectively just syntactic sugar for try:finally:except:? | 00:36 |
| spiv | Roughly, yes. | 00:36 |
| beuno | mwhudson, do you have a bit of time today to review Verterok's branch for traceback logging? | 00:36 |
| lifeless | so the squashing will still happen | 00:36 |
| spiv | But that is helpful, in this case. | 00:37 |
| lifeless | spiv: how so? | 00:37 |
| spiv | Because unlike try/except/finally, I'm fairly sure you can put the logic to preserve the original exception (if any) inside the context manager. | 00:37 |
| mwhudson | Verterok: yeah, should think so | 00:38 |
| === dereine is now known as dereine[afk] | ||
| spiv | So the obvious spelling of "with write_locked(foo): ..." can then DTRT, where "foo.lock(); try: ... finally: foo.unlock()" doesn't. | 00:39 |
| lifeless | __exit__( exc_type, exc_val, exc_tb) | 00:39 |
| lifeless | is the key spelling | 00:39 |
| lifeless | spiv: but you can spell write_locked as try:finally:except e:try:self.unlock() except:pass; raise e | 00:40 |
| spiv | It is possible to preserve the original exception (and traceback) with try/except; our needs_write_lock decorator does that now. | 00:40 |
| beuno | mwhudson, thanks. It's a big patch, and mostly touches code you've worked on | 00:40 |
| spiv | But it's awkward to reuse that in a typical try/finally, which means that it's going to be easy to miss places that don't do it properly. | 00:41 |
| lifeless | apply_locked ? | 00:42 |
| lifeless | erm | 00:42 |
| lifeless | apply_write_locked, suggesting a name | 00:42 |
| spiv | Yeah. I was also thinking that *maybe* it would be possible to re-write just the finally block as "preserve_original_exception(foo.unlock)" | 00:43 |
| spiv | (not a great name, obviously) | 00:44 |
| lifeless | the sys.tb* are not threadsafe though | 00:44 |
| spiv | sys.exc_info() is. | 00:44 |
| lifeless | oh cool | 00:44 |
| spiv | The tricky bit is that I need to look up if there can be times where sys.exc_info() can be set when there isn't an active exception (and I suspect there are). | 00:45 |
| === RAOF_ is now known as RAOF | ||
| spiv | Possibly those are just corner cases about invoking things from except: blocks. But I'd prefer a solution that obviously correct :) | 00:46 |
| lifeless | abentley: ping | 00:48 |
| abentley | lifeless: pong | 00:49 |
| lifeless | abentley: the intertree previewtree test, I'm not quite sure what its testing | 00:49 |
| lifeless | abentley: I just had a conflict on that change, so I thought I'd expand on the comment. | 00:49 |
| lifeless | abentley: is there a different InterTree that it tests? Or are you just adding-some-coverage-to-PreviewTree ? | 00:49 |
| abentley | I'm just adding-some-coverage-to-PreviewTree | 00:50 |
| lifeless | ok. | 00:50 |
| lifeless | # PreviewTree doesn't get the stock interface tests for working tree, | 00:51 |
| lifeless | # having it exercised by the standard intertree tests provides useful test | 00:51 |
| lifeless | # coverage. | 00:51 |
| lifeless | thats my expanded comment, seem ok ? | 00:51 |
| Verterok | beuno, mwhudson: thanks! | 00:51 |
| lifeless | [I've also made it clear that the InterTree tests are running with PreviewTree, so failures are clearer | 00:51 |
| lifeless | ] | 00:52 |
| beuno | Verterok thanks for working on it :) | 00:52 |
| abentley | lifeless: I don't understand why you're referring to working tree. | 00:52 |
| lifeless | s/working tree/trees/ | 00:52 |
| abentley | lifeless: Okay, so now I don't understand the comment, because PreviewTree is exercised by the tree_implementation tests | 00:53 |
| lifeless | abentley: I'm trying to write down _why_ we get more coverage by having PreviewTree present in the InterTree tests. | 00:54 |
| lifeless | obviously we *do*, and thats fine. | 00:54 |
| abentley | I would say "PreviewTree does get the stock interface tests for tree..." | 00:54 |
| lifeless | but the System-Under-Test is the InterTree class and its subclasses, not any specific tree implementation; its very weird from that perspective to have PreviewTree here | 00:54 |
| abentley | So the point is that PreviewTree doesn't have an InterTree, perhaps? | 00:56 |
| lifeless | # The stock interface tests for 'tree' are insufficient to thoroughly cover | 00:56 |
| lifeless | # PreviewTree. Exercising it by the InterTree tests provides useful | 00:56 |
| lifeless | # additional coverage. | 00:56 |
| lifeless | abentley: from a theory perspective, any failures you uncovered are failures in the tree interface tests | 00:57 |
| lifeless | [in that they fail to cover something that anything claiming to be a Tree should provide] | 00:57 |
| lifeless | poolie: you sunk my battleship | 00:58 |
| abentley | lifeless: So do you think that iter_changes et al should be tested in tree_implementations? | 00:58 |
| lifeless | poolie: (conflict in NEWS after the lock patch landed) | 00:59 |
| lifeless | abentley: uhm, that question suggests I need to read a little deeper. Tree.iter_changes is meant to be just a thunk down to InterTree; if its not its going to be asymmetric across types. | 01:00 |
| lifeless | abentley: I'll be a minute, just fixing this conflict for pqm | 01:00 |
| abentley | lifeless: For PreviewTree, it's not, but that's not relevant. | 01:01 |
| poolie | lifeless: someone should write a script to avoid NEWS conflicts :-P | 01:02 |
| abentley | I need to make sure that PreviewTree.iter_changes works. How should we be testing that? | 01:02 |
| lifeless | abentley: ok, now I see whats going on | 01:02 |
| lifeless | abentley: InterTree is the right place to test iter_changes; I think PreviewTree should not have an iter_changes method though | 01:04 |
| lifeless | abentley: because wt.iter_changes(preview_tree) should be the reverse of preview_tree.iter_changes(wt) | 01:04 |
| lifeless | anyhow, the comment I propose now is: | 01:05 |
| lifeless | # PreviewTree does not have an InterTree optimiser class. | 01:05 |
| abentley | lifeless: In these tests, it's using InterTree.iter_changes. | 01:05 |
| abentley | It still needs to be tested. | 01:05 |
| abentley | If we just use the existing tests, it won't be. | 01:06 |
| lifeless | I'm getting more confused by the minute | 01:06 |
| abentley | There needs to be a scenario for every tree type. | 01:06 |
| lifeless | InterTree does not have a scenario for every tree type and shouldn't have one | 01:06 |
| abentley | Correct. | 01:07 |
| lifeless | it should have a scenario for every code path from InterTree | 01:07 |
| abentley | But we do need to test every tree type in "tree_implementations". | 01:07 |
| poolie | lifeless: +1 to taking files from a special directory and merging them into NEWS | 01:07 |
| abentley | Sorry | 01:07 |
| abentley | in "intertree_implementations". | 01:08 |
| poolie | i don't see why special handling would be needed for deletions | 01:08 |
| mwhudson | how do i make a repository a no-trees repository again? | 01:08 |
| lifeless | poolie: in a single-file approach | 01:08 |
| lifeless | mwhudson: touch no-working-trees in .bzr/repository | 01:08 |
| mwhudson | lifeless: thanks | 01:08 |
| poolie | lifeless: i mean if someone changes the news entry after it's merged into NEWS | 01:08 |
| poolie | that is a real conflict | 01:08 |
| poolie | we'd want them to instead update the bit merged in to NEWS | 01:08 |
| abentley | Otherwise, we don't know that those operations work. | 01:09 |
| lifeless | abentley: the point of interfaces is to avoid polynomial growth; test that object A implements interface I correctly, then test that object B uses interface I correctly | 01:09 |
| lifeless | abentley: InterTree tests are tests of object B on the interface 'Tree' | 01:10 |
| lifeless | abentley: any failure on an arbitrary (Tree,Tree) pair passed into InterTree.get(Tree, Tree).iter_changes() is either a failure in the Tree interface tests (if the object doesn't support something), or a failure in the InterTree tests (if the code path in InterTree is faulty) | 01:11 |
| abentley | lifeless: I think that isn't true when optimizers are invoked. I suspect that the InterTree optimizer for WorkingTree4 has requirements that Tree doesn't meet. | 01:11 |
| lifeless | abentley: the optimiser for WT4 only kicks in (and this is tested) when the other tree is a DirStateRevisionTree | 01:12 |
| abentley | lifeless: So it is not a test on the interface 'Tree'. | 01:12 |
| lifeless | abentley: what 'it' there? | 01:13 |
| abentley | A test of iter_changes involving a wt4 and a DirstateRevisionTree. | 01:14 |
| lifeless | right, its a test of InterTree (specifically InterDirstateTree) | 01:14 |
| abentley | But you said "InterTree tests are tests of object B on the interface 'Tree'" | 01:14 |
| lifeless | object B is is the SUT, which is InterDirstateTree | 01:15 |
| lifeless | the interface 'Tree' is a layer the test depends on | 01:15 |
| abentley | lifeless: expand SUT please? | 01:15 |
| lifeless | system under test | 01:15 |
| lifeless | the code being tested | 01:15 |
| lifeless | as opposed to things the test needs but assumes are in good working order | 01:16 |
| abentley | lifeless: So you are saying that InterTree and not InterDirstateTree tests are tests on the interface "Tree"? | 01:16 |
| lifeless | I'm saying they are both tests that build on the interface "Tree" but *do not test the interace "Tree"* | 01:17 |
| lifeless | they make no assertions about the behaviour of e.g. get_file_sha1 | 01:17 |
| lifeless | abentley: we almost certainly have missing test coverage of the Tree interface | 01:17 |
| abentley | lifeless: Well, less since I merged my previous two patches. | 01:19 |
| lifeless | abentley: so doing what you've done is a good thing, I'm just trying to make sure its commented correctly; and ideally get some bugs filed about the things you found out so that we can fix the other faulty/missing tessts | 01:19 |
| lifeless | abentley: skipping the theory, here is the pragmatic thing I'm trying to get at: a broken method on PreviewTree found by running InterTree tests implies a missing/faulty test in tree_implementations/*.py | 01:21 |
| abentley | lifeless: Since PreviewTree's iter_changes was broken, this suggests that iter_changes should be tested in tree_implementations. | 01:22 |
| lifeless | abentley: the transform.iter_changes was broken, or InterTree.iter_changes broke on PreviewTrees? | 01:22 |
| abentley | InterTree.iter_changes broke on PreviewTrees | 01:22 |
| lifeless | abentley: that says that tree_implementations is missing tests, but not of iter_changes | 01:23 |
| lifeless | abentley: rather of the parts of the Tree interface that are not fully tested. | 01:23 |
| abentley | I don't think there's anything that mandates that iter_changes be implemented in terms of InterTree. I think it's an implementation detail. | 01:24 |
| lifeless | abentley: you found get_file_sha1 was missing, IIRC? | 01:24 |
| abentley | lifeless: Yes, and _comparison_data, _file_size. | 01:26 |
| lifeless | abentley: to me that says there are missing tests for get_file_sha1, _comparison_data, _file_size on Tree | 01:26 |
| abentley | lifeless: We don't disagree about that. | 01:27 |
| lifeless | ok | 01:27 |
| lifeless | phew, I thought we were stuck. | 01:27 |
| abentley | But I also think that iter_trees should be tested on every class that claims to provide it. | 01:27 |
| abentley | Because testing that PreviewTree provides X and InterTree works with X doesn't work if iter_changes doesn't use InterTree. | 01:28 |
| lifeless | abentley: I don't think anyone should override iter_changes, and so we shouldn't need to test it on each tree. | 01:28 |
| lifeless | iter_changes needs two trees to test; doing interface tests for that needs two degrees of parameterisation; its tricky at best. | 01:29 |
| lifeless | I think what you've done is ok, though I'm struggling to reconstruct the change you made vis-a-vis _test_mutable_trees_to_test_trees | 01:29 |
| abentley | I wasn't suggesting it we needed to do n^2 complexity. | 01:29 |
| lifeless | (its broken by iter_changes branch) | 01:29 |
| lifeless | s/by/my/ | 01:29 |
| abentley | But to not test at all seems questionable. | 01:30 |
| lifeless | abentley: I'm not suggesting that we don't test! | 01:31 |
| abentley | lifeless: You are essentially saying we should test InterTree.iter_changes, not Tree.iter_changes. | 01:31 |
| lifeless | abentley: I'm saying that there should be only one implementation of Tree.iter_changes - its meant to be just syntactic sugar | 01:32 |
| lifeless | abentley: because the multimethod support InterObject gives us lets us test it effectively; it certainly looks like you found it easy enough to slot it in. | 01:33 |
| abentley | lifeless: So yeah, that's what we disagree on. Mandating that Tree.iter_changes be implemented via InterTree and therefore not testing Tree.iter_changes. | 01:34 |
| lifeless | I guess so | 01:35 |
| abentley | lifeless: Anyhow, I just changed _test_mutable_trees_to_test_trees to take TestCase as a parameter. | 01:36 |
| abentley | That allows me to call addCleanup to clean up the PreviewTree's TreeTransform. | 01:37 |
| lifeless | yup, thanks | 01:41 |
| lifeless | I had a change there to add C and python versions of the dirstate iter_changes code | 01:42 |
| abentley | lifeless: So one of the breakages was that PreviewTree doesn't provide .inventory, and iter_changes attempted to use it. | 01:43 |
| lifeless | now I need to figure out why readdir acceleration fails on PQM | 01:43 |
| === mw is now known as mw|out | ||
| poolie | jam, still around/ | 02:57 |
| Verterok | Hi, any thoughts about implementing __str__ in bzrlib.inventory.Inventory?...to avoid this http://rafb.net/p/yY76bI24.html | 02:57 |
| lifeless | Verterok: well thats for debugging really :P | 02:58 |
| Verterok | hehe | 02:59 |
| jam | spiv: there was a specific discussion in the Pyrex mailing list, about Pyrex leaving something in sys.exc_info() when there wasn't an active exception. | 02:59 |
| Verterok | lifeless: it's using __repr__ | 02:59 |
| jam | poolie: I'm aronud a bit, but I'll probably be in and out | 02:59 |
| lifeless | Verterok: I'd definitely want that output given that error to analyse things; user input shouldn't be able to trigger any normal exception like that | 02:59 |
| lifeless | jam: can you put that python 2.4 IFDEF in the pyrex bug I opened ? | 02:59 |
| lifeless | jam: PQM itself needs that | 02:59 |
| poolie | jam, so, for the lca shape merge, i'd like to merge it as-is to 1.7 in preparation for a 1.7.1 | 03:02 |
| poolie | what say you? | 03:04 |
| lifeless | poolie: is it really worth a 1.7.1 for it ? It doesn't seem to meet our general policy there [its not a regression] | 03:04 |
| jam | lifeless: well, we don't have a real policy for "large project publicly using bzr having problems doing common operations needs an officially released update to function properly" | 03:07 |
| jam | not sure if that makes a 1.7.1 valid or not | 03:07 |
| jam | just saying that it is outside of general policy we have crafted so far | 03:07 |
| lifeless | mmm | 03:08 |
| jam | for *their* trees, 'bzr merge' likes to leave broken paths around, because they have lots of things that get merged into multiple "release" branches, and then the release branches get merged (causes criss-cross) | 03:12 |
| lifeless | 1.7.1 will affect everyone by causing a new upgrade, more QA for distro folk etc | 03:13 |
| jam | poolie: My concern is that 1.7.1 will come out with it, and then 1.8 won't have it, which will be weird. | 03:13 |
| jam | lifeless: I'm not particularly concerned with the code causing regressions. I've done a lot of testing, including setting it as the default algorithm and running the full test suite. | 03:13 |
| jam | ATM the issues are "clarity of design" etc | 03:14 |
| jam | which is more a "can we maintain this?" rather than "is it broken?" | 03:14 |
| Verterok | lifeless: what's your recommendation? I made trivial fix, added __str__ to Inventory, and now only shows: http://paste.ubuntu.com/49910/ | 03:14 |
| jam | lifeless: I don't see a "pyrex bug that you just opened" can you link it for me? | 03:15 |
| poolie | jam, so i do see the "clarity of design" thing as a case of the general thing about the way we do reviews | 03:15 |
| lifeless | Verterok: I think the bug is that it's showing the inventory and not a tree objct | 03:15 |
| lifeless | Verterok: totally unrelated to __str__ or __repr__ | 03:15 |
| poolie | if we merge it to bzr.1.7 we should immediately merge that back to trunk | 03:15 |
| Verterok | lifeless: ok, thanks for the tip :) I'll back after digging a bit more | 03:16 |
| lifeless | jam: https://bugs.edge.launchpad.net/bzr/+bug/271939/comments/2 | 03:16 |
| ubottu | Ubuntu bug 271939 in bzr "extensions fail to build on python 2.4" [Medium,Triaged] | 03:16 |
| jam | lifeless: of course, lp has a bug that linking to a comment on a bug doesn't have an obvious link back to the bug itself ... :) | 03:17 |
| lifeless | hey, I just work here | 03:17 |
| lifeless | jam: re using 'pathjoin' rather than 'osutils.pathjoin' | 03:18 |
| jam | lifeless: what about: https://bugs.edge.launchpad.net/bzr/+bug/271939/comments/3 | 03:18 |
| ubottu | Ubuntu bug 271939 in bzr "extensions fail to build on python 2.4" [Medium,Triaged] | 03:19 |
| lifeless | jam: you can't use default values in cdef functions | 03:19 |
| lifeless | jam: thanks | 03:19 |
| jam | so you can't do "cdef myfunction(foo, bar=XXX)" ? | 03:19 |
| lifeless | right | 03:19 |
| lifeless | so I can cache it in some of the places its used, and I've just done that | 03:20 |
| lifeless | but I really don't want a double-lookup in _update_entry | 03:20 |
| poolie | jam, lifeless, any other concerns about doing this? | 03:20 |
| lifeless | poolie: I think it doesn't match our stated motivations for point releases. So we shouldn't do it, or we should rewrite those motivations. | 03:21 |
| jam | lifeless: I don't have a problem with it being at module scope, I just find "from bzrlib import osutils\nfrom bzrlib.osutils import X, Y" to be a bit odd. | 03:21 |
| lifeless | jam: we do it a lot; doing an import and assignment would be more weird IMNSHO, but I can do that if you want | 03:22 |
| fullermd | Whoah. Did I miss the announcement of meta week on the list? | 03:22 |
| poolie | lifeless: ok, we'll add "or as needed" :-) specifically, this is a serious bug for numerous users | 03:22 |
| lifeless | poolie: its not a regression | 03:23 |
| lifeless | poolie: thats the real thing that annoys me about it | 03:23 |
| jam | lifeless: strictly speaking neither was 1.6.1 | 03:23 |
| jam | branch --stacked wasn't *in* 1.5 | 03:23 |
| lifeless | jam: 1.6 was a brown paper bag | 03:23 |
| jam | so we couldn't regress anything | 03:23 |
| lifeless | jam: it had a format that could create data loss; that is a regression | 03:23 |
| poolie | is this defined in hacking or is it just general principle? | 03:24 |
| lifeless | poolie: memory from our interminable discussions years ago | 03:24 |
| poolie | i don't remember us saying it was only regressions and not bugs | 03:24 |
| lifeless | poolie: dunno if its enshrined or not | 03:24 |
| jam | lifeless: i don't actually know any way that data loss could have actually happened in it. but if you say so | 03:24 |
| poolie | _anyhow_, they want it sooner than 1.8 and i want to help them | 03:24 |
| poolie | i think this is a reasonable use of a point release | 03:24 |
| jam | poolie: we could always make it "1.7-mysql" :) | 03:25 |
| poolie | jam, 1.7-we-love-you-and-brought-you-flowers | 03:25 |
| lifeless | I can't wait for 2.5.34, when we have more large users | 03:25 |
| poolie | me either, that will be great | 03:25 |
| poolie | well | 03:25 |
| poolie | to be a bit more serious, we have some other options | 03:25 |
| poolie | 1- just wait for 1.8 | 03:26 |
| poolie | 2- start releasing 1.8 now, from trunk | 03:26 |
| poolie | 3- do a 1.7-mysql that's not a regular release | 03:26 |
| poolie | 2s/$/, with this merged in first/ | 03:26 |
| poolie | let's decide what's right in this case and we can use that to tune the documented policy if necessary | 03:27 |
| lifeless | My understanding, from the original agreement with them was that we would do (1) | 03:27 |
| lifeless | we'd get them a fix, and then work to get it into the normal release | 03:27 |
| poolie | the original plan was it would be in _1.7_ since the patch was ready before then | 03:28 |
| poolie | after it looked likely it would slip i told them we would do a 1.7.1 | 03:28 |
| poolie | or at least that it would be soon after 1.7 | 03:28 |
| poolie | not a month later | 03:28 |
| poolie | so, 1 would both be disappointing for them and breaking our commitment | 03:28 |
| lifeless | I don't think its breaking our commitment if it took more than one release to polish the workaround to inclusion | 03:29 |
| lifeless | I can understand the disappointment | 03:29 |
| poolie | are there any issues other than the policy one? | 03:30 |
| lifeless | releases have a cost; I don't see why paying that cost is better than spending the same effort on getting the thing merged to trunk | 03:31 |
| poolie | it's a good poitn | 03:32 |
| poolie | but for them it won't really be done until it's in a release | 03:32 |
| poolie | as they can't ask everyone to run from trunk | 03:32 |
| lifeless | so if you want to talk about getting it done, why didn't we just do what Aaron requested during the 1.7 cycle, then it could be landed already? | 03:33 |
| lifeless | jam: re putting the python stuff in _dirstate_helpers_py.py, I'm a bit ambivalent; I guess feeling lazy more than anything | 03:36 |
| jam | lifeless: well, if we are getting to that point, why didn't we review it a month earlier when it was posted ? | 03:36 |
| jam | there are a lot of "woulda-coulda-shoulda"s we can get to | 03:36 |
| jam | but how do we get where we want to be now? | 03:36 |
| jam | lifeless: I think it is a bit easier to find the comparison code if it follows the same layout | 03:37 |
| jam | is it more than a cut & paste for you to do so? | 03:37 |
| lifeless | jam: adjust imports, possibly circular ones | 03:37 |
| lifeless | other than that, no, just c&Pp | 03:37 |
| jam | lifeless: ATM, I can respect your feeling, I think it is cleaner to put it in _py.py, but it doesn't change the correctness of your patch :) | 03:38 |
| lifeless | jam: moving it over | 03:39 |
| lifeless | I ended up with it in dirstate.py because _update_entry started there. | 03:39 |
| * spiv -> lunch | 03:44 | |
| lifeless | jam: circular imports up the wazoow | 03:50 |
| Verterok | lifeless: when you have a few minutes to spare in the inventory.__repr__ bug, I have a question (or two) | 04:30 |
| lifeless | Verterok: sure | 04:31 |
| lifeless | Verterok: I think its a annotate bug :P | 04:31 |
| Verterok | lifeless: indeed :) | 04:31 |
| Verterok | lifeless: acctually Inventory contributes a bit | 04:32 |
| Verterok | lifeless: Inventory.__getitem__ raises errors.NoSuchId, with the inventory instance instead of a tree | 04:33 |
| Verterok | maybe annotate could catch that and raise the right error? | 04:33 |
| Verterok | or there is an API to access the inventory that annotate isn't using? | 04:34 |
| * Verterok hides | 04:34 | |
| lifeless | Verterok: I need food rather badly; could you pastebin the backtrace perhaps? or file a bug about the bad UI result? | 04:35 |
| lifeless | I'll look whwen I get back | 04:35 |
| Verterok | lifeless: np, I'll keep playing a bit, and file a bug about it | 04:36 |
| lifeless | Verterok: ah caffeine and food | 05:03 |
| Verterok | lifeless: what we would do without them! | 05:03 |
| fullermd | Starve in our sleep. | 05:04 |
| Verterok | jaja | 05:04 |
| lifeless | ITYM java :P | 05:04 |
| Verterok | :p | 05:05 |
| Verterok | lifeless: done, filed Bug #273835 | 05:28 |
| ubottu | Launchpad bug 273835 in bzr "annotate of a not present file_id give a huge error message" [Undecided,New] https://launchpad.net/bugs/273835 | 05:28 |
| lifeless | Verterok: thanks | 05:29 |
| Verterok | ups...I think it's a duplicate :p (Bug #246573) | 05:31 |
| ubottu | Launchpad bug 246573 in bzr "'bzr annotate file.OTHER' during contents conflict gives traceback" [Medium,Confirmed] https://launchpad.net/bugs/246573 | 05:31 |
| * AfC wonders if the Bazaar hackers have landed the compression work they've been talking about over the last few months. | 06:13 | |
| beuno | AfC, I think the b-tree stuff is in 1.7 as experimental | 06:14 |
| lifeless | beuno: groupcompress is what afc means | 06:14 |
| lifeless | AfC: no, its not landed yet | 06:14 |
| beuno | lifeless, oh, I thought that was part of the btree? | 06:15 |
| lifeless | beuno: no | 06:15 |
| beuno | lifeless, so that would be another format? | 06:16 |
| lifeless | groupcompress is a replacement for the 'knit' stuff | 06:16 |
| lifeless | btree isn't in a format in bzr.dev yet | 06:16 |
| beuno | but both of them will trigger a format change, right? | 06:17 |
| lifeless | either of | 06:18 |
| lifeless | (yes, you need a new format to use either set of code) | 06:19 |
| === Snaury is now known as Snaury[away] | ||
| === tro|| is now known as tro | ||
| vila | hi all, yeah for 1.7 ! | 06:55 |
| lifeless | vila: I'm still not sure what stuff you wanted in my inventory docs | 06:57 |
| lifeless | vila: AFAICT I wrote some prose; you were confused by it; I rephrased the exact same text and it made you happy. | 06:57 |
| vila | lifeless: your answers made me happy, I'm not sure they found their way in the text, but I think I BB:approved anyway | 06:58 |
| lifeless | vila: it was approved with the edit, but I'm feeling lost as to how to do the edit without repeating myself lots | 06:59 |
| vila | I can review it again if you want but I'm not sure about where to find the latests version | 07:00 |
| vila | s/ts/t/ | 07:00 |
| vila | I needed to read it again anyway | 07:01 |
| poolie | hi vila! | 07:01 |
| vila | hey poolie :) | 07:01 |
| lifeless | vila: on-list/bb | 07:01 |
| vila | lifeless: ok, I've got it back (I've lost all my read/unread markers last week and had to triage ~10.000 mails again :-/) | 07:04 |
| fullermd | Gyuh. | 07:05 |
| fullermd | What a horrible thought. | 07:05 |
| vila | Just thinking about it is far less painful though :D | 07:06 |
| poolie | vila: um | 07:06 |
| poolie | anyhow, i'm reading your 2.6 patch | 07:07 |
| fullermd | Y'know, that sorta thing wouldn't happen if you used vi... | 07:07 |
| * fullermd hides. | 07:07 | |
| vila | fullermd: I'm not sure there is mail agent suiting my needs for vi, but anyway, storing ~25.000 files in a single directory is more likely the root cause, especially when mounted over NFS | 07:10 |
| vila | sometimes you just have to pay for your sins :D | 07:10 |
| lifeless | vila: "NotFileSystem" | 07:10 |
| vila | lifeless: until it's broken, don't fix it :D It's likely a combination NFS/shutting down a virtual machine including a running mail client inside an editor, something I don't even want to start debugging, not even starting to think about it :) | 07:13 |
| lifeless | spiv: let me know if you want to chat re Inter*Remote* | 07:33 |
| lifeless | vila: how do you feel about me just landing the current prose? | 07:42 |
| vila | lifeless: just give me a few more minutes and I send you a patch where I inserted in your document the relevant comments | 07:43 |
| lifeless | vila: oh thanks | 07:43 |
| spiv | lifeless: If there's no InterOtherToRemote/InterRemoteToOther, which InterRepo would you want used? Whichever of InterSameData/InterModel1and2/InterDifferingSerializer fits best? | 07:49 |
| lifeless | spiv: 'yes' | 07:53 |
| lifeless | spiv: as in, the RemoteRepo already exposes the needed data to choose one of those and use it | 07:53 |
| * spiv nods | 07:53 | |
| lifeless | spiv: my reasoning in a nutshell is - the generic API should be fine for performance | 07:54 |
| spiv | At the moment, the generic InterRepo's would force an _ensure_real just by the is_compatible checks. | 07:54 |
| vila | lifeless: sent | 07:55 |
| lifeless | spiv: if its not then many other things like 'annotate', 'cat', 'fast-export' that operate directly on RemoteRepo etc will be slow too | 07:55 |
| igc | lifeless: wrt the inventory prose patch, please check 'make docs' works before submitting it | 07:55 |
| lifeless | spiv: realy? those attributes are statically allocated by find_repositoryV2 I thought | 07:55 |
| igc | it didn't for me | 07:55 |
| spiv | They check repository._serializer | 07:55 |
| spiv | Which is a property that does _ensure_real atm :( | 07:56 |
| vila | igc, lifeless: I didn't check and my patch may contain even more errors :-/ | 07:56 |
| lifeless | spiv: oh, thats reasonable. Its needed to ensure the inventory and revision style is understood | 07:56 |
| lifeless | spiv: so fix that :P | 07:56 |
| spiv | That's something to fix in a find_repositoryV3... | 07:56 |
| lifeless | spiv: yah, I'm not trying to add work you understand, rather reduce overall work | 07:56 |
| spiv | I do understand that :) | 07:57 |
| igc | hi vila! | 07:57 |
| vila | hi Ian ! | 07:57 |
| lifeless | vila: so there is duplication straight up | 07:57 |
| vila | lifeless: ? my patch try to add things you already added ? | 07:58 |
| vila | if that's the case, I may have started with the wrong base, if you think what my patch try to add is already there, forget it and merge your version | 07:59 |
| lifeless | vila: btw its easier to merge patches if they are attachments | 08:00 |
| vila | lifeless: I was about to ask that precise question :) | 08:01 |
| * vila solves that kind of problem by having a mail agent integrated into an editor :D | 08:01 | |
| * vila should nevertheless think more about vi's users :) | 08:02 | |
| lifeless | vila: well, everything you quoted was already duplication | 08:02 |
| igc | vila: I'll take a look at 'how various cmds display revisions' tonight fwiw | 08:05 |
| lifeless | vila: I don't have any specific ideas on how to parameterise log_adapters; if I did I would have written them down. | 08:05 |
| vila | igc: thanks | 08:05 |
| lifeless | vila: I just think it needs doing; look at bzr-search if you want an example of a plugin patching into the log adapter stack | 08:06 |
| vila | lifeless: ok | 08:06 |
| vila | lifeless: ha, excellent | 08:06 |
| igc | spiv, poolie: well done on http://bazaar-vcs.org/SmartPushAnalysis1.8 - will be nice as we nail each of the issues found! | 08:06 |
| poolie | hm | 08:07 |
| poolie | it still needs more structure as a document but thanks | 08:08 |
| vila | I started with revno: 3641 | 08:09 |
| vila | revision-id: robertc@robertcollins.net-20080827004239-7d2b1m4bsd2u8ufm | 08:09 |
| vila | but anyway, BB:approve, land, land ! :) | 08:09 |
| lifeless | vila: This is the patch I have uncommitted. ... | 08:09 |
| lifeless | http://paste.ubuntu.com/49971/ | 08:10 |
| lifeless | 10 past 5 makes an unhappy boy | 08:10 |
| lifeless | vila: (bzr log -m "\bVincent\b") will use a bzr search index, if you have one | 08:10 |
| lifeless | igc: looks like a rest bug to me :( | 08:21 |
| lifeless | igc: its valid reset list AFAICT, but it fails-to-format | 08:29 |
| === Spaz is now known as Kittens | ||
| === Kittens is now known as Spaz | ||
| === dereine[afk] is now known as dereine | ||
| a_c_m | with bzr using file permissions can you restrict commit access to a folder in a branch e.g. only about the dba to commit to /sql ? would that work? | 09:16 |
| bob2 | no | 09:16 |
| a_c_m | is there a way to achieve that? | 09:17 |
| bob2 | you could use a commit hook, I think | 09:19 |
| a_c_m | why would the file permissions thing not work? | 09:19 |
| lifeless | a_c_m: because bzr does not version anything other than the 'x' bit | 09:19 |
| lifeless | a_c_m: you could use a seperate baranch for /sql | 09:20 |
| bob2 | a_c_m: all the data in the branch is stored in .bzr in the root of the branch | 09:20 |
| lifeless | a_c_m: or you could just enforce policy on merge; bzr is aimed at distributed setups | 09:20 |
| a_c_m | lifeless: humm ok, the commit hooks method is interesting, but i'm no python programer | 09:22 |
| lifeless | a_c_m: so, you could get someone to write it for you, its no harder than shell (actually easier than shell :P) | 09:23 |
| lifeless | a_c_m: because we support many databases, polcy can't be enforced by normal access control | 09:26 |
| lifeless | a_c_m: instead you have to do it 'when the content arrives' | 09:26 |
| a_c_m | lifeless: makes sense really :) | 09:31 |
| vigneswari | hello all | 11:18 |
| vigneswari | plz help in resolving my problem reg.bzr-trac | 11:18 |
| vigneswari | if i create any brach or repo using bzr init or init-repo..i couldnt view in trac browser | 11:19 |
| vigneswari | am i asking in correct channel? | 11:24 |
| vigneswari | plz help in resolving my problem reg.bzr-trac | 11:48 |
| vigneswari | if i create any brach or repo using bzr init or init-repo..i couldnt view in trac browser | 11:48 |
| vigneswari | should i provide some more details? | 11:52 |
| bob2 | maybe try the list | 11:58 |
| frk2 | hi guys! | 12:08 |
| frk2 | have successfully switched my project over to bzr from svn but have some issues with versioning while merging | 12:09 |
| jakobb | vigneswari: I just checked the website of trac: it says: 'it provides an interface to subversion' Are you even sure it should work with bzr? | 12:09 |
| jakobb | aah got it.... there is a plugin | 12:10 |
| frk2 | my problem is, mostly, that after merging and pushing - version numbers on the target repository get overwritten | 12:10 |
| bob2 | yes | 12:10 |
| frk2 | is that intentional? | 12:12 |
| frk2 | is thats how bzr is supposed to work? or am i doing something wrong | 12:13 |
| bob2 | you can set the append_mumble option | 12:13 |
| frk2 | bob2, append_mumble? | 12:13 |
| bob2 | append_revisions_only | 12:14 |
| frk2 | in bazaar.conf? | 12:15 |
| bob2 | in the branch.conf for the trunk | 12:15 |
| lifeless | frk2: merge + commit doesn't reset revisions | 12:17 |
| lifeless | frk2: 'pull' can and so can 'push' | 12:17 |
| frk2 | right | 12:17 |
| frk2 | thats whats happening | 12:18 |
| frk2 | we have a central trunk | 12:18 |
| frk2 | where multiple developers PULL from, and then PUSH | 12:18 |
| lifeless | frk2: this is covered in the users guide I believe | 12:18 |
| frk2 | if the branches diverge, one of us has to MERGE and PUSH, upsetting revision numbers | 12:18 |
| lifeless | frk2: recommended way to manage your trunk is to use checkouts for the trunk itself | 12:18 |
| lifeless | frk2: then you don't push into it, you commit your merge | 12:19 |
| lifeless | revision numbers won't change if you do this | 12:19 |
| frk2 | hmm | 12:20 |
| === dereine is now known as dereine[afk] | ||
| frk2 | I understand... but the whole point of me using bzr was that we have developers who have no write access to trunk | 12:20 |
| === dereine[afk] is now known as dereine | ||
| frk2 | so, we merge their changes and then push to trunk | 12:20 |
| lifeless | frk2: so those developers can't push anyhow | 12:20 |
| lifeless | frk2: exactly | 12:20 |
| frk2 | ah okay | 12:20 |
| frk2 | i see :) | 12:20 |
| jakobb | vigneswari: I guess you should try to get one of the developers of the bzr-plugin for trac to answer your question; I don't think the 'general' audience here has much experience with it | 12:21 |
| vigneswari | jakobb, any separate channel for plugins | 12:22 |
| jakobb | not that I'm aware of | 12:25 |
| jakobb | I do see that jelmer is among the developers... he's in here as well | 12:26 |
| vigneswari | jelmer, do u have any idea abt my issue? | 12:30 |
| vigneswari | in bzr-trac integration | 12:30 |
| jelmer | vigneswari, you mean trac-bzr ? | 12:31 |
| jelmer | (there are two different projects these days) | 12:31 |
| vigneswari | jelmer, yes | 12:32 |
| vigneswari | jelmer, am not able to see the content of branch as well repo | 12:33 |
| vigneswari | jelmer, anything created using bzr init command | 12:33 |
| jelmer | vigneswari: Did you edit the trac configuration file to include bzr? | 12:33 |
| vigneswari | tracbzr.* = enabled jelmer | 12:34 |
| vigneswari | jelmer, this line i ve added in trac.ini file | 12:34 |
| vigneswari | nothing else :) | 12:34 |
| jelmer | nothing about trac not being able to find the plugin, etc, in the logs? | 12:37 |
| vigneswari | jelmer, http://pastebin.com/m14c672cb | 12:44 |
| vigneswari | jelmer, i cant locate the logs | 12:44 |
| jelmer | vigneswari, please file a bug | 12:45 |
| vigneswari | jelmer, where? | 12:46 |
| jelmer | launchpad.net/trac-bzr | 12:46 |
| vigneswari | jelmer, ok | 12:48 |
| vigneswari | thnks | 12:49 |
| xtrqt | I have branch without main repo ~/a, and in it I have ~/a/b which is standalone branch of project-part, I want to have only ~/a branch and not to lose revs in b. | 13:16 |
| xtrqt | how could I import b as subdirectory of a, without deleting /a/b/.bzr | 13:16 |
| luks | you can try https://launchpad.net/bzr-merge-into | 13:19 |
| xtrqt | thanks | 13:21 |
| Stev | Hi | 13:50 |
| Stev | I'm pushing my revisions to a ftp server (from a free hosting service), is there some web interface to browse through the sources/revisions? The ones i've found are not suitable for me as I cannot run anything execpt cgi/php/perl scripts on the host. | 13:54 |
| Kinnison | Register it on launchpad and use that to view the source? | 13:57 |
| Kinnison | E.g. http://bazaar.launchpad.net/~dsilvers/flail/devel/files | 13:57 |
| Stev | Uhm nice :) | 13:58 |
| Stev | OK, another question then... is there a way to push more to than one locations at once? | 14:00 |
| luks | I dont think so | 14:00 |
| Stev | I mean.. "bzr push" and it pushes "ftp://server1.foo.com" and "sftp://aaa@bbb.com" | 14:00 |
| Stev | ok, thanks, i think i'll just create a small script/alias to avoid typing the 2nd whole url :) Thanks guys | 14:01 |
| luks | well, you can use bzr-bookmarks to not having to type the whole url | 14:03 |
| Stev | Had a look at bzr-bookmarks, thanks | 14:07 |
| nevans | hmm... bzr-bookmarks... that looks useful. | 14:09 |
| === mw|out is now known as mw | ||
| rocky | jelmer: which version (if any) of bzr-svn should we use with bzr-1.7 ? | 14:43 |
| jelmer | rocky, the 0.4 branch at the moment | 14:44 |
| rocky | kk | 14:44 |
| Tak | jelmer: I think I'm supposed to ping you about monodevelop-bzr? | 14:49 |
| jelmer | Tak, Hi | 14:49 |
| jelmer | Tak, What about specifically? | 14:49 |
| Tak | hi - I've been working on it in a branch | 14:49 |
| Tak | speaking with palango, he said I should request to be added to the monodevelop-bzr team | 14:50 |
| Tak | (which I have, on launchpad) | 14:51 |
| jelmer | ah, ok | 14:52 |
| jelmer | one sec, let me check if I've received any email yet | 14:52 |
| strk | bzr: ERROR: no such option: --no-tree | 14:58 |
| strk | bzr branch --no-tree <src> <tgt> | 14:59 |
| LarstiQ | strk: supplied to what command? | 14:59 |
| strk | Bazaar (bzr) 1.6.1 | 14:59 |
| jelmer | Tak, I've approved you | 15:00 |
| Tak | cool | 15:00 |
| LarstiQ | strk: branch doesn't take a --no-tree argument | 15:00 |
| LarstiQ | strk: did you mean init-repo --no-trees? | 15:01 |
| strk | I never know what I'm doing when it comes to bzr really | 15:02 |
| LarstiQ | strk: hmm :) | 15:02 |
| LarstiQ | strk: what are you trying to do in this specific case? | 15:02 |
| strk | setup my working envorinment :) | 15:02 |
| strk | so far I've been using two branches | 15:03 |
| strk | one bound to the main shared one online | 15:03 |
| strk | and one unbound | 15:03 |
| strk | both with no trees | 15:03 |
| strk | then a separate tree-only dir, from which i used to 'bzr switch' | 15:03 |
| strk | between the bound and unbound ones | 15:03 |
| strk | this was as for lifeless suggestion | 15:03 |
| strk | not sure it's a good setup though | 15:03 |
| strk | it surely isn't straightforward | 15:03 |
| strk | so may change habits and only branch when really needed | 15:04 |
| strk | as long as I can still do offline setups w/out big hassle | 15:04 |
| Odd_Bloke | strk: Please file a bug about the lack of a --no-tree option to branch. | 15:05 |
| strk | Odd_Bloke: url ? | 15:06 |
| Odd_Bloke | strk: launchpad.net/bzr "Report A Bug", I think. | 15:06 |
| LarstiQ | strk: I guess that is how I would work if I wanted to use switch. | 15:08 |
| LarstiQ | strk: although I'd a shared repository inited with --no-trees | 15:08 |
| * LarstiQ fails in English | 15:08 | |
| LarstiQ | use | 15:08 |
| Tak | branch pushed | 15:13 |
| Odd_Bloke | strk: Give me a link to the bug report and I'll claim it. :) | 15:15 |
| strk | LarstiQ: there should be a 'drop-tree' or similar to use after the fact IIRC | 15:16 |
| LarstiQ | strk: `bzr remove-tree` | 15:17 |
| strk | Odd_Bloke: https://bugs.launchpad.net/bzr/+bug/273993 | 15:19 |
| ubottu | Ubuntu bug 273993 in bzr "bzr 1.6.1 lacks --no-tree option for 'branch'" [Undecided,New] | 15:19 |
| Odd_Bloke | strk: Thanks. :) | 15:21 |
| strk | LarstiQ: so, now I created the two branches, and dropped tree | 15:21 |
| strk | but I forgot how I was supposed to crete the actual working tree for use with switch | 15:21 |
| strk | checkou --lightweight ? | 15:21 |
| Odd_Bloke | strk: Yup. | 15:22 |
| strk | good. all setup now :) | 15:22 |
| enobrev | anybody ever see a "Unrecognised container format" error after trying to "update" a recently pushed set of changes? | 16:36 |
| enobrev | actual error message is bzr: ERROR: Unrecognised container format: 'B419' | 16:37 |
| LarstiQ | enobrev: I haven't, can you pastebin the entirety? | 16:38 |
| enobrev | that's it... that's the whole error... what would you like me to pastebin? | 16:38 |
| enobrev | LarstiQ, or at least, that's all I get from bzr when i try to bzr update | 16:39 |
| james_w | enobrev: please run again with -Derror as an option | 16:39 |
| LarstiQ | enobrev: the command you tried plus it's output. If there is no traceback, supply -Derror as well. | 16:39 |
| enobrev | cool... thanks... one mo. | 16:39 |
| enobrev | LarstiQ, james_w: hey, that's fancy, here it is: http://pastebin.com/d5f6b5372 | 16:43 |
| james_w | wow | 16:44 |
| enobrev | that sounds ominous | 16:44 |
| james_w | it seems to be trying to read the pack header and getting something totally unexpected back | 16:45 |
| enobrev | hmm... well, is there a way to revert a push? | 16:45 |
| james_w | it should say "Bazaar pack format 1 (introduced in 0.18)" and it says "B419" apparently | 16:46 |
| enobrev | any way i can help debug? | 16:46 |
| james_w | I'm just looking at where we should look | 16:47 |
| enobrev | i'm completely blank on this one... as for getting my job done, i just need to know how to revert the push - but if this is a bug i can help find / report, i'll be glad to help dig if you point me in the right direction | 16:48 |
| LarstiQ | what's it bound to? | 16:49 |
| enobrev | not sure what you mean | 16:49 |
| LarstiQ | enobrev: what does `bzr info` say? | 16:49 |
| enobrev | LarstiQ: ah, thx: "Standalone tree (format: pack-0.92) Location: branch root: ." | 16:50 |
| james_w | enobrev: do you have .bzr/repository/packs/ ? | 16:51 |
| enobrev | james_w: yep | 16:52 |
| enobrev | 7 .pack files within | 16:52 |
| james_w | enobrev: can you run "head -n 2 .bzr/repository/packs/*.pack ? | 16:52 |
| LarstiQ | enobrev: where did you push from, and whereto? | 16:53 |
| enobrev | another dev pushed from bzr 1.6.1 on a mac | 16:53 |
| LarstiQ | update isn't in your typical workflow on a standalone branhc | 16:53 |
| enobrev | onto this 1.5 repo on my server | 16:53 |
| LarstiQ | enobrev: to what, this branch? | 16:53 |
| enobrev | yes | 16:53 |
| LarstiQ | ok | 16:54 |
| enobrev | james_w, head doesn't seem to like the wildcard | 16:54 |
| james_w | enobrev: it works here, may be a new feature or extension | 16:54 |
| james_w | for i in .bzr/repository/packs/*.pack; do echo $i; head -n 2 $i; done | 16:55 |
| james_w | that should do it | 16:55 |
| enobrev | oh man.. silly mistake.. sorry - i was in .bzr | 16:55 |
| enobrev | I got it one sec... | 16:55 |
| enobrev | one of the packs came back as B419. did you wan the full output? | 16:56 |
| james_w | that's the badger then | 16:56 |
| james_w | I wonder why it's got the first line missing | 16:57 |
| james_w | you can fix it by adding "Bazaar pack format 1 (introduced in 0.18)" as the first line to that file | 16:57 |
| enobrev | oh i see, so the first line is supposed to be "Bazaar pack format..." | 16:57 |
| enobrev | oddly enough there's another pack file that's missing it as well | 16:57 |
| enobrev | should i just open it up in vim and add it to the top? | 16:58 |
| enobrev | here's the output, btw http://pastebin.com/d155efcd1 | 16:59 |
| james_w | yeah, you'll need to fix them both | 17:00 |
| enobrev | i see... ok, i'll give it a shot, thanks guys.. back in a couple min. | 17:01 |
| LarstiQ | well | 17:02 |
| enobrev | LarstiQ: ? | 17:02 |
| LarstiQ | if that is missing, the question arises as to what more could be wrong | 17:02 |
| enobrev | any suggestions? | 17:02 |
| LarstiQ | enobrev: make a backup before you do anything else | 17:02 |
| LarstiQ | enobrev: cp -a repo backup | 17:02 |
| enobrev | already done. | 17:02 |
| LarstiQ | should be enough | 17:02 |
| LarstiQ | enobrev: cool :) | 17:03 |
| LarstiQ | enobrev: well then, go ahead and try it | 17:03 |
| LarstiQ | enobrev: might want a `bzr check` later as well | 17:03 |
| enobrev | ah.. ok | 17:03 |
| enobrev | bzr check gave the same error | 17:06 |
| enobrev | wow, talk about files that look like you don't want to edit them manually. trying another bzr check... | 17:08 |
| enobrev | It's GOOD!!! | 17:10 |
| enobrev | thank you gentlemen. | 17:10 |
| enobrev | bzr update worked just fine after fixing the headers on the pack files. going to have to tell the other dev what happened to see if he can figure out anything from his end... appreciate the help. | 17:11 |
| === dereine is now known as dereine[afk] | ||
| quicksilver | any news on the bzr web integration thingy? | 17:38 |
| quicksilver | was it called loggerhead? | 17:38 |
| * quicksilver googles | 17:38 | |
| jelmer | quicksilver, yup | 17:39 |
| jelmer | lp/loggerhead | 17:39 |
| jelmer | it's awesome | 17:39 |
| quicksilver | that's interesting, because an awesome thing was just the kind of thing I wanted | 17:40 |
| quicksilver | where's it's home page these days? | 17:40 |
| quicksilver | google for 'loggerhead bzr' doesn't appear to work. | 17:40 |
| jelmer | :-) I think the launchpad page is the main page for it these days | 17:40 |
| quicksilver | did it become launchpad, then, basically? | 17:41 |
| jelmer | quicksilver, it's homepage is on launchpad I think, or are you searching for an example instance to see how it looks like? | 17:42 |
| jelmer | for the latter, see e.g. http://bzr-playground.gnome.org/ | 17:43 |
| abeaumont | hi, how can a svn repo be updated from a bzr repo created with svn-import? | 17:43 |
| jelmer | hi abeaumont | 17:43 |
| quicksilver | jelmer: I'm looking to download it to install locaally | 17:44 |
| quicksilver | ah | 17:44 |
| quicksilver | https://launchpad.net/loggerhead | 17:44 |
| jelmer | abeaumont, pushing back into svn you mean? | 17:45 |
| jelmer | abeaumont: bzr push <svn-url>/branch-path | 17:45 |
| abeaumont | jelmer: yes, that's what i mean | 17:46 |
| jelmer | abeaumont, you can only push one branch at a time though | 17:46 |
| abeaumont | jelmer: hmmm, so, there's no need for svn specific command needed, as with svn-import? | 17:47 |
| jelmer | abeaumont: You don't need a svn-specific command to import from svn per se, you can use "bzr branch" as well | 17:47 |
| jelmer | abeaumont, there are no bzr commands for copying all of the branches underneath a repository | 17:48 |
| jelmer | abeaumont, that's why svn-import exists | 17:48 |
| abeaumont | jelmer: ahhh, ok, i didn't understand svn-import purpose then | 17:48 |
| abeaumont | jelmer: ok, thanks! | 17:48 |
| rockstar | How do I set my smtp server port in bazaar.conf ? | 18:05 |
| rockstar | abentley, ^^ Maybe you know? I don't see any docs about it. | 18:08 |
| fdv | bzr: ERROR: Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch | 18:13 |
| fdv | can anybody tell me why that is necessary? | 18:14 |
| jelmer | fdv, why the change of main history is needed? | 18:14 |
| fdv | I mean, as long as I get an error when trying to commit when there's a mid-air-collision, how will the two branches diverge? | 18:15 |
| fdv | a little more context, perhaps. I do a bzr bind, then an update | 18:16 |
| fdv | that's when I get this error | 18:16 |
| fdv | oh, maybe it's because I have set the setting globally | 18:17 |
| * fdv tests | 18:17 | |
| fdv | that's better, yes | 18:21 |
| fdv | sorry about the fuss | 18:21 |
| abeaumont | jelmer: it worked like a charm, many thanks! | 18:40 |
| === dereine[afk] is now known as dereine | ||
| === dereine is now known as dereine[afk] | ||
| === dereine[afk] is now known as dereine | ||
| eyepulp_ | yo ho ho | 18:58 |
| eyepulp_ | tryng to get 1.7 setup properly on osx without having to run the setup.py install. is this doable? | 18:58 |
| LarstiQ | eyepulp_: I myself run from the source tree without installing | 19:00 |
| eyepulp_ | hrm - from the python command line I can do "from bzrlib import workingtree" but when running under textmate and trying to commit it says it can't find the module bzrlib | 19:01 |
| eyepulp_ | the add and init work fine | 19:02 |
| eyepulp_ | looking at the textmate commit code now | 19:03 |
| LarstiQ | eyepulp_: bzrlib users need to be able to find it. One option is to install it so it gets into python<version>/site-packages/ | 19:06 |
| LarstiQ | eyepulp_: another is to broaden the python path, for instance, export PYTHONPATH=~/src/bzr/bzr.dev/ | 19:07 |
| eyepulp_ | yeah, I have a .pth file that points to the dir above bzrlib | 19:07 |
| LarstiQ | ok | 19:07 |
| LarstiQ | eyepulp_: but textmate isn't looking at it? | 19:07 |
| eyepulp_ | as mentioned, I can drop into the py interpreter and import bzrlib | 19:08 |
| eyepulp_ | but yeah, TM can't find it. | 19:08 |
| strk | I'm trying to install the bzr-gtk plugin, but isn't working | 19:08 |
| eyepulp_ | I've restarted TM on the odd chance it cached the .pth settings | 19:08 |
| jam | beuno: ping | 19:08 |
| strk | I got bzr-1.6.1 release | 19:08 |
| strk | and fetched bzr-gtk from repository | 19:08 |
| strk | do I need a bzr-gtk *release* instead ? | 19:09 |
| strk | bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute 'link_button_set_uri_hook' | 19:09 |
| jam | siretart: ping | 19:09 |
| strk | ^^ this is the error with that setup | 19:09 |
| jelmer | strk, afaik that's caused by a too old version of pygtk | 19:09 |
| strk | uhm | 19:09 |
| jam | hmm... perhaps I can ask Jelmer... do you know the process for packaging bzrtools? | 19:10 |
| jam | siretart and beuno have done the last few, so I'm not explicitly set up for it | 19:10 |
| jam | but I'd like to, and I'd like to get 1.7 into the ppa | 19:10 |
| jelmer | jam: Same story as everything else :-) | 19:10 |
| strk | I'm on debian... could add ppa with instructions | 19:10 |
| jelmer | strk: On debian, you should be able to just install the debian package | 19:10 |
| strk | ii python-gtk2 2.8.6-8 | 19:10 |
| jam | jelmer: well, not the same as bzr-svn or bzr, since I packaged both of those :) | 19:11 |
| jelmer | jam: ah, it's probably not based on the Debian package then | 19:11 |
| jam | there seems to be a lp:~jelmer/bzrtools/experimental | 19:11 |
| strk | Need to get 213MB of archives. | 19:11 |
| strk | :! | 19:11 |
| strk | 156 upgraded, 102 newly installed, 30 to remove and 541 not upgraded. | 19:11 |
| jam | Is it just grab that, put in a new dch entry | 19:11 |
| jam | and package it up? | 19:11 |
| strk | not now plz :) | 19:11 |
| jelmer | jam, Yeah, I think so | 19:11 |
| jam | Ah, now I see the other packaging branches, thanks for bearing with me | 19:12 |
| abentley | rockstar: You put a colon after the server name, followed by the port number. | 19:13 |
| rockstar | abentley, that wasn't working. I ended up just setting up a local postfix instance to relay mail. | 19:13 |
| abentley | rockstar: Works for me. What config line did you have. | 19:14 |
| rockstar | smtp_server = <mail_host>:587 | 19:14 |
| abentley | rockstar: That looks right. Where did you put it? | 19:15 |
| rockstar | Tried two different servers. | 19:15 |
| rockstar | abentley, bazaar.conf [DEFAULT] | 19:15 |
| abentley | I mean, did you put it in bazaar.conf, locations.conf or branch.conf? | 19:15 |
| abentley | Okay, perhaps it was being overridden by a setting in locations.conf. | 19:16 |
| rockstar | Yea, wasn't defined anywhere else. | 19:16 |
| abentley | rockstar: Was any additional configuration needed, e.g. username or password? | 19:17 |
| rockstar | No, but the relay server I set up in postfix requires it. | 19:18 |
| eyepulp_ | LarstiQ: it looks like textmate is using a different install of python than I am. irksome | 19:19 |
| abentley | What operation were you doing? | 19:19 |
| eyepulp_ | me? | 19:20 |
| eyepulp_ | not me - sorry | 19:20 |
| abentley | eyepulp_: no, I meant rockstar. | 19:20 |
| LarstiQ | eyepulp_: if you try setting PYTHONPATH in the shell instead of using a .pth, it should pick up on that though? | 19:20 |
| rockstar | abentley, trying to submit to PQM. Comcast decided to start blacking port 25 today. | 19:21 |
| rockstar | I also can't seem to type blocking today... | 19:23 |
| abentley | rockstar: Maybe you can and your computer's just trying to make you crazy... | 19:24 |
| rockstar | abentley, if you had been working on cscvs as long as I have, you would start hallucinating too... :) | 19:25 |
| jam | jelmer: so which is more correct to use... ~debian-bazaar/bzrtools/debian, or ~jelmer/bzrtools/experimental, or is it something over in the bzr.debian.org domain? | 19:27 |
| jelmer | jam: http://bzr.debian.org/pkg-bazaar/bzrtools/experimental is the most correct at this point | 19:27 |
| jam | jelmer: of course, "experimental" is rich-root while "unstable" is still knit format... | 19:28 |
| jelmer | jam: I've recently merged the debian/ directory and the upstream branch | 19:29 |
| jam | sure, I noticed | 19:29 |
| jelmer | jam, since that involved using join, I had to upgrade | 19:29 |
| jam | well, you didn't *have* to. I've done it about 4 times in the bzr code base | 19:29 |
| jam | with various plugisn | 19:30 |
| jam | but probably the simple "bzr join" command wouldn't work without it | 19:30 |
| === mw is now known as mw|food | ||
| jam | bzr merge-into would, though | 19:30 |
| LarstiQ | are you sure? | 19:30 |
| jam | LarstiQ: asking me? I just did it (as well as updating bzr-merge-into to work again :) | 19:31 |
| LarstiQ | hmm, maybe I did explicitly ask for --development-subtree | 19:31 |
| LarstiQ | jam: sort of, I was pondering if join didn't work by default | 19:31 |
| LarstiQ | jam: maybe I've been living too close to nested-trees lately | 19:31 |
| jam | ugh, we've got 3 different ways that bzrtools is being packaged... :( | 19:32 |
| jam | with different branch ancestries | 19:32 |
| jam | jelmer: I'm not positive, but I think your 1.7 package for bzrtools is incorrect. | 19:58 |
| jam | Is see: | 19:58 |
| jam | http://edge.launchpad.net/bzrtools/stable/1.6.0/+download/bzrtools-1.6.0.tar.gz | 19:58 |
| jam | sorry | 19:58 |
| jam | Depends: ${python:Depends}, bzr (>= 1.6~), bzr (<< 1.7~), patch | 19:58 |
| jam | which means the bzrtools 1.7 package is depending on bzr 1.6 rather than bzr 1.7 | 19:59 |
| jelmer | jam, Sorry, I had that fixed, just not pushed yet | 19:59 |
| jelmer | jam: Should be pushed now | 19:59 |
| jam | any particular reason you don't use a checkout? You seem to often forget to push | 20:01 |
| siretart | jam: pong? | 20:03 |
| jelmer | I sometimes do but always unbind when I work offline | 20:04 |
| jelmer | (I hate bzr up's behaviour turning local commits into pending merges) | 20:04 |
| jam | siretart: jelmer answered my question, thanks for getting back to me | 20:06 |
| siretart | k | 20:07 |
| jam | jelmer: do I need to do a new bzr-svn package for bzr 1.7? Or is it still compatible with the 0.4.12 release? | 20:11 |
| jelmer | jam, You need a new one - I silently released 0.4.13 today | 20:12 |
| jam | again with "experimental" ? | 20:13 |
| jam | and you did upload it, right? | 20:13 |
| jelmer | yep | 20:14 |
| jam | jelmer: so do I need to be releasing them as 0.4.13-2~bazaar1, or 0.4.13-1~bazaar1 ? | 20:14 |
| jam | since you had to do a -2 | 20:15 |
| jelmer | the first | 20:15 |
| jelmer | so people who are using ubuntu will get your package rather than the broken 0.4.13-1 | 20:16 |
| jelmer | (just theory, in practice this can't really happen because the time window between -1 and -2 is so short) | 20:17 |
| jam | I suppose, though your -2 branch supersedes the -2~bazaar1 one anyway | 20:18 |
| jam | s/branch/package/ | 20:18 |
| nDuff | Does bzr-rebase contain functionality equivalent to "git rebase -i"? | 20:23 |
| jam | jelmer: you may have uploaded, but I don't have a bzr-svn-0.4.13 tag | 20:24 |
| Odd_Bloke | nDuff: Describe what the git command does. :) | 20:24 |
| jam | Odd_Bloke: it doesn't have --interactive, I believe | 20:24 |
| jam | Robert has talked about it, as have others | 20:24 |
| nDuff | Odd_Bloke, provides a text file describing the order in which the given revisions are applied, and allows that file to be edited to reorder or coalesce revisions. | 20:24 |
| jam | or maybe you do and I just forgot --export-upstream | 20:25 |
| jam | let me check | 20:25 |
| Odd_Bloke | nDuff: Then, no, I don't think so. | 20:25 |
| jam | last I recall, lifeless thought it would be about 1 day worth of work to implement it | 20:31 |
| jam | jelmer: what about bzr-gtk? Since that is in the same repo | 20:32 |
| jelmer | jam, try "debian-0.4.13-2" | 20:35 |
| jelmer | jam, I've started using "bzr mark-uploaded" (from bzr builddeb) | 20:35 |
| jam | jelmer: I just needed to use --export-upstream=. | 20:36 |
| jelmer | yeah, by default the location is set to launchpad | 20:36 |
| === mw|food is now known as mw | ||
| Odd_Bloke | jam: Is that 1 lifeless day or 1 normal-person day? :p | 20:38 |
| jam | Odd_Bloke: well, parsing a text file isn't particularly difficult | 20:41 |
| jam | it is more the what do you do when you conflict, and how do you resume | 20:42 |
| Odd_Bloke | So one normal-person day? | 20:42 |
| jam | anyway, mostly afk because the sick baby just woke up | 20:43 |
| Crusher4 | I'm having problems with Mac OS X 10.5.5 + bzr 1.5 and/or 1.6.1 + sftp repository | 20:54 |
| Crusher4 | it says 'garbage packet recieved' | 20:56 |
| Crusher4 | but i can ssh to it just fine | 20:56 |
| Crusher4 | just tried it with 1.7, same problem | 21:03 |
| rockstar | jelmer, around? | 21:53 |
| jelmer | rockstar, sortof | 21:53 |
| rockstar | jelmer, what does "sort of" mean? | 21:53 |
| rockstar | Could you help me with a libsvn issue? | 21:54 |
| jelmer | rockstar, sure | 21:54 |
| rockstar | I'm stuck, and I'm searching for help... | 21:54 |
| rockstar | jelmer, https://code.edge.launchpad.net/~rockstar/launchpad-cscvs/remove-pysvn | 21:55 |
| rockstar | I'm trying to check out from libsvn using the SWIG python bindings. | 21:55 |
| rockstar | However, I think I have the params right, but it fires off the exception SubversionException: (None, 195002) which appears to be a revision error. | 21:57 |
| jelmer | yeah, that's SVN_ERR_CLIENT_BAD_REVISION | 21:58 |
| rockstar | jelmer, do you have that memorized?! | 21:58 |
| jelmer | well, there's a couple of these that you hit very often | 21:59 |
| jelmer | rockstar, what are the exact arguments you are passing in? | 22:03 |
| rockstar | client.svn_client_checkout(svn_url, path, core.svn_opt_revision_t(), True, client.svn_client_ctx_t(), self._pool) | 22:09 |
| rockstar | jelmer, ^^ | 22:09 |
| jelmer | rockstar, you have to initialize core.svn_opt_revision_t | 22:11 |
| rockstar | jelmer, yea, so the actual call is client.svn_client_checkout(svn_url, path, revision, True, ctx, self._pool) | 22:12 |
| rockstar | I just wanted demonstrate the types. | 22:12 |
| jelmer | (pool is optional, you shouldn't use it for new code) | 22:13 |
| rockstar | jelmer, I thought that was correct. IT should be managing its pools on its own, right? | 22:14 |
| jelmer | yeah | 22:15 |
| rockstar | But if I remove it, I still get the error. :( | 22:16 |
| jelmer | how do you initialize opt_revision_t ? | 22:17 |
| rockstar | revision = core.svn_opt_revision_t() | 22:17 |
| jelmer | you don't initialize any of the members of svn_opt_revision_t ? | 22:19 |
| rockstar | jelmer, I found no docs that said I needed to. :( | 22:20 |
| jelmer | You found docs !? (-: | 22:21 |
| rockstar | Yea, it's called reading other people's code... :) | 22:21 |
| jelmer | I always initialize the "kind" member | 22:22 |
| jelmer | not sure if that's really necessary | 22:22 |
| rockstar | jelmer, I don't think I'm familiar with that. | 22:25 |
| jelmer | revision.kind = svn_opt_revision_head | 22:27 |
| rockstar | jelmer, holy crap, I think that got it! | 22:29 |
| === fta_ is now known as fta | ||
| rockstar | jelmer, still around? | 23:04 |
| jelmer | rockstar, yeah | 23:04 |
| rockstar | So if I set revision.kind to svn_opt_revision_number, how do I set the actual number? | 23:05 |
| jelmer | rev.value.number IIRC | 23:07 |
| rockstar | Ah, great, thanks. | 23:08 |
| === thumper_laptop is now known as thumper | ||
| === sdboyer is now known as fapi | ||
| === fapi is now known as sdboyer | ||
| === sdboyer is now known as RuPaul | ||
| === RuPaul is now known as sdboyer | ||
| jml | lifeless: hello | 23:50 |
| igc | morning | 23:58 |
| poolie | hello igc, jml | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!