[00:02] hmm [00:27] mwhudson: ? [00:28] lifeless: nm :) [00:29] good morning bzr! [00:34] hi poolie [00:38] morning [00:40] lifeless: thanks for your help so far with my bug 356028. Where do we go from here? [00:40] Launchpad bug 356028 in bzr "bzr check fails with KeyError" [Undecided,New] https://launchpad.net/bugs/356028 [01:25] * igc continues reviewing the check patch from lifeless [04:03] * igc lunch [04:36] igc: what -Dprogress changes? [04:44] igc: oh, I see it. [04:48] lifeless: ui/text.py + some doc in debug-flags & NEWS [04:49] yah [04:49] I can split it out if needed, but it seems like make-work [07:22] lifeless, around? [07:23] yes [07:25] lifeless, scenario: I have a working tree with changes in it from a merge. How can I get the revisions that are being merged into this tree? [07:28] cli or lib? [07:28] lifeless, lib [07:29] lifeless, it looks like WorkingTree.changes_from(WorkingTree.basis_tree).modified will give me a list of tuples in which index 1 is a rev id. [07:29] tree.get_parent_ids() returns a vector [07:30] 0 is the tree's commit (which may not be the branch tip if the tree is stale) [07:30] 1 is the first merge [07:30] etc [07:30] then use tree.branch.repository (or some other repo if needed) to get a graph - r.get_graph() [07:31] Hm. That's a bit sub-optimal. The WorkingTree is a checkout, both branches are remote branches (on Launchpad) [07:31] if you want all the 'new revs' you can use one of the difference functions in the graph object (pydoc bzrlib.graph.graph) to get the new revs [07:31] the tree doesn't store or cache the new revs details [07:31] Yea, all I want is the revs that will be merged in the merge. [07:32] if you want the revs that will be the parents of the new commits, it is precisely tuple(tree.get_parent_ids()) [07:33] assuming this is for tarmac; it sounds like you're reproducing some aspect of bzr core - is there some higher level functio that isn't quite right? [07:33] Well, ideally, I want all the revs that will be part of the merge, i.e. the source branch may have 10 revisions with 3 different authors. I want to find those 3 authors. [07:33] ok, then do the graph bit I referenced above [07:34] You mean bzrlib.graph.Graph ? [07:34] tree.branch.repository.get_graph(), and then one of the functions there can give you the difference data [07:35] bzr status -v does precisely this [07:35] in terms of performance; firstly lightweight checkouts over the internet are slow. [07:35] I don't recommend that lightweight checkouts ever be used over the net [07:36] but even so - you need the revision graph, so there really isn't anyway around it: you either have it locally, or you don't :) [07:36] It's not lightweight. It's similar to what PQM does, if I'm not mistaken. [07:36] Although Tarmac is pretty worthless if the net goes away. [07:37] if its a heavyweight checkout then you have the revision data locally [07:37] Okay. That's good. [07:37] But that local revision data is still gotten through tree.branch.repository, correct? [07:38] yes [07:38] the branch oobject will be a local bound branch [07:39] Ah, that's nice. I always wondered what the difference was between lightweight and heavyweight checkouts. [07:41] hi all [07:46] hey vila [08:13] spiv, how did you go today? [08:15] poolie: good so far. A little bit of API friction but nothing serious. [08:19] I have StreamSource producing inventory delta records and StreamSink consuming them successfully in-process, I think. I haven't done a full test suite run yet though. [08:20] spiv: I'm inclined to have it in the normal SS and SS [08:20] spiv: rather than subclasses; what do you think? [08:20] spiv: (your text implies you agree, just putting it out there for explicit consideration) [08:21] lifeless: yes, that's definitely my preference, and how it's implemented so far. [08:23] The only real impediment to that I think is making sure it can operate compatibly with network sinks/sources that can't take inv deltas, I haven't poked much at that yet but I'm sure it's not going to be too bad. [08:23] spiv: I think we should define them as all taking them [08:23] its why I made this a critical bug, so it would be in place for 2.0 and not need bumping then [08:24] well [08:24] Sure, but there are 1.16 and earlier servers (and clients) that can't. Possibly we can just make RemoteStreamSink/Source translate delta->fulltext before passing to the network serialisation layer. [08:25] ^w [08:25] spiv: on a missing verb condition? yes, for push. pull will get the missing verb asking for the stream. [08:25] (iff the network layer knows that the other end can't cope with inv delta recods) [08:26] Right. Like I said, I don't think it's too hard to deal with. [08:27] agreed [08:31] EOD [08:35] spiv, so when you say in process you mean it works doing a cross-format local pull? [08:35] or push [08:35] poolie: right. [08:45] spiv: do you know how to bind a class method into an instance method explicitly ? [08:48] spiv: re-reading my question I now have doubts about the means :) The need is: I want to decide at load_tests() time what method will be called inside setUp. I don't want to have a test in setUp, I want a single raw call [08:56] vila: I don't quite follow your question. [08:56] Or what problem you are trying to solve :) [08:58] spiv: I want parametrized tests to call a method during setUp. I want to define that method in load_tests. I refer to that method by its name, so I get the class attribute, [08:58] If I make a call with attribute, it's an unbound method [08:58] If I make a call with that attribute, it's an unbound method [08:59] spiv: my current workaround is to do: self._do_changes(self) [08:59] and that's ugly :) [08:59] I don't understand why it would be an unbound method in that case. [08:59] There's some part of this picture I don't see :) [09:00] if you do "x = object.method", then "x" will be a bound method (assuming no wacky descriptors like property, staticmethod, etc) [09:00] spiv: because the test object is created and then self.do_change receive class.method because the test instance doesn't exist when load_tests is called [09:01] vila: ?! [09:01] vila: pastebin your code [09:01] vila: you're doing something special [09:01] vila: so you're doing "x = klass.method", because you don't have an instance of the object yet? [09:01] (why?) [09:01] In that case, yes, you should do what you're doing. [09:02] There's probably a way to bind it post hoc, but I'd avoid the magic. This sounds like a strange thing to be doing, though. [09:02] http://paste.ubuntu.com/206061/ [09:03] i'm going to stop soon... [09:04] spiv, lifeless: I realize I shouldn't run into that, that's why I ask where I went wrong :) [09:04] poolie: g'night [09:05] vila: so I think that's as clean as you can make that approach with current APIs [09:05] spiv, lifeless : An other way to do what I want is to use the *name* of the method, but it's not very elegant either :-/ [09:06] so to paraphrase [09:06] you want to run a set of tests in a class, twice [09:06] vila: because multiply_tests doesn't give you any way to read attributes off the test cases you are multiplying, just assign to them. [09:06] changing one function call from A to B [09:06] spiv: yes [09:06] lifeless: yes [09:06] vila: (and you really would want to make sure that if it did it that the bound methods were bound to the right TestCase instance!) [09:07] vila: file a bug on testscenarios if you would; this is interesting :) [09:07] vila: personally I think I would have gone with the name of the method and a getattr [09:08] getattr at call time, that is, obviously. [09:08] spiv: Yeah, that's what I thought, thanks [09:08] Because "here's the name of the method" is a very clear indirection point. [09:08] lifeless: will do, thanks too :) [09:08] And also because that would consume less memory I think ;) [09:09] spiv: and can be explicitly checked at setUp time, right [09:09] Creating methods via assigning callables to instances is pretty cool, but it's easy for it to be confusing. [09:10] spiv: well, the same can be said about any technique you don't practice often [09:10] def do_dirty_tree: [09:10] getattr(self, change_method)(self) [09:10] Well, yes, but particularly with dynamic features where you can't e.g. look up _do_changes in your tags file an get taken to the method definitino. [09:10] spiv: I don't think cricket rules are so confusing since my last trip to Australia for instance :-D [09:11] vila: do you remember how many ways there are to get out? :) [09:12] * vila looks behind him, but no, lifeless isn't reading above his shoulder :) [09:12] spiv: no. But I think I could understand when it happens when watching a game... [09:12] (http://en.wikipedia.org/wiki/Laws_of_cricket#Ways_to_get_out has the answer) [09:14] 42 laws... now, *that's* says a lot about H2G author :-) [09:14] err HG2 [09:18] vila, having what looks like a test class but only exists to provide those mixin bits seems not quite right [09:18] hm [09:18] lifeless: https://bugs.edge.launchpad.net/testscenarios/+filebug :-P [09:19] vila: bah humbug [09:19] poolie: creating a mixin just for creating a mixin ? [09:19] using the word mixin loosely [09:19] vila: one way would be to write those mutators as standalone functions that take a test case object [09:19] poolie: Right, I see your point [09:19] vila: testscenarios has a functional feel [09:19] in parts... [09:20] not so much in [09:20] + tests.multiply_tests(changes_tests, changes_scenarios, result) [09:20] using the word functional loosely :P [09:20] that line was just annoying me [09:20] vila: fixed [09:20] it's a shame it doesn't return a thing for you to use [09:21] poolie: so that I can assign the right method there you mean ? [09:21] I'm quite happy with getattr(self, self._do_changes)() [09:22] I'ts clear, light and robust [09:22] so i was going to theorize thatn [09:23] if you want more power in your test multiplication stuff [09:23] you're probably doing it wrong [09:23] as they say [09:23] like, trying to test too many combinations [09:23] presumably the effects of strictness are separated in the code from the determination of whether we're strictly ok or not? [09:24] vlia, what i was going to say about the mixin class is, why not put do_uncommitted_changes and do_pending_merges into the TestPushStrict class [09:24] if they're only used there [09:25] and then, um [09:25] getattr(self, self._type_of_changes) [09:26] vila, rugby union also has laws [09:26] poolie: it seems we all agree about getattr(self, self._do_changes)() [09:28] jml: well, the point is, I once watched a cricket match, and when one team burst out in joy, I was puzzled about why :) [09:28] jml: at least in rugby you get some understanding that when the ball pass the line, points are scored :) [09:29] > Results 1 - 10 of about 1,210,000 for rugby scandal [09:29] vila: depends on which line :) [09:29] vila: :) my new bit, maybe, is suggesting you fuse the classes [09:29] also, i think _do_changes is not such a good name [09:29] because it actually sounds like a method [09:30] but you can't _do_changes [09:30] i mean, you can't _do_changes() [09:30] Sometimes the ball passes a line and then they stand in a funny formation and just toss it back over the line ;) [09:30] oh like basketball? :) [09:31] poolie: I may be overtesting here, but yet, the full test suite reveals at least one bug when I make --strict the default for push (push can be used without tree and I wasn't testing that) [09:31] Yeah, a variable name that clearly indicates "this variable is the name of a method" rather than "this variable is a method" would be good I think. [09:31] vila: nice one [09:31] and fair enough [09:31] on further consideration [09:31] i think one reason to put the methods in their class is to make it clear how much stuff they apply to [09:32] spiv: but they are having some kind of discussion when they stand in that funny formation, not a single team piling up with joy :) [09:32] parameterization is kind of action-at-a-distance [09:32] which can be confusing [09:32] so the more you do to reduce the distance and make it clear, the better [09:32] poolie: right [09:32] vila: i'm playing with bzr-upload testsuite, i'm trying to add a test for my branch, but i've seen that many tests are disabled due to not having FtpServer feature, i installed test_local_server but even with the plugin (and installing anon proftpd) it didn't work, looking at the code i'm not sure it should work... should it? [09:32] poolie: yes, [09:33] abeaumont_: short: you want to install muddleftp [09:33] abeaumont_: long: local_test_server is used to *inject* real ftp servers into the test suite [09:34] poolie: and also it helps make clear what facilities the methods can use (i.e. a method on a TestCaseWithTransport can obviously use self.make_branch, a free function somewhere less clearly so). "Action at a distance" is a key part of the problem, I think. [09:34] spiv: I agree with that [09:36] poolie: my intent in defining more classes here is that it's better than a single one for clarity. It may not be pure enough for application code, but the classes are final here, so any reader can focus on trivial test code without the need to read more classes [09:36] * igc dinner [09:37] vila: ah, ok, i'll look at muddleftp. Thanks! [09:38] abeaumont_: eerk, memory playing tricks, I meant: http://code.google.com/p/pyftpdlib/ [09:39] abeaumont_: bzrlib supports medusa and pyftplib, but medusa is bogus starting with python2.6 [09:39] abeaumont_: look at bzrlib/tests/ftp_server directory for all the details [09:47] vila: ok, thanks again :) [09:48] vila: i was surprised to see that my broken code didn't cause any test to fail, until i used verbose :D [09:48] abeaumont_: hmm, but even the non verbose mode should tell you about skipped tests no ? [09:50] vila: yes, but i didn't take it too seriously (FtpServer? my trivial test doesn't need such a thing :) [09:50] abeaumont_: :) [09:57] Hi [09:58] Is the encrypted repository format already usable? [10:02] hmm. [10:08] lifeless: ./bzr selftest '(?i)loom' => FAILED (failures=3, errors=6) :-} [10:08] lifeless: no offence intended, just a data point :-D [10:50] <\sh> lifeless: bug #81689 , well this could be a nice workaround, but in general I would like to see that behaviour fixed on MS Windows :) [10:50] Launchpad bug 81689 in bzr "Branches with symlinks can't be checked out on Windows" [Medium,Triaged] https://launchpad.net/bugs/81689 === mvo__ is now known as mvo [12:58] Hi [12:58] Does anyone know of a tool that I can use to generate merge graphs for a bzr repo? [13:02] like 'bzr visualise' [13:06] I wan't to show a commit history graph on a web page [13:06] TheJosh1337: bzr qlog [13:07] ha, that's different, I thought you wanted bzr viz for all branches in a shared repo [13:08] What I want is a generated image file which I can dump onto a website [13:08] You want to ask again to beuno maybe, or garyvdm (but he's off-line right now) [13:08] showing the commits and merges made to trunk [13:08] or become friendly with the PHP gd commands [13:10] beuno, is there a program that is similar to bzr viz, but which generates an image file appropriate for embedding on a web page? [13:11] TheJosh1337: I think bzrtools has something like that [13:11] it generates a graphviz file iirc [13:11] cool [13:14] sweet that's perfect thanks!q [13:55] asabil, Thank you that was perfect. The tool generates .pngs native, so it's perfect. [13:55] im off now, going to bed === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell === abentley1 is now known as abentley === bac` is now known as bac [15:12] vila, hi! [15:13] beuno: good morning ;-) [15:13] vila, good afternoon [15:13] how are you? [15:14] beuno: fine, you ? [15:14] vila, pretty good as well [15:14] want to help me out with a small OSX issue? [15:14] I need bzr 1.16 working on 10.5 :) [15:14] let's try [15:15] beuno: let me guess, you have the C files for the extensions ? [15:15] vila, I haven't done anything, the guy always uses the installer [15:15] and there's only one available for 1.14 [15:16] oh, damn, phanatic where are you ? :-/ [15:16] hmm, wait didn't someone create an installer for 1.16 ? [15:16] and I impulsively upgraded all branches at the office to 2a [15:16] and I left out one of the guys who uses 10.5 [15:17] beuno: just use 1.16 from source [15:17] verterok, how do I tell him to do that? :) [15:17] verterok: can't you 10.4 installer be used on 10.5 ? [15:17] verterok: can't youR 10.4 installer be used on 10.5 ? [15:18] vila: no :( becuase 10.5 defulat python installation is in a different directory than the MacPython install in 10.4 :p [15:18] * vila cries [15:18] * verterok joins vila [15:18] * beuno cries [15:19] http://bazaar-vcs.org/MacOSXBundle/Prepare [15:19] beuno: curl > bzr-1.16.1.tar.gz && tar -zxf bzr-1.16.1.tar.gz && cd bzr-1.16 && make; ./bzr [15:20] verterok: excellent ! Update the wiki :-P [15:20] vila: heh [15:21] verterok, will try that, and continue crying about the installer [15:21] thank you :) [15:21] http://straussd.fourkitchens.com/bzr-1.16-osx-10.5.zip [15:21] oh [15:21] http://straussd.fourkitchens.com/bzr-1.16-osx-10.5-2.zip [15:21] beuno: or I can build a bzr-only package in my 10.5 machine...but you 'll need to wait bit [15:21] eerr, forget the first link [15:21] ohh, nice! [15:22] OH [15:22] even nicer :) [15:22] I thought that one found its way to the right place though, I'll try to poke the list [15:23] perfect, now I feel less bad about upgrading everything without talking to anyone [15:23] thank you :) [15:25] vila: btw, I'm doing a bit of research to automate the 10.5 installer build, looks like it's possible as 10.5 use an xml descriptionto build the installer, with 10.4 I'm still stuck with the manual build (damn binary formats!) [15:26] verterok: that would be a signigicant step for 10.5 and maybe you may find a way to use that installer for 10.4 too.... [15:26] vila: I hope so... [15:27] vila, installer worked great [15:30] beuno: please reply on the list and keep david in CC :-P === Kissaki^0ff is now known as Kissaki [16:56] so i've got local changes in a branch i need to move to another local branch, which i would usually cheat with cd ~/right.place; bzr diff ../wrong.place | patch -p0 [16:56] but this time it has file moves [16:57] which diff/patch won't pick up... is there a way to pull this off with shelves or something? [16:58] or is it just easiest to replay the moves and then diff/patch (which i imagine may very well be the case)? [16:58] phinze, cd right.place; bzr merge --uncommitted ../wrong.place [16:58] aha... will give it a shot jml [16:58] jml, phinze: will work if both branches are at the same tip [16:59] "All changes applied successfully. [16:59] beautiful; thanks :) [16:59] phinze, yeah, it's one of my favourite features. [16:59] vila: actually wrong.place was a large feature branch and right.place was trunk, and it work without problems... [17:00] so i guess today i got lucky :) [17:00] phinze: oh, it will always work, the question is will it do what you think :) [17:01] phinze: merge --uncommitted will get the uncommitted changes but also the missing revisions [17:01] vila, ! [17:01] hah; yeah looks good for this case, though the code in question was in a plugin that is kept in sync between the two branches, so that probably helps [17:01] the merge didn't look like it was any more than what 'bzr st' showed [17:03] phinze: most of the time I use it to apply a work in progress on a remote-but-accesible-vis-mounted-file-system machine where I want to run tests before committing [17:03] s/vis/via/ [17:03] yeah i was in a fixing-bug-on-feature-branch-caused-by-plugin-code-kept-in-trunk situation [17:13] jml, phinze: bah forget me, I misread the command as (cd ~/wrong.place; bzr diff) | (cd ~/right.place; patch -p0) [17:42] Hi.. How do I update the content of a sandbox to a given version ? [17:43] or do I need to create a new clone to do so? [17:47] (I'm thinking of the equivalent of just doing: hg up -r ) [17:47] 'bzr revert -r xxx' [17:48] dash: thanks [17:51] quick question based on trondn's; if i bzr revert -r previous-rev-no [17:52] bzr revno still shows the current revno [17:52] right. revert only affects your working copy, not your branch. [17:52] this is why i thought revert wasn't doing it's thing... how can see what the state of my current branch is? [17:52] which part of its state? [17:53] oh, okay, how can i see my current working copy [17:53] it's the files you've got :) [17:53] use case is as follows: i need to go back and work on an older, tagged version [17:53] so i used bzr tags to find the revno [17:53] ok [17:53] then the correct thing to do is revert to that revno and do whatever work i need to do? [17:54] thanks for the help by the way dash [17:54] np [17:54] well it depends [17:54] do i have the right workflow for my use case? [17:54] you want to create a new version based on modifications to the version at that tag, and not including the changes since the tag? [17:55] in this case, probably not === mario_ is now known as pygi [17:55] but i can see other cases where i may [17:55] i.e. a "sustaining tail" [17:55] i guess that'd be it's own branch then? [17:55] yes [17:56] you can do 'bzr branch -r ' if you only want to get the history up to a certain point [17:56] when creating a branch [17:56] but in the case i'm not making changes, i can just revert -r revno and do my build with alternate parameters, right? [17:56] yep. [17:57] okay, thanks.... spent a lot of time with the docs on this... [17:57] i didn't find much in the docs with what to do with a tag once you've got one :) [17:57] and i'm obviously new to bzr [17:57] it's just a name for a revision [17:58] yeah, it's the larger workflow issues [17:58] i.e. going back to a tag, working from there, issuing a patch, etc. [17:58] i think i'm in good shape for now though, thanks dash! [17:59] :) [18:00] ingenthr: bzr itself, for example, has separate branches for each major version [18:01] so if there's a problem in 1.15, changes can be made in lp:bzr/1.15 and 1.15.1, 1.15.2, etc., versions can be released from there [18:03] where 1.15 is a tag, right? [18:03] not a revno [18:03] it's a branch name [18:03] they may use tags, I don't remember. [18:11] Hi all. I appreciate bzr for its ease of use. I am currently worked with just one colleague on a paper in latex and we want to use bzr. I have my own repository and I sent it to him via e-mail. Now what is the most straightforward way to send him a patch which he may merge (eventually getting conflicts)? I want the result to be that we have the same revisions [18:12] I tried to use bzr submit -o file [18:12] using as a public branch a branch with the exact revision I sent [18:12] and then merge works, but does not commit a new version, so the log message is not the same for example. I want instead to see the same log message and author of the commit on both sides. [18:13] the original revisions are still there [18:13] but if there were no modifications on the other side, he could use pull instead of merge [18:14] then the branch would look identically on both sides [18:14] aha just use pull [18:14] and if there are conflicts it will work as usual [18:14] he will get conflicts, then send a patch to me, isn't it? [18:14] if there is a possibility for conflicts, pull will refuse to work [18:14] pull will only work if there are no changes at all [18:15] hmm conflicts always lead to confusion. So if we both change the repository what are the options to get synchronised? [18:15] without both having r/w access to a repository? [18:16] well, the easiest option is to use merge and not worry [18:16] bzr log will still show you the original revisions [18:16] luks: you mean, use merge, and then commit? [18:16] but it will have one new revision, the merge commit [18:16] yes [18:17] but if I happen to have both repositories, will bzr be able to tell that the two seemingly different commits are the same? [18:17] as I said, there are situations when you can use pull instead of merge [18:17] He could pull on a clean copy of the last synchronisation point [18:17] Chuck__: I think you are misunderstanding how merge works [18:18] and then merge with his own, that would work? [18:18] luks please explain me if you have time [18:18] I always get confused by VCS in general [18:18] sure [18:19] let's assume you have two branches, both with two commits A B [18:20] now if you commit C to one of them, you can use bzr send to generate a patch and use bzr pull on the other side to apply it [18:20] then you end up with identical branches on both sides [18:21] now let's say you commit C to one of them, and send him the patch [18:21] but before he gets the patch, he commits D to his branch [18:21] luks wait a sec. I am already lost [18:21] now you have "A B C" and he has "A B D" [18:21] ah ok [18:22] yes this is the situation [18:22] and in this situation you need to merge [18:22] aha ok [18:22] so after merge you end up something that is not really a line [18:22] one sec [18:23] yes this is clear, it's like a diamond sort of [18:24] ok, so I'm not doing to "draw" it :) [18:24] the point is that bzr knows where each revision is from [18:24] and it knows the original ordering of the revisions [18:25] ok [18:25] so the merge is actually a new revision [18:25] so your revision C is still there, but there is a new revision, under which your original revision is merged [18:25] yes [18:25] yes but will I see C in the changelog? [18:26] of course [18:26] hmm then I did the wrong experiment, let me redo it [18:26] you will see it "indented" under the new revision [18:26] aah so only when I finally commit the merge. So the merge status is special. I have the conflicts and then I can commit, but it will actually commit 2 revisions [18:26] did I get it? [18:27] technically, it will commit only 1 revision [18:27] your original revision will be copied when you run merge [18:28] my original revision="C" [18:28] ? [18:28] and the new revision will be added when you merge [18:28] yes [18:28] but after merge if I do bzr log I still don't see C, right? [18:28] Chuck__: are you on windows by a chance? [18:28] Chuck__: you should see C [18:28] luks: no way, I left windows for good 12 years ago :) [18:28] aha ok I will retry now [18:29] ok I see C [18:29] whatever it is [18:29] I was just wrong earlier. [18:29] if you have bzr-gtk or qbzr installed (bzr plugins), you can use bzr viz or bzr qlog [18:29] that should make it much more obvious what's going on [18:30] so it's very clear now. I just prepare a patch with "bzr something" which I already forgot, and then "bzr merge" on the obtained file. What is something btw :) I'll write this down [18:30] bzr send [18:30] something is send :) [18:30] yea [18:31] you've been patient and helpful. Thanks. A last question though: is there any sane reason why I should prefer the hassle to find a shared sftp service instead of sending patches via e-mail in such a simple scenario? [18:31] it might be easier for you than sending emails [18:31]