[00:00] jelmer: I'm happy to put the effort in but I need clarity [00:00] lifeless, not sure I follow [00:00] rousskov: good luck! I'll check backlog tomorrow to see how it played out for you. And hire a lawyer ;) [00:00] I am looking at http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#bzr-svn and http://bazaar-vcs.org/BzrForeignBranches/Subversion but am either not seeing it or I have a client or svn problem [00:00] lifeless, there can very well be a bug that's causing bzr-rebase to skip some merges unnecessarily [00:00] * LarstiQ goes to bed [00:00] FYI. I have to leave in 20 minutes. but I will be back. [00:00] jelmer: rousskov tried rebase --always-rebase-merges --new-nick [00:00] jelmer: he says it stopped setting the nick, and still skipped the merges [00:01] I can't see why it would stop setting the nick [00:01] sevenseeker, not seeing what? [00:01] lifeless, Well, you're the author of --new-nick :-) [00:01] jelmer: thanks :P [00:02] how to use an existing working copy... the example creates a bzr repo first then checks out [00:02] rousskov: can you edit rebase.py (~/.bazaar/plugins/rebase/rebase.py) [00:02] Sure [00:02] sevenseeker, just run bzr in the working copy [00:03] lifeless, I'm happy to help wrt the merge bug though, but I think I'm not more qualified than you to say anything about --new-nick [00:03] --- rebase.py 2009-01-15 06:07:29 +0000 [00:03] +++ rebase.py 2009-01-16 00:02:38 +0000 [00:03] @@ -177,6 +177,7 @@ [00:03] oldparents = parent_map[oldrevid] [00:03] assert isinstance(oldparents, tuple), "not tuple: %r" % oldparents [00:03] if len(oldparents) > 1: [00:03] + import pdb;pdb.set_trace() [00:03] additional_parents = heads_cache.heads(oldparents[1:]) [00:04] rousskov: then run the process as previously described, with "--new-nick --always-rebase-merges" [00:05] OK. [00:05] it will drop into a debugger, similar to gdb [00:05] at the merge revisions [00:05] n will step a line [00:05] s [00:05] do you want me to create another fake_upstream? [00:05] s will step into [00:05] rousskov: no, the fake upstream is fine [00:06] just a new fresh-branch [00:06] OK [00:06] bt will get a backtrace [00:06] print EXPR will print the expression [00:07] jelmer: ok, so I want to not only use bzr on the checkout but in essence branch that workingcopy too, can I safely initialize a bzr repo on top of a svn working copy? [00:07] jelmer: btw, I appreciate your help and clues :) [00:07] rousskov: when it stops the first time, I'd like to identify if its one of the revisions that was being skipped [00:07] so 'p oldrevid' [00:08] sevenseeker, not sure I follow. You can create a bzr branch based on the working copy by running "bzr branch

" [00:08] then in your BADBRANCH run bzr log --show-ids, and grep for the revid [00:09] Is it bzr branch $badly $fresh [00:09] yes [00:09] Or bzr branch -r $THATNUMBER $badly $fresh [00:09] the former [00:09] OK [00:10] bzr branch $badly $fresh [00:10] cd $fresh [00:10] bzr rebase --new-nick ../fake-upstream [00:10] except with --always-rebase-merges added [00:11] OK. I am in the debugger. [00:11] p oldrevid [00:12] OK. I did the grep in $badly. [00:13] Found parent and revision IDs [00:14] Found two matches: parent and revision-id [00:14] look at the revision with that revision id [00:14] jelmer: we use svn and I want to use bzr for local changes, but I want to branch our trunk... I am getting this http://paste.lisp.org/display/73676 [00:14] (if you didn't get context, you might prefer less and a search in the output) [00:14] when I run: bzr branch [00:14] or bzr log -r rev:$REVISIONID [00:14] sevenseeker, that's a bug fixed in the 0.5 unfortunately [00:14] oic === dereine is now known as dereine[OFF] [00:15] I have context. [00:15] is it one of the merges that were getting skipped? [00:15] sevenseeker, it should be possible to work around it by using "bzr branch

