2011/4/21 Vishvananda Ishaya <[email protected]>: > This right here is my main issue with bzr. I can handle the slowness,
Slight change of topic. What exactly is it that you guys find so slow that you actually feel the need to complain about it? I can't help but wonder if there's something different in the way we use bzr that makes it feel slow for you and not for me, because I'm really not getting it. I'm not trying to devalue your opinions, I'm just trying to understand them, otherwise this discussion will never, ever be productive. For giggles (and to actually have some numbers that we can relate to) I tried using bzr to work on the linux kernel for a little bit. That's a pretty massive body of history as well as code. While I could *measure* the difference (after all, these computer things can measure stuff with pretty decent resolution), it didn't really *feel* much different. All of these were done with a cold cache: It took 13.5 seconds to run "git diff". It took 15.2 seconds to run "bzr diff". Committing a one-line change with "git commit -a -m foo" took 15.8 seconds. Committing a one-line change with "bzr commit -m foo" took 16.3 seconds. Committing a one-line change with "git commit -m foo <filename>" took 15.8 seconds. (Not kidding!) Committing a one-line change with "git add <filename>; git commit -m foo" took 0.5 seconds. Committing a one-line change with "bzr commit -m foo <filename>" took 1.5 seconds. Yes, it's consistently slower (except that odd-ball "git commit -m foo <filename>" thing which I ran 3 times extra to make sure), but not nearly enough that I'd spend time complaining about it. If I want to commit something and don't set a commit message on the command line, the majority of the time will be spent in a text editor typing a commit message anyway. If I specify a commit message on the command line, it's only when I want to push my changes that I need to wait for it to finish. If I'm just committing stuff to snapshot my current work in progress, I just run "bzr commit -m foo" and alt-tab my way back to my editor. Please help me understand either: * how these small differences end up having a large impact (like, say, which part of your workflow gets interrupted by it on a regular basis) or * what you're doing that is actually much slower. I'll readily admit that my analysis further up was crude and by no means at all comprehensive. I didn't feel the need to do 50 different things to measure the exact difference, since I have a hunch that you guys will have examples readily available that can explain and help me understand better. > but I find it very difficult to maintain multiple branches and share patches > between them in bzr. I end up doing a lot of diff | patch -p0. I think > git's rebase is far superior to that workflow. I'll take a look at loom, > sounds interesting. This sounds fascinating. I can't remember having to do anything like this. Can you give me an example? -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
