[00:02] hello [00:16] poolie: I need more details on vila's stuff to find it [00:21] "how various commands display revisions" [00:21] and there's one about python2.6, which does have a patch that i'm about to read [00:23] you don't need to spend a lot of time on it, i think he'd just like to know people read them [00:31] I read the former [00:31] I'll pass on the latter for now [00:31] spiv: btw aren't context manages 2.5? [00:34] lifeless: yeah, they are. [00:34] lifeless: but we're still supporting 2.4, so that doesn't help us much. [00:36] spiv: yah, not to mention, like I said, I don't think they help anyhow [00:36] spiv: because, aren't they effectively just syntactic sugar for try:finally:except:? [00:36] Roughly, yes. [00:36] mwhudson, do you have a bit of time today to review Verterok's branch for traceback logging? [00:36] so the squashing will still happen [00:37] But that is helpful, in this case. [00:37] spiv: how so? [00:37] 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:38] Verterok: yeah, should think so === dereine is now known as dereine[afk] [00:39] So the obvious spelling of "with write_locked(foo): ..." can then DTRT, where "foo.lock(); try: ... finally: foo.unlock()" doesn't. [00:39] __exit__( exc_type, exc_val, exc_tb) [00:39] is the key spelling [00:40] spiv: but you can spell write_locked as try:finally:except e:try:self.unlock() except:pass; raise e [00:40] It is possible to preserve the original exception (and traceback) with try/except; our needs_write_lock decorator does that now. [00:40] mwhudson, thanks. It's a big patch, and mostly touches code you've worked on [00:41] 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:42] apply_locked ? [00:42] erm [00:42] apply_write_locked, suggesting a name [00:43] 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:44] (not a great name, obviously) [00:44] the sys.tb* are not threadsafe though [00:44] sys.exc_info() is. [00:44] oh cool [00:45] 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). === RAOF_ is now known as RAOF [00:46] Possibly those are just corner cases about invoking things from except: blocks. But I'd prefer a solution that obviously correct :) [00:48] abentley: ping [00:49] lifeless: pong [00:49] abentley: the intertree previewtree test, I'm not quite sure what its testing [00:49] abentley: I just had a conflict on that change, so I thought I'd expand on the comment. [00:49] abentley: is there a different InterTree that it tests? Or are you just adding-some-coverage-to-PreviewTree ? [00:50] I'm just adding-some-coverage-to-PreviewTree [00:50] ok. [00:51] # PreviewTree doesn't get the stock interface tests for working tree, [00:51] # having it exercised by the standard intertree tests provides useful test [00:51] # coverage. [00:51] thats my expanded comment, seem ok ? [00:51] beuno, mwhudson: thanks! [00:51] [I've also made it clear that the InterTree tests are running with PreviewTree, so failures are clearer [00:52] ] [00:52] Verterok thanks for working on it :) [00:52] lifeless: I don't understand why you're referring to working tree. [00:52] s/working tree/trees/ [00:53] lifeless: Okay, so now I don't understand the comment, because PreviewTree is exercised by the tree_implementation tests [00:54] abentley: I'm trying to write down _why_ we get more coverage by having PreviewTree present in the InterTree tests. [00:54] obviously we *do*, and thats fine. [00:54] I would say "PreviewTree does get the stock interface tests for tree..." [00:54] 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:56] So the point is that PreviewTree doesn't have an InterTree, perhaps? [00:56] # The stock interface tests for 'tree' are insufficient to thoroughly cover [00:56] # PreviewTree. Exercising it by the InterTree tests provides useful [00:56] # additional coverage. [00:57] abentley: from a theory perspective, any failures you uncovered are failures in the tree interface tests [00:57] [in that they fail to cover something that anything claiming to be a Tree should provide] [00:58] poolie: you sunk my battleship [00:58] lifeless: So do you think that iter_changes et al should be tested in tree_implementations? [00:59] poolie: (conflict in NEWS after the lock patch landed) [01:00] 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] abentley: I'll be a minute, just fixing this conflict for pqm [01:01] lifeless: For PreviewTree, it's not, but that's not relevant. [01:02] lifeless: someone should write a script to avoid NEWS conflicts :-P [01:02] I need to make sure that PreviewTree.iter_changes works. How should we be testing that? [01:02] abentley: ok, now I see whats going on [01:04] abentley: InterTree is the right place to test iter_changes; I think PreviewTree should not have an iter_changes method though [01:04] abentley: because wt.iter_changes(preview_tree) should be the reverse of preview_tree.iter_changes(wt) [01:05] anyhow, the comment I propose now is: [01:05] # PreviewTree does not have an InterTree optimiser class. [01:05] lifeless: In these tests, it's using InterTree.iter_changes. [01:05] It still needs to be tested. [01:06] If we just use the existing tests, it won't be. [01:06] I'm getting more confused by the minute [01:06] There needs to be a scenario for every tree type. [01:06] InterTree does not have a scenario for every tree type and shouldn't have one [01:07] Correct. [01:07] it should have a scenario for every code path from InterTree [01:07] But we do need to test every tree type in "tree_implementations". [01:07] lifeless: +1 to taking files from a special directory and merging them into NEWS [01:07] Sorry [01:08] in "intertree_implementations". [01:08] i don't see why special handling would be needed for deletions [01:08] how do i make a repository a no-trees repository again? [01:08] poolie: in a single-file approach [01:08] mwhudson: touch no-working-trees in .bzr/repository [01:08] lifeless: thanks [01:08] lifeless: i mean if someone changes the news entry after it's merged into NEWS [01:08] that is a real conflict [01:08] we'd want them to instead update the bit merged in to NEWS [01:09] Otherwise, we don't know that those operations work. [01:09] 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:10] abentley: InterTree tests are tests of object B on the interface 'Tree' [01:11] 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] 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:12] abentley: the optimiser for WT4 only kicks in (and this is tested) when the other tree is a DirStateRevisionTree [01:12] lifeless: So it is not a test on the interface 'Tree'. [01:13] abentley: what 'it' there? [01:14] A test of iter_changes involving a wt4 and a DirstateRevisionTree. [01:14] right, its a test of InterTree (specifically InterDirstateTree) [01:14] But you said "InterTree tests are tests of object B on the interface 'Tree'" [01:15] object B is is the SUT, which is InterDirstateTree [01:15] the interface 'Tree' is a layer the test depends on [01:15] lifeless: expand SUT please? [01:15] system under test [01:15] the code being tested [01:16] as opposed to things the test needs but assumes are in good working order [01:16] lifeless: So you are saying that InterTree and not InterDirstateTree tests are tests on the interface "Tree"? [01:17] I'm saying they are both tests that build on the interface "Tree" but *do not test the interace "Tree"* [01:17] they make no assertions about the behaviour of e.g. get_file_sha1 [01:17] abentley: we almost certainly have missing test coverage of the Tree interface [01:19] lifeless: Well, less since I merged my previous two patches. [01:19] 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:21] 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:22] lifeless: Since PreviewTree's iter_changes was broken, this suggests that iter_changes should be tested in tree_implementations. [01:22] abentley: the transform.iter_changes was broken, or InterTree.iter_changes broke on PreviewTrees? [01:22] InterTree.iter_changes broke on PreviewTrees [01:23] abentley: that says that tree_implementations is missing tests, but not of iter_changes [01:23] abentley: rather of the parts of the Tree interface that are not fully tested. [01:24] 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] abentley: you found get_file_sha1 was missing, IIRC? [01:26] lifeless: Yes, and _comparison_data, _file_size. [01:26] abentley: to me that says there are missing tests for get_file_sha1, _comparison_data, _file_size on Tree [01:27] lifeless: We don't disagree about that. [01:27] ok [01:27] phew, I thought we were stuck. [01:27] But I also think that iter_trees should be tested on every class that claims to provide it. [01:28] Because testing that PreviewTree provides X and InterTree works with X doesn't work if iter_changes doesn't use InterTree. [01:28] abentley: I don't think anyone should override iter_changes, and so we shouldn't need to test it on each tree. [01:29] iter_changes needs two trees to test; doing interface tests for that needs two degrees of parameterisation; its tricky at best. [01:29] 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] I wasn't suggesting it we needed to do n^2 complexity. [01:29] (its broken by iter_changes branch) [01:29] s/by/my/ [01:30] But to not test at all seems questionable. [01:31] abentley: I'm not suggesting that we don't test! [01:31] lifeless: You are essentially saying we should test InterTree.iter_changes, not Tree.iter_changes. [01:32] abentley: I'm saying that there should be only one implementation of Tree.iter_changes - its meant to be just syntactic sugar [01:33] 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:34] 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:35] I guess so [01:36] lifeless: Anyhow, I just changed _test_mutable_trees_to_test_trees to take TestCase as a parameter. [01:37] That allows me to call addCleanup to clean up the PreviewTree's TreeTransform. [01:41] yup, thanks [01:42] I had a change there to add C and python versions of the dirstate iter_changes code [01:43] lifeless: So one of the breakages was that PreviewTree doesn't provide .inventory, and iter_changes attempted to use it. [01:43] now I need to figure out why readdir acceleration fails on PQM === mw is now known as mw|out [02:57] jam, still around/ [02:57] Hi, any thoughts about implementing __str__ in bzrlib.inventory.Inventory?...to avoid this http://rafb.net/p/yY76bI24.html [02:58] Verterok: well thats for debugging really :P [02:59] hehe [02:59] 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] lifeless: it's using __repr__ [02:59] poolie: I'm aronud a bit, but I'll probably be in and out [02:59] 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] jam: can you put that python 2.4 IFDEF in the pyrex bug I opened ? [02:59] jam: PQM itself needs that [03:02] 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:04] what say you? [03:04] 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:07] 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] not sure if that makes a 1.7.1 valid or not [03:07] just saying that it is outside of general policy we have crafted so far [03:08] mmm [03:12] 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:13] 1.7.1 will affect everyone by causing a new upgrade, more QA for distro folk etc [03:13] 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] 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:14] ATM the issues are "clarity of design" etc [03:14] which is more a "can we maintain this?" rather than "is it broken?" [03:14] lifeless: what's your recommendation? I made trivial fix, added __str__ to Inventory, and now only shows: http://paste.ubuntu.com/49910/ [03:15] lifeless: I don't see a "pyrex bug that you just opened" can you link it for me? [03:15] 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] Verterok: I think the bug is that it's showing the inventory and not a tree objct [03:15] Verterok: totally unrelated to __str__ or __repr__ [03:15] if we merge it to bzr.1.7 we should immediately merge that back to trunk [03:16] lifeless: ok, thanks for the tip :) I'll back after digging a bit more [03:16] jam: https://bugs.edge.launchpad.net/bzr/+bug/271939/comments/2 [03:16] Ubuntu bug 271939 in bzr "extensions fail to build on python 2.4" [Medium,Triaged] [03:17] 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] hey, I just work here [03:18] jam: re using 'pathjoin' rather than 'osutils.pathjoin' [03:18] lifeless: what about: https://bugs.edge.launchpad.net/bzr/+bug/271939/comments/3 [03:19] Ubuntu bug 271939 in bzr "extensions fail to build on python 2.4" [Medium,Triaged] [03:19] jam: you can't use default values in cdef functions [03:19] jam: thanks [03:19] so you can't do "cdef myfunction(foo, bar=XXX)" ? [03:19] right [03:20] so I can cache it in some of the places its used, and I've just done that [03:20] but I really don't want a double-lookup in _update_entry [03:20] jam, lifeless, any other concerns about doing this? [03:21] 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] 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:22] 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] Whoah. Did I miss the announcement of meta week on the list? [03:22] lifeless: ok, we'll add "or as needed" :-) specifically, this is a serious bug for numerous users [03:23] poolie: its not a regression [03:23] poolie: thats the real thing that annoys me about it [03:23] lifeless: strictly speaking neither was 1.6.1 [03:23] branch --stacked wasn't *in* 1.5 [03:23] jam: 1.6 was a brown paper bag [03:23] so we couldn't regress anything [03:23] jam: it had a format that could create data loss; that is a regression [03:24] is this defined in hacking or is it just general principle? [03:24] poolie: memory from our interminable discussions years ago [03:24] i don't remember us saying it was only regressions and not bugs [03:24] poolie: dunno if its enshrined or not [03:24] lifeless: i don't actually know any way that data loss could have actually happened in it. but if you say so [03:24] _anyhow_, they want it sooner than 1.8 and i want to help them [03:24] i think this is a reasonable use of a point release [03:25] poolie: we could always make it "1.7-mysql" :) [03:25] jam, 1.7-we-love-you-and-brought-you-flowers [03:25] I can't wait for 2.5.34, when we have more large users [03:25] me either, that will be great [03:25] well [03:25] to be a bit more serious, we have some other options [03:26] 1- just wait for 1.8 [03:26] 2- start releasing 1.8 now, from trunk [03:26] 3- do a 1.7-mysql that's not a regular release [03:26] 2s/$/, with this merged in first/ [03:27] let's decide what's right in this case and we can use that to tune the documented policy if necessary [03:27] My understanding, from the original agreement with them was that we would do (1) [03:27] we'd get them a fix, and then work to get it into the normal release [03:28] the original plan was it would be in _1.7_ since the patch was ready before then [03:28] after it looked likely it would slip i told them we would do a 1.7.1 [03:28] or at least that it would be soon after 1.7 [03:28] not a month later [03:28] so, 1 would both be disappointing for them and breaking our commitment [03:29] I don't think its breaking our commitment if it took more than one release to polish the workaround to inclusion [03:29] I can understand the disappointment [03:30] are there any issues other than the policy one? [03:31] 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:32] it's a good poitn [03:32] but for them it won't really be done until it's in a release [03:32] as they can't ask everyone to run from trunk [03:33] 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:36] 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] lifeless: well, if we are getting to that point, why didn't we review it a month earlier when it was posted ? [03:36] there are a lot of "woulda-coulda-shoulda"s we can get to [03:36] but how do we get where we want to be now? [03:37] lifeless: I think it is a bit easier to find the comparison code if it follows the same layout [03:37] is it more than a cut & paste for you to do so? [03:37] jam: adjust imports, possibly circular ones [03:37] other than that, no, just c&Pp [03:38] 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:39] jam: moving it over [03:39] I ended up with it in dirstate.py because _update_entry started there. [03:44] * spiv -> lunch [03:50] jam: circular imports up the wazoow [04:30] lifeless: when you have a few minutes to spare in the inventory.__repr__ bug, I have a question (or two) [04:31] Verterok: sure [04:31] Verterok: I think its a annotate bug :P [04:31] lifeless: indeed :) [04:32] lifeless: acctually Inventory contributes a bit [04:33] lifeless: Inventory.__getitem__ raises errors.NoSuchId, with the inventory instance instead of a tree [04:33] maybe annotate could catch that and raise the right error? [04:34] or there is an API to access the inventory that annotate isn't using? [04:34] * Verterok hides [04:35] Verterok: I need food rather badly; could you pastebin the backtrace perhaps? or file a bug about the bad UI result? [04:35] I'll look whwen I get back [04:36] lifeless: np, I'll keep playing a bit, and file a bug about it [05:03] Verterok: ah caffeine and food [05:03] lifeless: what we would do without them! [05:04] Starve in our sleep. [05:04] jaja [05:04] ITYM java :P [05:05] :p [05:28] lifeless: done, filed Bug #273835 [05:28] 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:29] Verterok: thanks [05:31] ups...I think it's a duplicate :p (Bug #246573) [05:31] Launchpad bug 246573 in bzr "'bzr annotate file.OTHER' during contents conflict gives traceback" [Medium,Confirmed] https://launchpad.net/bugs/246573 [06:13] * AfC wonders if the Bazaar hackers have landed the compression work they've been talking about over the last few months. [06:14] AfC, I think the b-tree stuff is in 1.7 as experimental [06:14] beuno: groupcompress is what afc means [06:14] AfC: no, its not landed yet [06:15] lifeless, oh, I thought that was part of the btree? [06:15] beuno: no [06:16] lifeless, so that would be another format? [06:16] groupcompress is a replacement for the 'knit' stuff [06:16] btree isn't in a format in bzr.dev yet [06:17] but both of them will trigger a format change, right? [06:18] either of [06:19] (yes, you need a new format to use either set of code) === Snaury is now known as Snaury[away] === tro|| is now known as tro [06:55] hi all, yeah for 1.7 ! [06:57] vila: I'm still not sure what stuff you wanted in my inventory docs [06:57] vila: AFAICT I wrote some prose; you were confused by it; I rephrased the exact same text and it made you happy. [06:58] 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:59] vila: it was approved with the edit, but I'm feeling lost as to how to do the edit without repeating myself lots [07:00] I can review it again if you want but I'm not sure about where to find the latests version [07:00] s/ts/t/ [07:01] I needed to read it again anyway [07:01] hi vila! [07:01] hey poolie :) [07:01] vila: on-list/bb [07:04] 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:05] Gyuh. [07:05] What a horrible thought. [07:06] Just thinking about it is far less painful though :D [07:06] vila: um [07:07] anyhow, i'm reading your 2.6 patch [07:07] Y'know, that sorta thing wouldn't happen if you used vi... [07:07] * fullermd hides. [07:10] 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] sometimes you just have to pay for your sins :D [07:10] vila: "NotFileSystem" [07:13] 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:33] spiv: let me know if you want to chat re Inter*Remote* [07:42] vila: how do you feel about me just landing the current prose? [07:43] 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] vila: oh thanks [07:49] lifeless: If there's no InterOtherToRemote/InterRemoteToOther, which InterRepo would you want used? Whichever of InterSameData/InterModel1and2/InterDifferingSerializer fits best? [07:53] spiv: 'yes' [07:53] spiv: as in, the RemoteRepo already exposes the needed data to choose one of those and use it [07:53] * spiv nods [07:54] spiv: my reasoning in a nutshell is - the generic API should be fine for performance [07:54] At the moment, the generic InterRepo's would force an _ensure_real just by the is_compatible checks. [07:55] lifeless: sent [07:55] 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] lifeless: wrt the inventory prose patch, please check 'make docs' works before submitting it [07:55] spiv: realy? those attributes are statically allocated by find_repositoryV2 I thought [07:55] it didn't for me [07:55] They check repository._serializer [07:56] Which is a property that does _ensure_real atm :( [07:56] igc, lifeless: I didn't check and my patch may contain even more errors :-/ [07:56] spiv: oh, thats reasonable. Its needed to ensure the inventory and revision style is understood [07:56] spiv: so fix that :P [07:56] That's something to fix in a find_repositoryV3... [07:56] spiv: yah, I'm not trying to add work you understand, rather reduce overall work [07:57] I do understand that :) [07:57] hi vila! [07:57] hi Ian ! [07:57] vila: so there is duplication straight up [07:58] lifeless: ? my patch try to add things you already added ? [07:59] 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 [08:00] vila: btw its easier to merge patches if they are attachments [08:01] 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:02] * vila should nevertheless think more about vi's users :) [08:02] vila: well, everything you quoted was already duplication [08:05] vila: I'll take a look at 'how various cmds display revisions' tonight fwiw [08:05] 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] igc: thanks [08:06] 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] lifeless: ok [08:06] lifeless: ha, excellent [08:06] spiv, poolie: well done on http://bazaar-vcs.org/SmartPushAnalysis1.8 - will be nice as we nail each of the issues found! [08:07] hm [08:08] it still needs more structure as a document but thanks [08:09] I started with revno: 3641 [08:09] revision-id: robertc@robertcollins.net-20080827004239-7d2b1m4bsd2u8ufm [08:09] but anyway, BB:approve, land, land ! :) [08:09] vila: This is the patch I have uncommitted. ... [08:10] http://paste.ubuntu.com/49971/ [08:10] 10 past 5 makes an unhappy boy [08:10] vila: (bzr log -m "\bVincent\b") will use a bzr search index, if you have one [08:21] igc: looks like a rest bug to me :( [08:29] igc: its valid reset list AFAICT, but it fails-to-format === Spaz is now known as Kittens === Kittens is now known as Spaz === dereine[afk] is now known as dereine [09:16] 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] no [09:17] is there a way to achieve that? [09:19] you could use a commit hook, I think [09:19] why would the file permissions thing not work? [09:19] a_c_m: because bzr does not version anything other than the 'x' bit [09:20] a_c_m: you could use a seperate baranch for /sql [09:20] a_c_m: all the data in the branch is stored in .bzr in the root of the branch [09:20] a_c_m: or you could just enforce policy on merge; bzr is aimed at distributed setups [09:22] lifeless: humm ok, the commit hooks method is interesting, but i'm no python programer [09:23] a_c_m: so, you could get someone to write it for you, its no harder than shell (actually easier than shell :P) [09:26] a_c_m: because we support many databases, polcy can't be enforced by normal access control [09:26] a_c_m: instead you have to do it 'when the content arrives' [09:31] lifeless: makes sense really :) [11:18] hello all [11:18] plz help in resolving my problem reg.bzr-trac [11:19] if i create any brach or repo using bzr init or init-repo..i couldnt view in trac browser [11:24] am i asking in correct channel? [11:48] plz help in resolving my problem reg.bzr-trac [11:48] if i create any brach or repo using bzr init or init-repo..i couldnt view in trac browser [11:52] should i provide some more details? [11:58] maybe try the list [12:08] hi guys! [12:09] have successfully switched my project over to bzr from svn but have some issues with versioning while merging [12:09] 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:10] aah got it.... there is a plugin [12:10] my problem is, mostly, that after merging and pushing - version numbers on the target repository get overwritten [12:10] yes [12:12] is that intentional? [12:13] is thats how bzr is supposed to work? or am i doing something wrong [12:13] you can set the append_mumble option [12:13] bob2, append_mumble? [12:14] append_revisions_only [12:15] in bazaar.conf? [12:15] in the branch.conf for the trunk [12:17] frk2: merge + commit doesn't reset revisions [12:17] frk2: 'pull' can and so can 'push' [12:17] right [12:18] thats whats happening [12:18] we have a central trunk [12:18] where multiple developers PULL from, and then PUSH [12:18] frk2: this is covered in the users guide I believe [12:18]