" [00:16] would bzr URL be (since it is non existent on my box) something like file://foo/spam/eggs? [00:16] lifeless, no [00:16] It is a change on a $badly branch [00:16] sevenseeker, no, it can be a local path [00:16] awesome, thank you I will try that [00:16] rousskov: then you're looking at a child of the revision [00:17] rousskov: please do bzr log -r rev:$REVISIONID instead [00:17] You are right, sorry. [00:17] I looked at parent match, not revision-id [00:17] thats ok [00:18] The revision-id change was indeed skipped, I think. [00:18] ok good [00:18] It is a merge from a parent branch. [00:18] now we try to figure out why it is being skipped [00:18] what does 'p skip_full_merged' show [00:19] FYI. I only have a few minutes [00:19] ok [00:19] False [00:19] when you need to go, go. But this is stuf I can't reproduce [00:19] I understand. [00:19] ok [00:19] hit n ENTER [00:20] keep doing that until the line it shows is [00:20] -> parents = [new_parent] [00:20] if parent in additional_parents and parent not in parents: [00:20] -> if parent in additional_parents and parent not in parents: [00:20] jelmer: seems to have worked, I will be working on it tonight and see for sure... thank you very much [00:21] 'p parent' [00:21] 'pp additional parents' [00:21] 'p parents' [00:22] pastebin that if you can, it won't disclose the nick we're removing [00:22] go around the for parent in parents loop using 'n ENTER' [00:22] oh never mind [00:22] I see the bug [00:22] jelmer: bad code is bad :) [00:23] thats rousskov [00:23] * rousskov crosses fingers [00:23] jelmer: please look at the loop: summarised as 'for parent in parents: parents.append(parent)' [00:23] jelmer: shouldn't that be 'for parent in oldparents: parents.append(parent)' [00:26] lifeless, do you want me to make that change and retry? If yes, what do I do with the current debugging session? I do not want to corrupt repository by killing something in the middle of an update... [00:26] lifeless, I will try follow your future instructions in about an hour. Thank you. [00:28] lifeless: yeah, I think so [00:28] thumper: woo [00:28] let's go [00:30] poolie1: OK === kiko-phone is now known as kiko [00:35] rousskov: I will write a test case for this [00:36] rousskov: and if it fixes it you should be able to just pull in the changes [01:01] jelmer: whats the bug number I'm fixing? [01:08] thumper: https://bugs.edge.launchpad.net/bzr/+bugs?field.searchtext=upgrade&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package= [01:08] blaaaaah [01:11] jelmer: bug 266897 fixed [01:11] Launchpad bug 266897 in bzr-rebase "bzr-rebase loses merges" [High,Triaged] https://launchpad.net/bugs/266897 [01:11] lifeless, cool [01:11] rousskov: when you return, cd to ~/.bazaar/plugins/rebase, bzr revert, bzr pull [01:12] rousskov: then repeat the test - make a new fresh branch, cd to that, bzr rebase --new-nick ../fake-upstream [01:12] rousskov: you do *not* need --always-rebase-merges [01:12] jelmer: https://code.edge.launchpad.net/~lifeless/bzr-rebase/dev [01:13] jelmer: I'd really like to be able to rebase when there is nothing new to pull in [01:13] jelmer: to allow rebase to support just doing edits like this [01:13] lifeless, that should already be possible [01:13] jelmer: no, it complains/errors [01:13] jelmer: replay gave spurious conflicts [01:13] lifeless, if you are already up to date to master, it will just pull [01:14] jelmer: no, wrong graph case [01:14] jelmer: imagine that master hasn't changed [01:14] jelmer: and you object to the concept of rebase-to-do-a-pull because it turns tested code into untested code [01:15] :) [01:15] jelmer: anyhow, if master hasn't changed, but you want to cause a rebase to be executed, it refuses [01:15] lifeless, yes, why would you want to rebase in that case? [01:15] you have to do a commit to master - a no-change commit - to force it to rebase [01:15] jelmer: I have several use cases. This nick editing is one of them [01:15] lifeless, I don't think rebase should be a generic history patching tool [01:16] jelmer: another is to combine two revisions out of the set being rebased [01:16] jelmer: a third is to exclude a revision [01:16] jelmer: its all part of the overall rebase -i stuff [01:16] lifeless, That doesn't make any sense until -i is implemented [01:16] chicken and egg [01:16] right [01:17] so it makes sense now [01:17] its just that its not very useful until -i is implemented [01:17] sure [01:17] anyhow [01:17] I'm not asking that it rebase by default when there is nothing new on master [01:17] just that there be some way to say 'trust me and JFDI' [01:22] lifeless: Happy to merge a patch that implements a --force-rebase or something like that, although I don't see the point in just generating new revision ids [01:23] jelmer: sure, neither do I unless some other change is actually occuring [01:24] jelmer: I'm at a bit of a loss about how to make a --force-rebase option though [01:25] lifeless: I think it shouldn't be a separate option perhaps, but an implicit part of -i (which would need a separate generate_..._plan() function, etc) [01:27] je well it would have been useful for rousskov here [01:29] lifeless, ah, you mean for --new-nicks ? [01:29] yes [01:29] I see rebase mostly as a tool for shaping the graph, not one that changes the actual contents of revisions [01:30] which *is* implemented [01:30] not sure I follow? [01:30] what is implemented? [01:30] new-nick is implemented :) [01:30] anyhow, I think there is such overlap in shaping the graph and setting content that we shouldn't write two tools [01:31] I think the UI from rebase is confusing if people are using it for other things than rebasing on a master branch [01:32] If you want to fix up a couple of revisions, you don't need the concept of a master branch at all [01:32] well [01:32] we need these fixup capabilities [01:32] common requests: [01:32] edit revision metadata [01:32] delete badly added files [01:33] split out history when a project is factored out [01:33] I agree we need the fixup capabilities, I just don't think rebase should be the answer. [01:33] We need a separate tool that can apply specific modification commands to a range of revisions [01:34] why? [01:36] because rebase is aimed at rebasing revisions of one branch onto a master branch, it's UI has the notion of a current branch and an upstream branch on top of which everything is done. [01:36] well bzr has that concept itself [01:37] It's confusing that people would need two branches if they are just trying to fix a couple of branch nicks [01:37] I don't see it being an issue [01:37] Also, if we're going to end up making rebase the place to rewrite the contents of revisions, it will grow horribly complex (in code as well as UI) [01:37] anything that rewrites contents will contain all of rebase [01:38] except for [perhaps] some of the plan generation [01:39] lifeless: Executing the plan would be different [01:39] jelmer: not much [01:39] lifeless, since rebase can just do a merge, but in other situations (changing the conents of the revision) this is not sufficient [01:39] jelmer: I think you are 'borrowing trouble' [01:40] lifeless, I don't see there's a significant amount of code that can be shared between rebase and e.g. a tool that removes a directory from a range of revisions [01:41] lifeless, borrowing from where? [01:41] jelmer: they both need to plan out what will be done to allow recovery; they need to assign new revision ids, they need to preserve merges, they need to setup a working tree for each output revision and do a commit [01:41] jelmer: this is *identical* [01:42] jelmer: the only difference is that an edit needs to occur to the tree before the commit [01:43] lifeless: preserving merges isn't a problem if you're not changing the graph [01:43] lifeless, Setting up the working tree is trivial, it's a simple revert. [01:44] jelmer: look, if I put up a merge you object to, we can talk about it [01:44] right now we're arguing about whether it conceptually fits, and we clearly don't agree about what work the code has to do [01:44] I'm not working on arbitrary editing at the moment [01:44] so the only thing I care about right now is whether the new-nicks patch is acceptable [01:46] lifeless, I think the discussion about the concepts is important. I object to the new-nicks patch because it's changing the revision contents, not the graph shape. I really think that should be a separate command. [01:46] jelmer: ok; I'll fork rebase then I guess [01:46] jelmer: because I don't want to reinvent all the useful stuff in rebase [01:47] lifeless: Uhm, what about just adding a separate command provided by the rebase plugin? [01:47] jelmer: I don't understand, it would be a complete copy and paste [01:48] lifeless, 1 conflicts encountered. Should I resolve and continue-rebase? [01:48] jelmer: rebase already changes the contents of revisions - thats what it does because it pulls in changes at the middle of the graph [01:48] rousskov: yes please [01:49] rousskov: continue-rebase --new-nicks I think [01:49] rousskov: I deliberately avoided recording new-nicks in the plan, because I wanted to be minimal [01:50] Sigh. Too late. I ran rebase-continue without --new-nicks [01:50] * rousskov will redo. [01:51] rousskov: hmm, I need to add the option [01:51] one second [01:52] lifeless: it would just take a simple revision range, much like replay and not have any of the other arguments, not pull rather than rebase if master was an ancestor of the current tip, etc [01:53] jelmer: well I thought replay would be appropriate [01:53] jelmer: but it caused conflicts for rousskov; so I figured there was something wrong there [01:53] lifeless, but I see signs of progress: everything got merged and I have a mixture of old and new nicks, as expected. [01:54] well, rebase is causing conflicts now as well. [01:54] jelmer: I mean, rousskov's use case should just have been 'branch from the start point; replay --new-nick BADBRANCH' [01:54] jelmer: but it conflicted, which is weird [01:54] lifeless, I think replay would be much more appropriate than rebase [01:54] jelmer: I added new-nick to replay as well [01:55] jelmer: I don't see why it shouldn't be in rebase, its valid to want to new-nick *and* rebase-on-master at the same time [01:55] rousskov: pull again please, rev 117 should give you a continue-rebase supporting --new-nick [01:56] OK. Will redo, specifying --new-nick with continue-rebase. [01:56] jelmer: I also think there is some conflation in our discussion; I haven't been referring to the plugin throughout, not to the specific command [01:57] jelmer: except for about 3 statements [01:57] lifeless: Sure, and perhaps you might want to insert a new revision in between some of the revisions you're rebasing. That doesn't mean it has to be part of rebase. [01:57] lifeless: Your patch does add --new-nicks to the rebase command, so I think it's relevant. [01:57] especially since replay is hidden at the moment [01:58] jelmer: it does, because replay is [I assumed erroneously] conflicting; but as rousskov says now that rebase is handling merges correctly t is conflicting as well [02:00] lifeless: So it makes most sense to me to have a new command "bzr filter-revisions" or something that can take an awful lot of command-line options and will just apply them to each of the revisions specified. [02:01] jelmer: if you want me to remove --new-nick from cmd_rebase, I'll do that, but I think its unhelpful to do so because these transforms are not as separate as I think you think they are [02:01] . o O ( success! ) [02:01] rousskov: excellent [02:01] rousskov: sorry I didn't reply to your december mail : I was on leave then [02:01] and didn't see it till now [02:02] lifeless, not separate in what regard? Separate from graph changes? [02:02] yeah [02:02] lifeless, jelmer, Thanks for all the help. [02:02] I find users tend to want several different changes all at once [02:02] rousskov: no problem [02:03] lifeless, next time folks complain that bzr does not work well on Windows, I will skip a round. :-) [02:03] hah [02:04] So I now have about 10 useless branches. Is there a better strategy than "rm -rf" to get rid of them completely? [02:04] unless you plan to rsync the entire repo somewhere public, I suggest you just rm -rf and ignore them [02:05] they won't propogate unless they are referenced [02:05] Does not plan to rsync [02:05] and they will be nearly trivial in disk space [02:05] OK. I am not going to suggest that there should be a branch removal command :-). [02:06] we're going to add one, for remote server access [02:06] but it won't delete the content immediately [02:06] there is a plugin that can do that I think [02:06] resurrecting old content can be very useful [02:06] and the planned gc command will be a generic cleanup-my-repo tool [02:07] * rousskov nods. I am just thinking of folks committing really top-secret-stuff by mistake (I was not). [02:07] rousskov: yeah. Its because of that that unreferenced content is not propogated [02:08] How does repo know what is not referenced if I just rm -rf a checked out branch? [02:09] the branch has a pointer in it [02:09] the branch tip, and the tags, are refs into the repository [02:09] Sure, but I removed the branch. Is there a pointer from repo to the branch? [02:10] no [02:10] branch foo bar; rm -rf bar. [02:10] yup [02:10] How will repo know that bar is not referenced? [02:10] well, 'bar' had the same refs as 'foo', because you took no actions on the branch after making it [02:10] so there isn't anything that is not referenced [02:11] branch foo bar; bzr commit -m 'new' bar; rm -rf bar [02:11] OK. Let's assume I committed to bar before rm -rf. [02:11] that would create a new revision in the repo [02:11] How would repo know that this new revision is not referenced? [02:11] the repo can tell its not referenced by gathering all the refs, then walking the graph; anything in the repo not found by the walk is unreferenced [02:12] I still do not see how repo will distinguish between me running "rm -rf" and "echo rm -rf" in some random directory that it does not know about. [02:13] I guess my definition of "referenced" is wrong. [02:13] rousskov: perhaps [02:13] the branch has the reference [02:13] if the branch isn't there, there isn't a reference [02:13] But repo does not know that the branch is not there. [02:13] yes it does [02:14] the branch is contained within the repo if it is using it for history storage [02:14] Are you saying I should do rm -rf *in the repository*? [02:14] rousskov: no, just the branches you don't want [02:14] But in the repository? [02:14] rousskov: wherever the branches are [02:15] rousskov: I don't know where that is related to any repositories you may or may not have :) [02:15] Repo is in /home/rousskov/programs/bazaar/repos/squid/ [02:15] Branches are in /home/rousskov/Edit/squid3/ [02:16] All the commands you told me were executed in the second directory. [02:16] with that layout, you probably aren't using the repository for history storage at all :) [02:16] which is fine [02:16] But each branch command creates something in the repository. [02:16] rousskov: does it? [02:16] Should I rm -rf that something? [02:17] lifeless, it sure does! [02:17] rousskov: by something, do you mean a directory under /home/rousskov/programs/bazaar/repos/squid/ ? [02:17] One directory per branch [02:17] Yes [02:17] with the basename of the branch ? [02:17] Yes [02:17] ok, they are the branches [02:17] * rousskov ducks [02:18] you probably also had copies of the branches in Edit [02:18] So I should remove both with rm -rf, right? [02:18] yes [02:18] rm -rf anything with the name of the temp branches you were working with [02:18] Is my layout wrong? I thought I followed Squid3 instructions when setting this up. [02:19] I think its fine [02:19] its a little confusing when you use bzr's purest capabilities, because you're in the emulated cvs mode [02:20] Am I using bzr purest capabilities? [02:20] somewhat [02:20] Like --new-nick? [02:20] well new-nick was created for you :) [02:20] by purest I mean working in fully distributed mode [02:21] if there isn't an explicit repository bzr just creates one inline in the branch object [02:21] anyhow [02:21] And I am emulating CVS because I keep repo separate? [02:21] yes [02:21] I see. [02:22] it just means that how you see bzr work everyday isn't its default mode [02:22] its fully supported and I use it in that way for squid myself [02:22] (the way you do) [02:23] It also means I confuse bzr gurus when talking about branches that are actually branch copies. [02:24] or branch references [02:24] note that all the commands worked [02:24] the only confusion occured at the end when talking about cleaning things up:) [02:24] food time, bbs [02:25] Thanks again. [02:40] jelmer: I'm not against having a filtering specific command, but I think it really would just make rebase and replay into shims [02:40] there are other options already present on rebase that control what content changes happen [02:41] (always-rebase-merges is one) [05:01] jamesh: is that actually true that smtp through gmail doesn't file it as sent? [05:01] hrm [05:01] poolie1: I don't think it does. [05:02] iirc it is just an SMTP server [05:02] it is usually up to the MUA to store sent messages [05:02] yes, but this is magic [05:02] it does store it [05:03] i just tested [05:05] hmm. I'd tried this out in the past, so either I didn't notice it storing copies (as the MUA I used did so) or it has added the magic since then [05:05] it might be that if your mua also writes into Sent it de-dupes them [05:05] it does seem to do that pretty aggressively [05:06] also the sent message is marked as read [05:06] right. [05:06] so it's easy not to notice it [05:07] well, it was a pretty quick hack and does let you defer sending the message [05:07] yeah [05:07] it's very useful and a clever hack [05:08] but... Pedantical :-) [05:08] dot com === sdboyer__ is now known as sdboyer === thumper_laptop is now known as thumper [05:51] kfogel, poke [05:52] pygi: perk [05:52] kfogel, you have mailz! [05:52] probably not very useful atm, I'll make sure to write something more detailed tonight if it'll be of any use [05:53] pygi: see my response :-) [05:53] kfogel, afaik it'll be available as e-book, yes [05:54] kfogel, I could probably send you a TOC if you wish? [05:54] pygi: e-book under an open license (one that will permit us to remix, etc)? [05:54] That would be *terrific*. [05:54] kfogel, no :/ [05:54] pygi: who is publisher? [05:55] Packt Publishing [05:55] pygi: hmmm. Have you asked them about doing a CC-BY or CC-BY-SA license? [05:55] many publishers are willing these days [05:55] O'Reilly does it *all the time*, it doesn't seem to hurt sales. [05:56] (I think it probably increases sales, at least for some books, in fact.) [05:56] O'Reilly isn't interested in a bzr book tho :) [05:56] but that doesn't matter really :) [05:57] pygi: no, I just mean as a point to tell Packt. [05:57] kfogel, nop, we haven't asked them to publish the book under an open licence [05:57] pygi: are they not interested in printing one, or not interested in paying an advance for one? [05:58] jamesh, they're not interested in bzr right now, because DVCS is not that big of a market, and they're already covering git [05:58] pygi: what I'm getting at is that, for our purposes, a book will have zero impact on bzr adoption if it's not free online. Because for someone to buy a book, they've already made the decision -- they're making an investment in bzr. We need to provide materials to get people to that point, *before* they buy a book. One great way to do this is to have the book be open. Then they can poke around investment-free. [05:59] pygi: Would you like to ask them? Personally, I can tell you that making my book open (producingoss.com) was the best decision I ever made about that book. It has become much more popular than it ever could have been otherwise. Plus, I got free translations out of it! Some of which are now being published. [05:59] kfogel, I can understand that [06:00] kfogel, I'd need to talk (again) with Szi and Jon about that, but asking isn't a problem [06:00] pygi: I don't mean to be a downer, but: don't even think about royalties. You're not going to make any more than the advance on this book (you probably already know that). The benefit is really to your reputation. In which case... having it circulate more freely == more benefit. [06:00] kfogel, haha, no, I'm not thinking about royalties [06:00] they SHOULD make a bzr book :( bzr is so awesome [06:00] I suppose O'Reilly has all that web 2.0 money though, so doesn't need to make a profit from selling books any more [06:01] Toksyuryel, we're on it ;) [06:01] pygi: cool, talk w/ Szi and Jon and see what they think. If they'd like to talk to me about what it did for ProducingOSS, I'd be happy to talk about it. [06:01] pygi: but http://producingoss.com/translations.html will give you some idea :-). [06:01] kfogel, I've sent you a mail that has TOC btw [06:01] kfogel, hehe :) [06:01] yea, I have that book, google bought me one :p [06:02] pygi: oh, heh! Prolly has my signature in it, then. [06:02] aha [06:02] you would think that the official RCS of choice for the GNU project would catch the attention of the O'Reilly people [06:02] maybe it's too much of a moving target still though [06:03] Toksyuryel, its just that git is much more widely used [06:03] and linux kernel ofcourse is git [06:03] Toksyuryel: they didn't do a book about Arch either, when it was the official RCS of choice for GNU [06:03] I think Bazaar will have to work on its own merits [06:03] I thought Arch was a distro [06:03] and even the Git book isn't too big (I think 200 pages, I'd need to look) [06:03] Toksyuryel, arch linux is a distro :) [06:03] (and it shouldn't have any trouble there) [06:03] well, git NEEDS a book to even understand it [06:04] Toksyuryel: http://www.gnu.org/software/gnu-arch/ [06:04]