| AfC | lifeless: where did you upload your GPG key? It's still not on any of the public keyservers. | 00:26 |
|---|---|---|
| lifeless | subkeys | 00:27 |
| igc | morning | 00:35 |
| lifeless | hi | 00:36 |
| mwhudson | hi igc, lifeless, AfC | 00:36 |
| igc | hi guys | 00:39 |
| distatica | 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 |
| distatica | I'm a bzr / programming newbie, for what it's worth. | 00:43 |
| lifeless | distatica: the easiest thing is just to undo the changes you don't want | 00:45 |
| lifeless | and commit | 00:45 |
| distatica | you mean manually? Just go in and remove those and then make a new commit? | 00:45 |
| distatica | Or do you mean there's a way to undo a revision? | 00:45 |
| lifeless | you can undo a revision | 00:46 |
| lifeless | but as you're new to bzr I suggest not doing that until you've got some more experience | 00:46 |
| distatica | ok | 00:46 |
| lifeless | just edit your files and make them the way you want, and do a commit | 00:46 |
| === KX is now known as KX|360 | ||
| distatica | could I make the last commit a patch, revert back and apply that patch? Or am I just getting too complicated? | 00:47 |
| distatica | 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:47 |
| lifeless | so | 00:48 |
| lifeless | if you've shared the branch with someone you can't really ever delete the fact that you /did X/ | 00:49 |
| lifeless | think of bzr as a journal | 00:49 |
| distatica | ok | 00:49 |
| lifeless | once shared with people they have the journal | 00:49 |
| lifeless | you can't erase from their copy | 00:49 |
| lifeless | if you haven't shared it with people you can rip the most recent page in your journal out | 00:49 |
| lifeless | and then write on a new page | 00:49 |
| lifeless | the way you'd pop two commits off is: | 00:50 |
| lifeless | bzr uncommit | 00:50 |
| lifeless | bzr shelve --all | 00:50 |
| lifeless | bzr uncommit | 00:50 |
| lifeless | bzr shelve --all | 00:50 |
| lifeless | now, bzr unshelve | 00:50 |
| distatica | so, if I make 3 commits, revert back 1, and then share the repo, the log will only show 2 commits? | 00:50 |
| distatica | ok | 00:50 |
| lifeless | will put the most recent shelved changes up ready for editing | 00:50 |
| lifeless | yes, though 'revert' doesn't affect the journal at all; 'bzr uncommit' does | 00:51 |
| distatica | oh I see | 00:51 |
| lifeless | (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 |
| distatica | 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 |
| lifeless | anyhow, at this point in my example, you'd change things so they are you want, the commit | 00:51 |
| lifeless | bzr unshelve | 00:52 |
| lifeless | and bzr commit again | 00:52 |
| distatica | ok | 00:52 |
| lifeless | and you're back nearly-where-you-started but with the commit 2 back changed | 00:52 |
| lifeless | so back to the journal analogy | 00:52 |
| lifeless | if someone has been reading your journal | 00:52 |
| lifeless | its not pointless ;) | 00:52 |
| lifeless | if they haven't, if its private notes, then its fine to just change your mind | 00:52 |
| distatica | 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:53 |
| lifeless | the key thing is sharing | 00:54 |
| distatica | yeah, once it's gone then it's stone. | 00:54 |
| lifeless | once you've done that its more tricky :) | 00:54 |
| distatica | great, thank you. | 00:59 |
| igc | lifeless: does that mean that stacked branches are implicitly standalone? | 01:11 |
| lifeless | igc: not sure what you mean by that | 01:14 |
| igc | lifeless: when you said "we explicitly don't stack in shared repos" | 01:14 |
| igc | what did you mean exactly? | 01:14 |
| lifeless | so | 01:14 |
| lifeless | in principle a branch can be stacked, while in a shared repo | 01:15 |
| lifeless | but our ui code says 'oh, you have a shared repo, we won't stack' | 01:15 |
| lifeless | so it should be unusual, but its not impossible, to encounter a stacked branch in a shared repo | 01:15 |
| lifeless | I think we'll probably make it very common when we overhaul how we manage branches | 01:15 |
| igc | ok | 01:15 |
| lifeless | but thats a different discussion | 01:16 |
| igc | right | 01:16 |
| igc | lifeless: on another topic, that commit file patch has been reworked as we discussed | 01:21 |
| igc | I know you're really busy ... | 01:21 |
| lifeless | thanks | 01:21 |
| igc | but if you're happy with it, I'll land it fro 1.15 today | 01:21 |
| lifeless | I appreciate the ping | 01:22 |
| lifeless | my day is: | 01:22 |
| lifeless | 1) slides, deadline is today | 01:22 |
| lifeless | 2) final prep for trip | 01:22 |
| lifeless | 3) all other stuff | 01:23 |
| AfC | lifeless: ah, there it is now. | 01:25 |
| AfC | mwhudson: morning :) | 01:25 |
| jml | poolie: you know how you say you use the register-branch API -- how exactly do you authenticate with that? | 01:29 |
| jml | bzr alias snt="snt" | 01:39 |
| * jml corrects the typo and tweetoblags. | 01:40 | |
| poolie | jml: i think it uses https auth | 01:48 |
| poolie | hello all | 01:49 |
| poolie | i'm basically getting ready to go and doing slides today | 01:49 |
| poolie | lifeless: i approved your patch as you probably saw | 01:49 |
| jml | poolie: yes. | 01:49 |
| jml | poolie: and it prompts you for your Launchpad password? | 01:49 |
| poolie | i think so | 01:50 |
| poolie | it's so 2006 :) | 01:50 |
| poolie | also, saying "it's so x" is so 2006 :) | 01:50 |
| lifeless | poolie: I landed it as you may have seen :) | 01:50 |
| jml | poolie: I'm actually waiting for a revival of "c'mon, it's the nineties!" | 01:51 |
| jml | poolie: I may be waiting a while. | 01:51 |
| spm | jml: so long as we skip the 80's revival. there are some places that should be left in the past. | 02:05 |
| lifeless | spm: when doves fly | 02:22 |
| spm | lifeless: ha! 'twas more the vison of the 80's "BIG" hair and warrick kapper style shorts that terrifies | 02:23 |
| jml | lifeless: also when they cry. | 02:23 |
| lifeless | it a myth | 02:25 |
| bob2 | shudder | 02:34 |
| fullermd | jelmer: ping | 03:06 |
| jelmer | fullermd: pong | 03:12 |
| fullermd | Is there some reason you chose malloc.h rather than just using stdlib.h in the pyrex rio stuff? | 03:13 |
| lifeless | igc: ping | 03:17 |
| lifeless | igc: I didn't see a new merge request for that branch; did you simply push up changes? | 03:17 |
| igc | lifeless: I did push the changes and ... | 03:27 |
| igc | I tried to tell lp that it needs a new review | 03:27 |
| igc | but the latter didn't seem to do much :-( | 03:27 |
| lifeless | I've filed a bug | 03:27 |
| lifeless | one thing I've seen already | 03:28 |
| lifeless | the def check inner function | 03:28 |
| lifeless | thats very opaque style | 03:28 |
| lifeless | it would be clearer to either just do self.assertEqual(x, ...) 3 times | 03:28 |
| igc | I just copied what was there from memory | 03:29 |
| lifeless | I realise this is kindof trivial, but we had 100 line tests that looked like that once | 03:29 |
| lifeless | and it was fugly | 03:29 |
| fullermd | 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:34 |
| jelmer | fullermd: I've sent a merge req | 03:37 |
| fullermd | Rox. jelmer++ | 03:40 |
| * jelmer longs back to the days when statements had to be terminated with semicolons and malloc lived in malloc.h | 03:41 | |
| fullermd | 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:47 |
| lifeless | igc: ok reviewed | 03:54 |
| igc | lifeless: thanks | 03:54 |
| lifeless | igc: I'mvery glad you factored it out, because now I'm sure there was something really wrong earlier ;) | 03:55 |
| lifeless | igc: and yes, I've just checked your older code | 03:56 |
| lifeless | so the problem is, you don't actually force include missing parents | 03:57 |
| lifeless | they aren't being generated from iter_changes | 03:57 |
| lifeless | so you'll have to iter_changes the *entire tree* if the user uses specific files | 03:57 |
| lifeless | igc: If you want to chat about this, I'm happy to do so | 04:00 |
| igc | lifeless: thanks. I'll take a look soon | 04:00 |
| lifeless | igc: I'm going to nose down on presentations | 04:06 |
| lifeless | igc: you may need to ring me :P | 04:06 |
| igc | ok | 04:06 |
| * igc lunch | 04:58 | |
| lifeless | so the good news is we saturate my link very happily branching bbc over the smart server | 05:34 |
| lifeless | igc: did my review make sense? | 05:39 |
| igc | lifeless: just got back from lunch - I'll take a look now | 05:40 |
| igc | lifeless: so, I might be stupid but I still don't see the problem ... | 05:46 |
| lifeless | ok | 05:46 |
| igc | iter_changes only needs to return changed parents, not all of them | 05:46 |
| lifeless | right, but unless its looking at parents it won't return them, because iter_changes has a bug | 05:46 |
| igc | i.e. if a parent isn't in iter_changes, then it isn't needed in apply_delta IIUIC | 05:46 |
| igc | lifeless: but it *is* looking at parent right now | 05:47 |
| lifeless | how? | 05:47 |
| igc | it looks at the whole tree, then post-filters | 05:47 |
| lifeless | ow | 05:48 |
| lifeless | I'm really torn | 05:48 |
| igc | nad osutils.parent_directories doesn't need to return the root | 05:48 |
| igc | at the os level, '' doesn't make sense | 05:48 |
| lifeless | well, other code would be cleaner if it does - as you are making sure you have [''] always | 05:48 |
| igc | also, my change to when record_titer_changes was deliberate ... | 05:49 |
| igc | and the comment still hold exactly as is btw | 05:49 |
| igc | I benchmarked to decide when it was the right thing fwiw | 05:49 |
| lifeless | why the (len(self.parents) < 2 and not self.specific_files and not self.exclude) | 05:51 |
| lifeless | clause? | 05:51 |
| igc | because for non-chk formats, ... | 05:51 |
| igc | it's slower than the current code otherwise | 05:52 |
| igc | at least on Emacs | 05:52 |
| igc | I'm happy to extend the comment along those lines | 05:53 |
| lifeless | 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:53 |
| lifeless | and that its only faster with record_iter_changes on chk repositoreis because the chk code is able to compensate | 05:54 |
| lifeless | I appreciate that you've got it going faster | 05:54 |
| igc | yes, according to my measurements | 05:54 |
| lifeless | 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 |
| ubottu | Launchpad bug 347649 in bzr "iter_changes missing support needed for commit" [High,Confirmed] https://launchpad.net/bugs/347649 | 05:54 |
| igc | it was consistently slower - 08. vs 04 or something like that | 05:54 |
| lifeless | as they will have to basically undo this patch to fix it | 05:54 |
| lifeless | on the other hand I don't want to block performance improvements | 05:55 |
| igc | lifeless: I did look at trying to remove the file_across_trees bit but ... | 05:55 |
| igc | it broke the test suite cos ... | 05:55 |
| lifeless | do you have any suggestion about how we can do both things? | 05:55 |
| igc | we trap for bogus include paths | 05:55 |
| igc | and iter_changes doesn't see those | 05:56 |
| lifeless | file_across_trees is a problem because it upcassts the dirstate to an inventory - its spectcularly slow | 05:56 |
| lifeless | emacs is what 20K files? | 05:56 |
| igc | just checking, we're talking about the _set_specific_file_ids() method yes? | 05:57 |
| lifeless | yes | 05:57 |
| igc | emacs is 8K from memory | 05:57 |
| igc | 100K revisions but ... | 05:57 |
| igc | that doesn't matter myuch here | 05:57 |
| lifeless | ok, so 16K inventory entries | 05:57 |
| lifeless | I don't feel good about this code | 05:58 |
| lifeless | 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:58 |
| lifeless | I'll be effectively offline for 2 weeks, and I don't like the idea of you being blocked for that long. | 05:59 |
| igc | I see and agree with the desire for one iter_changes call covering ... | 05:59 |
| igc | legal filename checking, strict checking and collecting results | 05:59 |
| igc | but I don't see it being necessary to get there in a single step | 06:00 |
| lifeless | I bet you cold cache specific file commits will be way slower with your patch | 06:01 |
| lifeless | particularly on the large trees I've been working up to - 50K and 100K files | 06:01 |
| igc | slower than now or slower than possible? | 06:02 |
| lifeless | slower than now | 06:02 |
| lifeless | I could be wrong | 06:02 |
| lifeless | 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:03 |
| igc | I'll throw together the OOo tree and benchmark on it | 06:04 |
| lifeless | cold cache will be key to see the disk IO impact | 06:05 |
| lifeless | I can suggest a completely different approach if you just want to make it faster in the interim | 06:05 |
| igc | lifeless: design wise, I have a question ... | 06:05 |
| igc | if we delegate specific_file prcoessing to iter_changes ... | 06:05 |
| lifeless | (an approach I wouldn't feel unhappy about) | 06:05 |
| igc | how we we accurately insert the parents after the fact? | 06:06 |
| igc | s/we/can/ | 06:06 |
| igc | we don't have all the info? | 06:06 |
| lifeless | igc: iter_changes is allowed to jump around | 06:06 |
| lifeless | igc: it already does this for renames | 06:06 |
| lifeless | iter_changes has built into it the logic of find_ids_across_trees | 06:07 |
| lifeless | anyway | 06:07 |
| lifeless | if you want something easy | 06:07 |
| lifeless | add a parameter to finish_inventory called 'basis_inventory' | 06:07 |
| lifeless | and if use_record_iter_changes is False in commit | 06:07 |
| lifeless | pass self.basis_inventory to finish_inventory | 06:07 |
| lifeless | and in finish_inventory do: | 06:08 |
| lifeless | if self.repository._format._commit_inv_deltas | 06:08 |
| lifeless | delta = self.new_inventory._make_delta(basis_inventory) | 06:08 |
| lifeless | self.repository.add_inventory_by_delta(basis_inventory, basis_inventory.revision_id) | 06:09 |
| lifeless | ^ | 06:09 |
| lifeless | this will work around finish_inventory being overly slow in CHK repositories when not using record_iter_changes | 06:09 |
| lifeless | and as you'll already have a basis_inventory it should be nigh free | 06:10 |
| igc | lifeless: ok, I'll play with that next week and try it on some larger data sets | 06:11 |
| lifeless | igc: I would expect that to be ~= to what you have today, and deal with cold cache and other situations much better | 06:12 |
| lifeless | no where near as fast as fixing iter_changes | 06:12 |
| lifeless | I would expect a fixed iter_changes to smoke everything | 06:12 |
| lifeless | as for what to do in iter_changes to handle parent dirs | 06:14 |
| lifeless | I would keep a minimal set of directory items output | 06:14 |
| lifeless | and a 'we need a parent of X' queue | 06:14 |
| mtaylor | morning lifeless | 06:14 |
| lifeless | at the end of the normal loop, if there 'we need a parent of X' is non-empty | 06:14 |
| lifeless | we do the normal loop on just the missing parents | 06:15 |
| lifeless | without recursion | 06:15 |
| lifeless | hi mtaylor | 06:15 |
| lifeless | 25 minutes to branch samba with bzr | 06:15 |
| lifeless | 16 with git :( | 06:15 |
| lifeless | I think the difference is entirely size | 06:15 |
| lifeless | as both saturated my link | 06:16 |
| mtaylor | lifeless: I had to use hg ove the past few days for something - hated every second | 06:16 |
| lifeless | mtaylor: :) | 06:16 |
| igc | lifeless: right, and it's the lack of recursion support that makes it hard to tack these on now | 06:16 |
| igc | 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:17 |
| igc | and anything else that looks the same but doesn't take the specific_files parameter | 06:18 |
| lifeless | igc: Sure, I wouldn't have suggested a generic function if I didn't think it could be useful generically ;) | 06:18 |
| lifeless | igc: that said, I think Inventory.iter_changes should take specific_files :) | 06:18 |
| igc | with chk_maps, I'm pretty sure we get the lot and post-filter much like this | 06:19 |
| igc | lifeless: anyhow, thanks for the feedback & have fun at uds/allhands | 06:20 |
| lifeless | I'd like to have a toolkit of iter_changes iterator filters | 06:20 |
| lifeless | quite separately from making commit awesome | 06:20 |
| igc | lifeless: I was thinking along those lines too | 06:21 |
| lifeless | but the only way to avoid excess IO is for iter_changes to know that it should skip over things | 06:21 |
| lifeless | which the sepecific + exclude params are needed or | 06:21 |
| lifeless | *for* | 06:21 |
| igc | when dirstate.iter_changes() supports exclude as a parameter, I'll be far more interested :-) | 06:23 |
| lifeless | I'd like it if someone other than John and I did that | 06:24 |
| lifeless | we've got a bunch of talented people | 06:24 |
| igc | we do | 06:24 |
| igc | 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 | |
| igc | I've read the dirstate code multiple times and it still makes my head spin :-( | 06:25 |
| lifeless | the C version is a lot clearer | 06:25 |
| lifeless | we got to use functions | 06:26 |
| lifeless | they help ;) | 06:26 |
| igc | yes :-) | 06:26 |
| lifeless | If you want to poke at iterchanges a bit and send mail asking for clarification please do | 06:26 |
| lifeless | it will be an asset to have you understand it | 06:26 |
| lifeless | though, does our medical cover self inflicted insanity? | 06:28 |
| lifeless | igc: I have another hidden motivation | 06:34 |
| lifeless | I want to make the commit code radically simpler | 06:34 |
| igc | lifeless: I'm all for that | 06:34 |
| lifeless | by having it be _just_ policy on top of iter_changes + CommitBuilder | 06:34 |
| lifeless | policy+ui | 06:35 |
| igc | though it's pretty good but one particular bit now | 06:35 |
| igc | and that bit is around the pointless-commit checking | 06:35 |
| lifeless | yes | 06:35 |
| igc | I think some of check_pointless() ought to be pushed down into builder.any_changes() | 06:35 |
| lifeless | yes, or removed | 06:36 |
| lifeless | uhm | 06:36 |
| lifeless | any_changes is kindof pure | 06:36 |
| lifeless | I don't think it should be saying 'no' if there are changes | 06:36 |
| lifeless | also | 06:37 |
| lifeless | check_pointless should also catch pointless merge commits | 06:38 |
| lifeless | if you know what I mean | 06:38 |
| igc | 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:39 |
| igc | anyhow, back to other stuff | 06:40 |
| lifeless | sure | 06:40 |
| lifeless | I agree | 06:40 |
| vila | hi all | 07:31 |
| lifeless | hi | 07:32 |
| jml | lifeless: how go the talks? | 07:40 |
| lifeless | good | 07:53 |
| lifeless | gc one nailed I think | 07:53 |
| lifeless | bvg one nearly full-draft | 07:53 |
| knielsen | 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 |
| Peng_ | beuno or mwhudson: ping | 08:29 |
| knielsen | ie. N -> (N-1), but what about composite revision numbers? | 08:29 |
| lifeless | knielsen: X.Y.Z->X.Y.(Z-1) forall Z > 0 | 08:30 |
| lifeless | knielsen: X-1 for all X.Y.Z, Z=0 | 08:30 |
| lifeless | If I remember correctly ;) | 08:30 |
| fullermd | Sounds like an XY problem question, though. | 08:30 |
| * lifeless looks around for the muzzle | 08:31 | |
| fullermd | I told you, wait 'till she leaves town. | 08:32 |
| lifeless | :P | 08:32 |
| knielsen | lifeless: hm, thanks, but doesn't that sound too simplistic? | 08:32 |
| * knielsen thinking | 08:32 | |
| lifeless | knielsen: if you want it to be complex, I can come up with some extra stuff | 08:32 |
| vila | X.Y.Z->X.Y.(Z-1) forall Z > 1 X-1 otherwise (we don't have Z=0 AFAIK) | 08:33 |
| Youssef | Hi all! | 08:33 |
| Youssef | is there an admin? | 08:33 |
| vila | knielsen: but relying on revnos is fragile, why don't you just access the revision map and take the first parent / | 08:34 |
| vila | s!/!?! | 08:34 |
| Peng_ | I hate time zones. | 08:34 |
| * vila talking perl again :( | 08:34 | |
| knielsen | vila: yeah, just wondering | 08:34 |
| Peng_ | Whoever invented time zones had no respect for programmers. :( | 08:34 |
| vila | Peng: go to North Pole and turn around if you don't like the current TZ | 08:35 |
| knielsen | 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 |
| Youssef | please guys respond me! | 08:35 |
| Peng_ | Youssef: I admin things, but probably not what you're interested in. | 08:35 |
| Youssef | lol | 08:36 |
| Youssef | okauy | 08:36 |
| Youssef | yesterday i asked what is the difference between | 08:36 |
| Youssef | create a checkout and make a local copy of the branch | 08:36 |
| vila | 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:36 |
| fullermd | Time zones are an artifact of diurnal slavery. Liberate thyself! | 08:37 |
| knielsen | 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 |
| lifeless | vila: you're wrong ;) | 08:38 |
| lifeless | vila: the parent of the first commit on a branch is a mainline rev | 08:38 |
| Youssef | Peng_: | 08:38 |
| Youssef | ??? | 08:38 |
| Peng_ | fullermd: I did, but the rest of the planet hasn't followed along, so I still have to deal with it. | 08:38 |
| Peng_ | Youssef: Probably the difference between "bzr checkout' and "bzr branch". See ToirtoiseBZR's docs and "bzr help". | 08:38 |
| fullermd | Peng_: Their fault then. Apply beatings until behavior is modified. Making bail is left as an exercise for the reader. | 08:39 |
| Youssef | Mmhhhh... okay thanks | 08:40 |
| Peng_ | fullermd: I can't beat up everyone. | 08:40 |
| vila | knielsen: not inside a given branch, on trunk the first to push will even keep the same revno as his local branch | 08:40 |
| Peng_ | Wait, I only have to beat up all Bazaar users. That's significantly easier, but still impractical. | 08:40 |
| vila | lifeless: wrong about Z=1 or about revno stability ? | 08:41 |
| lifeless | vila: Z=1 | 08:42 |
| knielsen | 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 |
| knielsen | right? | 08:42 |
| lifeless | knielsen: yes | 08:42 |
| vila | knielsen: yes | 08:43 |
| lifeless | knielsen: this is used to control presentation of history | 08:43 |
| vila | knielsen: either your manage history presentation from trunk or you force your local history upon others | 08:44 |
| vila | the later doesn't scale very well | 08:44 |
| knielsen | well, actually I prefer to always use revid: when sending revision references to others (or tags of course) ... | 08:45 |
| knielsen | but I don't understand what you mean with "manage history presentation from trunk" ? | 08:45 |
| knielsen | sounds like there is some documentation somewhere that I would like to read to learn about this ;-) | 08:45 |
| vila | knielsen: you mean you're voluntering to write it ? Great ! :-) | 08:46 |
| knielsen | 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 |
| knielsen | vila: I might actually, but I will have to learn it first ;-) | 08:47 |
| vila | knielsen: the left-hand side history for a given branch is shown by 'bzr log -n1' | 08:47 |
| knielsen | probably I will check into the source code | 08:47 |
| vila | i.e. you get the commit messages for the commits done on that branch only, not the commit messages for the merged revisions | 08:48 |
| vila | 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:49 |
| vila | *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:50 |
| knielsen | vila: yes. Exactly | 08:51 |
| vila | it's a highly subjective matter | 08:51 |
| knielsen | 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:52 |
| knielsen | vila: and often I see the tools or people providing notifications in the form of the revision number of the new revision | 08:53 |
| vila | knielsen: we call that a gatekeeper | 08:53 |
| lifeless | knielsen: huh? | 08:53 |
| lifeless | 1.2.1 descending from 1.1.2 ? | 08:53 |
| lifeless | oh, its the newer form, the original had the drop-2 items property | 08:54 |
| knielsen | 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 |
| knielsen | vila: so the solution is to use revision id's, of course... | 08:54 |
| lifeless | knielsen: long lived branches often set the append only flag | 08:55 |
| lifeless | which means the revnos are stable | 08:55 |
| knielsen | lifeless: yes, I want to check up on that flag, wasn't aware of it. sounds useful | 08:55 |
| lifeless | bzr help configuration, I believe | 08:55 |
| knielsen | I guess I will look into the source to learn more at some point | 08:55 |
| fullermd | 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:56 |
| vila | fullermd: right | 08:57 |
| knielsen | lifeless, vila: anyway, thanks a lot for you comments, quite useful | 08:58 |
| * igc dinner | 09:19 | |
| === fta_ is now known as fta | ||
| bialix | jelmer: I have a couple questions about bzr-git | 11:15 |
| bialix | 1) does it can work with github? at least for branch/pull | 11:15 |
| bialix | 2) why you has marked it as incompatible with Windows? | 11:15 |
| jelmer | bialix: it works with github | 11:27 |
| jelmer | bialix: it's not been tested on Windows yet, and I'm aware of some places where we should be converting / to \ | 11:28 |
| bialix | jelmer: re Dulwich: does C-extensions (_object.c and _pack.c) is used now? | 11:33 |
| jelmer | bialix: they're optional | 11:33 |
| jelmer | bialix: patches to fix the windows issues are very much welcome btw | 11:34 |
| bialix | I've fixed setup.py to compile them, but _pack.c cannot be compiled with MSVC right now (MSVC lacks stdint.h) | 11:34 |
| bialix | jelmer: I have interest in bzr-git | 11:34 |
| jelmer | bialix: you can steal the stdint.h replacement from bzr-svn | 11:34 |
| bialix | perhaps I need to work with some github projects, so | 11:34 |
| bialix | ok, I'll look to bzr-svn then | 11:35 |
| bialix | jelmer: how you prefer to get patches: by mail or via LP merge requests? | 11:36 |
| jelmer | bialix: by email | 11:36 |
| bialix | ok | 11:36 |
| awilkins | lifeless: Did you speak to me earlier? I have an alert but my scrollback doesn't contain it | 11:49 |
| awilkins | 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:51 |
| lifeless | awilkins: bug, windows specific | 11:55 |
| lifeless | fail during inserting a pack | 11:55 |
| lifeless | then do the same pull again | 11:55 |
| lifeless | fail the second time because we can't rename over the file | 11:55 |
| awilkins | lifeless: Aha, yes, I got that | 11:55 |
| lifeless | can you file a bug:) | 11:56 |
| awilkins | Definitely, I was watching with a FS traceer | 11:56 |
| awilkins | I think the fail may either have been a permissions thing or a result of that jailbreak bug | 11:56 |
| awilkins | Although it recurred after I fixed the jailbreak, move the repo, made a new one, and pushed all the branches into it | 11:56 |
| awilkins | 'twas always a particular pack, I recognised the MD5 each time | 11:57 |
| lifeless | yes | 11:57 |
| lifeless | odd to have it happen again >< | 11:57 |
| lifeless | reproducible? | 11:58 |
| lifeless | [and have you filed a bug for the rename handling of it on windows? :)] | 11:58 |
| awilkins | Gimme a chance... | 11:58 |
| lifeless | :P | 11:59 |
| awilkins | I saw it write the pack and then write it again in the same session | 12:00 |
| lifeless | oh? depends on what you mean by that | 12:00 |
| lifeless | older clients write to packs by doing append many times | 12:00 |
| awilkins | I still have the nagging thought that it could have been an MD5 collision but that would be rather silly | 12:00 |
| awilkins | This was a 14.1 client writing to a 14.1 server over HTTP HPSS | 12:01 |
| lifeless | so that does a single post | 12:01 |
| lifeless | if it was an md5 collision a different error | 12:01 |
| lifeless | would have been reported | 12:01 |
| lifeless | one that says 'lucky you' in essence | 12:01 |
| awilkins | Does it even check? | 12:02 |
| lifeless | yes | 12:02 |
| lifeless | welllll | 12:02 |
| lifeless | there are checks about this | 12:02 |
| awilkins | The trace (which I didn't save, sorry) had the offending pack created and written in "packs" then in upload, then it tries to rename it from upload to packs and fails | 12:02 |
| awilkins | Maybe I'll do it again when I'm back in the office | 12:03 |
| awilkins | Right now I have an annoying deadline I'm going to miss | 12:03 |
| lifeless | oh | 12:03 |
| lifeless | might be a suspend/resume bug | 12:04 |
| awilkins | Of the session? | 12:04 |
| lifeless | yeah, stateless server - saves in progress pack as <hash>.pack in uplaods | 12:04 |
| lifeless | then does the final rename to ../packs in a separate hpss call | 12:05 |
| awilkins | That rename is the bit that fails - shouldn't it be doing all the pack writing like that and not creating files in "packs" | 12:05 |
| awilkins | Hmmph, I can't branch 1.14 from lp | 12:06 |
| awilkins | Error received from smart server: ('error', "'AbsentContentFactory' object has no attribute 'get_bytes_as'") | 12:07 |
| awilkins | I've been getting that for 3 days now | 12:07 |
| lifeless | try with sftp | 12:07 |
| lifeless | if that works we need to repair the branch | 12:07 |
| lifeless | smart server wants more data in stacked branches | 12:08 |
| lifeless | repair is a bit wrong; just push a tad more data into it | 12:08 |
| awilkins | Looks like a missing bit of API | 12:08 |
| lifeless | bzr branch nosmart+bzr+ssh://b.l.n/~bzr/bzr/bzr.dev | 12:08 |
| awilkins | Got a 'str' object has no attribute 'get' trying sftp | 12:11 |
| awilkins | I think that might be bzr-svn though | 12:11 |
| jelmer | awilkins: yeah, that's a known issue fixed in 0.6 | 12:12 |
| awilkins | Ok, the problem occurs in the finish() method of NewPack | 12:19 |
| jelmer | vila: are you aware of the python-webdav module? | 12:30 |
| vila | jelmer: never heard about it | 12:34 |
| jelmer | vila: python-based webdav server implementation | 12:36 |
| jelmer | vila: I'm looking at it for bzr-svn server side testing | 12:37 |
| bialix | jelmer: ping | 16:30 |
| jelmer | bialix: pong | 16:30 |
| bialix | jelmer: if you don't like my test command I'll keep it for myself in my own branch | 16:31 |
| bialix | so other patches I'll prepare in another branch | 16:31 |
| bialix | what I should do? | 16:32 |
| jelmer | bialix: Please keep it separate | 16:32 |
| bialix | ok | 16:32 |
| bialix | jelmer: are you ok to put test files into temp subdir? | 16:33 |
| mxpxpod | jelmer: around? | 16:35 |
| jelmer | mxpxpod: hi | 16:35 |
| mxpxpod | I'm getting an error trying to push to a branch using bzr-svn | 16:35 |
| mxpxpod | SubversionException: ("'/svn/support/!svn/bc/5/branches/1.0' path not found", 160013) | 16:35 |
| jelmer | bialix: ideally check for TEMPDIR environment variable and if that doesn't exist, tempdir subdir | 16:35 |
| jelmer | mxpxpod: can you give a bit more context? | 16:36 |
| mxpxpod | jelmer: do you want my .bzr.log? | 16:36 |
| jelmer | mxpxpod: yeah, can you mail that perhaps? | 16:36 |
| bialix | jelmer: on Windows there are $TEMP and $TMP. Also I can use tempdir python std lib | 16:36 |
| mxpxpod | jelmer: yup, where would you like it emailed to? | 16:36 |
| jelmer | mxpxpod: jelmer@samba.org | 16:36 |
| === mario_ is now known as pygi | ||
| jelmer | bialix: ah, yeah, python std lib tempdir sounds like a good idea | 16:37 |
| bialix | ok | 16:37 |
| mxpxpod | jelmer: sent | 16:37 |
| bialix | jelmer: do you did rebase of my forst patch? | 16:50 |
| mxpxpod | jelmer: let me know what you figure out... | 16:50 |
| bialix | s/forst/first/ | 16:50 |
| jelmer | bialix: yeah, I dpushed it | 16:51 |
| jelmer | bialix: dulwich is maintainer in parallel in both git and bzr | 16:51 |
| bialix | :-( | 16:51 |
| jelmer | mxpxpod: no email yet | 16:51 |
| jelmer | s/maintainer/maintained/ | 16:51 |
| mxpxpod | jelmer: check your spam... it's from bryan@reigndropsfall.net | 16:52 |
| bialix | jelmer: even file-ids are not preserved :-( | 16:53 |
| bialix | should I send to you plain diffs then? | 16:53 |
| jelmer | bialix: no, please by all means do send bundles | 16:54 |
| jelmer | bialix: dpush will preserve whatever it can in git | 16:54 |
| jelmer | bialix: | 16:54 |
| jelmer | bialix: it will retain author/committer, commit message and multiple commits and the merge graph | 16:54 |
| bialix | I have a lot of coinflicts | 16:54 |
| jelmer | sorry about that | 16:54 |
| jelmer | it would've been the same with a plain diff though | 16:54 |
| bialix | :-/ | 16:55 |
| jelmer | at some point bzr-git will start supporting push | 16:55 |
| * bialix need to figure out how to best handle this in the future | 16:56 | |
| jelmer | mxpxpod: still nothing, can you try jelmer@ubuntu.com ? | 16:56 |
| mxpxpod | jelmer: yeah | 16:56 |
| * jelmer dinner | 16:57 | |
| mxpxpod | jelmer: sent | 16:58 |
| * bialix waves | 16:59 | |
| jelmer | mxpxpod: that worked | 17:01 |
| jelmer | mxpxpod: please file a bug | 17:01 |
| jelmer | mxpxpod: there is one somewhere there | 17:01 |
| jelmer | mxpxpod: 0.6 ? | 17:01 |
| mxpxpod | jelmer: 0.5.4 | 17:01 |
| awilkins | jelmer: Do you still have to use svn-push or can you just use push for new branches that don't exist in the target repo? | 17:30 |
| awilkins | (for 0.5.4) | 17:30 |
| SamB | awilkins: I don't think svn-push still exists ? | 17:31 |
| * awilkins reads the help and answers his own question | 17:34 | |
| awilkins | SamB: It's there, but the help says it just tells you to use push | 17:34 |
| awilkins | It's going to be a long push anyway, many MB of data over a rather slow upstream | 17:34 |
| awilkins | I do find myself wishing it was a bit more chatty | 17:34 |
| awilkins | It's just sitting there eating bandwidth and some feedback would be nice :-) | 17:34 |
| awilkins | If only so I can tell when I've hit my ISP cap and it's throttled me :-) | 17:34 |
| SamB | doesn't it show you the progress ? | 17:35 |
| SamB | and transfer rate ? | 17:35 |
| awilkins | SamB: The other transports do, but this one isn't | 17:35 |
| jam | mneptok: I heard you were looking for me | 17:51 |
| awilkins | Yegods I hate having a slow upstream | 18:01 |
| mneptok | jam: i am! | 18:06 |
| mneptok | jam: got time to look into a bug that's blocking some MariaDB work? | 18:06 |
| mneptok | jam: https://bugs.launchpad.net/bzr/+bug/375898 | 18:07 |
| ubottu | Ubuntu bug 375898 in bzr "bzr merge fails: bzr: ERROR: No final name for trans_id 'new-1'" [Undecided,New] | 18:07 |
| mneptok | !botsnack | 18:07 |
| ubottu | Yum! Err, I mean, APT! | 18:07 |
| jam | mneptok: I have not specifically looked at that yet, if you give me a bit I'll have a peek | 18:09 |
| mneptok | jam: at your leisure, sir. | 18:11 |
| mneptok | jam: thanks for the mental bandwidth :) | 18:11 |
| === Kissaki^0ff is now known as Kissaki | ||
| jam | mneptok: so is re-doing the merge of pbxt an option? | 18:30 |
| knielsen | jam: that's certainly an option. The merge described in the bug was just a test, and since there were problems it has been put on hold | 18:31 |
| jam | because I'm guessing that doing something like "bzr merge-into/bzr join" is going to be a lot easier | 18:31 |
| knielsen | jam: we were not aware of the bzr join functionality, but it looks interesting (and what is bzr merge-into?) | 18:33 |
| jam | knielsen: 'lp:bzr-merge-into' is a plugin that merges a project into a subdirectory of another project | 18:33 |
| jam | 'bzr join' is a built-in command to do the same thing, but as written has specific requirements as to repo formats, etc | 18:34 |
| knielsen | jam: sounds like this would be better, using a supported way to merge a subproject rather than the hackish/abusish approach from the bug... | 18:35 |
| jam | knielsen: so from what I could see, you are merging everything in, but you get some filename conflicts, so you move them out of the way, do the global merge, then merge them back in | 18:35 |
| jam | sorry, | 18:35 |
| jam | rename them to where you really want them | 18:35 |
| knielsen | yes, sounds right | 18:36 |
| jam | let me give it a poke, since I should have what you need here | 18:37 |
| knielsen | hm, bzr docs says `bzr join` requires that the tree to be joined be first split out with `bzr split`... but won't that prevent commits from the original subproject tree to be pullable into the new joined tree? | 18:38 |
| knielsen | well, I should try it and see | 18:38 |
| jam | knielsen: well, I've used 'merge-into' before to maintain a nested structure | 18:39 |
| knielsen | jam: ok, I'll look into that as well | 18:39 |
| jam | the only known issue is that newly added files in the root of the subproject | 18:39 |
| jam | will show up in the root of the outer project | 18:39 |
| jam | rather than in the subdir | 18:39 |
| jam | otherwise, things should flow fine | 18:39 |
| jam | knielsen: what rev of maria should I try to use? | 18:39 |
| jam | (just before the pbxt merge) | 18:39 |
| jam | ah, I think I found it | 18:40 |
| knielsen | jam: you can use the revid:paul.mccullagh@primebase.org-20090407105746-tolv5dita1d3eavm of lp:maria | 18:41 |
| jam | k, i used -r'revid:paul.mccullagh@primebase.org-20090407105746-tolv5dita1d3eavm' since that was in the bug report | 18:41 |
| jam | looks about the same :) | 18:41 |
| knielsen | jam: just out of curiosity, do you think the "ERROR: No final name for trans_id 'new-1'" is a bzr bug, or caused by user abuse? | 18:42 |
| jam | (At first glance Pidgin decided to turn : Paul into a smiley face, so it wasn't obvious) | 18:42 |
| knielsen | heh | 18:42 |
| jam | knielsen: it *is* a bug, but whether it was introduced at the 'combine' step, or at the new merge time... | 18:43 |
| knielsen | jam: right... | 18:43 |
| knielsen | jam: there is a _lot_ of add/rename/modify going on on top of each other on the same files, so lots of potential for borner case bugs. | 18:44 |
| knielsen | s/borner/corner/ | 18:45 |
| Tak | is there a way to explicitly close a branch? (bzrlib) | 18:46 |
| jam | Tak: del branch | 18:47 |
| jam | knielsen: I'll post my approximate steps | 18:47 |
| Tak | aha, thanks | 18:47 |
| knielsen | jam: cool, thanks | 18:47 |
| Tak | hmm, how does that work when I have a tree and/or a revisiontree that I've obtained from that branch? | 18:49 |
| Tak | do I need to del them all? | 18:49 |
| jam | Tak: well, you need to get rid of all references to the branch | 18:53 |
| jam | I'm not sure how you got a "tree" from the branch, though certainly a revtree via repository | 18:53 |
| jam | I doubt the revtree references the branch, but it would reference the repository | 18:53 |
| jam | knielsen: update posted to 375898 | 18:54 |
| Tak | ok, so I need to nuke everything that might reference the branch | 18:54 |
| * knielsen looking | 18:54 | |
| Tak | I suppose Branch.close() wouldn't be considered in the future? ;-) | 18:54 |
| jam | knielsen: I can say that after doing the recipe I mentioned | 18:55 |
| jam | I can do: "bzr merge lp:pbxt" | 18:55 |
| jam | and the files changed are in storage/pbxt/... and mysql-test/suite/pbxt/... | 18:56 |
| knielsen | jam: right, that's cool | 18:56 |
| knielsen | jam: I'll definitely try it out and see how it works | 18:56 |
| knielsen | jam: With the original merge I did, the but shows up when merging a single changeset from lp:pbxt, but merging all of lp:pbxt worked like you tested on the new merge. So will be interesting to compare | 18:57 |
| jam | knielsen: can you give the cherrypick you want me to try? | 18:58 |
| jam | (note that I won't have applied your individual patches yet) | 18:58 |
| jam | but we still shouldn't get 'no name for new-1' sort of stuff | 18:58 |
| jam | we could give conflicts, etc, but that error is an internal bug | 18:59 |
| knielsen | jam: I did `bzr branch -rrevid:paul.mccullagh@primebase.org-20090403100843-wrwq5hjzvnigsx69 lp:pbxt to-be-merged and then merged from the to-be-merged branch. | 18:59 |
| jam | knielsen: that would be a complete merge, not a cherrypick, at least as far as I can see | 19:00 |
| jam | you aren't specifying an explicit base | 19:00 |
| jam | what you just mentioned should be equivalent to: | 19:00 |
| jam | bzr merge -r revid::paul.mccullagh@primebase.org-20090403100843-wrwq5hjzvnigsx69 lp:pbxt | 19:00 |
| knielsen | jam: that might be the same as cherry-picking revid:revid:paul.mccullagh@primebase.org-20090402202852-wa2fbcmrdy7gda2f..revid:paul.mccullagh@primebase.org-20090403100843-wrwq5hjzvnigsx69 - I'm not sufficiently knowledable with bzr to know (it's a single commit) | 19:01 |
| jam | and at least here, I get: | 19:01 |
| jam | $ bzr merge -r revid:paul.mccullagh@primebase.org-20090403100843-wrwq5hjzvnigsx69 ../pbxt | 19:01 |
| jam | M mysql-test/suite/pbxt/r/type_varchar.result | 19:01 |
| jam | M mysql-test/suite/pbxt/t/type_varchar.test | 19:01 |
| jam | M storage/pbxt/src/ha_pbxt.cc | 19:01 |
| jam | All changes applied successfully. | 19:01 |
| knielsen | jam: basically, I'm merging the next single commit on lp:pbxt ... | 19:01 |
| knielsen | jam: right, so it works! | 19:01 |
| jam | knielsen: with the range you gave, I get the same result "All changes applied successfully" | 19:03 |
| jam | and it doesn't count as a cherrypick | 19:03 |
| knielsen | jam: right, so in the merge in the bug report, the two first files are actually deleted in the merged mariadb tree ... | 19:03 |
| jam | because evid:paul.mccullagh@primebase.org-20090402202852-wa2fbcmrdy7gda2f is in your ancestry already | 19:03 |
| knielsen | jam: and bzr says something strange: +N mysql-test/suite/pbxt/r/type_varchar.result.OTHER | 19:03 |
| knielsen | +N mysql-test/suite/pbxt/t/type_varchar.test.OTHER | 19:03 |
| jam | knielsen: well "Contents conflict in ...." is "You deleted X, but OTHER modified it, Conflict" | 19:03 |
| jam | so we version the latest version of the OTHER (as .OTHER) | 19:04 |
| jam | since you can "bzr revert .....OTHER" if you want to preserve your delete | 19:04 |
| jam | or you can "mv x.OTHER x" if you want to restore the file | 19:04 |
| knielsen | jam: right. In any case the conflicts are correct | 19:04 |
| jam | [I'm not particularly fond of versioning foo.OTHER, but I understand why it was chosen.] | 19:04 |
| jam | that said, the "No final name for trans_id 'new-1'" is still a bug | 19:05 |
| knielsen | of course | 19:05 |
| jam | I don't know how it thinks it wants to version a file, with no real file-id | 19:05 |
| jam | and obviously no filesystem path | 19:05 |
| jam | knielsen: anyway, I can probe directly into the bug, or I can say "use merge-into" to do this sort of thing, and we can punt for now | 19:06 |
| jam | I'd like to get back to working on my presentation for next week, if that is ok | 19:06 |
| knielsen | jam: yes, agree. Using merge-into is in any case much better, thanks a lot for that hint. | 19:07 |
| knielsen | jam: so I will look into merge-into to solve our problem. And then later when you or someone else get back to look at the bug, I hope you will have the necessary information to debug it | 19:08 |
| knielsen | jam: I gave the 3-step sequence to reproduce from public launchpad trees, with revid:s to make sure they stay stable, so hopefully that will be sufficient | 19:09 |
| knielsen | jam: in any case, thanks a lot for your time and help! | 19:09 |
| vxnick | hi all - I'm trying to bzr push a branch to a remote server via sftp, but I get the message "This transport does not update the working tree of: <repo location>" | 19:14 |
| Tak | that's just a warning | 19:15 |
| vxnick | Tak: it doesn't push anything though - it says "no new revisions to push" even when I bzr add them | 19:17 |
| vxnick | do I need to commit before I push or something? | 19:17 |
| knielsen | vxnick: yes, you need to commit before you push. push transfers only committed changes. | 19:24 |
| vxnick | knielsen: ah ok - I was under the impression that checkout/commit were distinct from pull/push | 19:25 |
| kfogel | I'm running bleeding-edge bzr. I'm initting a new repository (new project); I'm tempted to use format 1.14 or 1.14-rich-root -- I would use brisbane-core, but apparently it's not in trunk yet? So, anyone advise for/against 1.14? | 19:35 |
| xnox | bzr: ERROR: Must end write group before releasing write lock on CHKInventoryRepository | 20:20 |
| xnox | Please help. This is on bzr pull from svn | 20:20 |
| xnox | it seems to me there is a race condition between pull and repacking of revisions on rich-root svn repo's with regards to write lock. That's on bzr 15 | 20:54 |
| jfroy | hello | 21:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!