[00:26] lifeless: where did you upload your GPG key? It's still not on any of the public keyservers. [00:27] subkeys [00:35] morning [00:36] hi [00:36] hi igc, lifeless, AfC [00:39] hi guys [00:43] Let's say I made two revisions a moment ago, the last one I want to keep, the first one I made changes that I don't want anymore. What options do I have now? I don't want to revert back two revisions and lose the changes I made, but I'm not sure how to handle that. [00:43] I'm a bzr / programming newbie, for what it's worth. [00:45] distatica: the easiest thing is just to undo the changes you don't want [00:45] and commit [00:45] you mean manually? Just go in and remove those and then make a new commit? [00:45] Or do you mean there's a way to undo a revision? [00:46] you can undo a revision [00:46] but as you're new to bzr I suggest not doing that until you've got some more experience [00:46] ok [00:46] just edit your files and make them the way you want, and do a commit === KX is now known as KX|360 [00:47] could I make the last commit a patch, revert back and apply that patch? Or am I just getting too complicated? [00:47] For the record, I can undo these changes in about 20 minutes of work, so it's not a major critical issue, I was just going to learn how to do it while I'm here, unless I don't have the knowledge yet to perform it. [00:48] so [00:49] if you've shared the branch with someone you can't really ever delete the fact that you /did X/ [00:49] think of bzr as a journal [00:49] ok [00:49] once shared with people they have the journal [00:49] you can't erase from their copy [00:49] if you haven't shared it with people you can rip the most recent page in your journal out [00:49] and then write on a new page [00:50] the way you'd pop two commits off is: [00:50] bzr uncommit [00:50] bzr shelve --all [00:50] bzr uncommit [00:50] bzr shelve --all [00:50] now, bzr unshelve [00:50] so, if I make 3 commits, revert back 1, and then share the repo, the log will only show 2 commits? [00:50] ok [00:50] will put the most recent shelved changes up ready for editing [00:51] yes, though 'revert' doesn't affect the journal at all; 'bzr uncommit' does [00:51] oh I see [00:51] (the shelve --all, unshelve pair is a no-op, you could just do uncommit, shelve --all, uncommit to get to the same state) [00:51] this is an issue I've been having, being a non-programmer some of my commits are... well pointless. :) It's just me screwing around with one thing, doesn't work, go back, try another. [00:51] anyhow, at this point in my example, you'd change things so they are you want, the commit [00:52] bzr unshelve [00:52] and bzr commit again [00:52] ok [00:52] and you're back nearly-where-you-started but with the commit 2 back changed [00:52] so back to the journal analogy [00:52] if someone has been reading your journal [00:52] its not pointless ;) [00:52] if they haven't, if its private notes, then its fine to just change your mind [00:53] ok, that's great news actually -- I had asked this question from someone a while back and got the impression (most likely due to my own ignorance) that once it was there it was set in stone and that was that. [00:54] the key thing is sharing [00:54] yeah, once it's gone then it's stone. [00:54] once you've done that its more tricky :) [00:59] great, thank you. [01:11] lifeless: does that mean that stacked branches are implicitly standalone? [01:14] igc: not sure what you mean by that [01:14] lifeless: when you said "we explicitly don't stack in shared repos" [01:14] what did you mean exactly? [01:14] so [01:15] in principle a branch can be stacked, while in a shared repo [01:15] but our ui code says 'oh, you have a shared repo, we won't stack' [01:15] so it should be unusual, but its not impossible, to encounter a stacked branch in a shared repo [01:15] I think we'll probably make it very common when we overhaul how we manage branches [01:15] ok [01:16] but thats a different discussion [01:16] right [01:21] lifeless: on another topic, that commit file patch has been reworked as we discussed [01:21] I know you're really busy ... [01:21] thanks [01:21] but if you're happy with it, I'll land it fro 1.15 today [01:22] I appreciate the ping [01:22] my day is: [01:22] 1) slides, deadline is today [01:22] 2) final prep for trip [01:23] 3) all other stuff [01:25] lifeless: ah, there it is now. [01:25] mwhudson: morning :) [01:29] poolie: you know how you say you use the register-branch API -- how exactly do you authenticate with that? [01:39] bzr alias snt="snt" [01:40] * jml corrects the typo and tweetoblags. [01:48] jml: i think it uses https auth [01:49] hello all [01:49] i'm basically getting ready to go and doing slides today [01:49] lifeless: i approved your patch as you probably saw [01:49] poolie: yes. [01:49] poolie: and it prompts you for your Launchpad password? [01:50] i think so [01:50] it's so 2006 :) [01:50] also, saying "it's so x" is so 2006 :) [01:50] poolie: I landed it as you may have seen :) [01:51] poolie: I'm actually waiting for a revival of "c'mon, it's the nineties!" [01:51] poolie: I may be waiting a while. [02:05] jml: so long as we skip the 80's revival. there are some places that should be left in the past. [02:22] spm: when doves fly [02:23] lifeless: ha! 'twas more the vison of the 80's "BIG" hair and warrick kapper style shorts that terrifies [02:23] lifeless: also when they cry. [02:25] it a myth [02:34] shudder [03:06] jelmer: ping [03:12] fullermd: pong [03:13] Is there some reason you chose malloc.h rather than just using stdlib.h in the pyrex rio stuff? [03:17] igc: ping [03:17] igc: I didn't see a new merge request for that branch; did you simply push up changes? [03:27] lifeless: I did push the changes and ... [03:27] I tried to tell lp that it needs a new review [03:27] but the latter didn't seem to do much :-( [03:27] I've filed a bug [03:28] one thing I've seen already [03:28] the def check inner function [03:28] thats very opaque style [03:28] it would be clearer to either just do self.assertEqual(x, ...) 3 times [03:29] I just copied what was there from memory [03:29] I realise this is kindof trivial, but we had 100 line tests that looked like that once [03:29] and it was fugly [03:34] jelmer: FreeBSD malloc.h has been #error'ing since 2001 (and #warning'ing since 1994) and pointing grumpily at stdlib. Builds fine for me with that change. [03:37] fullermd: I've sent a merge req [03:40] Rox. jelmer++ [03:41] * jelmer longs back to the days when statements had to be terminated with semicolons and malloc lived in malloc.h [03:47] When men were real men, women were real women, and small furry creatures from Alpha Centauri were real small furry creatures from Alpha Centauri? [03:54] igc: ok reviewed [03:54] lifeless: thanks [03:55] igc: I'mvery glad you factored it out, because now I'm sure there was something really wrong earlier ;) [03:56] igc: and yes, I've just checked your older code [03:57] so the problem is, you don't actually force include missing parents [03:57] they aren't being generated from iter_changes [03:57] so you'll have to iter_changes the *entire tree* if the user uses specific files [04:00] igc: If you want to chat about this, I'm happy to do so [04:00] lifeless: thanks. I'll take a look soon [04:06] igc: I'm going to nose down on presentations [04:06] igc: you may need to ring me :P [04:06] ok [04:58] * igc lunch [05:34] so the good news is we saturate my link very happily branching bbc over the smart server [05:39] igc: did my review make sense? [05:40] lifeless: just got back from lunch - I'll take a look now [05:46] lifeless: so, I might be stupid but I still don't see the problem ... [05:46] ok [05:46] iter_changes only needs to return changed parents, not all of them [05:46] right, but unless its looking at parents it won't return them, because iter_changes has a bug [05:46] i.e. if a parent isn't in iter_changes, then it isn't needed in apply_delta IIUIC [05:47] lifeless: but it *is* looking at parent right now [05:47] how? [05:47] it looks at the whole tree, then post-filters [05:48] ow [05:48] I'm really torn [05:48] nad osutils.parent_directories doesn't need to return the root [05:48] at the os level, '' doesn't make sense [05:48] well, other code would be cleaner if it does - as you are making sure you have [''] always [05:49] also, my change to when record_titer_changes was deliberate ... [05:49] and the comment still hold exactly as is btw [05:49] I benchmarked to decide when it was the right thing fwiw [05:51] why the (len(self.parents) < 2 and not self.specific_files and not self.exclude) [05:51] clause? [05:51] because for non-chk formats, ... [05:52] it's slower than the current code otherwise [05:52] at least on Emacs [05:53] I'm happy to extend the comment along those lines [05:53] So this means tha the self.specific_files and self.exclude processing with record_iter_changes is _slower_ than the old full-tree code path [05:54] and that its only faster with record_iter_changes on chk repositoreis because the chk code is able to compensate [05:54] I appreciate that you've got it going faster [05:54] yes, according to my measurements [05:54] I'm really worried that the other changes, such as the reinstance of files_across_trees are going to make it harder for someone to come bacj and fix bug 347649 properly [05:54] Launchpad bug 347649 in bzr "iter_changes missing support needed for commit" [High,Confirmed] https://launchpad.net/bugs/347649 [05:54] it was consistently slower - 08. vs 04 or something like that [05:54] as they will have to basically undo this patch to fix it [05:55] on the other hand I don't want to block performance improvements [05:55] lifeless: I did look at trying to remove the file_across_trees bit but ... [05:55] it broke the test suite cos ... [05:55] do you have any suggestion about how we can do both things? [05:55] we trap for bogus include paths [05:56] and iter_changes doesn't see those [05:56] file_across_trees is a problem because it upcassts the dirstate to an inventory - its spectcularly slow [05:56] emacs is what 20K files? [05:57] just checking, we're talking about the _set_specific_file_ids() method yes? [05:57] yes [05:57] emacs is 8K from memory [05:57] 100K revisions but ... [05:57] that doesn't matter myuch here [05:57] ok, so 16K inventory entries [05:58] I don't feel good about this code [05:58] so I'm going to recuse my self as a review at this point; I don't want to block you, and I haven't managed to open your eyes to why the layering is a problem or matters so much [05:59] I'll be effectively offline for 2 weeks, and I don't like the idea of you being blocked for that long. [05:59] I see and agree with the desire for one iter_changes call covering ... [05:59] legal filename checking, strict checking and collecting results [06:00] but I don't see it being necessary to get there in a single step [06:01] I bet you cold cache specific file commits will be way slower with your patch [06:01] particularly on the large trees I've been working up to - 50K and 100K files [06:02] slower than now or slower than possible? [06:02] slower than now [06:02] I could be wrong [06:03] but what you trade off is some unoptimised code (CHKRepository.add_inventory) for some optimised code that does a lot of IO (WT.iter_changes of everything) [06:04] I'll throw together the OOo tree and benchmark on it [06:05] cold cache will be key to see the disk IO impact [06:05] I can suggest a completely different approach if you just want to make it faster in the interim [06:05] lifeless: design wise, I have a question ... [06:05] if we delegate specific_file prcoessing to iter_changes ... [06:05] (an approach I wouldn't feel unhappy about) [06:06] how we we accurately insert the parents after the fact? [06:06] s/we/can/ [06:06] we don't have all the info? [06:06] igc: iter_changes is allowed to jump around [06:06] igc: it already does this for renames [06:07] iter_changes has built into it the logic of find_ids_across_trees [06:07] anyway [06:07] if you want something easy [06:07] add a parameter to finish_inventory called 'basis_inventory' [06:07] and if use_record_iter_changes is False in commit [06:07] pass self.basis_inventory to finish_inventory [06:08] and in finish_inventory do: [06:08] if self.repository._format._commit_inv_deltas [06:08] delta = self.new_inventory._make_delta(basis_inventory) [06:09] self.repository.add_inventory_by_delta(basis_inventory, basis_inventory.revision_id) [06:09] ^ [06:09] this will work around finish_inventory being overly slow in CHK repositories when not using record_iter_changes [06:10] and as you'll already have a basis_inventory it should be nigh free [06:11] lifeless: ok, I'll play with that next week and try it on some larger data sets [06:12] igc: I would expect that to be ~= to what you have today, and deal with cold cache and other situations much better [06:12] no where near as fast as fixing iter_changes [06:12] I would expect a fixed iter_changes to smoke everything [06:14] as for what to do in iter_changes to handle parent dirs [06:14] I would keep a minimal set of directory items output [06:14] and a 'we need a parent of X' queue [06:14] morning lifeless [06:14] at the end of the normal loop, if there 'we need a parent of X' is non-empty [06:15] we do the normal loop on just the missing parents [06:15] without recursion [06:15] hi mtaylor [06:15] 25 minutes to branch samba with bzr [06:15] 16 with git :( [06:15] I think the difference is entirely size [06:16] as both saturated my link [06:16] lifeless: I had to use hg ove the past few days for something - hated every second [06:16] mtaylor: :) [06:16] lifeless: right, and it's the lack of recursion support that makes it hard to tack these on now [06:17] lifeless: btw, there is a genuine use case for filter_iter_changes_by_paths() beyond commit: post processing the output from Inventory.iter_changes() [06:18] and anything else that looks the same but doesn't take the specific_files parameter [06:18] igc: Sure, I wouldn't have suggested a generic function if I didn't think it could be useful generically ;) [06:18] igc: that said, I think Inventory.iter_changes should take specific_files :) [06:19] with chk_maps, I'm pretty sure we get the lot and post-filter much like this [06:20] lifeless: anyhow, thanks for the feedback & have fun at uds/allhands [06:20] I'd like to have a toolkit of iter_changes iterator filters [06:20] quite separately from making commit awesome [06:21] lifeless: I was thinking along those lines too [06:21] but the only way to avoid excess IO is for iter_changes to know that it should skip over things [06:21] which the sepecific + exclude params are needed or [06:21] *for* [06:23] when dirstate.iter_changes() supports exclude as a parameter, I'll be far more interested :-) [06:24] I'd like it if someone other than John and I did that [06:24] we've got a bunch of talented people [06:24] we do [06:25] and it's a talent knowing which bits of code to leave to the experts :-) :-) [06:25] * lifeless snorts [06:25] * lifeless looks around for that beaker of expert-juice [06:25] I've read the dirstate code multiple times and it still makes my head spin :-( [06:25] the C version is a lot clearer [06:26] we got to use functions [06:26] they help ;) [06:26] yes :-) [06:26] If you want to poke at iterchanges a bit and send mail asking for clarification please do [06:26] it will be an asset to have you understand it [06:28] though, does our medical cover self inflicted insanity? [06:34] igc: I have another hidden motivation [06:34] I want to make the commit code radically simpler [06:34] lifeless: I'm all for that [06:34] by having it be _just_ policy on top of iter_changes + CommitBuilder [06:35] policy+ui [06:35] though it's pretty good but one particular bit now [06:35] and that bit is around the pointless-commit checking [06:35] yes [06:35] I think some of check_pointless() ought to be pushed down into builder.any_changes() [06:36] yes, or removed [06:36] uhm [06:36] any_changes is kindof pure [06:36] I don't think it should be saying 'no' if there are changes [06:37] also [06:38] check_pointless should also catch pointless merge commits [06:38] if you know what I mean [06:39] that "initial commit is just a root directory" stuff seems to look way too much into the builder for my liking (was my point) [06:40] anyhow, back to other stuff [06:40] sure [06:40] I agree [07:31] hi all [07:32] hi [07:40] lifeless: how go the talks? [07:53] good [07:53] gc one nailed I think [07:53] bvg one nearly full-draft [08:29] is there an algorithm that given a bzr revision number will provide the revision number of the parent (leftmost parent in case of merge changeset) ? [08:29] beuno or mwhudson: ping [08:29] ie. N -> (N-1), but what about composite revision numbers? [08:30] knielsen: X.Y.Z->X.Y.(Z-1) forall Z > 0 [08:30] knielsen: X-1 for all X.Y.Z, Z=0 [08:30] If I remember correctly ;) [08:30] Sounds like an XY problem question, though. [08:31] * lifeless looks around for the muzzle [08:32] I told you, wait 'till she leaves town. [08:32] :P [08:32] lifeless: hm, thanks, but doesn't that sound too simplistic? [08:32] * knielsen thinking [08:32] knielsen: if you want it to be complex, I can come up with some extra stuff [08:33] X.Y.Z->X.Y.(Z-1) forall Z > 1 X-1 otherwise (we don't have Z=0 AFAIK) [08:33] Hi all! [08:33] is there an admin? [08:34] knielsen: but relying on revnos is fragile, why don't you just access the revision map and take the first parent / [08:34] s!/!?! [08:34] I hate time zones. [08:34] * vila talking perl again :( [08:34] vila: yeah, just wondering [08:34] Whoever invented time zones had no respect for programmers. :( [08:35] Peng: go to North Pole and turn around if you don't like the current TZ [08:35] vila: I prefer revid:'s myself, but most of the world seems to be using revision numbers without considering that they can change at each merge [08:35] please guys respond me! [08:35] Youssef: I admin things, but probably not what you're interested in. [08:36] lol [08:36] okauy [08:36] yesterday i asked what is the difference between [08:36] create a checkout and make a local copy of the branch [08:36] knielsen: there are not supposed to change in a given branch, not even a trunk one where other branches are merged into if you use append_revisions_only [08:37] Time zones are an artifact of diurnal slavery. Liberate thyself! [08:38] vila: well, if two people branch from revision N, and each commit revision N+1, then at least one of the commits will change the revision number when you merge ;-) [08:38] vila: you're wrong ;) [08:38] vila: the parent of the first commit on a branch is a mainline rev [08:38] Peng_: [08:38] ??? [08:38] fullermd: I did, but the rest of the planet hasn't followed along, so I still have to deal with it. [08:38] Youssef: Probably the difference between "bzr checkout' and "bzr branch". See ToirtoiseBZR's docs and "bzr help". [08:39] Peng_: Their fault then. Apply beatings until behavior is modified. Making bail is left as an exercise for the reader. [08:40] Mmhhhh... okay thanks [08:40] fullermd: I can't beat up everyone. [08:40] knielsen: not inside a given branch, on trunk the first to push will even keep the same revno as his local branch [08:40] Wait, I only have to beat up all Bazaar users. That's significantly easier, but still impractical. [08:41] lifeless: wrong about Z=1 or about revno stability ? [08:42] vila: Z=1 [08:42] vila: didn't know about append_revisions_only, want to check that ... but what I mean is if I eg. branch from an old revision of lauchpad directory, commit locally, merge tip of the launchpad branch, and finally push the result to the launchpad branch, all intervening revision numbers will change [08:42] right? [08:42] knielsen: yes [08:43] knielsen: yes [08:43] knielsen: this is used to control presentation of history [08:44] knielsen: either your manage history presentation from trunk or you force your local history upon others [08:44] the later doesn't scale very well [08:45] well, actually I prefer to always use revid: when sending revision references to others (or tags of course) ... [08:45] but I don't understand what you mean with "manage history presentation from trunk" ? [08:45] sounds like there is some documentation somewhere that I would like to read to learn about this ;-) [08:46] knielsen: you mean you're voluntering to write it ? Great ! :-) [08:47] lifeless: right, just did a simple example of multiple branching/merging, and I got 1.1.2 as the parent of 1.2.1, so the issue _is_ a bit more complex (as it must necessarily be) [08:47] vila: I might actually, but I will have to learn it first ;-) [08:47] knielsen: the left-hand side history for a given branch is shown by 'bzr log -n1' [08:47] probably I will check into the source code [08:48] i.e. you get the commit messages for the commits done on that branch only, not the commit messages for the merged revisions [08:49] managing history presentation from trunk then means that you chose proper commit messages when merging and generally do only commits for merges in trunk [08:50] *but* if you push on trunk, you end up with series of commits for each feature or bugfixes, not a synthetic view, but a detailed one [08:51] vila: yes. Exactly [08:51] it's a highly subjective matter [08:52] vila: well, the underlying problem is an automatic tool that monitors a public branch for changes, and eg. builds and tests each new revision, or does some other action [08:53] vila: and often I see the tools or people providing notifications in the form of the revision number of the new revision [08:53] knielsen: we call that a gatekeeper [08:53] knielsen: huh? [08:53] 1.2.1 descending from 1.1.2 ? [08:54] oh, its the newer form, the original had the drop-2 items property [08:54] vila: but the revision number is actually not suitable for this in the general case. Just knowing the revision number does not allow you to do anything really reliably, as when you look at the branch that revision number may rever so something else entirely [08:54] vila: so the solution is to use revision id's, of course... [08:55] knielsen: long lived branches often set the append only flag [08:55] which means the revnos are stable [08:55] lifeless: yes, I want to check up on that flag, wasn't aware of it. sounds useful [08:55] bzr help configuration, I believe [08:55] I guess I will look into the source to learn more at some point [08:56] To be precise, it's not so much that the flag keeps the revnos stable, as that it prevents you from doing the things that make them change. [08:57] fullermd: right [08:58] lifeless, vila: anyway, thanks a lot for you comments, quite useful [09:19] * igc dinner === fta_ is now known as fta [11:15] jelmer: I have a couple questions about bzr-git [11:15] 1) does it can work with github? at least for branch/pull [11:15] 2) why you has marked it as incompatible with Windows? [11:27] bialix: it works with github [11:28] bialix: it's not been tested on Windows yet, and I'm aware of some places where we should be converting / to \ [11:33] jelmer: re Dulwich: does C-extensions (_object.c and _pack.c) is used now? [11:33] bialix: they're optional [11:34] bialix: patches to fix the windows issues are very much welcome btw [11:34] I've fixed setup.py to compile them, but _pack.c cannot be compiled with MSVC right now (MSVC lacks stdint.h) [11:34] jelmer: I have interest in bzr-git [11:34] bialix: you can steal the stdint.h replacement from bzr-svn [11:34] perhaps I need to work with some github projects, so [11:35] ok, I'll look to bzr-svn then [11:36] jelmer: how you prefer to get patches: by mail or via LP merge requests? [11:36] bialix: by email [11:36] ok [11:49] lifeless: Did you speak to me earlier? I have an alert but my scrollback doesn't contain it [11:51] lifeless: I either had an obscure bug or suffered from an MD5 collision in my packs... I think the bug is far more likely [11:55] awilkins: bug, windows specific [11:55] fail during inserting a pack [11:55] then do the same pull again [11:55] fail the second time because we can't rename over the file [11:55] lifeless: Aha, yes, I got that [11:56] can you file a bug:) [11:56] Definitely, I was watching with a FS traceer [11:56] I think the fail may either have been a permissions thing or a result of that jailbreak bug [11:56] Although it recurred after I fixed the jailbreak, move the repo, made a new one, and pushed all the branches into it [11:57] 'twas always a particular pack, I recognised the MD5 each time [11:57] yes [11:57] odd to have it happen again >< [11:58] reproducible? [11:58] [and have you filed a bug for the rename handling of it on windows? :)] [11:58] Gimme a chance... [11:59] :P [12:00] I saw it write the pack and then write it again in the same session [12:00] oh? depends on what you mean by that [12:00] older clients write to packs by doing append many times [12:00] I still have the nagging thought that it could have been an MD5 collision but that would be rather silly [12:01] This was a 14.1 client writing to a 14.1 server over HTTP HPSS [12:01] so that does a single post [12:01]