[00:04] vila: TestCompare is a level higher than TestIterChanges [00:05] look at TestIterChanges [00:10] lifeless, Yup, I'm on IterChanges, does test_file_rename suits you ? [00:10] ok [00:13] jml: ping [00:13] lifeless: pong. [00:14] is launchpad-bazaar 'just the server side code' or 'stuff for launchpad-bazaar'? [00:14] (I'm asking because IMO launchpad plugin bugs belong in launchpad-bazaar; I think poolie has been treating it that way too) [00:15] lifeless: I think it should be just the server side code. [00:16] lifeless: and I *thought* I'd already said so to both you & poolie [00:16] jml: Ok. Can you make this more clear on project pages etc [00:16] although maybe not as clearly / officially / permanently as I ought [00:16] lifeless: will do. [00:17] jml: e.g. https://edge.launchpad.net/launchpad-bazaar it entirely unclear, though it is a wonderful mission statement [00:18] it just doesn't help me understand what bugs/questions are relevant there :) [00:21] * jml sends an email to a person [00:22] * thumper feels like he needs a PR person sometimes [00:34] hello thumper [00:34] bam bam [00:34] hi poolie [00:37] vila: how are you going? [00:37] trying to understand what is *in* the heap in CHKMap,iter_changes [00:38] vila: ok; do you suspect a bug in that later? [00:39] *layer* [00:39] so far, yes. [00:39] vila: it should be trivial to examine whitebox style - left = dict(map1.iteritems()), right = dict(map2.iteritems()) [00:40] then you can say deleted_keys = set(left) - set(right) [00:40] and new_keys = set(right) - set(left) [00:40] and (a little more work needed) [00:41] unchanged = set([key for key in set(left).intersection(set(right)) if left[key] == right[key]]) [00:41] changed = set(right).intersection(set(left)) - unchanged [00:42] and you can do this from within a debugger in CHKInventory.iter_changes, before the loop [00:42] and compare it to [00:42] list(self.id_to_entry.iter_changes(basis.id_to_entry)) [00:42] vila: ^ [00:43] ack === mw is now known as mw|out [00:51] poolie: http://www.google.com.au/search?q=launchpad+bazaar+password+authentication&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:unofficial&client=firefox-a [00:51] my google-fu is strong [00:51] right, so since the tests is about renaming a single file unchanged shouldn't be empty [00:51] right, so since the test is about renaming a single file unchanged shouldn't be empty [00:52] vila: 'changed should not be empty' [00:52] ? [00:52] changed is empty too [00:53] vila: keep poking it for a little bit, I'll just flush my cache [00:53] I really meant unchanged shouldn't be empty, there is a directory and a file inside it that are used in the test but not concerned by the rename itself [00:54] vila: ok [00:54] so may be the bug occured before, when the map were built [00:54] vila: note that unchanged is not reported by iter_changes [00:54] so may be the bug occured before, when the maps were built [00:55] vila: so its the dict comparison that would show them as unchanged [00:55] lifeless, sure, I used it as the simplest communication vector, eye-grepping left and right told me that before [00:55] vila: you can also do self[self.path2id['dir'] etc to check [00:56] in left: (('b-id',), 'dir: b-id\x00root-id\x00b\x00vila@scythe-20081114004115-p86lzmmfsqqie2a3') [00:56] in right: (('b-id',), 'dir: b-id\x00root-id\x00b\x00vila@scythe-20081114004115-oh1ijsqf60ht5rzs') [00:57] is the latest part a rev-id ? [00:59] that's the crux of the problem, there is no difference between the twosm yet iter_changes saw them as different [01:03] vila: yes, the end is the revision_id [01:03] they are different [01:03] but perhaps inv.iter_changes is not meant to report these differences [01:03] ah yes [01:04] in CHKInventory.iter_changes [01:04] if there is no change at all, but the revision is different, just continue [01:04] rather than yielding [01:07] so [01:08] if not changed_content and parent[0] == parent[1] and name[0] == name[1] and executable[0] == executable[1]: [01:08] continue [01:12] jelmer: I'm getting a weird failure trying to branch a bzr branch whose parent is a Subversion branch [01:12] jfroy|work, what's the error? [01:13] bzr: ERROR: Revision {svn-v4:be02940b-5f7b-422b-ba6c-1eb93f4884eb::7882} not present in "6604@be02940b-5f7b-422b-ba6c-1eb93f4884eb:". [01:14] It's strange not because it is happening per se, but it's happening if I try to branch the the branch in a different repository [01:14] jfroy|work, this is what the warning in bzr-svn trunk is about.. [01:14] lifeless, that fixed some failures 17 failures out of 36 :) [01:14] The source branch is in shared repository A, and I can branch it in that repository fine. But if I try to branch in repository B, it fails with that error. [01:14] jfroy|work, the output of bzr-svn trunk can change, breaking some core assumptions made in bzr [01:15] Right, I used trunk for a brief while some time ago. [01:15] But I am not right now. [01:15] the same key refers to slightly different contents in bzr apparently [01:16] jfroy|work, one of the revisions you're fetching was apparently imported using trunk [01:28] lifeless, so, out of the 19 remaining failures, most need either specific_files filter or include_unchanged or want_unversioned implemented [01:29] 3 sounds like bugs in CHKInventory.inter_changes about missing/renamed files. I'll look into them first [01:29] ok [01:29] commit and push first [01:29] small steps [01:34] jelmer: OK sorry, had to take care of something [01:35] I checked out the svn branch in repository B just fine. [01:35] So basically, I should re-branch the svn branch in repository A [01:35] And indeed, I might have done the initial checkout in repository A using bzr-svn trunk. [01:35] ok i'm going back to 288751 now [01:36] i might push my bzr branch of that and get some user testing [01:44] hey i am running bzr on my windows box and i created a project on my linux box and i am getting the error Not a branch [01:44] i a connecting via ftp [02:08] is there any documentation on setting up a server to be able to push to and pull from? [02:09] lamalex: yes, in the users guide [02:11] yah, i just found it [02:11] my google-fu was failing me, but now i got it [02:13] vila: how are you progressing? [02:14] lifeless, :) You always ping just when I want to ask you a question :) [02:14] its the chip implanted in your brain [02:14] I get a flashing red LED here [02:14] lifeless, haaa, I thought it was tobacco craving... [02:15] so, for bzrlib.tests.intertree_implementations.test_compare.TestIterChanges.test_missing_and_renamed [02:16] CHKMap,iter_changes knows nothing about the missing file renamed and transformed into a directory and I don't understand if that's the bug [02:17] so [02:17] this may need special casing in the test [02:17] RevisionTree.iter_changes(RevisionTree) can never have 'missing' files :) [02:19] you mean something like in test_only_in_source_and_missing (just below) ? [02:20] vila: yes [02:20] only on tree2 [02:20] erm [02:20] sure [02:20] *thinks* [02:20] yes [02:20] tree12 [02:20] *2* [02:22] well, in the permutation we added, we want only the tests that use two revision trees and we don't want tests that need one or two working treees (as tests about missing files are) [02:22] do you agree ? [02:22] ~. [02:24] vila: one working tree will be fine [02:24] vila: because the existing dirstate<->workingtree needs one revision tree [02:24] vila: so the new if block should be tree2 only [02:25] I added if not tree2.path2id('directory'): for test_missing_and_renamed [02:25] cool [02:26] my question was more about why we encounter these failing tests and a general rule I can apply for the other ones :) [02:26] vila: yes, I agree [02:27] test_only_in_target_and_missing for example needs kind of the same test for the same root cause, the change ends up being a 'missing' one that can be represented in our case [02:29] and instead of duplicating that block, I'll do a helper named file_id_is_missing(path) that will raise TestNotApplicable, agree ? [02:30] file_id_cannot_be_missing_in(path, tree) [02:31] how about [02:31] not_applicable_if_missing_in(path, tree) [02:31] deal [02:32] self, path, tree actually :P [02:32] hmm, unless it needs to be a function, then path, tree is fine :> [02:32] yeah, yeah, don't worry :) [02:37] jam: spiv: - there are two cases I think, xml->chk, and chk->chk [02:37] the former hits interdiffering [02:38] so fetch.py should just find the nodes only-in the interesting inventory maps [02:38] I suggest a new method on chk_map to support this; similar to the iter_changes one [02:38] because it has the same problems with when-are-duplicate-keys-encountered [02:39] it probably wants to take two sets though, not two objects [02:39] right [02:40] a naive implementation (use iterchanges, discard some data) is probably easy to get going, and will let the interface be settled [02:43] in terms of layering [02:43] hmm, actually, I'll comment later [02:43] other than to say I agree its not a CHKMap method [02:46] how can i run bzr as the nobody user ("bzr commit" is being spawned by a exec() command from php) [02:47] a_c_m: bzr doesn't particularly care [02:47] a_c_m: just make sure your permissions etc allow it to do what it needs :> [02:47] lifeless: i think they are, but i think bzr is expecting a .bzr directory in the users home folder [02:47] which being the nobody user, it doesn't have [02:47] anyway to bypass that check? [02:48] a_c_m: it needs a ~/.bazaar, and a ~/.bzr.log it can write too [02:48] you'll need them available in whatever account it is running as [02:48] right, so how do i create / fake that, as a the nobody user ? [02:49] who doesnt have a home directory ? [02:49] 'nobody' shouldn't own any files [02:49] a_c_m: well, my advice would be to not run bzr as 'nobody' [02:50] right, but i dont have that option really [02:50] nobody isn't meant to have write access anywhere, so asking bzr to do something your system is almost certainly setup to prevent won't end well [02:53] a_c_m: why don't you have an option? [02:53] use sudo to run a trivial shell script that can only commit the required stuff [02:54] the bzr statement is being kicked off by apache [02:54] a_c_m: so? tell apache what user to use [02:54] i think i've worked out a way around it [02:54] apache user == nobody === timchen119 is now known as nasloc__ [03:39] awesome [03:40] some one just mailed me asking how to login in latin on intrepid [03:40] haha [03:40] I'll need to fix it again I suspect :P [03:44] perf testing this children thunk [03:44] I expect satisfactory results, because the design makes sense to me :) [03:44] * lifeless has no ego, really [03:54] is there a bzr-svn ppa? [03:54] or any way to get a bzr-svn to go with bzr 1.9 package? [03:54] i'm on hardy, btw [03:58] ugh [03:58] Inventory.apply_delta mutates the inventory entries it is passed [03:58] * lifeless fixes [03:58] flacoste: not sure [03:59] * flacoste thinks i might be better to use bzr-svn as a branch [04:22] Woah why is Loggerhead using half my RAM? [04:23] (That would be more dramatic if I wasn't running it on a $20 VPS. :P ) [04:24] lifeless: so at the moment "_fetch_uses_delta" determines "include_delta_closure" but they're not really the same thing [04:35] Peng_: *probably* a bug in Bazaar's logging. The Launchpad Code team are looking at it. [04:35] (it's one of our dozen #1 priorities) [04:36] It was only 200 MB. I was surprised because it almost doubled in 6 hours. [04:36] (doubled *to* 200 MB, I mean) [04:37] jml: Logging leaks RAM? [04:38] Peng_: uhh, I meant "something in getting a revision log". I haven't been following the details of the discussion. [04:39] spiv: jam: just pushing a tweak to allow inv._make_delta(inv), which unsurprisingly improves fetching from dev3 to dev4 dramatically [04:42] jml: Oh! [04:43] Hey look, it dropped 4 MB of RAM. [04:43] Anyway.. [04:48] How do I increment the version no of a repo to an arbitrary integer? [04:49] You, uh, don't? [04:49] cafuego: while `/bin/true` ; do bzr commit --unchanged ; done [04:49] Or that. [04:49] cafuego: that outta do ti. :| [04:50] AfC: ta [04:50] cafuego: ? [04:50] [notice the subtle "ti" mimicking the reversed "fi" that ends a shell if block, clearly I was playing on that instead of just saying "outta do it". Yup. Uh huh] [04:50] Peng_: I'm setting up bzr for a piece of software that's at rev 12. I'm missing v1 and 2, but would like the commits match the version number (it's a single php file) [04:51] AfC: if you 'sudo rmmod sjh' the problem should go away ;-) [04:51] cafuego: uh, Peter, can I politely suggest that you're on completely the wrong track? [04:51] Yes, you can. [04:51] cafuego: as for your task at hand, why not just use tags? [04:52] That sounds like more work ;-) [04:52] [sooner or later you're going to have more than one commit : "version" and you'll be screwed anyway, hence my suggestion expressed a moment ago] [04:52] AfC: No, that work would be done ona dev branch, not on trunk. [04:52] cafuego: or, do what everyone else does, and have the version embedded in a file somewhere and ignore it from there. [04:52] AfC: I'll merge those into trunk and a single revision, thus keeping it in sync. [04:53] while true; do something; done [04:53] no need - in fact you shouldn't backtick it [04:53] mlh: I was in a channel the other day where someone had the nick 'something'. The conversation went to Who's On First" in a real hurry. [04:54] hah [04:54] mlh: Ah yes. I knew that. In fact, that's what my fingers typed, and then I second guessed myself. Thanks [04:55] while I'm on a roll ... :-) [04:55] true is faster than /bin/true, being a builtin (I think) and : might be even faster [04:58] mlh: it is a builtin, yes [04:58] $ help true [04:58] I don't knows on third [05:01] lifeless, just pushed handling specific files for iter_changes [05:02] sweet [05:02] right, done, excellent. [05:08] lifeless: like http://pastebin.ubuntu.com/71665/ [05:09] unfortunately now i understand it i can't think of a better way to explain it :) [05:11] spiv: want some sad news? [05:12] Using saved push location: bzr+ssh://bazaar.launchpad.net/... [05:12] No new revisions to push. [05:12] HPSS calls: 19 [05:12] HPSS calls: 6 [05:12] HPSS calls: 7 [05:12] poolie: why line 23/24 ? [05:24] http://paste.ubuntu.com/71472/ [05:25] jml: not as bad as I'd fear ;) [05:26] spiv: if I had to call Tim 32 times to find out I had nothing to do, I'd be upset. :) [05:28] hmm. you could probably make a parlour game out of protocol design. [05:28] jml :-) [05:28] jml: I noticed recently how many times waiters at restaurants come up to your table to find out that everything is fine. [05:29] varies per country and restaurant [05:29] spiv: polling sucks [05:29] lifeless: it's not a big deal, it just seems like it's a class property not an instance one [05:29] poolie: I'm semi-serious though. [05:30] poolie: formats are instances :) [05:32] how does lh want patches? branches? bb? lp merge-proposals [05:32] ? [05:32] jml, i know [05:36] spiv: i noticed they all did that in adelaide, not so much in melbourne. [05:46] lifeless: i think through lp [05:47] jml: ^^ lh above is loggerhead [05:48] lifeless: I don't know for sure. I think bb. [05:48] lifeless: I merely hang out with a bunch of people who care about loggerhead :) [05:51] lifeless, yeah for getting rid of make_inv_delta !! [05:52] lifeless, did you happen to hack on that profiling for loggerhead. [05:52] rockstar: thats why I'm asking [05:53] lifeless, oh, I hadn't read backlog. [05:53] Submit a merge proposal. [05:53] ok [05:53] I've only just started now [05:53] but the day is close to halt() so getting the facts straight [05:54] rockstar: I was planning on writing the profile to request_serial.callgrind in the working dir [05:54] lifeless, there's something going on with stderr. I couldn't capture it properly. [05:57] I wanted to put the profiling data into the HTTPResponse, but it never really worked right. [05:57] rockstar: ok, well I don't :) [05:57] rockstar: should I preserve yours, or just alter it to suit? [05:58] lifeless, alter to suit. [06:02] rockstar: the reason I don't, is that it would force buffering and be a race condition,FWIW [06:03] lifeless, oh, I'm fine with that. In fact, if I could get more detail in a log, then I'd rather have that. [06:03] what is the getattr('close' thing all about ? [06:04] lifeless, no idea. I haven't touched that branch in two weeks. I was probably in the middle of scheming something. [06:05] ok [06:05] and self.lock? [06:06] lifeless, threading thing. [06:06] yah, just climbed into the base class [06:07] fugly [06:07] lifeless, indeed! [06:08] most of it has to do with buffering. [06:08] overly clever fools. [06:09] Yea, I figured I could have removed much of that code. [06:11] also, it will buffer badly; list.extend is not the fastest thing in the world [06:11] I particularly like their use of inline methods [06:13] lifeless: this is the basic approach to instert_records: [06:13] # We can insert the knit record literally if either we already [06:13] # have its basis OR the basis is not present even in the [06:13] # fallbacks. In the latter case it will either turn up later [06:13] # in the stream and all will be well, or it won't turn up at [06:13] # all and we'll raise an error at the end. [06:14] rockstar: just adding save to disk, then will be done [06:16] poolie: not quite right. I think: [06:16] poolie: ah, never mind me, thats fine [06:17] poolie: I was thinking that it may make fulltext things it doesn't need to; that we could (should?) insert it literally always, if we dno't have its basis then at the end, copy the basis in as a full text. [06:17] (from the fallback repo) [06:17] poolie: butperhaps this is over complicated [06:19] i thought about that too [06:19] however, it seems like you may end up with more data [06:20] because you'll get a fulltext plus a delta rather than just one (perhaps larger) fulltext [06:20] there are various possibilities, like if you get a lot of direct children of a fulltext that's in the fallback repo [06:20] thats true; OTOH we won't ever turn a ft into a delta, so perhaps more data here is better for when its merged to the trunk repo. [06:20] it would have been better to just copy it [06:21] true [06:21] so it does seem more complicated because you have to recurse back in to the fallback repo to get the delta closure... [06:21] (that's kindof a flaw itself, but we're working with what we have today ;P) [06:21] poolie: so, your text is fine; we both thought about and discarded the same thing [06:23] ok [06:23] so i have that approach working [06:23] insert_records is a bit complex i'm going to see if i can refactor that [06:23] but it is passing now [06:31] rockstar: I can has kcachegrind love [06:32] 26% in simpletal [06:32] expandInline [06:32] ok, not bzrlib. yay [06:33] something silly is logging gif content to stdout [06:33] oh, thats me [06:33] whats all this /static stuff ? [06:34] * lifeless thinks loggerhead trunk is broken [06:34] (assuming this is close to trunk) [06:34] anyho [06:34] w [06:35] rockstar: its done [07:09] lifeless, only 2 failures left for ./bzr selftest --no-plugins -s bt.intertree IterChange.*CHK [07:10] vila: congrats [07:17] morning folks [07:27] hello pygi [07:28] lifeless: so now some of the effort tests in test_knit are failing [07:28] hey poolie, how's it going? :) [07:32] poolie: push one in, the other pops out [07:34] ? [07:35] commenting on bug fixing in general [07:36] oh, right [07:47] rockstar: around? [07:52] woo! [07:52] bug 288751 is dead, i think [07:52] Launchpad bug 288751 in bzr "bzr push to stacked branch returns error Revision not in " [Critical,Triaged] https://launchpad.net/bugs/288751 [07:52] and probably all its brothers [07:55] poolie: congrats! [08:17] lifeless, no more failures :) [08:17] lifeless, pushed to bbc [08:19] vila: vcool [08:20] lifeless, I kept all the hacks in the same place so there will be a single place to de-hack :) === doko_ is now known as doko [08:35] lifeless, TestCompare tests passing too [08:40] night all [08:43] night [09:59] hi [09:59] good morning [09:59] at least here :P [10:04] I need to remove some files that lives in my history that are HUGE and when I mean huge I mean 600mb that is not anymore in the tree and they are present only for 1 revision [10:04] is there a way ? [10:08] jquery [10:08] ops [10:10] :-) [10:22] Is there a command akin to 'switch' for branches - i.e. created with 'branch' not 'switch'? [10:24] I haven't found anything so far and wonder if the only way is to delete my local branch and issue the branch command again for the one I want? [10:25] Maybe "pull --overwrite", depending on exactly what you mean by "akin to". [10:25] Which is a bit of a shame because the branches contain lots of similar code [10:26] Maybe overwrite will work. I'll take a look [10:27] Perfect! Thanks. [10:28] Also, you could create a shared repository above the branch, and "bzr reconfigure" the currently --standalone branch into a --use-shared branch. [10:33] I'll take a look into it, thanks. [10:38] I'm using bzr v1.3.1 from Ubuntu 8.04 LTS right now. I planning on sticking with the latest bzr available in ubuntu for production use, because it gives me a good indication of how stable that version of bzr is, and how backward compatible it might be in the event of an upgrade. Does anyone see any problems with this, or should I be trying to stick to the latest version of bzr off the website? [10:58] Sorry, what gives you an indication of "stable for production use"? [10:58] You should most certainly be using the latest release of Bazaar if you are able. That's where the bug fixes are. [11:44] Yes, the enormous test suite is far more reassuring than a slow creep of revision numbers === jszakmeister is now known as jszakmeister|awa [12:17] hello everyone. I was wondering, could Bazaar be used within a design department? That would mean large files (10-300MB), autoversioning would be nice... [12:17] It wouldn't be advisable [12:17] It's not suited to large files [12:17] Have you considered ZFS? [12:19] It wouldn't provide iron-clad-forever versioning but it would give you a considerable cusion [12:19] *cushion [12:21] ... ZFS -> the file system? does it store previews (1-step) versions? [12:31] ah, the copy-on-write feature, thnx alott [12:37] k , thnx bye === thekorn_ is now known as thekorn [12:50] I need to remove some files that lives in my history that are HUGE and when I mean huge I mean 600mb that is not anymore in the tree and they are present only for 1 revision [12:51] Hi all, I'm in linux and tried to install the vimdiff plugin (copy to ~/.bazaar/plugins/vimdiff (there are README and __init__.py)), making the .py executeable, but when I do 'bzr plugins' it's not listed. [12:51] what am I missing? [12:55] hiperlink: Look in ~/.bzr.log, it might tell you. [13:02] @Odd_bloke as I'm not a python programmer, I'm not good at interpreting this: http://gist.github.com/24890 [13:03] hiperlink: If you 'cd ~/.bazaar/plugins', 'python -c "import vimdiff"', what happens? [13:06] ImportError: "No module named vimdiff" [13:07] oh I got it, accidentally I moved the __init__.py to plugins/ not into plugins/vimdiff/. [13:07] Anyway: thanks for your help [13:07] Yeah, that'll do it. [13:07] now it works. === kiko-phone is now known as kiko [14:07] visik7: Your best bet is probably to branch the revision just before the giant file was introduced (revision N), and then use the "rebase" plugin to re-create revisions N+2... on top of revision N (i.e. skipping revision N+1). [14:08] :/ [14:08] This means that the revisions N+2... will have their revision-id change, so any branches off the un-rebased revision will become stale/still include the giant file. [14:35] lifeless, you filed to merge proposals with the same commits, except for a last one. Any reason for that? to land them separetly? [14:54] if I pushed a commit but then I want to revert that commit in order to make little commits, how can I revert without removing those files that were added? [14:57] maybe I could do a bzr revert -r1; bzr diff -r1..2 | patch? [14:59] err, 2..1 [15:05] nevermind, all figured out now === mm-mysql__ is now known as mm-mysql [15:42] hi ,bzr-svn do not wok , i installed bzr-svn with macports, [15:43] bzr checkout svn+http://www.prestashop.com/publicsvn/trunk/ shop-trunk The svn+ syntax is deprecated, use http://www.prestashop.com/publicsvn/trunk/ instead. - [ ] copying revision 0/4815 [15:44] stay in this screen about five minute, [15:57] army: Are you sure it's not doing anything? [15:58] Just because it's not reporting progress doesn't mean it's not doing anything (unfortunately). [15:58] ? yes ,no reporting progress, === kiko is now known as kiko-fud [16:01] Initialising Subversion metadata cache in /Users/army/.bazaar/svn-cache/6e0da8f0-d90d-0410-b14f-823b0ad1652c bzr: ERROR: plugins is already versioned === evarlast_ is now known as evarlast [16:52] If you have a checkout with local commits, how can one commit, say, a single file to the bound branch? We get "ERROR: Selected-file commit of merges is not supported yet" right now. === mw|out is now known as mw === kiko-fud is now known as kiko-phone === bac_afk is now known as bac === bac is now known as bac_afk === mw is now known as mw|food === mw|food is now known as mw === kiko-phone is now known as kiko [20:48] Hi, I have a question about the bzr notification - it's only giving me notifications when I commit. Is that it's supposed behaviour? I thought it would notify me when others committed. [20:49]