| lifeless | jelmer: I'm happy to put the effort in but I need clarity | 00:00 |
|---|---|---|
| jelmer | lifeless, not sure I follow | 00:00 |
| LarstiQ | rousskov: good luck! I'll check backlog tomorrow to see how it played out for you. And hire a lawyer ;) | 00:00 |
| sevenseeker | 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 |
| jelmer | 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 | |
| rousskov | FYI. I have to leave in 20 minutes. but I will be back. | 00:00 |
| lifeless | jelmer: rousskov tried rebase --always-rebase-merges --new-nick | 00:00 |
| lifeless | jelmer: he says it stopped setting the nick, and still skipped the merges | 00:00 |
| lifeless | I can't see why it would stop setting the nick | 00:01 |
| jelmer | sevenseeker, not seeing what? | 00:01 |
| jelmer | lifeless, Well, you're the author of --new-nick :-) | 00:01 |
| lifeless | jelmer: thanks :P | 00:01 |
| sevenseeker | how to use an existing working copy... the example creates a bzr repo first then checks out | 00:02 |
| lifeless | rousskov: can you edit rebase.py (~/.bazaar/plugins/rebase/rebase.py) | 00:02 |
| rousskov | Sure | 00:02 |
| jelmer | sevenseeker, just run bzr in the working copy | 00:02 |
| jelmer | 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 |
| lifeless | --- rebase.py 2009-01-15 06:07:29 +0000 | 00:03 |
| lifeless | +++ rebase.py 2009-01-16 00:02:38 +0000 | 00:03 |
| lifeless | @@ -177,6 +177,7 @@ | 00:03 |
| lifeless | oldparents = parent_map[oldrevid] | 00:03 |
| lifeless | assert isinstance(oldparents, tuple), "not tuple: %r" % oldparents | 00: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 |
| lifeless | rousskov: then run the process as previously described, with "--new-nick --always-rebase-merges" | 00:04 |
| rousskov | OK. | 00:05 |
| lifeless | it will drop into a debugger, similar to gdb | 00:05 |
| lifeless | at the merge revisions | 00:05 |
| lifeless | n will step a line | 00:05 |
| lifeless | s | 00:05 |
| rousskov | do you want me to create another fake_upstream? | 00:05 |
| lifeless | s will step into | 00:05 |
| lifeless | rousskov: no, the fake upstream is fine | 00:05 |
| lifeless | just a new fresh-branch | 00:06 |
| rousskov | OK | 00:06 |
| lifeless | bt will get a backtrace | 00:06 |
| lifeless | print EXPR will print the expression | 00:06 |
| sevenseeker | 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 |
| sevenseeker | jelmer: btw, I appreciate your help and clues :) | 00:07 |
| lifeless | rousskov: when it stops the first time, I'd like to identify if its one of the revisions that was being skipped | 00:07 |
| lifeless | so 'p oldrevid' | 00:07 |
| jelmer | sevenseeker, 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 |
| lifeless | then in your BADBRANCH run bzr log --show-ids, and grep for the revid | 00:08 |
| rousskov | Is it bzr branch $badly $fresh | 00:09 |
| lifeless | yes | 00:09 |
| rousskov | Or bzr branch -r $THATNUMBER $badly $fresh | 00:09 |
| lifeless | the former | 00:09 |
| rousskov | OK | 00:09 |
| lifeless | bzr branch $badly $fresh | 00:10 |
| lifeless | cd $fresh | 00:10 |
| lifeless | bzr rebase --new-nick ../fake-upstream | 00:10 |
| lifeless | except with --always-rebase-merges added | 00:10 |
| rousskov | OK. I am in the debugger. | 00:11 |
| lifeless | p oldrevid | 00:11 |
| rousskov | OK. I did the grep in $badly. | 00:12 |
| rousskov | Found parent and revision IDs | 00:13 |
| rousskov | Found two matches: parent and revision-id | 00:14 |
| lifeless | look at the revision with that revision id | 00:14 |
| sevenseeker | 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 |
| lifeless | (if you didn't get context, you might prefer less and a search in the output) | 00:14 |
| sevenseeker | when I run: bzr branch <svn working copy> <new bzr branch> | 00:14 |
| lifeless | or bzr log -r rev:$REVISIONID | 00:14 |
| jelmer | sevenseeker, that's a bug fixed in the 0.5 unfortunately | 00:14 |
| sevenseeker | oic | 00:14 |
| === dereine is now known as dereine[OFF] | ||
| rousskov | I have context. | 00:15 |
| lifeless | is it one of the merges that were getting skipped? | 00:15 |
| jelmer | sevenseeker, it should be possible to work around it by using "bzr branch <repository-url> <bzr-url>" | 00:15 |
| sevenseeker | would bzr URL be (since it is non existent on my box) something like file://foo/spam/eggs? | 00:16 |
| rousskov | lifeless, no | 00:16 |
| rousskov | It is a change on a $badly branch | 00:16 |
| jelmer | sevenseeker, no, it can be a local path | 00:16 |
| sevenseeker | awesome, thank you I will try that | 00:16 |
| lifeless | rousskov: then you're looking at a child of the revision | 00:16 |
| lifeless | rousskov: please do bzr log -r rev:$REVISIONID instead | 00:17 |
| rousskov | You are right, sorry. | 00:17 |
| rousskov | I looked at parent match, not revision-id | 00:17 |
| lifeless | thats ok | 00:17 |
| rousskov | The revision-id change was indeed skipped, I think. | 00:18 |
| lifeless | ok good | 00:18 |
| rousskov | It is a merge from a parent branch. | 00:18 |
| lifeless | now we try to figure out why it is being skipped | 00:18 |
| lifeless | what does 'p skip_full_merged' show | 00:18 |
| rousskov | FYI. I only have a few minutes | 00:19 |
| lifeless | ok | 00:19 |
| rousskov | False | 00:19 |
| lifeless | when you need to go, go. But this is stuf I can't reproduce | 00:19 |
| rousskov | I understand. | 00:19 |
| lifeless | ok | 00:19 |
| lifeless | hit n ENTER | 00:19 |
| lifeless | keep doing that until the line it shows is | 00:20 |
| rousskov | -> parents = [new_parent] | 00:20 |
| lifeless | if parent in additional_parents and parent not in parents: | 00:20 |
| rousskov | -> if parent in additional_parents and parent not in parents: | 00:20 |
| sevenseeker | jelmer: seems to have worked, I will be working on it tonight and see for sure... thank you very much | 00:20 |
| lifeless | 'p parent' | 00:21 |
| lifeless | 'pp additional parents' | 00:21 |
| lifeless | 'p parents' | 00:21 |
| lifeless | pastebin that if you can, it won't disclose the nick we're removing | 00:22 |
| lifeless | go around the for parent in parents loop using 'n ENTER' | 00:22 |
| lifeless | oh never mind | 00:22 |
| lifeless | I see the bug | 00:22 |
| lifeless | jelmer: bad code is bad :) | 00:22 |
| lifeless | thats rousskov | 00:23 |
| * rousskov crosses fingers | 00:23 | |
| lifeless | jelmer: please look at the loop: summarised as 'for parent in parents: parents.append(parent)' | 00:23 |
| lifeless | jelmer: shouldn't that be 'for parent in oldparents: parents.append(parent)' | 00:23 |
| rousskov | 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 |
| rousskov | lifeless, I will try follow your future instructions in about an hour. Thank you. | 00:26 |
| jelmer | lifeless: yeah, I think so | 00:28 |
| poolie1 | thumper: woo | 00:28 |
| poolie1 | let's go | 00:28 |
| thumper | poolie1: OK | 00:30 |
| === kiko-phone is now known as kiko | ||
| lifeless | rousskov: I will write a test case for this | 00:35 |
| lifeless | rousskov: and if it fixes it you should be able to just pull in the changes | 00:36 |
| lifeless | jelmer: whats the bug number I'm fixing? | 01:01 |
| poolie1 | 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 |
| poolie1 | blaaaaah | 01:08 |
| lifeless | jelmer: bug 266897 fixed | 01:11 |
| ubottu | Launchpad bug 266897 in bzr-rebase "bzr-rebase loses merges" [High,Triaged] https://launchpad.net/bugs/266897 | 01:11 |
| jelmer | lifeless, cool | 01:11 |
| lifeless | rousskov: when you return, cd to ~/.bazaar/plugins/rebase, bzr revert, bzr pull | 01:11 |
| lifeless | rousskov: then repeat the test - make a new fresh branch, cd to that, bzr rebase --new-nick ../fake-upstream | 01:12 |
| lifeless | rousskov: you do *not* need --always-rebase-merges | 01:12 |
| lifeless | jelmer: https://code.edge.launchpad.net/~lifeless/bzr-rebase/dev | 01:12 |
| lifeless | jelmer: I'd really like to be able to rebase when there is nothing new to pull in | 01:13 |
| lifeless | jelmer: to allow rebase to support just doing edits like this | 01:13 |
| jelmer | lifeless, that should already be possible | 01:13 |
| lifeless | jelmer: no, it complains/errors | 01:13 |
| lifeless | jelmer: replay gave spurious conflicts | 01:13 |
| jelmer | lifeless, if you are already up to date to master, it will just pull | 01:13 |
| lifeless | jelmer: no, wrong graph case | 01:14 |
| lifeless | jelmer: imagine that master hasn't changed | 01:14 |
| lifeless | jelmer: and you object to the concept of rebase-to-do-a-pull because it turns tested code into untested code | 01:14 |
| lifeless | :) | 01:15 |
| lifeless | jelmer: anyhow, if master hasn't changed, but you want to cause a rebase to be executed, it refuses | 01:15 |
| jelmer | lifeless, yes, why would you want to rebase in that case? | 01:15 |
| lifeless | you have to do a commit to master - a no-change commit - to force it to rebase | 01:15 |
| lifeless | jelmer: I have several use cases. This nick editing is one of them | 01:15 |
| jelmer | lifeless, I don't think rebase should be a generic history patching tool | 01:15 |
| lifeless | jelmer: another is to combine two revisions out of the set being rebased | 01:16 |
| lifeless | jelmer: a third is to exclude a revision | 01:16 |
| lifeless | jelmer: its all part of the overall rebase -i stuff | 01:16 |
| jelmer | lifeless, That doesn't make any sense until -i is implemented | 01:16 |
| lifeless | chicken and egg | 01:16 |
| jelmer | right | 01:16 |
| lifeless | so it makes sense now | 01:17 |
| lifeless | its just that its not very useful until -i is implemented | 01:17 |
| jelmer | sure | 01:17 |
| lifeless | anyhow | 01:17 |
| lifeless | I'm not asking that it rebase by default when there is nothing new on master | 01:17 |
| lifeless | just that there be some way to say 'trust me and JFDI' | 01:17 |
| jelmer | 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:22 |
| lifeless | jelmer: sure, neither do I unless some other change is actually occuring | 01:23 |
| lifeless | jelmer: I'm at a bit of a loss about how to make a --force-rebase option though | 01:24 |
| jelmer | 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:25 |
| lifeless | jewell it would have been useful for rousskov here | 01:27 |
| jelmer | lifeless, ah, you mean for --new-nicks ? | 01:29 |
| lifeless | yes | 01:29 |
| jelmer | I see rebase mostly as a tool for shaping the graph, not one that changes the actual contents of revisions | 01:29 |
| lifeless | which *is* implemented | 01:30 |
| jelmer | not sure I follow? | 01:30 |
| jelmer | what is implemented? | 01:30 |
| lifeless | new-nick is implemented :) | 01:30 |
| lifeless | anyhow, I think there is such overlap in shaping the graph and setting content that we shouldn't write two tools | 01:30 |
| jelmer | I think the UI from rebase is confusing if people are using it for other things than rebasing on a master branch | 01:31 |
| jelmer | If you want to fix up a couple of revisions, you don't need the concept of a master branch at all | 01:32 |
| lifeless | well | 01:32 |
| lifeless | we need these fixup capabilities | 01:32 |
| lifeless | common requests: | 01:32 |
| lifeless | edit revision metadata | 01:32 |
| lifeless | delete badly added files | 01:32 |
| lifeless | split out history when a project is factored out | 01:33 |
| jelmer | I agree we need the fixup capabilities, I just don't think rebase should be the answer. | 01:33 |
| jelmer | We need a separate tool that can apply specific modification commands to a range of revisions | 01:33 |
| lifeless | why? | 01:34 |
| jelmer | 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 |
| lifeless | well bzr has that concept itself | 01:36 |
| jelmer | It's confusing that people would need two branches if they are just trying to fix a couple of branch nicks | 01:37 |
| lifeless | I don't see it being an issue | 01:37 |
| jelmer | 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 |
| lifeless | anything that rewrites contents will contain all of rebase | 01:37 |
| lifeless | except for [perhaps] some of the plan generation | 01:38 |
| jelmer | lifeless: Executing the plan would be different | 01:39 |
| lifeless | jelmer: not much | 01:39 |
| jelmer | lifeless, since rebase can just do a merge, but in other situations (changing the conents of the revision) this is not sufficient | 01:39 |
| lifeless | jelmer: I think you are 'borrowing trouble' | 01:39 |
| jelmer | 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:40 |
| jelmer | lifeless, borrowing from where? | 01:41 |
| lifeless | 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 |
| lifeless | jelmer: this is *identical* | 01:41 |
| lifeless | jelmer: the only difference is that an edit needs to occur to the tree before the commit | 01:42 |
| jelmer | lifeless: preserving merges isn't a problem if you're not changing the graph | 01:43 |
| jelmer | lifeless, Setting up the working tree is trivial, it's a simple revert. | 01:43 |
| lifeless | jelmer: look, if I put up a merge you object to, we can talk about it | 01:44 |
| lifeless | 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 |
| lifeless | I'm not working on arbitrary editing at the moment | 01:44 |
| lifeless | so the only thing I care about right now is whether the new-nicks patch is acceptable | 01:44 |
| jelmer | 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 |
| lifeless | jelmer: ok; I'll fork rebase then I guess | 01:46 |
| lifeless | jelmer: because I don't want to reinvent all the useful stuff in rebase | 01:46 |
| jelmer | lifeless: Uhm, what about just adding a separate command provided by the rebase plugin? | 01:47 |
| lifeless | jelmer: I don't understand, it would be a complete copy and paste | 01:47 |
| rousskov | lifeless, 1 conflicts encountered. Should I resolve and continue-rebase? | 01:48 |
| lifeless | 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 |
| lifeless | rousskov: yes please | 01:48 |
| lifeless | rousskov: continue-rebase --new-nicks I think | 01:49 |
| lifeless | rousskov: I deliberately avoided recording new-nicks in the plan, because I wanted to be minimal | 01:49 |
| rousskov | Sigh. Too late. I ran rebase-continue without --new-nicks | 01:50 |
| * rousskov will redo. | 01:50 | |
| lifeless | rousskov: hmm, I need to add the option | 01:51 |
| lifeless | one second | 01:51 |
| jelmer | 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:52 |
| lifeless | jelmer: well I thought replay would be appropriate | 01:53 |
| lifeless | jelmer: but it caused conflicts for rousskov; so I figured there was something wrong there | 01:53 |
| rousskov | lifeless, but I see signs of progress: everything got merged and I have a mixture of old and new nicks, as expected. | 01:53 |
| rousskov | well, rebase is causing conflicts now as well. | 01:54 |
| lifeless | jelmer: I mean, rousskov's use case should just have been 'branch from the start point; replay --new-nick BADBRANCH' | 01:54 |
| lifeless | jelmer: but it conflicted, which is weird | 01:54 |
| jelmer | lifeless, I think replay would be much more appropriate than rebase | 01:54 |
| lifeless | jelmer: I added new-nick to replay as well | 01:54 |
| lifeless | 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 |
| lifeless | rousskov: pull again please, rev 117 should give you a continue-rebase supporting --new-nick | 01:55 |
| rousskov | OK. Will redo, specifying --new-nick with continue-rebase. | 01:56 |
| lifeless | 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:56 |
| lifeless | jelmer: except for about 3 statements | 01:57 |
| jelmer | 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 |
| jelmer | lifeless: Your patch does add --new-nicks to the rebase command, so I think it's relevant. | 01:57 |
| jelmer | especially since replay is hidden at the moment | 01:57 |
| lifeless | 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 | 01:58 |
| jelmer | 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:00 |
| lifeless | 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 |
| rousskov | . o O ( success! ) | 02:01 |
| lifeless | rousskov: excellent | 02:01 |
| lifeless | rousskov: sorry I didn't reply to your december mail : I was on leave then | 02:01 |
| lifeless | and didn't see it till now | 02:01 |
| jelmer | lifeless, not separate in what regard? Separate from graph changes? | 02:02 |
| lifeless | yeah | 02:02 |
| rousskov | lifeless, jelmer, Thanks for all the help. | 02:02 |
| lifeless | I find users tend to want several different changes all at once | 02:02 |
| lifeless | rousskov: no problem | 02:02 |
| rousskov | lifeless, next time folks complain that bzr does not work well on Windows, I will skip a round. :-) | 02:03 |
| lifeless | hah | 02:03 |
| rousskov | So I now have about 10 useless branches. Is there a better strategy than "rm -rf" to get rid of them completely? | 02:04 |
| lifeless | unless you plan to rsync the entire repo somewhere public, I suggest you just rm -rf and ignore them | 02:04 |
| lifeless | they won't propogate unless they are referenced | 02:05 |
| rousskov | Does not plan to rsync | 02:05 |
| lifeless | and they will be nearly trivial in disk space | 02:05 |
| rousskov | OK. I am not going to suggest that there should be a branch removal command :-). | 02:05 |
| lifeless | we're going to add one, for remote server access | 02:06 |
| lifeless | but it won't delete the content immediately | 02:06 |
| lifeless | there is a plugin that can do that I think | 02:06 |
| lifeless | resurrecting old content can be very useful | 02:06 |
| lifeless | and the planned gc command will be a generic cleanup-my-repo tool | 02:06 |
| * rousskov nods. I am just thinking of folks committing really top-secret-stuff by mistake (I was not). | 02:07 | |
| lifeless | rousskov: yeah. Its because of that that unreferenced content is not propogated | 02:07 |
| rousskov | How does repo know what is not referenced if I just rm -rf a checked out branch? | 02:08 |
| lifeless | the branch has a pointer in it | 02:09 |
| lifeless | the branch tip, and the tags, are refs into the repository | 02:09 |
| rousskov | Sure, but I removed the branch. Is there a pointer from repo to the branch? | 02:09 |
| lifeless | no | 02:10 |
| rousskov | branch foo bar; rm -rf bar. | 02:10 |
| lifeless | yup | 02:10 |
| rousskov | How will repo know that bar is not referenced? | 02:10 |
| lifeless | well, 'bar' had the same refs as 'foo', because you took no actions on the branch after making it | 02:10 |
| lifeless | so there isn't anything that is not referenced | 02:10 |
| lifeless | branch foo bar; bzr commit -m 'new' bar; rm -rf bar | 02:11 |
| rousskov | OK. Let's assume I committed to bar before rm -rf. | 02:11 |
| lifeless | that would create a new revision in the repo | 02:11 |
| rousskov | How would repo know that this new revision is not referenced? | 02:11 |
| lifeless | 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:11 |
| rousskov | 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:12 |
| rousskov | I guess my definition of "referenced" is wrong. | 02:13 |
| lifeless | rousskov: perhaps | 02:13 |
| lifeless | the branch has the reference | 02:13 |
| lifeless | if the branch isn't there, there isn't a reference | 02:13 |
| rousskov | But repo does not know that the branch is not there. | 02:13 |
| lifeless | yes it does | 02:13 |
| lifeless | the branch is contained within the repo if it is using it for history storage | 02:14 |
| rousskov | Are you saying I should do rm -rf *in the repository*? | 02:14 |
| lifeless | rousskov: no, just the branches you don't want | 02:14 |
| rousskov | But in the repository? | 02:14 |
| lifeless | rousskov: wherever the branches are | 02:14 |
| lifeless | rousskov: I don't know where that is related to any repositories you may or may not have :) | 02:15 |
| rousskov | Repo is in /home/rousskov/programs/bazaar/repos/squid/ | 02:15 |
| rousskov | Branches are in /home/rousskov/Edit/squid3/ | 02:15 |
| rousskov | All the commands you told me were executed in the second directory. | 02:16 |
| lifeless | with that layout, you probably aren't using the repository for history storage at all :) | 02:16 |
| lifeless | which is fine | 02:16 |
| rousskov | But each branch command creates something in the repository. | 02:16 |
| lifeless | rousskov: does it? | 02:16 |
| rousskov | Should I rm -rf that something? | 02:16 |
| rousskov | lifeless, it sure does! | 02:17 |
| lifeless | rousskov: by something, do you mean a directory under /home/rousskov/programs/bazaar/repos/squid/ ? | 02:17 |
| rousskov | One directory per branch | 02:17 |
| rousskov | Yes | 02:17 |
| lifeless | with the basename of the branch ? | 02:17 |
| rousskov | Yes | 02:17 |
| lifeless | ok, they are the branches | 02:17 |
| * rousskov ducks | 02:17 | |
| lifeless | you probably also had copies of the branches in Edit | 02:18 |
| rousskov | So I should remove both with rm -rf, right? | 02:18 |
| lifeless | yes | 02:18 |
| lifeless | rm -rf anything with the name of the temp branches you were working with | 02:18 |
| rousskov | Is my layout wrong? I thought I followed Squid3 instructions when setting this up. | 02:18 |
| lifeless | I think its fine | 02:19 |
| lifeless | its a little confusing when you use bzr's purest capabilities, because you're in the emulated cvs mode | 02:19 |
| rousskov | Am I using bzr purest capabilities? | 02:20 |
| lifeless | somewhat | 02:20 |
| rousskov | Like --new-nick? | 02:20 |
| lifeless | well new-nick was created for you :) | 02:20 |
| lifeless | by purest I mean working in fully distributed mode | 02:20 |
| lifeless | if there isn't an explicit repository bzr just creates one inline in the branch object | 02:21 |
| lifeless | anyhow | 02:21 |
| rousskov | And I am emulating CVS because I keep repo separate? | 02:21 |
| lifeless | yes | 02:21 |
| rousskov | I see. | 02:21 |
| lifeless | it just means that how you see bzr work everyday isn't its default mode | 02:22 |
| lifeless | its fully supported and I use it in that way for squid myself | 02:22 |
| lifeless | (the way you do) | 02:22 |
| rousskov | It also means I confuse bzr gurus when talking about branches that are actually branch copies. | 02:23 |
| lifeless | or branch references | 02:24 |
| lifeless | note that all the commands worked | 02:24 |
| lifeless | the only confusion occured at the end when talking about cleaning things up:) | 02:24 |
| lifeless | food time, bbs | 02:24 |
| rousskov | Thanks again. | 02:25 |
| lifeless | 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 |
| lifeless | there are other options already present on rebase that control what content changes happen | 02:40 |
| lifeless | (always-rebase-merges is one) | 02:41 |
| poolie1 | jamesh: is that actually true that smtp through gmail doesn't file it as sent? | 05:01 |
| poolie1 | hrm | 05:01 |
| jamesh | poolie1: I don't think it does. | 05:01 |
| jamesh | iirc it is just an SMTP server | 05:02 |
| jamesh | it is usually up to the MUA to store sent messages | 05:02 |
| poolie1 | yes, but this is magic | 05:02 |
| poolie1 | it does store it | 05:02 |
| poolie1 | i just tested | 05:03 |
| jamesh | 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 |
| poolie1 | it might be that if your mua also writes into Sent it de-dupes them | 05:05 |
| poolie1 | it does seem to do that pretty aggressively | 05:05 |
| poolie1 | also the sent message is marked as read | 05:06 |
| jamesh | right. | 05:06 |
| poolie1 | so it's easy not to notice it | 05:06 |
| jamesh | well, it was a pretty quick hack and does let you defer sending the message | 05:07 |
| poolie1 | yeah | 05:07 |
| poolie1 | it's very useful and a clever hack | 05:07 |
| poolie1 | but... Pedantical :-) | 05:08 |
| lifeless | dot com | 05:08 |
| === sdboyer__ is now known as sdboyer | ||
| === thumper_laptop is now known as thumper | ||
| pygi | kfogel, poke | 05:51 |
| kfogel | pygi: perk | 05:52 |
| pygi | kfogel, you have mailz! | 05:52 |
| pygi | probably not very useful atm, I'll make sure to write something more detailed tonight if it'll be of any use | 05:52 |
| kfogel | pygi: see my response :-) | 05:53 |
| pygi | kfogel, afaik it'll be available as e-book, yes | 05:53 |
| pygi | kfogel, I could probably send you a TOC if you wish? | 05:54 |
| kfogel | pygi: e-book under an open license (one that will permit us to remix, etc)? | 05:54 |
| kfogel | That would be *terrific*. | 05:54 |
| pygi | kfogel, no :/ | 05:54 |
| kfogel | pygi: who is publisher? | 05:54 |
| pygi | Packt Publishing | 05:55 |
| kfogel | pygi: hmmm. Have you asked them about doing a CC-BY or CC-BY-SA license? | 05:55 |
| kfogel | many publishers are willing these days | 05:55 |
| kfogel | O'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 |
| pygi | O'Reilly isn't interested in a bzr book tho :) | 05:56 |
| pygi | but that doesn't matter really :) | 05:56 |
| kfogel | pygi: no, I just mean as a point to tell Packt. | 05:57 |
| pygi | kfogel, nop, we haven't asked them to publish the book under an open licence | 05:57 |
| jamesh | pygi: are they not interested in printing one, or not interested in paying an advance for one? | 05:57 |
| pygi | 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 |
| kfogel | 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:58 |
| kfogel | 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 |
| pygi | kfogel, I can understand that | 05:59 |
| pygi | kfogel, I'd need to talk (again) with Szi and Jon about that, but asking isn't a problem | 06:00 |
| kfogel | 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 |
| pygi | kfogel, haha, no, I'm not thinking about royalties | 06:00 |
| Toksyuryel | they SHOULD make a bzr book :( bzr is so awesome | 06:00 |
| jamesh | 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:00 |
| pygi | Toksyuryel, we're on it ;) | 06:01 |
| kfogel | 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 |
| kfogel | pygi: but http://producingoss.com/translations.html will give you some idea :-). | 06:01 |
| pygi | kfogel, I've sent you a mail that has TOC btw | 06:01 |
| pygi | kfogel, hehe :) | 06:01 |
| pygi | yea, I have that book, google bought me one :p | 06:01 |
| kfogel | pygi: oh, heh! Prolly has my signature in it, then. | 06:02 |
| pygi | aha | 06:02 |
| Toksyuryel | you would think that the official RCS of choice for the GNU project would catch the attention of the O'Reilly people | 06:02 |
| Toksyuryel | maybe it's too much of a moving target still though | 06:02 |
| pygi | Toksyuryel, its just that git is much more widely used | 06:03 |
| pygi | and linux kernel ofcourse is git | 06:03 |
| jamesh | Toksyuryel: they didn't do a book about Arch either, when it was the official RCS of choice for GNU | 06:03 |
| jamesh | I think Bazaar will have to work on its own merits | 06:03 |
| Toksyuryel | I thought Arch was a distro | 06:03 |
| pygi | and even the Git book isn't too big (I think 200 pages, I'd need to look) | 06:03 |
| pygi | Toksyuryel, arch linux is a distro :) | 06:03 |
| jamesh | (and it shouldn't have any trouble there) | 06:03 |
| Toksyuryel | well, git NEEDS a book to even understand it | 06:03 |
| jamesh | Toksyuryel: http://www.gnu.org/software/gnu-arch/ | 06:04 |
| Toksyuryel | it is written in some kind of goofy alien language | 06:04 |
| pygi | kfogel, if we end up actually doing that, I'll include you in conversation with Packt, if it'll be needed | 06:05 |
| Toksyuryel | I 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-gpl3 | 06:06 |
| kfogel | pygi: 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 |
| kfogel | :-) | 06:06 |
| pygi | Toksyuryel, tons of projects adopting git is a metric tho :) | 06:06 |
| pygi | kfogel, haha :D | 06:06 |
| Toksyuryel | pygi: that makes me cry :( I really broke down in tears when I saw that perl had switched to git | 06:06 |
| fullermd | Diploma... IRC... what? | 06:06 |
| pygi | fullermd, the cheese | 06:07 |
| fullermd | Mmm, cheese. | 06:07 |
| Toksyuryel | we need better PR for bzr. gotta get more buzz out there | 06:07 |
| Toksyuryel | how to do that though? | 06:07 |
| pygi | Toksyuryel, just have patience :) | 06:07 |
| fullermd | The early bird catches the worm, but the second mouse gets the cheese. | 06:07 |
| Toksyuryel | fullermd: that's a good quote | 06:07 |
| * Toksyuryel writes that one down | 06:08 | |
| * fullermd can't even remember the first time he heard it. | 06:08 | |
| fullermd | The first step to better PR is to make every large project's first reaction not be "Holy crap, this is slow" | 06:08 |
| Toksyuryel | there 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 :P | 06:09 |
| pygi | kfogel, ok, if you'll have any questions about TOC; please shout ... gotta do some work now :( | 06:09 |
| kfogel | I have to say, I haven't experienced speed problems so far. | 06:09 |
| kfogel | pygi: will do (haven't seen email yet, am working on something else) | 06:09 |
| fullermd | True, but there's hg sitting right there laughing at the idea that C is needed to be $LOTS faster than bzr. | 06:09 |
| Toksyuryel | bzr's speed comes not from its code execution but from its ease of use | 06:10 |
| kfogel | fullermd: I too am skeptical that C vs Python is a major factor here. | 06:10 |
| fullermd | A lot of things are slower, but the network is what really kills you. | 06:10 |
| Toksyuryel | you spend a lot less time fumbling with it than you do with other rcs | 06:10 |
| jamesh | Toksyuryel: a number of the places where bzr feels slow, the CPU isn't pegged | 06:10 |
| fullermd | And 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 |
| jamesh | that can indicate that the interpreter speed isn't the issue | 06:11 |
| fullermd | But they both have good smart servers. bzr... er... well, it HAS a smart server... | 06:11 |
| Toksyuryel | bzr's dumb server is as smart as its smart server :P | 06:11 |
| lifeless | kfogel: We typically get a 30-60 percent time reduction when we pryex inner loops | 06:11 |
| fullermd | The smart server has historically been a really GOOD dumb server. Actual smarts are slowly trickling in. | 06:12 |
| fullermd | But still. I wish the VFS layer on it had never been written. | 06:12 |
| lifeless | kfogel: I think we could get a further 50 percent redution on the output with real C and not refcounted memory-scattered structs | 06:12 |
| kfogel | lifeless: wow. But the big question is, on what operations is this the case? | 06:13 |
| fullermd | One way to look at it is that we're in a way better performance position than hg or git. | 06:13 |
| kfogel | fullermd: ? | 06:13 |
| fullermd | Because we have both there; we KNOW things can be radically faster. And we can even tear them apart and see how. | 06:13 |
| fullermd | We 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 |
| lifeless | kfogel: status, sequence matching, local dirstate parsing, knit index parsing [obsoleted], B+Tree index parsing (in 1.9 and newer formats) | 06:14 |
| kfogel | fullermd: mrm. I don't get the feeling that either git or hg developers ever say that to themselves :-). | 06:14 |
| fullermd | Well, no. That's why we're in this position ;p | 06:14 |
| lifeless | python is very fast at adhoc stuff, but C is maaaassively faster when used end to end | 06:15 |
| Toksyuryel | converting the codebase would take quite a while though | 06:16 |
| Toksyuryel | I 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 things | 06:16 |
| Toksyuryel | like the constantly changing index format | 06:16 |
| Toksyuryel | it is easy to quickly impliment that stuff for testing in python | 06:17 |
| lifeless | Toksyuryel: there are no plans to convert all of the code base | 06:17 |
| Toksyuryel | once the codebase settles down, I think is when a potential conversion to C should pop up on the radar | 06:17 |
| lifeless | Toksyuryel: there is significant community attraction to being python | 06:18 |
| Toksyuryel | it's a nice buzzword, sure | 06:18 |
| lifeless | Toksyuryel: we already have C extensions for inner loops | 06:18 |
| lifeless | Toksyuryel: its not a buzzword; I started a thread about this in uhm, september or october | 06:18 |
| lifeless | we'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 others | 06:19 |
| Toksyuryel | lifeless: I am not suggesting that the experimental nature is a bad thing; it is one of the things I love about bzr | 06:20 |
| lifeless | good! | 06:21 |
| lifeless | but there is some confusion out there about what it means | 06:21 |
| jamesh | Toksyuryel: so, code in C often runs faster than code in Python, but code in Python is usually easier to change. | 06:22 |
| jamesh | if 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 |
| jamesh | if you've using the wrong algorithm, fixing that problem can speed things up more than a Python->C conversion would | 06:22 |
| jamesh | so starting from Python code is a plus there. | 06:23 |
| Toksyuryel | jamesh: that's my point | 06:24 |
| jamesh | Toksyuryel: one problem is that it is difficult to tell whether you're code has settled into the best possible algorithms. | 06:25 |
| jamesh | someone might come up with something faster, or external matters change requiring changes in the project | 06:26 |
| Toksyuryel | jamesh: well I can say with certainty that a new release every month is not "settled" :P | 06:26 |
| pygi | kfogel, wake up | 06:33 |
| kfogel | pygi: ? | 06:33 |
| kfogel | pygi: (just about to go to bed, actually) | 06:33 |
| pygi | kfogel, 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 |
| kfogel | pygi: both, but mainly the latter. | 06:33 |
| pygi | kfogel, well, we can obviously fix that | 06:34 |
| pygi | but I'll let you go to bed I guess, so poke me when you want to talk | 06:34 |
| kfogel | pygi: 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 |
| kfogel | pygi: if you tried to make the book solve this problem, that would only ruin the book :-). | 06:35 |
| pygi | :P | 06:35 |
| kfogel | pygi: ok, good night for real. See you later! | 06:35 |
| pygi | kfogel, ok, ok | 06:35 |
| pygi | night | 06:35 |
| lifeless | uisn't the cheatsheet that? | 06:38 |
| pygi | lifeless, obviously, not in a connected, workflow-like way? You'd have to ask kfogel :p | 06:39 |
| lifeless | have a good weekend | 06:43 |
| pygi | thanks, the same :) | 06:44 |
| === thumper_laptop is now known as thumper | ||
| lifeless | min 0.00234603881836 | 07:06 |
| lifeless | max 0.0709958076477 | 07:06 |
| lifeless | avg 0.00280290386045 | 07:06 |
| lifeless | times to extract a single inventory text with in-memory index and hot cache | 07:06 |
| lifeless | min 0.00236701965332 | 07:11 |
| lifeless | max 0.0570821762085 | 07:11 |
| lifeless | avg 0.00280372190905 | 07:11 |
| lifeless | dev 0.00103978222127 | 07:11 |
| lifeless | std dev added | 07:11 |
| lifeless | poolie1: ^ | 07:14 |
| vila | hi all | 07:33 |
| poolie1 | lifeless: hi | 07:40 |
| lifeless | $ bzr compressbench | 07:50 |
| lifeless | Raw size 3461880213 | 07:50 |
| lifeless | Compressed size 141152371 | 07:50 |
| lifeless | durations: | 07:50 |
| lifeless | min 0.00240206718445 | 07:50 |
| lifeless | max 0.0537631511688 | 07:50 |
| lifeless | avg 0.00287260593959 | 07:50 |
| lifeless | dev 0.00104769617119 | 07:50 |
| lifeless | per_k_times: | 07:50 |
| lifeless | min 5.22243953561e-05 | 07:50 |
| lifeless | max 0.00116888823111 | 07:50 |
| lifeless | avg 6.24545846438e-05 | 07:50 |
| lifeless | dev 2.27784216077e-05 | 07:50 |
| Jc2k | lifeless: how is the compression going? rob still swoons everytime he hears "group compress" | 10:10 |
| === asac_ is now known as asac | ||
| liw | I 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 |
| liw | would merging the foo.deb branch into foo, but removing debian/* before committing work ok? | 11:52 |
| james_w | I believe so | 11:54 |
| liw | hmm, if I do that, then merge into foo.deb again, debian/* gets removed, which is undesireable | 11:55 |
| james_w | but if you run "bzr revert debian" when merging back it should resurrect, no? | 11:56 |
| james_w | that might mean that it will try and add debian to foo again next time you merge | 11:56 |
| liw | you 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_w | ah, if you merge .deb to foo, rm debian, commit, merge back and "bzr revert ." then commit it may do the right thing | 11:57 |
| james_w | i.e. do a "null merge" back straight away | 11:57 |
| liw | yeah, that seems to work | 11:58 |
| liw | thanks! | 11:58 |
| === kiko is now known as kiko-phone | ||
| === kiko-phone is now known as kiko-fud | ||
| Jc2k | LarstiQ: ping | 14:39 |
| LarstiQ | Jc2k: pong | 14:45 |
| Jc2k | LarstiQ: are you the one to speak to about bzr-hookless-email? | 14:47 |
| LarstiQ | Jc2k: I mentioned it on the mailing list, so I guess so :) | 14:47 |
| LarstiQ | Jc2k: I've only recently taken over maintenance, but shoot | 14:47 |
| Jc2k | LarstiQ: cool, i'm looking at making a more generic version and didnt want to turn up with it out of nowhere | 14:48 |
| LarstiQ | Jc2k: what are you thinking of? | 14:49 |
| Jc2k | what i want to do is have post-commit and post-change-branch-tip hooks, but outside of the bzr instance that actually commits | 14:49 |
| LarstiQ | right, that makes sense | 14:50 |
| Jc2k | i have a test script (with tests) that does this, but its seperate to bzr-hookless-email atm | 14:51 |
| Jc2k | there 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 scanning | 14:52 |
| Jc2k | but at the same time, it would be nice if things like bzr-cia could 'just work' for both modes of operation.. | 14:52 |
| Jc2k | LarstiQ: 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 :p | 14:55 |
| james_w | you could define a new hook point, and each plugin could register in both? | 14:55 |
| james_w | or you could extend the API somehow | 14:55 |
| Jc2k | james_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 those | 14:56 |
| Jc2k | i 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 plugin | 14:57 |
| LarstiQ | Jc2k: I'm willing to work on this | 14:57 |
| LarstiQ | Jc2k: would you mind replying on the mailinglist stating your intention? | 14:58 |
| Jc2k | okie dokie. i'll push the play branch i have too. | 14:58 |
| LarstiQ | cool | 14:59 |
| === kiko-fud is now known as kiko-phone | ||
| phinze | is there a good doc somewhere for "how to land a feature branch" ? | 15:29 |
| phinze | http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#sending-changes <-- looking at that | 15:31 |
| Jc2k | LarstiQ: mail sent, with a stupid typo :( | 15:32 |
| === tchan1 is now known as tchan | ||
| LarstiQ | Jc2k: thanks | 16:07 |
| === thekorn_ is now known as thekorn | ||
| phinze | here we go... http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#merging-a-feature-into-the-trunk | 16:48 |
| === You're now known as ubuntulog | ||
| === dereine[OFF] is now known as dereine | ||
| === dereine is now known as dereine[OFF] | ||
| delaney | hi, 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 |
| jelmer | delaney: I think that's supposed to be fixed in the latest version | 18:13 |
| delaney | 1.11? | 18:14 |
| delaney | rc | 18:14 |
| jelmer | deepjoy, yeah | 18:16 |
| === dereine[OFF] is now known as dereine | ||
| delaney | Well if I init from command line I can add etc, but if I init via tortoisebzr it does work | 18:17 |
| delaney | get bzr: ERROR: No WorkingTree exists for " | 18:17 |
| jelmer | not sure then, sorry | 18:18 |
| delaney | heh, actually I'm getting it with a second right click... weird, that has to be a bug. | 18:18 |
| delaney | But still no option to add. | 18:20 |
| delaney | thanks anyways jelmer | 18:20 |
| === dereine is now known as dereine[OFF] | ||
| mib_2nb27u | I 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-do | mib_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-do | And startup time seems to be mostly Python's fault. | 19:26 |
| mib_2nb27u | Does it mean that hg is equally slow? | 19:27 |
| Lo-lan-do | Various strategies are being tried to mitigate that. | 19:27 |
| Lo-lan-do | No idea, I don't know hg :-) | 19:27 |
| mib_2nb27u | I thought that hg is almost equal to git | 19:27 |
| Lo-lan-do | (I hope I didn't talk too much rubbish) | 19:28 |
| mib_max | Are 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-do | I don't know myself, but maybe others do. | 19:32 |
| fullermd | Plenty probably. | 19:33 |
| fullermd | It'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 |
| kumi | Anyone know if nested tree support will land this year? It's the only SVN feature that makes me jealous | 19:35 |
| mib_max | so this speed problems is derived from design of bzr and to make it comparable to git, bzr must be rewritten? | 19:35 |
| mib_max | Why then all this new features are being added into flawed codebase? | 19:36 |
| Lo-lan-do | I guess it's because there are people adding features and others working on speed. It's not an either/or case. | 19:37 |
| luks | it's now flawed, it's called extensible | 19:37 |
| vila | kumi, the year is still young, all dreams are possible :-) | 19:37 |
| vila | mib_max: welcome on the channel, we appreciate your enthusiasm | 19:38 |
| mib_max | speed improvements aren't that visible (going from 100x times slower to 50x times slower than git is very good, but ...) | 19:38 |
| vila | bzr is layered so that some features can be added while other layers are rewritten for better performances | 19:38 |
| vila | s/added/& in some layers/ | 19:39 |
| mib_max | vila, and are there any plans to stop adding new features and make previous usable performance-wise | 19:39 |
| Lo-lan-do | Why stop adding features? | 19:40 |
| vila | mib_max: no, that's more fun that way | 19:40 |
| mib_max | Lo-lan-do, to make old features usable? | 19:41 |
| Lo-lan-do | People 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 |
| vila | seriously, this is a free software project, different people have different aims | 19:41 |
| vila | Lo-lan-do: exactly | 19:41 |
| vila | Many bzr users are perfectly happy with the actual performance | 19:42 |
| mib_max | of course, but I though that bzr is Canonical sponsored project and there are some developers working on it from Canonical, right? | 19:43 |
| vila | I personally have problems with performance for one project, but for most of my daily usage, performance is not a concern | 19:43 |
| vila | mib_max: and Canonical also ask for features with priorioties higher than performance (AFAIK), so what ? | 19:43 |
| Lo-lan-do | vila: 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 |
| vila | Lo-lan-do: is that vc.el related ? | 19:44 |
| === kiko-phone is now known as kiko-afk | ||
| mib_max | vila, 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 faster | 19:45 |
| Lo-lan-do | vila: Possibly. How can I check? | 19:45 |
| vila | mib_max: I don't know the internals of Canonical so I can't speak for them | 19:46 |
| mib_max | vila, 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 project | 19:46 |
| vila | Lo-lan-do: I'm using emacs myself and I don't have the problem, what's your version ? | 19:46 |
| mib_max | that big size of repository is because of a lot of changesets or what? | 19:47 |
| vila | mib_max: the initial branch may be slow but you're asking for it so I think I don't understand your problem | 19:47 |
| Lo-lan-do | vila: 22.2.1 from sid | 19:47 |
| vila | Lo-lan-do: 22.1.1 here, so I will have to use my 8-ball | 19:48 |
| Lo-lan-do | mib_max: Try a lightweight checkout if you don't want the full history, or a stacked branch. | 19:48 |
| vila | Stacked branch is for pushing, why are your branching bzr mib_max ? | 19:48 |
| mib_max | the problem for me that repository size is about 10x of source tree size | 19:48 |
| mib_max | Is branching bzr forbidden operation in bzr? | 19:49 |
| Jc2k | i think the bzr repository is in an older format? | 19:50 |
| vila | mib_max: cool down, I'm asking about your expected needs to give you an appropriate answer :) | 19:50 |
| vila | 96 ~= 6 x 15... | 19:50 |
| vila | So what ? | 19:50 |
| mib_max | actually it is 12, not 15, I will convert it to git and see how it will perform | 19:51 |
| mib_max | vila, 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 bored | 19:52 |
| luks | this looks like regular trolling to me :) | 19:52 |
| mib_max | vila, I believe bzr branch definetly needs to output some more information about how much it is downloading instead of just rotating | | 19:52 |
| Jc2k | i think trunk bzr does. | 19:53 |
| vila | mib_max: try bzr.dev | 19:53 |
| vila | :) | 19:53 |
| mib_max | ? | 19:53 |
| mib_max | I tried | 19:53 |
| mib_max | it shows some corruption | 19:53 |
| vila | Wait ! It's not performance related ! It's a feature ! *You* don't want it. Isn't it ? | 19:53 |
| mib_max | No revisions to pull.] Pull phase 0/2 | 19:54 |
| mib_max | It is performance related | 19:54 |
| mib_max | it is so slow, that it needs to show that it is still working and not frozen | 19:54 |
| vila | You mean your internet connection ? | 19:54 |
| mib_max | "No revisions to pull.] Pull phase 0/2 " - output from ./bzr pull on latest bzr.dev | 19:54 |
| mib_max | maybe | 19:55 |
| vila | Care to check your CPU usage and network usage ? | 19:55 |
| mib_max | It would be much better if bzr will tell me that it is downlading at XXX Kbps | 19:55 |
| vila | <Jc2k> i think trunk bzr does. | 19:56 |
| vila | <vila> mib_max: try bzr.dev | 19:56 |
| mib_max | it is not providing it me for pull | 19:56 |
| mib_max | Will try for branch | 19:56 |
| vila | Oh wait ! No, I have to write that for http :-) | 19:56 |
| vila | It works for sftp only so far | 19:56 |
| mib_max | it provides something for branch that is major good step here) | 19:57 |
| mib_max | but I think better will be not copied "records" but bytes | 19:57 |
| mib_max | And of course pull operation needs it too | 19:57 |
| mib_max | What lp:bzr uses? http or sftp or bzr? | 19:57 |
| Lo-lan-do | I'm sure your patch will be much appreciated. | 19:58 |
| vila | mib_max: when did you try bzr branch lp:mysql ? | 19:58 |
| mib_max | I tried to found pull.py, just as log.py but it is not there, where is pull output in source tree? | 19:58 |
| mib_max | vila, what do you mean "when" if you want I could do it now | 19:59 |
| vila | mib_max: please do so | 19:59 |
| Jc2k | the new progress stuff is swweeet. | 19:59 |
| mib_max | using bzr.dev or bzr 11_rc | 19:59 |
| vila | bzr.dev | 19:59 |
| mib_max | time ~/bzr/bzr branch lp:mysql-server ................. | 20:01 |
| mib_max | what lp: is using? sftp, bzr or http? | 20:04 |
| vila | all of them | 20:04 |
| Lo-lan-do | And IPoAC | 20:04 |
| mib_max | btw, bzr.dev does branch much better, now I have some moving numbers on screen :) | 20:05 |
| vila | time -p bzr branch lp:mysql-server so-what | 20:06 |
| vila | Branched 2710 revision(s). | 20:06 |
| vila | real 211.17 | 20:06 |
| vila | user 38.37 | 20:06 |
| vila | sys 47.93 | 20:06 |
| vila | That includes building the working tree on a NFS mounted file system | 20:07 |
| mib_max | I am doing it still | 20:08 |
| mib_max | what is your internet connection speed? | 20:08 |
| vila | 22Mdown/1Mup | 20:09 |
| mib_max | 4Mdown/0.7Mup, so I will do it about 5.5 times slower | 20:11 |
| mib_max | what is the size of .bzr in mysql? | 20:11 |
| vila | du -sk .bzr | 20:11 |
| vila | 680332.bzr | 20:11 |
| amanica_ | as far as I can see lp: = bzr+ssh://bazaar.launchpad.net/ | 20:12 |
| mib_max | 680Megabytes?? oO | 20:12 |
| vila | But I use a shared repository which contains many more than just lp:mysql-server, so I didn't just download that :-) | 20:13 |
| mib_max | Because you already had that revisions? | 20:13 |
| mib_max | Ok I will Ctrl-C it | 20:14 |
| vila | I had to download an additional pack file of about 7M containing the revisions I didn't have | 20:15 |
| === mvo__ is now known as mvo | ||
| mib_max | Ok. Another thing. Could you explain me some statements on http://whygitisbetterthanx.com/#cheap-local-branching | 20:20 |
| mib_max | Is it true that bzr can do thit as easy as git and author of site is incorrect? | 20:21 |
| vila | mib_max: <vila> time -p bzr branch lp:mysql-server so-what | 20:24 |
| vila | <vila> Branched 2710 revision(s). | 20:24 |
| vila | <vila> real 211.17 | 20:24 |
| vila | <vila> user 38.37 | 20:24 |
| vila | <vila> sys 47.93 | 20:24 |
| vila | Sounds pretty cheap to branch a ~130M tree to me | 20:25 |
| vila | and will certainly be faster if I was using a local FS | 20:25 |
| mib_max | It is your old results. You cheated, having most of revisions locally) | 20:25 |
| Jc2k | you can also have one working tree and use 'bzr switch' to connect it to different branches | 20:25 |
| vila | mib_max: I think luks was right | 20:26 |
| mib_max | Download speed meter and reporter in bzr.dev makes it more clear that in that case internet is bottleneck | 20:26 |
| mib_max | what lucks said? | 20:26 |
| mib_max | luks* | 20:26 |
| mib_max | Am I loosing messages? | 20:26 |
| vila | Either you're trolling or you don't understand what you're talking about, you asked about cheap branching, not initial branching | 20:27 |
| mib_max | I don't thaught that this repository will be 600M in size, bzr didn't told me that and was just rotating | 20:27 |
| mib_max | *rotating | | 20:27 |
| mib_max | Now in bzr.dev it makes much more sense | 20:28 |
| pickscrape | Branching mysql into a clean shared repository just took me: | 20:30 |
| pickscrape | real 911.39 | 20:30 |
| pickscrape | user 231.38 | 20:30 |
| pickscrape | sys 9.57 | 20:30 |
| pickscrape | Creating a local branch of the branch I just created took: | 20:30 |
| pickscrape | real 35.62 | 20:30 |
| pickscrape | user 4.19 | 20:30 |
| pickscrape | sys 2.08 | 20:30 |
| mib_max | From hd or internet? I realized that in my case internet was bottleneck, sorry for complaints. | 20:30 |
| pickscrape | My first branching was from launchpad. I didn't have any revisions previously downloaded. | 20:31 |
| mib_max | you have pretty fast internet access to lauchpad :) | 20:31 |
| Jc2k | mib_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 |
| pickscrape | Verizon fios (15MB down) | 20:32 |
| Jc2k | mib_max: you could then bzr switch foo and be back on the first branch | 20:32 |
| mib_max | Jc2k, 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 |
| vila | mib_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 meme | 20:34 |
| vila | This 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_max | Ok. 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_max | what tool I should use to view docs in bzr.dev/docs/developers ? It contains some includes ... | 20:38 |
| vila | make docs; use $your_favorite_browser doc/index,htlm | 20:40 |
| vila | make docs; use $your_favorite_browser doc/index.html | 20:40 |
| mib_max | emerge docutils did the magic for make docs | 20:40 |
| mib_max | thanks) | 20:40 |
| mib_max | is performance-roadmap document from that directory outdated? | 20:44 |
| mib_max | Are there any ways to read what was written during my connection loss? | 20:54 |
| vila | what connection loss ? Ctrl-c ? | 20:55 |
| mib_max | adsl provider breaking connection every 24h to do accounting | 20:55 |
| vila | Oh my... spiv ! Here is a use case to retry hpss requests ! | 20:57 |
| vila | mib_max: I don't think so | 20:57 |
| mib_max | :) | 20:57 |
| vila | mib_max: there is no general answer, were you doing a bzr branch ? | 20:58 |
| mib_max | I am about IRC :) | 20:58 |
| vila | no disconnection msg appeared here | 20:59 |
| mib_max | I am using mibbit.com to connect to IRC | 20:59 |
| mib_max | maybe their server was connected all the time | 20:59 |
| vila | I see | 20:59 |
| mib_max | Are 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 etc | 21:01 |
| vila | mib_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 updated | 21:03 |
| vila | s/working/worked/ | 21:03 |
| mib_max | is it possible for mere mortal to understand that topic and try to contribute to performance optimization of bzr? Any easy starting points? | 21:04 |
| vila | mib_max: you're welcome, my suggestion will be to start running 'bzr selftest' first | 21:06 |
| vila | second, go to launchpad and search for bugs tagged 'easy' or 'trivial' | 21:07 |
| mib_max | what is tradition? are all tests to pass? | 21:07 |
| vila | All commit on bzr.dev pass all tests on our gate keeper (nick pqm) | 21:07 |
| vila | All submissions should pass all tests | 21:08 |
| mib_max | 14 errors so far | 21:08 |
| vila | What os ? | 21:08 |
| mib_max | for example | 21:08 |
| mib_max | ERROR: blackbox.test_remove.TestRemove.test_remove_one_deleted_file exceptions must be strings, classes, or instances, not exceptions.OSError | 21:08 |
| mib_max | linux gentoo | 21:08 |
| vila | here you go :-) | 21:08 |
| vila | patch welcome ! | 21:09 |
| mib_max | so you say that on your gatekeeper all tests passes? | 21:09 |
| vila | python version ? | 21:09 |
| mib_max | 2.5.2 | 21:09 |
| vila | wow | 21:09 |
| mib_max | ? | 21:10 |
| mib_max | 2208/15811 in 3m28s, 26 err, 4 missing | 21:10 |
| vila | That's very very surprising | 21:10 |
| Jc2k | im seeing quite a few "run() got an unexpected keyword argument 'verbose' | 21:11 |
| vila | If you do 'bzr log --short' in your bzr working tree you will see all commits done on the Patch Queue Manager | 21:11 |
| vila | All of those commits were done after a 'make check' | 21:11 |
| mib_max | maybe some problems are because of execution? I execute bzr in bzr.dev working tree | 21:12 |
| vila | mib_max: that's what I do many times every day : './bzr selftest' | 21:12 |
| mib_max | actualy am using PATH/bzr selftest | 21:13 |
| mib_max | "~/bzr/bzr selftest" | 21:13 |
| vila | selftest should report which bzrlib is used and which python version is used in the first output lines | 21:13 |
| Jc2k | im seeing lots of loom related errors | 21:13 |
| vila | Jc2k: loom.... shouldn't fail more than ... oh wait... if they are stacked branch related, the bug is known | 21:14 |
| mib_max | it is using 1.12dev | 21:14 |
| mib_max | 44errs so far | 21:14 |
| mib_max | make check failed too | 21:14 |
| mib_max | I think it is some problems with pyx files | 21:14 |
| mib_max | http://www.mibbit.com/pb/iZYhA6 | 21:14 |
| mib_max | maybe I built pyrex libs in a bad way | 21:15 |
| vila | mib_max: sounds like a probable cause or a bad version of pyrex (I think we blacklisted one version of pyrex) | 21:16 |
| mib_max | deleted *.so from bzrlib | 21:16 |
| mib_max | now things are going better | 21:16 |
| mib_max | I am using pyrex 0.9.8.5 | 21:16 |
| mib_max | is it bad? | 21:16 |
| vila | I don't think so, I think 0.9.8.4 had problems | 21:16 |
| mib_max | what is recommended version? | 21:17 |
| vila | did you run a bare 'make' ? | 21:17 |
| mib_max | yes | 21:17 |
| vila | I don't know, jam should | 21:17 |
| beuno | branching large branches with --stacking is awesome. Why don't we advertise that more? | 21:17 |
| vila | beuno: because you do that better than us ? :-) | 21:18 |
| mib_max | pyrex modules are causing problems | 21:18 |
| mib_max | vila, what version of pyrex are you using? | 21:18 |
| beuno | vila, heh, maybe, maybe. I guess I'll need to blog! | 21:18 |
| vila | mib_max: I don't use any because I run from the same sources for several OSes | 21:19 |
| vila | but I'm not a good example :) | 21:19 |
| mib_max | vila, so you are running selftest using only python modules? | 21:19 |
| beuno | vila, btw, I'd like to have a (voice) chat with you at some point about a few ideas around bzr-upload | 21:19 |
| vila | beuno: we should try that this week-end (where are you this week-end ? Argentina ?) | 21:20 |
| beuno | vila, sounds good. I am in Argentina. We can ping-pong and see when both of us are awake and lucid | 21:21 |
| mib_max | vila, how long does it usually takes to run all tests? | 21:21 |
| vila | mib_max: locally yes, but in some branches under some OSes (mainly Ubuntu) I build them sometimes | 21:21 |
| vila | mib_max: ~10/15 minutes in my case | 21:21 |
| vila | But once you work on specific problems you don't have to run the whole test suite every time | 21:22 |
| vila | There are different ways to select a subset of the tests | 21:22 |
| mib_max | is 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_max | Lockable file was gc'd while locked | 21:23 |
| vila | I don't like it but it's not a test failure, just noise | 21:23 |
| mib_max | And it is ok to have XFAIL with bug # attached? (known bug) | 21:24 |
| vila | XFAIL == expected failure | 21:24 |
| mib_max | ok | 21:24 |
| vila | That's how we track some problems that are known but not yet addressed | 21:24 |
| mib_max | yes it is what I thought | 21:24 |
| vila | beuno: sounds like a good plan | 21:25 |
| mib_max | are there any ways to run tests in several threads? | 21:25 |
| vila | nothing 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 |
| vila | But the test framework itself doesn't forbid it either | 21:26 |
| mib_max | will it be x time faster to run it across x cores? If runned on tmpfs it is cpubound, right? | 21:27 |
| vila | Most of the test addicts prefer to run the "right" test for the part they are working on and that generally run in seconds | 21:27 |
| vila | s/the right test/the right testS/ | 21:28 |
| mib_max | i see | 21:28 |
| vila | running the full test suite is for when you do a break or switch to another task :) | 21:29 |
| vila | or before submission of course :) | 21:29 |
| mib_max | vila, btw what's the point of running selftest if I have no changes now and they all will pass, won't they? :) | 21:30 |
| vila | The point is to make sure they all pass so that you know which one you break :) | 21:30 |
| vila | And you just ran into that don't you ? | 21:31 |
| mib_max | into what? | 21:31 |
| mib_max | Into breakage of tests by bad pyrex? | 21:31 |
| vila | yup, I think we had a bug here on gentoo and it will be helpful if you could file it on launchpad | 21:32 |
| vila | s/we/had/we *have/ | 21:32 |
| vila | gee | 21:32 |
| vila | s/we had/we *have*/ | 21:32 |
| mib_max | :D | 21:32 |
| mib_max | As far as I understand gentoo doesn't use pyrex to build its own bzrs, it uses .c provided by tarball | 21:33 |
| vila | mib_max: pyrex 0.9.6.4-1ubuntu1 on hardy | 21:34 |
| vila | synchronicity :-) I was wondering about that | 21:34 |
| mib_max | it is because current stable pyrex in gentoo is older than one, needed to build bzr | 21:35 |
| vila | mib_max: You'll have to find someone more knowledgeable about pyrex than me though | 21:35 |
| mib_max | downgraded to 0.9.6.4 and problems are gone | 21:36 |
| mib_max | or no | 21:36 |
| mib_max | they are still here) | 21:36 |
| mib_max | does pqm use pyrex? | 21:36 |
| vila | mib_max: try jam if he come online later, I will leave shortly | 21:36 |
| vila | pqm certainly uses pyrex but I don't know which version | 21:36 |
| mib_max | ok thanks | 21:37 |
| * pickscrape runs selftest on gentoo too to see what happens... | 21:38 | |
| vila | mib_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_max | vila, pyrex 0.9.7 is not available in gentoo :( only 0.9.6 and then 0.9.8 | 21:39 |
| vila | :-) | 21:39 |
| mib_max | will leave it as it is for now | 21:40 |
| pickscrape | So far I just have an XFAIL | 21:40 |
| pickscrape | mib_max: how far in did you start getting errors? | 21:41 |
| mib_max | pickscrape, are you using bzr from gentoo or from bzr.dev? have you built pyrex modules? | 21:41 |
| vila | I'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 it | 21:41 |
| mib_max | about 150-200 tests | 21:41 |
| pickscrape | Aha, I've got 4 now, but only after 1000 or so. | 21:41 |
| mib_max | I get first near 150 | 21:42 |
| pickscrape | mib_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 again | 21:42 |
| mib_max | you wont get problems because with make you won't use pyrex modules | 21:42 |
| pickscrape | ok, I just ran make and restarted | 21:43 |
| mib_max | it worked? are you using pyrex from ~? | 21:43 |
| pickscrape | No, I'm getting errors | 21:44 |
| mib_max | on stable pyrex it complains about some modules incompatible with such old version of pyrex | 21:44 |
| pickscrape | pyrex 0.9.4.1 | 21:44 |
| mib_max | and in the begining of make you have complaint from bzr? | 21:44 |
| pickscrape | Ah yes, it did complain about that. | 21:45 |
| pickscrape | But the results I'm getting a different to those I got before running make. | 21:45 |
| mib_max | :) | 21:45 |
| pickscrape | s/ a / are / | 21:45 |
| pickscrape | All of the errors so far are "exceptions must be strings, classes, or instances, not exceptions.OSError" | 21:46 |
| mib_max | some here | 21:46 |
| pickscrape | Oh well :) | 21:46 |
| mib_max | *same* | 21:46 |
| gotgenes | What 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 |
| lifeless | gotgenes: log shows merges as indents | 21:48 |
| davidstrauss | Is it possible to merge in zero revisions to merely establish a common ancestor? | 21:48 |
| ronny | hi | 21:48 |
| gotgenes | lifeless: Oh, it surely does. But I did bzr log -l 1 and it was only showing the commit message. | 21:49 |
| gotgenes | Is that a bug? | 21:49 |
| ronny | is there any way to get something like WorkingTree.list_files thats not recursive and pinned down to a specific dir/file | 21:49 |
| gotgenes | Shouldn't it show the associated commit message? | 21:49 |
| pickscrape | gotgenes: you asked it to show only one revision, which in your case was the merge revision | 21:50 |
| lifeless | gotgenes: there is a discussion at the moment on the list about this; it is arguably a bug | 21:50 |
| lifeless | gotgenes: but its arguably right too :P. We may add log -c, like diff -c, to show the log of everything from before:X to X | 21:51 |
| gotgenes | pickscrape: True; but I guess the commits from the branch I merged from are relevant to the commit of the merge. | 21:51 |
| pickscrape | gotgenes: that could be quite a large can of worms though :) | 21:52 |
| lifeless | ronny: 'bzr ls' | 21:52 |
| gotgenes | lifeless: Ah okay. That seems a good compromise. | 21:52 |
| lifeless | ronny: perhaps | 21:52 |
| ronny | lifeless: im in search of an api | 21:52 |
| lifeless | gotgenes: you can simulate it today with bzr log -r before:foo..foo | 21:52 |
| lifeless | ronny: cmd_ls in builtins.py then | 21:53 |
| lifeless | ronny: sorry that I don't have more detail offhand | 21:53 |
| gotgenes | lifeless: Excellent tip! Many thanks. :-) | 21:53 |
| * ronny goes reading | 21:53 | |
| gotgenes | Also, out of curiosity, is anyone here at all familiar with any efforts to integrate bzr into NetBeans? | 21:53 |
| ronny | lifeless: oh, seems like the ls command is just using the full recursive version and ignores parts of the resultset | 21:55 |
| lifeless | ronny: do you need status like results? | 21:55 |
| lifeless | ronny: e.g. do you need unversioned files as well as versioned? | 21:55 |
| ronny | lifeless: yup | 21:56 |
| ronny | lifeless: its for anyvc workdir status info | 21:56 |
| lifeless | ronny: ah | 21:56 |
| lifeless | ronny: then 'iter_changes' definitely | 21:56 |
| lifeless | its the workhorse for status | 21:56 |
| ronny | does that give me unversioned/ignored= | 21:56 |
| lifeless | if you ask it to | 21:56 |
| lifeless | gotgenes: http://bazaar-vcs.org/IDEIntegration | 21:57 |
| ronny | is that api considered very stable? | 21:58 |
| ronny | cause i'll offload the actual implementation to javier ^^ | 21:59 |
| gotgenes | lifeless: Yeah, I see "We Need You" though I'm not a Java developer. | 21:59 |
| lifeless | ronny: iter_changes is pretty stable yeah | 22:00 |
| ronny | sweet | 22:01 |
| lifeless | its exposed in bzr-xmlrpc too | 22:01 |
| lifeless | for eclipse and other VC's that want status information | 22:01 |
| gotgenes | lifeless: Is that a wiki (community editable) page? | 22:02 |
| ronny | well, in pida we "invented" anyvc for vcs abstraction | 22:02 |
| lifeless | gotgenes: yes | 22:03 |
| ronny | and boy is abstracting branching patterns fun | 22:04 |
| gotgenes | lifeless: 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 |
| gotgenes | Ah, okay | 22:05 |
| gotgenes | got it | 22:05 |
| bialix | garyvdm: ping | 22: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 either | 22:16 |
| amanica_ | so I'll add some | 22:16 |
| bialix | but not all text files in the bzr.dev has LF-only | 22:16 |
| bialix | have | 22:17 |
| beuno | amanica_, be aware that branches with styling cleanups are usually rejected because of all the spurios conflicts they cause | 22:17 |
| amanica_ | I know | 22:17 |
| bialix | poolie explicitly asked about this cleanup | 22:17 |
| amanica_ | yip | 22:17 |
| beuno | ah, cool | 22:17 |
| amanica_ | bialix I tried to find offending stuff, but could not | 22:18 |
| bialix | tools/win32 | 22:19 |
| bialix | but it's not py | 22:19 |
| amanica_ | ah, but at the moment its not checked | 22:19 |
| amanica_ | its not part of bzrlib so its not considered part of the code | 22:20 |
| bialix | so I guess the real answer on your initial question: because all bzr hackers are linux guys | 22:20 |
| amanica_ | contrib is also like this | 22:20 |
| amanica_ | :) | 22:20 |
| amanica_ | so I thought that while I'm at it, I can check for that too | 22:21 |
| * bialix wanna to say to garyvdm that we have the fix for gentle stop subprocess problem | 22:24 | |
| ronny | "gentle stop" ? | 22:24 |
| bialix | yep | 22:25 |
| bialix | without using hammer and BFG | 22:25 |
| bialix | with "please" :-) | 22:26 |
| ronny | where can this happen? | 22:27 |
| bialix | it's for QBzr | 22: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 bye | 22:44 | |
| jam | Jc2k: Some of the loom failures should be fixed in loom trunk | 22:48 |
| jam | We updated "bzr status" to add another parameter | 22:48 |
| jam | and loom "monkeypatches" "bzr status" and thus also needed to be updated | 22:48 |
| Jc2k | jam: ah cool | 22:53 |
| === dereine[OFF] is now known as dereine | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!