making apps, making webs.

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...