lifelessjelmer: I'm happy to put the effort in but I need clarity00:00
jelmerlifeless, not sure I follow00:00
LarstiQrousskov: good luck! I'll check backlog tomorrow to see how it played out for you. And hire a lawyer ;)00:00
sevenseekerI 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 problem00:00
jelmerlifeless, there can very well be a bug that's causing bzr-rebase to skip some merges unnecessarily00:00
* LarstiQ goes to bed00:00
rousskovFYI. I have to leave in 20 minutes. but I will be back.00:00
lifelessjelmer: rousskov tried rebase --always-rebase-merges --new-nick00:00
lifelessjelmer: he says it stopped setting the nick, and still skipped the merges00:00
lifelessI can't see why it would stop setting the nick00:01
jelmersevenseeker, not seeing what?00:01
jelmerlifeless, Well, you're the author of --new-nick :-)00:01
lifelessjelmer: thanks :P00:01
sevenseekerhow to use an existing working copy... the example creates a bzr repo first then checks out00:02
lifelessrousskov: can you edit rebase.py (~/.bazaar/plugins/rebase/rebase.py)00:02
jelmersevenseeker, just run bzr in the working copy00:02
jelmerlifeless, 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-nick00:03
lifeless--- rebase.py   2009-01-15 06:07:29 +000000:03
lifeless+++ rebase.py   2009-01-16 00:02:38 +000000:03
lifeless@@ -177,6 +177,7 @@00:03
lifeless         oldparents = parent_map[oldrevid]00:03
lifeless         assert isinstance(oldparents, tuple), "not tuple: %r" % oldparents00:03
lifeless         if len(oldparents) > 1:00:03
lifeless+            import pdb;pdb.set_trace()00:03
lifeless             additional_parents = heads_cache.heads(oldparents[1:])00:03
lifelessrousskov: then run the process as previously described, with "--new-nick --always-rebase-merges"00:04
lifelessit will drop into a debugger, similar to gdb00:05
lifelessat the merge revisions00:05
lifelessn will step a line00:05
rousskovdo you want me to create another fake_upstream?00:05
lifelesss will step into00:05
lifelessrousskov: no, the fake upstream is fine00:05
lifelessjust a new fresh-branch00:06
lifelessbt will get a backtrace00:06
lifelessprint EXPR will print the expression00:06
sevenseekerjelmer: 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
sevenseekerjelmer: btw, I appreciate your help and clues :)00:07
lifelessrousskov: when it stops the first time, I'd like to identify if its one of the revisions that was being skipped00:07
lifelessso 'p oldrevid'00:07
jelmersevenseeker, not sure I follow. You can create a bzr branch based on the working copy by running "bzr branch <location-of-working-copy> <location-of-bzr-branch>"00:08
lifelessthen in your BADBRANCH run bzr log --show-ids, and grep for the revid00:08
rousskovIs it bzr branch $badly $fresh00:09
rousskovOr bzr branch -r $THATNUMBER $badly $fresh00:09
lifelessthe former00:09
lifeless  bzr branch $badly $fresh00:10
lifelesscd $fresh00:10
lifeless  bzr rebase --new-nick ../fake-upstream00:10
lifelessexcept with --always-rebase-merges added00:10
rousskovOK. I am in the debugger.00:11
lifelessp oldrevid00:11
rousskovOK. I did the grep in $badly.00:12
rousskovFound parent and revision IDs00:13
rousskovFound two matches: parent and revision-id00:14
lifelesslook at the revision with that revision id00:14
sevenseekerjelmer: 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/7367600:14
lifeless(if you didn't get context, you might prefer less and a search in the output)00:14
sevenseekerwhen I run: bzr branch <svn working copy> <new bzr branch>00:14
lifelessor bzr log -r rev:$REVISIONID00:14
jelmersevenseeker, that's a bug fixed in the 0.5 unfortunately00:14
=== dereine is now known as dereine[OFF]
rousskovI have context.00:15
lifelessis it one of the merges that were getting skipped?00:15
jelmersevenseeker, it should be possible to work around it by using "bzr branch <repository-url> <bzr-url>"00:15
sevenseekerwould bzr URL be (since it is non existent on my box) something like file://foo/spam/eggs?00:16
rousskovlifeless, no00:16
rousskovIt is a change on a $badly branch00:16
jelmersevenseeker, no, it can be a local path00:16
sevenseekerawesome, thank you I will try that00:16
lifelessrousskov: then you're looking at a child of the revision00:16
lifelessrousskov: please do  bzr log -r rev:$REVISIONID instead00:17
rousskovYou are right, sorry.00:17
rousskovI looked at parent match, not revision-id00:17
lifelessthats ok00:17
rousskovThe revision-id change was indeed skipped, I think.00:18
lifelessok good00:18
rousskovIt is a merge from a parent branch.00:18
lifelessnow we try to figure out why it is being skipped00:18
lifelesswhat does 'p skip_full_merged' show00:18
rousskovFYI. I only have a few minutes00:19
lifelesswhen you need to go, go. But this is stuf I can't reproduce00:19
rousskovI understand.00:19
lifelesshit n ENTER00:19
lifelesskeep doing that until the line it shows is00:20
rousskov-> parents = [new_parent]00:20
lifelessif parent in additional_parents and parent not in parents:00:20
rousskov-> if parent in additional_parents and parent not in parents:00:20
sevenseekerjelmer: seems to have worked, I will be working on it tonight and see for sure... thank you very much00:20
lifeless'p parent'00:21
lifeless'pp additional parents'00:21
lifeless'p parents'00:21
lifelesspastebin that if you can, it won't disclose the nick we're removing00:22
lifelessgo around the for parent in parents loop using 'n ENTER'00:22
lifelessoh never mind00:22
lifelessI see the bug00:22
lifelessjelmer: bad code is bad :)00:22
lifelessthats rousskov00:23
* rousskov crosses fingers00:23
lifelessjelmer: please look at the loop: summarised as 'for parent in parents: parents.append(parent)'00:23
lifelessjelmer: shouldn't that be 'for parent in oldparents: parents.append(parent)'00:23
rousskovlifeless, 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
rousskovlifeless, I will try follow your future instructions in about an hour. Thank you.00:26
jelmerlifeless: yeah, I think so00:28
poolie1thumper: woo00:28
poolie1let's go00:28
thumperpoolie1: OK00:30
=== kiko-phone is now known as kiko
lifelessrousskov: I will write a test case for this00:35
lifelessrousskov: and if it fixes it you should be able to just pull in the changes00:36
lifelessjelmer: whats the bug number I'm fixing?01:01
poolie1thumper: 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
lifelessjelmer: bug 266897 fixed01:11
ubottuLaunchpad bug 266897 in bzr-rebase "bzr-rebase loses merges" [High,Triaged] https://launchpad.net/bugs/26689701:11
jelmerlifeless, cool01:11
lifelessrousskov: when you return, cd to ~/.bazaar/plugins/rebase, bzr revert, bzr pull01:11
lifelessrousskov: then repeat the test - make a new fresh branch, cd to that, bzr rebase --new-nick ../fake-upstream01:12
lifelessrousskov: you do *not* need --always-rebase-merges01:12
lifelessjelmer: https://code.edge.launchpad.net/~lifeless/bzr-rebase/dev01:12
lifelessjelmer: I'd really like to be able to rebase when there is nothing new to pull in01:13
lifelessjelmer: to allow rebase to support just doing edits like this01:13
jelmerlifeless, that should already be possible01:13
lifelessjelmer: no, it complains/errors01:13
lifelessjelmer: replay gave spurious conflicts01:13
jelmerlifeless, if you are already up to date to master, it will just pull01:13
lifelessjelmer: no, wrong graph case01:14
lifelessjelmer: imagine that master hasn't changed01:14
lifelessjelmer: and you object to the concept of rebase-to-do-a-pull because it turns tested code into untested code01:14
lifelessjelmer: anyhow, if master hasn't changed, but you want to cause a rebase to be executed, it refuses01:15
jelmerlifeless, yes, why would you want to rebase in that case?01:15
lifelessyou have to do a commit to master - a no-change commit - to force it to rebase01:15
lifelessjelmer: I have several use cases. This nick editing is one of them01:15
jelmerlifeless,  I don't think rebase should be a generic history patching tool01:15
lifelessjelmer: another is to combine two revisions out of the set being rebased01:16
lifelessjelmer: a third is to exclude a revision01:16
lifelessjelmer: its all part of the overall rebase -i stuff01:16
jelmerlifeless, That doesn't make any sense until -i is implemented01:16
lifelesschicken and egg01:16
lifelessso it makes sense now01:17
lifelessits just that its not very useful until -i is implemented01:17
lifelessI'm not asking that it rebase by default when there is nothing new on master01:17
lifelessjust that there be some way to say 'trust me and JFDI'01:17
jelmerlifeless: 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 ids01:22
lifelessjelmer: sure, neither do I unless some other change is actually occuring01:23
lifelessjelmer: I'm at a bit of a loss about how to make a --force-rebase option though01:24
jelmerlifeless: 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:25
lifelessjewell it would have been useful for rousskov here01:27
jelmerlifeless, ah, you mean for --new-nicks ?01:29
jelmerI see rebase mostly as a tool for shaping the graph, not one that changes the actual contents of revisions01:29
lifelesswhich *is* implemented01:30
jelmernot sure I follow?01:30
jelmerwhat is implemented?01:30
lifelessnew-nick is implemented :)01:30
lifelessanyhow, I think there is such overlap in shaping the graph and setting content that we shouldn't write two tools01:30
jelmerI think the UI from rebase is confusing if people are using it for other things than rebasing on a master branch01:31
jelmerIf you want to fix up a couple of revisions, you don't need the concept of a master branch at all01:32
lifelesswe need these fixup capabilities01:32
lifelesscommon requests:01:32
lifelessedit revision metadata01:32
lifelessdelete badly added files01:32
lifelesssplit out history when a project is factored out01:33
jelmerI agree we need the fixup capabilities, I just don't think rebase should be the answer.01:33
jelmerWe need a separate tool that can apply specific modification commands to a range of revisions01:33
jelmerbecause 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
lifelesswell bzr has that concept itself01:36
jelmerIt's confusing that people would need two branches if they are just trying to fix a couple of branch nicks01:37
lifelessI don't see it being an issue01:37
jelmerAlso, 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
lifelessanything that rewrites contents will contain all of rebase01:37
lifelessexcept for [perhaps] some of the plan generation01:38
jelmerlifeless: Executing the plan would be different01:39
lifelessjelmer: not much01:39
jelmerlifeless, since rebase can just do a merge, but in other situations (changing the conents of the revision) this is not sufficient01:39
lifelessjelmer: I think you are 'borrowing trouble'01:39
jelmerlifeless, 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 revisions01:40
jelmerlifeless, borrowing from where?01:41
lifelessjelmer: 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 commit01:41
lifelessjelmer: this is *identical*01:41
lifelessjelmer: the only difference is that an edit needs to occur to the tree before the commit01:42
jelmerlifeless: preserving merges isn't a problem if you're not changing the graph01:43
jelmerlifeless, Setting up the working tree is trivial, it's a simple revert.01:43
lifelessjelmer: look, if I put up a merge you object to, we can talk about it01:44
lifelessright now we're arguing about whether it conceptually fits, and we clearly don't agree about what work the code has to do01:44
lifelessI'm not working on arbitrary editing at the moment01:44
lifelessso the only thing I care about right now is whether the new-nicks patch is acceptable01:44
jelmerlifeless, 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
lifelessjelmer: ok; I'll fork rebase then I guess01:46
lifelessjelmer: because I don't want to reinvent all the useful stuff in rebase01:46
jelmerlifeless: Uhm, what about just adding a separate command provided by the rebase plugin?01:47
lifelessjelmer: I don't understand, it would be a complete copy and paste01:47
rousskovlifeless, 1 conflicts encountered. Should I resolve and continue-rebase?01:48
lifelessjelmer: rebase already changes the contents of revisions - thats what it does because it pulls in changes at the middle of the graph01:48
lifelessrousskov: yes please01:48
lifelessrousskov: continue-rebase --new-nicks I think01:49
lifelessrousskov: I deliberately avoided recording new-nicks in the plan, because I wanted to be minimal01:49
rousskovSigh. Too late. I ran rebase-continue without --new-nicks01:50
* rousskov will redo.01:50
lifelessrousskov: hmm, I need to add the option01:51
lifelessone second01:51
jelmerlifeless: 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, etc01:52
lifelessjelmer: well I thought replay would be appropriate01:53
lifelessjelmer: but it caused conflicts for rousskov; so I figured there was something wrong there01:53
rousskovlifeless, but I see signs of progress: everything got merged and I have a mixture of old and new nicks, as expected.01:53
rousskovwell, rebase is causing conflicts now as well.01:54
lifelessjelmer: I mean, rousskov's use case should just have been 'branch from the start point; replay --new-nick BADBRANCH'01:54
lifelessjelmer: but it conflicted, which is weird01:54
jelmerlifeless, I think replay would be much more appropriate than rebase01:54
lifelessjelmer: I added new-nick to replay as well01:54
lifelessjelmer: 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 time01:55
lifelessrousskov: pull again please, rev 117 should give you a continue-rebase supporting --new-nick01:55
rousskovOK. Will redo, specifying --new-nick with continue-rebase.01:56
lifelessjelmer: I also think there is some conflation in our discussion; I haven't been referring to the plugin throughout, not to the specific command01:56
lifelessjelmer: except for about 3 statements01:57
jelmerlifeless: 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
jelmerlifeless: Your patch does add --new-nicks to the rebase command, so I think it's relevant.01:57
jelmerespecially since replay is hidden at the moment01:57
lifelessjelmer: it does, because replay is [I assumed erroneously] conflicting; but as rousskov says now that rebase is handling merges correctly t is conflicting as well01:58
jelmerlifeless: 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:00
lifelessjelmer: 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 are02:01
rousskov. o O ( success! )02:01
lifelessrousskov: excellent02:01
lifelessrousskov: sorry I didn't reply to your december mail : I was on leave then02:01
lifelessand didn't see it till now02:01
jelmerlifeless, not separate in what regard? Separate from graph changes?02:02
rousskovlifeless, jelmer, Thanks for all the help.02:02
lifelessI find users tend to want several different changes all at once02:02
lifelessrousskov: no problem02:02
rousskovlifeless, next time folks complain that bzr does not work well on Windows, I will skip a round. :-)02:03
rousskovSo I now have about 10 useless branches. Is there a better strategy than "rm -rf" to get rid of them completely?02:04
lifelessunless you plan to rsync the entire repo somewhere public, I suggest you just rm -rf and ignore them02:04
lifelessthey won't propogate unless they are referenced02:05
rousskovDoes not plan to rsync02:05
lifelessand they will be nearly trivial in disk space02:05
rousskovOK. I am not going to suggest that there should be a branch removal command :-).02:05
lifelesswe're going to add one, for remote server access02:06
lifelessbut it won't delete the content immediately02:06
lifelessthere is a plugin that can do that I think02:06
lifelessresurrecting old content can be very useful02:06
lifelessand the planned gc command will be a generic cleanup-my-repo tool02:06
* rousskov nods. I am just thinking of folks committing really top-secret-stuff by mistake (I was not).02:07
lifelessrousskov: yeah. Its because of that that unreferenced content is not propogated02:07
rousskovHow does repo know what is not referenced if I just rm -rf a checked out branch?02:08
lifelessthe branch has a pointer in it02:09
lifelessthe branch tip, and the tags, are refs into the repository02:09
rousskovSure, but I removed the branch. Is there a pointer from repo to the branch?02:09
rousskovbranch foo bar; rm -rf bar.02:10
rousskovHow will repo know that bar is not referenced?02:10
lifelesswell, 'bar' had the same refs as 'foo', because you took no actions on the branch after making it02:10
lifelessso there isn't anything that is not referenced02:10
lifelessbranch foo bar; bzr commit -m 'new' bar; rm -rf bar02:11
rousskovOK. Let's assume I committed to bar before rm -rf.02:11
lifelessthat would create a new revision in the repo02:11
rousskovHow would repo know that this new revision is not referenced?02:11
lifelessthe 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 unreferenced02:11
rousskovI 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:12
rousskovI guess my definition of "referenced" is wrong.02:13
lifelessrousskov: perhaps02:13
lifelessthe branch has the reference02:13
lifelessif the branch isn't there, there isn't a reference02:13
rousskovBut repo does not know that the branch is not there.02:13
lifelessyes it does02:13
lifelessthe branch is contained within the repo if it is using it for history storage02:14
rousskovAre you saying I should do rm -rf   *in the repository*?02:14
lifelessrousskov: no, just the branches you don't want02:14
rousskovBut in the repository?02:14
lifelessrousskov: wherever the branches are02:14
lifelessrousskov: I don't know where that is related to any repositories you may or may not have :)02:15
rousskovRepo is in /home/rousskov/programs/bazaar/repos/squid/02:15
rousskovBranches are in /home/rousskov/Edit/squid3/02:15
rousskovAll the commands you told me were executed in the second directory.02:16
lifelesswith that layout, you probably aren't using the repository for history storage at all :)02:16
lifelesswhich is fine02:16
rousskovBut each branch command creates something in the repository.02:16
lifelessrousskov: does it?02:16
rousskovShould I rm -rf that something?02:16
rousskovlifeless, it sure does!02:17
lifelessrousskov: by something, do you mean a directory under /home/rousskov/programs/bazaar/repos/squid/ ?02:17
rousskovOne directory per branch02:17
lifelesswith the basename of the branch ?02:17
lifelessok, they are the branches02:17
* rousskov ducks02:17
lifelessyou probably also had copies of the branches in Edit02:18
rousskovSo I should remove both with rm -rf, right?02:18
lifelessrm -rf anything with the name of the temp branches you were working with02:18
rousskovIs my layout wrong? I thought I followed Squid3 instructions when setting this up.02:18
lifelessI think its fine02:19
lifelessits a little confusing when you use bzr's purest capabilities, because you're in the emulated cvs mode02:19
rousskovAm I using bzr purest capabilities?02:20
rousskovLike --new-nick?02:20
lifelesswell new-nick was created for you :)02:20
lifelessby purest I mean working in fully distributed mode02:20
lifelessif there isn't an explicit repository bzr just creates one inline in the branch object02:21
rousskovAnd I am emulating CVS because I keep repo separate?02:21
rousskovI see.02:21
lifelessit just means that how you see bzr work everyday isn't its default mode02:22
lifelessits fully supported and I use it in that way for squid myself02:22
lifeless(the way you do)02:22
rousskovIt also means I confuse bzr gurus when talking about branches that are actually branch copies.02:23
lifelessor branch references02:24
lifelessnote that all the commands worked02:24
lifelessthe only confusion occured at the end when talking about cleaning things up:)02:24
lifelessfood time, bbs02:24
rousskovThanks again.02:25
lifelessjelmer: I'm not against having a filtering specific command, but I think it really would just make rebase and replay into shims02:40
lifelessthere are other options already present on rebase that control what content changes happen02:40
lifeless(always-rebase-merges is one)02:41
poolie1jamesh: is that actually true that smtp through gmail doesn't file it as sent?05:01
jameshpoolie1: I don't think it does.05:01
jameshiirc it is just an SMTP server05:02
jameshit is usually up to the MUA to store sent messages05:02
poolie1yes, but this is magic05:02
poolie1it does store it05:02
poolie1i just tested05:03
jameshhmm.  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 then05:05
poolie1it might be that if your mua also writes into Sent it de-dupes them05:05
poolie1it does seem to do that pretty aggressively05:05
poolie1also the sent message is marked as read05:06
poolie1so it's easy not to notice it05:06
jameshwell, it was a pretty quick hack and does let you defer sending the message05:07
poolie1it's very useful and a clever hack05:07
poolie1but... Pedantical :-)05:08
lifelessdot com05:08
=== sdboyer__ is now known as sdboyer
=== thumper_laptop is now known as thumper
pygikfogel, poke05:51
kfogelpygi: perk05:52
pygikfogel, you have mailz!05:52
pygiprobably not very useful atm, I'll make sure to write something more detailed tonight if it'll be of any use05:52
kfogelpygi: see my response :-)05:53
pygikfogel, afaik it'll be available as e-book, yes05:53
pygikfogel, I could probably send you a TOC if you wish?05:54
kfogelpygi: e-book under an open license (one that will permit us to remix, etc)?05:54
kfogelThat would be *terrific*.05:54
pygikfogel, no :/05:54
kfogelpygi: who is publisher?05:54
pygiPackt Publishing05:55
kfogelpygi: hmmm.  Have you asked them about doing a CC-BY or CC-BY-SA license?05:55
kfogelmany publishers are willing these days05:55
kfogelO'Reilly does it *all the time*, it doesn't seem to hurt sales.05:55
kfogel(I think it probably increases sales, at least for some books, in fact.)05:56
pygiO'Reilly isn't interested in a bzr book tho :)05:56
pygibut that doesn't matter really :)05:56
kfogelpygi: no, I just mean as a point to tell Packt.05:57
pygikfogel, nop, we haven't asked them to publish the book under an open licence05:57
jameshpygi: are they not interested in printing one, or not interested in paying an advance for one?05:57
pygijamesh, they're not interested in bzr right now, because DVCS is not that big of a market, and they're already covering git05:58
kfogelpygi: 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:58
kfogelpygi: 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
pygikfogel, I can understand that05:59
pygikfogel, I'd need to talk (again) with Szi and Jon about that, but asking isn't a problem06:00
kfogelpygi: 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
pygikfogel, haha, no, I'm not thinking about royalties06:00
Toksyuryelthey SHOULD make a bzr book :( bzr is so awesome06:00
jameshI suppose O'Reilly has all that web 2.0 money though, so doesn't need to make a profit from selling books any more06:00
pygiToksyuryel, we're on it ;)06:01
kfogelpygi: 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
kfogelpygi: but http://producingoss.com/translations.html will give you some idea :-).06:01
pygikfogel, I've sent you a mail that has TOC btw06:01
pygikfogel, hehe :)06:01
pygiyea, I have that book, google bought me one :p06:01
kfogelpygi: oh, heh!  Prolly has my signature in it, then.06:02
Toksyuryelyou would think that the official RCS of choice for the GNU project would catch the attention of the O'Reilly people06:02
Toksyuryelmaybe it's too much of a moving target still though06:02
pygiToksyuryel, its just that git is much more widely used06:03
pygiand linux kernel ofcourse is git06:03
jameshToksyuryel: they didn't do a book about Arch either, when it was the official RCS of choice for GNU06:03
jameshI think Bazaar will have to work on its own merits06:03
ToksyuryelI thought Arch was a distro06:03
pygiand even the Git book isn't too big (I think 200 pages, I'd need to look)06:03
pygiToksyuryel, arch linux is a distro :)06:03
jamesh(and it shouldn't have any trouble there)06:03
Toksyuryelwell, git NEEDS a book to even understand it06:03
jameshToksyuryel: http://www.gnu.org/software/gnu-arch/06:04
Toksyuryelit is written in some kind of goofy alien language06:04
pygikfogel, if we end up actually doing that, I'll include you in conversation with Packt, if it'll be needed06:05
ToksyuryelI don't think "the linux kernel uses it" should be a metric really... they used bitkeeper for a while remember. plus I think linus is still anti-gpl306:06
kfogelpygi: great.  Note that I can be much more diplomatic and calm than I was here in IRC tonight (I figured with you I could just be very direct).06:06
pygiToksyuryel, tons of projects adopting git is a metric tho :)06:06
pygikfogel, haha :D06:06
Toksyuryelpygi: that makes me cry :( I really broke down in tears when I saw that perl had switched to git06:06
fullermdDiploma...   IRC...    what?06:06
pygifullermd, the cheese06:07
fullermdMmm, cheese.06:07
Toksyuryelwe need better PR for bzr. gotta get more buzz out there06:07
Toksyuryelhow to do that though?06:07
pygiToksyuryel, just have patience :)06:07
fullermdThe early bird catches the worm, but the second mouse gets the cheese.06:07
Toksyuryelfullermd: that's a good quote06:07
* Toksyuryel writes that one down06:08
* fullermd can't even remember the first time he heard it.06:08
fullermdThe first step to better PR is to make every large project's first reaction not be "Holy crap, this is slow"06:08
Toksyuryelthere is a limit to how much speed you can squeeze out of python. and last time I brought up the notion of switching to C there were a lot of groans :P06:09
pygikfogel, ok, if you'll have any questions about TOC; please shout ...  gotta do some work now :(06:09
kfogelI have to say, I haven't experienced speed problems so far.06:09
kfogelpygi: will do (haven't seen email yet, am working on something else)06:09
fullermdTrue, but there's hg sitting right there laughing at the idea that C is needed to be $LOTS faster than bzr.06:09
Toksyuryelbzr's speed comes not from its code execution but from its ease of use06:10
kfogelfullermd: I too am skeptical that C vs Python is a major factor here.06:10
fullermdA lot of things are slower, but the network is what really kills you.06:10
Toksyuryelyou spend a lot less time fumbling with it than you do with other rcs06:10
jameshToksyuryel: a number of the places where bzr feels slow, the CPU isn't pegged06:10
fullermdAnd really, bzr [last I looked, anyway] utterly creams hg and git over dumb servers.  Neither of them seem to go for much more than "OK, works" in that case.06:10
jameshthat can indicate that the interpreter speed isn't the issue06:11
fullermdBut they both have good smart servers.  bzr...   er...   well, it HAS a smart server...06:11
Toksyuryelbzr's dumb server is as smart as its smart server :P06:11
lifelesskfogel: We typically get a 30-60 percent time reduction when we pryex inner loops06:11
fullermdThe smart server has historically been a really GOOD dumb server.  Actual smarts are slowly trickling in.06:12
fullermdBut still.  I wish the VFS layer on it had never been written.06:12
lifelesskfogel: I think we could get a further 50 percent redution on the output with real C and not refcounted memory-scattered structs06:12
kfogellifeless: wow.  But the big question is, on what operations is this the case?06:13
fullermdOne way to look at it is that we're in a way better performance position than hg or git.06:13
kfogelfullermd: ?06:13
fullermdBecause we have both there; we KNOW things can be radically faster.  And we can even tear them apart and see how.06:13
fullermdWe don't have to look at things and think "Yeah, that sucks...   but I don't know if it can really be made faster"06:13
lifelesskfogel: status, sequence matching, local dirstate parsing, knit index parsing [obsoleted], B+Tree index parsing (in 1.9 and newer formats)06:14
kfogelfullermd: mrm.  I don't get the feeling that either git or hg developers ever say that to themselves :-).06:14
fullermdWell, no.  That's why we're in this position   ;p06:14
lifelesspython is very fast at adhoc stuff, but C is maaaassively faster when used end to end06:15
Toksyuryelconverting the codebase would take quite a while though06:16
ToksyuryelI get the feeling that bzr is still in something of an experimental phase where they are still trying features and looking for the best way to handle things06:16
Toksyuryellike the constantly changing index format06:16
Toksyuryelit is easy to quickly impliment that stuff for testing in python06:17
lifelessToksyuryel: there are no plans to convert all of the code base06:17
Toksyuryelonce the codebase settles down, I think is when a potential conversion to C should pop up on the radar06:17
lifelessToksyuryel: there is significant community attraction to being python06:18
Toksyuryelit's a nice buzzword, sure06:18
lifelessToksyuryel: we already have C extensions for inner loops06:18
lifelessToksyuryel: its not a buzzword; I started a thread about this in uhm, september or october06:18
lifelesswe're experimental in the sense that we continually reevaluate what we have and look for improvements; there are some areas that are more in need of such improvements than others06:19
Toksyuryellifeless: I am not suggesting that the experimental nature is a bad thing; it is one of the things I love about bzr06:20
lifelessbut there is some confusion out there about what it means06:21
jameshToksyuryel: so, code in C often runs faster than code in Python, but code in Python is usually easier to change.06:22
jameshif you know you've got the fastest possible algorithm and data structures, then converting to C might be a good idea if speed is a problem.06:22
jameshif you've using the wrong algorithm, fixing that problem can speed things up more than a Python->C conversion would06:22
jameshso starting from Python code is a plus there.06:23
Toksyuryeljamesh: that's my point06:24
jameshToksyuryel: one problem is that it is difficult to tell whether you're code has settled into the best possible algorithms.06:25
jameshsomeone might come up with something faster, or external matters change requiring changes in the project06:26
Toksyuryeljamesh: well I can say with certainty that a new release every month is not "settled" :P06:26
pygikfogel, wake up06:33
kfogelpygi: ?06:33
kfogelpygi: (just about to go to bed, actually)06:33
pygikfogel, is the only reason you think it doesn't solve the problem its non-openess, or because it doesn't include what you imagined?06:33
kfogelpygi: both, but mainly the latter.06:33
pygikfogel, well, we can obviously fix that06:34
pygibut I'll let you go to bed I guess, so poke me when you want to talk06:34
kfogelpygi: a bzr book is a great thing.  But newcomers don't want a book (they just want to know that one exists!).  What they want, when evaluating bzr, is something that says "Yes, you can accomplish your familiar task XYZ using bzr, and here's how."06:34
kfogelpygi: if you tried to make the book solve this problem, that would only ruin the book :-).06:35
kfogelpygi: ok, good night for real.  See you later!06:35
pygikfogel, ok, ok06:35
lifelessuisn't the cheatsheet that?06:38
pygilifeless, obviously, not in a connected, workflow-like way? You'd have to ask kfogel :p06:39
lifelesshave a good weekend06:43
pygithanks, the same :)06:44
=== thumper_laptop is now known as thumper
lifelessmin 0.0023460388183607:06
lifelessmax 0.070995807647707:06
lifelessavg 0.0028029038604507:06
lifelesstimes to extract a single inventory text with in-memory index and hot cache07:06
lifelessmin 0.0023670196533207:11
lifelessmax 0.057082176208507:11
lifelessavg 0.0028037219090507:11
lifelessdev 0.0010397822212707:11
lifelessstd dev added07:11
lifelesspoolie1: ^07:14
vilahi all07:33
poolie1lifeless: hi07:40
lifeless$ bzr compressbench07:50
lifelessRaw size 346188021307:50
lifelessCompressed size 14115237107:50
lifelessmin 0.0024020671844507:50
lifelessmax 0.053763151168807:50
lifelessavg 0.0028726059395907:50
lifelessdev 0.0010476961711907:50
lifelessmin 5.22243953561e-0507:50
lifelessmax 0.0011688882311107:50
lifelessavg 6.24545846438e-0507:50
lifelessdev 2.27784216077e-0507:50
Jc2klifeless: how is the compression going? rob still swoons everytime he hears "group compress"10:10
=== asac_ is now known as asac
liwI have branch foo (upstream code) and foo.deb (packaging for .deb); I had to do a bugfix release without doing a new upstream release, so I did bug fixes in foo.deb; what's the best way of merging only the changes that affect upstream to foo?11:45
liwwould merging the foo.deb branch into foo, but removing debian/* before committing work ok?11:52
james_wI believe so11:54
liwhmm, if I do that, then merge into foo.deb again, debian/* gets removed, which is undesireable11:55
james_wbut if you run "bzr revert debian" when merging back it should resurrect, no?11:56
james_wthat might mean that it will try and add debian to foo again next time you merge11:56
liwyou know, it's really nice to be able to test these things without committing to a central repository and ruining everyone's day :)11:57
james_wah, if you merge .deb to foo, rm debian, commit, merge back and "bzr revert ." then commit it may do the right thing11:57
james_wi.e. do a "null merge" back straight away11:57
liwyeah, that seems to work11:58
=== kiko is now known as kiko-phone
=== kiko-phone is now known as kiko-fud
Jc2kLarstiQ: ping14:39
LarstiQJc2k: pong14:45
Jc2kLarstiQ: are you the one to speak to about bzr-hookless-email?14:47
LarstiQJc2k: I mentioned it on the mailing list, so I guess so :)14:47
LarstiQJc2k: I've only recently taken over maintenance, but shoot14:47
Jc2kLarstiQ: cool, i'm looking at making a more generic version and didnt want to turn up with it out of nowhere14:48
LarstiQJc2k: what are you thinking of?14:49
Jc2kwhat i want to do is have post-commit and post-change-branch-tip hooks, but outside of the bzr instance that actually commits14:49
LarstiQright, that makes sense14:50
Jc2ki have a test script (with tests) that does this, but its seperate to bzr-hookless-email atm14:51
Jc2kthere are some unanswered issues though - like i dont really want to use Branch.hooks[] because they would end up getting run by the bzr instance that lands the commits and by the script that is scanning14:52
Jc2kbut at the same time, it would be nice if things like bzr-cia could 'just work' for both modes of operation..14:52
Jc2kLarstiQ: and of course, bzr-hookless-email would then be the wrong name: it would be all about the hooks and it wouldnt just be about email :p14:55
james_wyou could define a new hook point, and each plugin could register in both?14:55
james_wor you could extend the API somehow14:55
Jc2kjames_w: the main problem with the 1st is each plugin would have to be aware of both entry points and have configuration foo to only fire from one of those14:56
Jc2ki had thought about new hook points that defaulted to firing from the existing hook points, but which could be fired externally 'after the fact' if you install this plugin14:57
LarstiQJc2k: I'm willing to work on this14:57
LarstiQJc2k: would you mind replying on the mailinglist stating your intention?14:58
Jc2kokie dokie. i'll push the play branch i have too.14:58
=== kiko-fud is now known as kiko-phone
phinzeis there a good doc somewhere for "how to land a feature branch" ?15:29
phinzehttp://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#sending-changes <-- looking at that15:31
Jc2kLarstiQ: mail sent, with a stupid typo :(15:32
=== tchan1 is now known as tchan
LarstiQJc2k: thanks16:07
=== thekorn_ is now known as thekorn
phinzehere we go... http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#merging-a-feature-into-the-trunk16:48
=== You're now known as ubuntulog
=== dereine[OFF] is now known as dereine
=== dereine is now known as dereine[OFF]
delaneyhi, I'm trying bazaar but it seems tortoisebzr does not work correctly on XP64.  Not getting the add/diff/etc menus, works fine from the console.  Is this a known problem?18:13
jelmerdelaney: I think that's supposed to be fixed in the latest version18:13
jelmerdeepjoy, yeah18:16
=== dereine[OFF] is now known as dereine
delaneyWell if I init from command line I can add etc, but if I init via tortoisebzr it does work18:17
delaneyget bzr: ERROR: No WorkingTree exists for "18:17
jelmernot sure then, sorry18:18
delaneyheh, actually I'm getting it with a second right click... weird, that has to be a bug.18:18
delaneyBut still no option to add.18:20
delaneythanks anyways jelmer18:20
=== dereine is now known as dereine[OFF]
mib_2nb27uI wanted to ask: there is a lot of progress on some features like stacked branches, views etc in recent bzr versions. But are there any plans to get bzr's speed closer to git?19:24
Lo-lan-domib_2nb27u: I regularly wonder about that too.  Apparently the standard answer is that bzr is pretty fast already (and it keeps improving), *apart* from startup time.19:26
Lo-lan-doAnd startup time seems to be mostly Python's fault.19:26
mib_2nb27uDoes it mean that hg is equally slow?19:27
Lo-lan-doVarious strategies are being tried to mitigate that.19:27
Lo-lan-doNo idea, I don't know hg :-)19:27
mib_2nb27uI thought that hg is almost equal to git19:27
Lo-lan-do(I hope I didn't talk too much rubbish)19:28
mib_maxAre there any  known chunks of code in bzr that could be optimized to get better performance or bzr already hit maximum performance allowed by current on-disk format?19:31
Lo-lan-doI don't know myself, but maybe others do.19:32
fullermdPlenty probably.19:33
fullermdIt's just mostly not a matter of "rewrite this function so it's faster", so much as "redesign the numbers, responsibilities, and positionings of abstraction layers".19:34
kumiAnyone know if nested tree support will land this year? It's the only SVN feature that makes me jealous19:35
mib_maxso this speed problems is derived from design of bzr and to make it comparable to git, bzr must be rewritten?19:35
mib_maxWhy then all this new features are being added into flawed codebase?19:36
Lo-lan-doI guess it's because there are people adding features and others working on speed.  It's not an either/or case.19:37
luksit's now flawed, it's called extensible19:37
vilakumi, the year is still young, all dreams are possible :-)19:37
vilamib_max: welcome on the channel, we appreciate your enthusiasm19:38
mib_maxspeed improvements aren't that visible (going from 100x times slower to 50x times slower than git is very good, but ...)19:38
vilabzr is layered so that some features can be added while other layers are rewritten for better performances19:38
vilas/added/& in some layers/19:39
mib_maxvila, and are there any plans to stop adding new features and make previous usable performance-wise19:39
Lo-lan-doWhy stop adding features?19:40
vilamib_max: no, that's more fun that way19:40
mib_maxLo-lan-do, to make old features usable?19:41
Lo-lan-doPeople who add features are not necessarily the ones able to improve performance anyway.  Stopping them from adding useful code would be counterproductive, right?19:41
vilaseriously, this is a free software project, different people have different aims19:41
vilaLo-lan-do: exactly19:41
vilaMany bzr users are perfectly happy with the actual performance19:42
mib_maxof course, but I though that bzr is Canonical sponsored project and there are some developers working on it from Canonical, right?19:43
vilaI personally have problems with performance for one project, but for most of my daily usage, performance is not a concern19:43
vilamib_max: and Canonical also ask for features with priorioties higher than performance (AFAIK), so what ?19:43
Lo-lan-dovila: It sometimes is, for me.  Emacs has decided to ask bzr whether a file is up-to-date whenever I open it, which means a one-second delay everytime I open a file.  It gets boring after a while.19:44
vilaLo-lan-do: is that vc.el related ?19:44
=== kiko-phone is now known as kiko-afk
mib_maxvila, is it so? I thought their goal would be to make bzr use as wide as possible, but most projects switches to either hg or git, because they are much faster19:45
Lo-lan-dovila: Possibly.  How can I check?19:45
vilamib_max: I don't know the internals of Canonical so I can't speak for them19:46
mib_maxvila, and another question: doing "bzr branch lp:bzr" is quite slow for me, I believe mostly it is because it is downloading 96Mb repository for 15Mb project19:46
vilaLo-lan-do: I'm using emacs myself and I don't have the problem, what's your version ?19:46
mib_maxthat big size of repository is because of a lot of changesets or what?19:47
vilamib_max: the initial branch may be slow but you're asking for it so I think I don't understand your problem19:47
Lo-lan-dovila: 22.2.1 from sid19:47
vilaLo-lan-do: 22.1.1 here, so I will have to use my 8-ball19:48
Lo-lan-domib_max: Try a lightweight checkout if you don't want the full history, or a stacked branch.19:48
vilaStacked branch is for pushing, why are your branching bzr mib_max ?19:48
mib_maxthe problem for me that repository size is about 10x of source tree size19:48
mib_maxIs branching bzr forbidden operation in bzr?19:49
Jc2ki think the bzr repository is in an older format?19:50
vilamib_max: cool down, I'm asking about your expected needs to give you an appropriate answer :)19:50
vila96 ~= 6 x 15...19:50
vilaSo what ?19:50
mib_maxactually it is 12, not 15, I will convert it to git and see how it will perform19:51
mib_maxvila, no problem here, I just thought that bzr is incapable of branching such big changests, e.g. I wasn't able to branch lp:mysql, it tooked too long and made me bored19:52
luksthis looks like regular trolling to me :)19:52
mib_maxvila, I believe bzr branch definetly needs to output some more information about how much it is downloading instead of just rotating |19:52
Jc2ki think trunk bzr does.19:53
vilamib_max: try bzr.dev19:53
mib_maxI tried19:53
mib_maxit shows some corruption19:53
vilaWait ! It's not performance related ! It's a feature ! *You* don't want it. Isn't it ?19:53
mib_maxNo revisions to pull.] Pull phase 0/219:54
mib_maxIt is performance related19:54
mib_maxit is so slow, that it needs to show that it is still working and not frozen19:54
vilaYou mean your internet connection ?19:54
mib_max"No revisions to pull.] Pull phase 0/2 " - output from ./bzr pull on latest bzr.dev19:54
vilaCare to check your CPU usage and network usage ?19:55
mib_maxIt would be much better if bzr will tell me that it is downlading at XXX Kbps19:55
vila<Jc2k> i think trunk bzr does.19:56
vila<vila> mib_max: try bzr.dev19:56
mib_maxit is not providing it me for pull19:56
mib_maxWill try for branch19:56
vilaOh wait ! No, I have to write that for http :-)19:56
vilaIt works for sftp only so far19:56
mib_maxit provides something for branch that is major good step here)19:57
mib_maxbut I think better will be not copied "records" but bytes19:57
mib_maxAnd of course pull operation needs it too19:57
mib_maxWhat lp:bzr uses? http or sftp or bzr?19:57
Lo-lan-doI'm sure your patch will be much appreciated.19:58
vilamib_max: when did you try bzr branch lp:mysql ?19:58
mib_maxI tried to found pull.py, just as log.py but it is not there, where is pull output in source tree?19:58
mib_maxvila, what do you mean "when" if you want I could do it now19:59
vilamib_max: please do so19:59
Jc2kthe new progress stuff is swweeet.19:59
mib_maxusing bzr.dev or bzr 11_rc19:59
mib_maxtime ~/bzr/bzr branch lp:mysql-server .................20:01
mib_maxwhat lp: is using? sftp, bzr or http?20:04
vilaall of them20:04
Lo-lan-doAnd IPoAC20:04
mib_maxbtw, bzr.dev does branch much better, now I have some moving numbers on screen :)20:05
vilatime -p bzr branch lp:mysql-server so-what20:06
vilaBranched 2710 revision(s).20:06
vilareal 211.1720:06
vilauser 38.3720:06
vilasys 47.9320:06
vilaThat includes building the working tree on a NFS mounted file system20:07
mib_maxI am doing it still20:08
mib_maxwhat is your internet connection speed?20:08
mib_max4Mdown/0.7Mup, so I will do it about 5.5 times slower20:11
mib_maxwhat is the size of .bzr in mysql?20:11
viladu -sk .bzr20:11
amanica_as far as I can see lp: = bzr+ssh://bazaar.launchpad.net/20:12
mib_max680Megabytes?? oO20:12
vilaBut I use a shared repository which contains many more than just lp:mysql-server, so I didn't just download that :-)20:13
mib_maxBecause you already had that revisions?20:13
mib_maxOk I will Ctrl-C it20:14
vilaI had to download an additional pack file of about 7M containing the revisions I didn't have20:15
=== mvo__ is now known as mvo
mib_maxOk. Another thing. Could you explain me some statements on http://whygitisbetterthanx.com/#cheap-local-branching20:20
mib_maxIs it true that bzr can do thit as easy as git and author of site is incorrect?20:21
vilamib_max: <vila> time -p bzr branch lp:mysql-server so-what20:24
vila<vila> Branched 2710 revision(s).20:24
vila<vila> real 211.1720:24
vila<vila> user 38.3720:24
vila<vila> sys 47.9320:24
vilaSounds pretty cheap to branch a ~130M tree to me20:25
vilaand will certainly be faster if I was using a local FS20:25
mib_maxIt is your old results. You cheated, having most of revisions locally)20:25
Jc2kyou can also have one working tree and use 'bzr switch' to connect it to different branches20:25
vilamib_max: I think luks was right20:26
mib_maxDownload speed meter and reporter in bzr.dev makes it more clear that in that case internet is bottleneck20:26
mib_maxwhat lucks said?20:26
mib_maxAm I loosing messages?20:26
vilaEither you're trolling or you don't understand what you're talking about, you asked about cheap branching, not initial branching20:27
mib_maxI don't thaught that this repository will be 600M in size, bzr didn't told me that and was just rotating20:27
mib_max*rotating |20:27
mib_maxNow in bzr.dev it makes much more sense20:28
pickscrapeBranching mysql into a clean shared repository just took me:20:30
pickscrapereal 911.3920:30
pickscrapeuser 231.3820:30
pickscrapesys 9.5720:30
pickscrapeCreating a local branch of the branch I just created took:20:30
pickscrapereal 35.6220:30
pickscrapeuser 4.1920:30
pickscrapesys 2.0820:30
mib_maxFrom hd or internet? I realized that in my case internet was bottleneck, sorry for complaints.20:30
pickscrapeMy first branching was from launchpad. I didn't have any revisions previously downloaded.20:31
mib_maxyou have pretty fast internet access to lauchpad :)20:31
Jc2kmib_max: if you were using a standard bazaar workflow (shared repository, branches with no trees and one working copy) then you could do 'bzr branch foo bar' and it would be instant. inside the working copy you could do 'bzr switch bar' - any commits there would now be recorded against the bar branch.20:31
pickscrapeVerizon fios (15MB down)20:32
Jc2kmib_max: you could then bzr switch foo and be back on the first branch20:32
mib_maxJc2k, is it answer for the question about whygitisbetter? I understand what you said, but statement on that site made me thought that my understanding is somewhere flawed ;) site should be updated.20:34
vilamib_max: which is why I did the bzr branch above, not to cheat, but to show that things doesn't have to be slow with bzr just because everybody repeat the meme20:34
vilaThis channel is more about answering questions about bzr than doing advocacy for or against it or any other DVCS (at least that's my impression after a couple of years)20:35
mib_maxOk. Ok. I apologise for complaint about slow branching from lp. bzr wasn't showing me that it is my internet connection that sucks. Bzr.dev got this nearly fixed so no problem here for now.20:36
mib_maxwhat tool I should use to view docs in bzr.dev/docs/developers ? It contains some includes ...20:38
vilamake docs; use $your_favorite_browser doc/index,htlm20:40
vilamake docs; use $your_favorite_browser doc/index.html20:40
mib_maxemerge docutils did the magic for make docs20:40
mib_maxis performance-roadmap document from that directory outdated?20:44
mib_maxAre there any ways to read what was written during my connection loss?20:54
vilawhat connection loss ? Ctrl-c ?20:55
mib_maxadsl provider breaking connection every 24h to do accounting20:55
vilaOh my... spiv ! Here is a use case to retry hpss requests !20:57
vilamib_max: I don't think so20:57
vilamib_max: there is no general answer, were you doing a bzr branch ?20:58
mib_maxI am about IRC :)20:58
vilano disconnection msg appeared here20:59
mib_maxI am using mibbit.com to connect to IRC20:59
mib_maxmaybe their server was connected all the time20:59
vilaI see20:59
mib_maxAre there any updated performance_*.txt from doc/developer as ones in that dir talks about changes planned to do after 0.16, about switching from knit repo etc21:01
vilamib_max: unfortunately no, some of the ideas described here have been implemented, some are working on, certainly all of them will be addressed at one point, but the document itself hasn't been updated21:03
mib_maxis it possible for mere mortal to understand that topic and try to contribute to performance optimization of bzr? Any easy starting points?21:04
vilamib_max: you're welcome, my suggestion will be to start running 'bzr selftest' first21:06
vilasecond, go to launchpad and search for bugs tagged 'easy' or 'trivial'21:07
mib_maxwhat is tradition? are all tests to pass?21:07
vilaAll commit on bzr.dev pass all tests on our gate keeper (nick pqm)21:07
vilaAll submissions should pass all tests21:08
mib_max14 errors so far21:08
vilaWhat os ?21:08
mib_maxfor example21:08
mib_maxERROR: blackbox.test_remove.TestRemove.test_remove_one_deleted_file     exceptions must be strings, classes, or instances, not exceptions.OSError21:08
mib_maxlinux gentoo21:08
vilahere you go :-)21:08
vilapatch welcome !21:09
mib_maxso you say that on your gatekeeper all tests passes?21:09
vilapython version ?21:09
mib_max2208/15811 in 3m28s, 26 err, 4 missing21:10
vilaThat's very very surprising21:10
Jc2kim seeing quite a few "run() got an unexpected keyword argument 'verbose'21:11
vilaIf you do 'bzr log --short' in your bzr working tree you will see all commits done on the Patch Queue Manager21:11
vilaAll of those commits were done after a 'make check'21:11
mib_maxmaybe some problems are because of execution? I execute bzr in bzr.dev working tree21:12
vilamib_max: that's what I do many times every day : './bzr selftest'21:12
mib_maxactualy am using PATH/bzr selftest21:13
mib_max"~/bzr/bzr selftest"21:13
vilaselftest should report which bzrlib is used and which python version is used in the first output lines21:13
Jc2kim seeing lots of loom related errors21:13
vilaJc2k: loom.... shouldn't fail more than ... oh wait... if they are stacked branch related, the bug is known21:14
mib_maxit is using 1.12dev21:14
mib_max44errs so far21:14
mib_maxmake check failed too21:14
mib_maxI think it is some problems with pyx files21:14
mib_maxmaybe I built pyrex libs in a bad way21:15
vilamib_max: sounds like a probable cause or a bad version of pyrex (I think we blacklisted one version of pyrex)21:16
mib_maxdeleted *.so from bzrlib21:16
mib_maxnow things are going better21:16
mib_maxI am using pyrex
mib_maxis it bad?21:16
vilaI don't think so, I think had problems21:16
mib_maxwhat is recommended version?21:17
viladid you run a bare 'make' ?21:17
vilaI don't know, jam should21:17
beunobranching large branches with --stacking is awesome. Why don't we advertise that more?21:17
vilabeuno: because you do that better than us ? :-)21:18
mib_maxpyrex modules are causing problems21:18
mib_maxvila, what version of pyrex are you using?21:18
beunovila, heh, maybe, maybe. I guess I'll need to blog!21:18
vilamib_max: I don't use any because I run from the same sources for several OSes21:19
vilabut I'm not a good example :)21:19
mib_maxvila, so you are running selftest using only python modules?21:19
beunovila, btw, I'd like to have a (voice) chat with you at some point about a few ideas around bzr-upload21:19
vilabeuno: we should try that this week-end (where are you this week-end ? Argentina ?)21:20
beunovila, sounds good. I am in Argentina. We can ping-pong and see when both of us are awake and lucid21:21
mib_maxvila, how long does it usually takes to run all tests?21:21
vilamib_max: locally yes, but in some branches under some OSes (mainly Ubuntu) I build them sometimes21:21
vilamib_max: ~10/15 minutes in my case21:21
vilaBut once you work on specific problems you don't have to run the whole test suite every time21:22
vilaThere are different ways to select a subset of the tests21:22
mib_maxis it ok: /home/max/bzr/bzrlib/lockable_files.py:116: UserWarning: LockableFiles(<bzrlib.transport.local.LocalTransport url=file:///tmp/testbzr-FwhMsk.tmp/bzrlib.tests.blackbox.test_shelve.TestShelveList.test_shelf_order/work/.bzr/repository/>) was gc'd while locked   warnings.warn("%r was gc'd while locked" % self)21:23
mib_maxLockable file was gc'd while locked21:23
vilaI don't like it but it's not a test failure, just noise21:23
mib_maxAnd it is ok to have XFAIL with bug # attached? (known bug)21:24
vilaXFAIL == expected failure21:24
vilaThat's how we track some problems that are known but not yet addressed21:24
mib_maxyes it is what I thought21:24
vilabeuno: sounds like a good plan21:25
mib_maxare there any ways to run tests in several threads?21:25
vilanothing automatic yet, this is discussed from time to time but nobody never did it (which is an indication that nobody really needs it)21:26
vilaBut the test framework itself doesn't forbid it either21:26
mib_maxwill it be x time faster to run it across x cores? If runned on tmpfs it is cpubound, right?21:27
vilaMost of the test addicts prefer to run the "right" test for the part they are working on and that generally run in seconds21:27
vilas/the right test/the right testS/21:28
mib_maxi see21:28
vilarunning the full test suite is for when you do a break or switch to another task :)21:29
vilaor before submission of course :)21:29
mib_maxvila, btw what's the point of running selftest if I have no changes now and they all will pass, won't they? :)21:30
vilaThe point is to make sure they all pass so that you know which one you break :)21:30
vilaAnd you just ran into that don't you ?21:31
mib_maxinto what?21:31
mib_maxInto breakage of tests by bad pyrex?21:31
vilayup, I think we had a bug here on gentoo and it will be helpful if you could file it on launchpad21:32
vilas/we/had/we *have/21:32
vilas/we had/we *have*/21:32
mib_maxAs far as I understand gentoo doesn't use pyrex to build its own bzrs, it uses .c provided by tarball21:33
vilamib_max: pyrex on hardy21:34
vilasynchronicity :-) I was wondering about that21:34
mib_maxit is because current stable pyrex in gentoo is older than one, needed to build bzr21:35
vilamib_max: You'll have to find someone more knowledgeable about pyrex than me though21:35
mib_maxdowngraded to and problems are gone21:36
mib_maxor no21:36
mib_maxthey are still here)21:36
mib_maxdoes pqm use pyrex?21:36
vilamib_max: try jam if he come online later, I will leave shortly21:36
vilapqm certainly uses pyrex but I don't know which version21:36
mib_maxok thanks21:37
* pickscrape runs selftest on gentoo too to see what happens...21:38
vilamib_max: pyrex0.9.7-1 on intrepid, so this one should works too (I'm pretty sure some core devs run intrepid (or may be they are already on jaunty...)))21:38
mib_maxvila, pyrex 0.9.7 is not available in gentoo :( only 0.9.6 and then 0.9.821:39
mib_maxwill leave it as it is for now21:40
pickscrapeSo far I just have an XFAIL21:40
pickscrapemib_max: how far in did you start getting errors?21:41
mib_maxpickscrape, are you using bzr from gentoo or from bzr.dev? have you built pyrex modules?21:41
vilaI'm sure a patch ensuring we're compatible with 0.9.8 will be warmly welcome, if you're interested in working on performance, ensuring the C extension works is definitely part of it21:41
mib_maxabout 150-200 tests21:41
pickscrapeAha, I've got 4 now, but only after 1000 or so.21:41
mib_maxI get first near 15021:42
pickscrapemib_max: I'm using a vanilla bzr.dev checkout with nothing made, but I just realised I ran bzr rather than ./bzr, so I'm starting again21:42
mib_maxyou wont get problems because with make you won't use pyrex modules21:42
pickscrapeok, I just ran make and restarted21:43
mib_maxit worked? are you using pyrex from ~?21:43
pickscrapeNo, I'm getting errors21:44
mib_maxon stable pyrex it complains about some modules incompatible with such old version of pyrex21:44
mib_maxand in the begining of make you have complaint from bzr?21:44
pickscrapeAh yes, it did complain about that.21:45
pickscrapeBut the results I'm getting a different to those I got before running make.21:45
pickscrapes/ a / are /21:45
pickscrapeAll of the errors so far are "exceptions must be strings, classes, or instances, not exceptions.OSError"21:46
mib_maxsome here21:46
pickscrapeOh well :)21:46
gotgenesWhat information is stored about a merge when I commit it? Is there somewhere I can view it? I can't seem to find anything about it in bzr log, but I see Launchpad knows a merge occured.21:46
lifelessgotgenes: log shows merges as indents21:48
davidstraussIs it possible to merge in zero revisions to merely establish a common ancestor?21:48
gotgeneslifeless: Oh, it surely does. But I did bzr log -l 1 and it was only showing the commit message.21:49
gotgenesIs that a bug?21:49
ronnyis there any way to get something like WorkingTree.list_files thats not recursive and pinned down to a specific dir/file21:49
gotgenesShouldn't it show the associated commit message?21:49
pickscrapegotgenes: you asked it to show only one revision, which in your case was the merge revision21:50
lifelessgotgenes: there is a discussion at the moment on the list about this; it is arguably a bug21:50
lifelessgotgenes: but its arguably right too :P. We may add log -c, like diff -c, to show the log of everything from before:X to X21:51
gotgenespickscrape: True; but I guess the commits from the branch I merged from are relevant to the commit of the merge.21:51
pickscrapegotgenes: that could be quite a large can of worms though :)21:52
lifelessronny: 'bzr ls'21:52
gotgeneslifeless: Ah okay. That seems a good compromise.21:52
lifelessronny: perhaps21:52
ronnylifeless: im in search of an api21:52
lifelessgotgenes: you can simulate it today with bzr log -r before:foo..foo21:52
lifelessronny: cmd_ls in builtins.py then21:53
lifelessronny: sorry that I don't have more detail offhand21:53
gotgeneslifeless: Excellent tip! Many thanks. :-)21:53
* ronny goes reading21:53
gotgenesAlso, out of curiosity, is anyone here at all familiar with any efforts to integrate bzr into NetBeans?21:53
ronnylifeless: oh, seems like the ls command is just using the full recursive version and ignores parts of the resultset21:55
lifelessronny: do you need status like results?21:55
lifelessronny: e.g. do you need unversioned files as well as versioned?21:55
ronnylifeless: yup21:56
ronnylifeless: its for anyvc workdir status info21:56
lifelessronny: ah21:56
lifelessronny: then 'iter_changes' definitely21:56
lifelessits the workhorse for status21:56
ronnydoes that give me unversioned/ignored=21:56
lifelessif you ask it to21:56
lifelessgotgenes: http://bazaar-vcs.org/IDEIntegration21:57
ronnyis that api considered very stable?21:58
ronnycause i'll offload the actual implementation to javier ^^21:59
gotgeneslifeless: Yeah, I see "We Need You" though I'm not a Java developer.21:59
lifelessronny: iter_changes is pretty stable yeah22:00
lifelessits exposed in bzr-xmlrpc too22:01
lifelessfor eclipse and other VC's that want status information22:01
gotgeneslifeless: Is that a wiki (community editable) page?22:02
ronnywell, in pida we "invented" anyvc for vcs abstraction22:02
lifelessgotgenes: yes22:03
ronnyand boy is abstracting branching patterns fun22:04
gotgeneslifeless: excellent. I'm looking for a way to actually edit it. I see Komodo supports Bazaar and would like to add it to that page.22:05
gotgenesAh, okay22:05
gotgenesgot it22:05
bialixgaryvdm: ping22:12
amanica_I see all the bzr code have unix style line endins. How is it kept that way?  Is there a test for it or were we just lucky?22:13
amanica_I ask because I'm about to add such a test as part of the trailing whitespace cleanup. and I'm just wondering.22:14
amanica_I cant find any documentation about thit in HACKING either22:16
amanica_so I'll add some22:16
bialixbut not all text files in the bzr.dev has LF-only22:16
beunoamanica_, be aware that branches with styling cleanups are usually rejected because of all the spurios conflicts they cause22:17
amanica_I know22:17
bialixpoolie explicitly asked about this cleanup22:17
beunoah, cool22:17
amanica_bialix I tried to find offending stuff, but could not22:18
bialixbut it's not py22:19
amanica_ah, but at the moment its not checked22:19
amanica_its not part of bzrlib so its not considered part of the code22:20
bialixso I guess the real answer on your initial question: because all bzr hackers are linux guys22:20
amanica_contrib is also like this22:20
amanica_so I thought that while I'm at it, I can check for that too22:21
* bialix wanna to say to garyvdm that we have the fix for gentle stop subprocess problem22:24
ronny"gentle stop" ?22:24
bialixwithout using hammer and BFG22:25
bialixwith "please" :-)22:26
ronnywhere can this happen?22:27
bialixit's for QBzr22:27
* bialix mutters: why for initial push to lp told about using default stacking branch, if the push anyway send all the data?22:39
* bialix waves bye22:44
jamJc2k: Some of the loom failures should be fixed in loom trunk22:48
jamWe updated "bzr status" to add another parameter22:48
jamand loom "monkeypatches" "bzr status" and thus also needed to be updated22:48
Jc2kjam: ah cool22:53
=== dereine[OFF] is now known as dereine

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!