making apps, making webs.

I'm starting to move most of my projects off launchpad onto bitbucket. launchpad just hasn't gone in the direction that is useful for me, or my projects. It still has some nice features, such as packaging farms (PPAs) and of course bzr integration. However, github and bitbucket have just been moving more towards making it easy for developers compared to launchpad which is more geared towards for distributors who work with an upstream. Last year I hoped launchpad would improve after it went open source, and it has improved. Just not really in the direction useful for my projects. Many people these days are able to use hg, or git... but still very many people have never even heard of bzr. I feel bzr+launchpad was holding one project back a little from gaining collaborators because of this. By that logic, I should be using svn for it... but I don't want to do that :) The documentation to convert repositories to mecurial is on the hg wiki. The conversion seems to mostly...

There is a good explanation of the problems people have because of gits lack of move support. This is Linus explaining this problem he has with git. The problem is that git gets confused when you move code from one file to another, and change it at the same time. Since it uses code similarity to find moved code - changing the code at the same time that you move it confuses it's move detection code. So the solution is a convention of making almost no code changes when moving a file. Delete the file, and create your new file with no changes, and merge - then make your code changes in the new file. See the problem with git and move for more details. Of course systems which don't use move detection by code similarity completely fail when people delete a file, and create a new file(eg. bzr). So both git, and bzr fail when you forget to follow conventions. An ultimate system would do both - detect code moves automatically, and allow you to do explicit moves. Update: Jay Parlar c...

With git, and bazaar two differences are that one tracks code moves fairly well and one tracks file moves well. One was originally written mostly by someone managing a code base, and the other is originally written by a company doing an operating system. So you can see their priorities - one has lots of code it cares more about, and the other has a lot of files it cares more about. (There are quite a few other priorities and features that each have). I guess tracking the code itself is much more important than tracking file renames - for me. Much more useful anyway. However *both* are important parts of revision control. Many times during development I might cut a function/class from one file and move it into another. I can't get reports of this information in a meaningful way with bazaar (or can I?). Also I might accidentally move a file with the command line tools, change it, then add it in again to the revision control system. This is because I forget that I need to use th...