I watched the YouTube presentation Tech Talk: Linus Torvalds on git a few weeks ago and one remark seems to be stuck in my mind.
In this presentation (around minute 33) Linus says something along the line of “Some people clone a SVN repository, do merging (=headache in SVN) and then push the result back to SVN.”.
The thought that I have is: If this is possible, then why don’t we port the great merging capabilities of GIT to become an integral part of SVN?
That way we have a great enhancement to SVN and we don’t have to migrate our corporate repositories and related scripts that hook to all kinds of issue tracking and continuous integration systems.
I must have missed something. What is it?
There is another big difference between SVN and GIT apart from one beeing centralized and the other not. GIT tracks content, SVN tracks files.
If you merge branch in SVN, SVN calculates the changes you did in the branch and apply these to the trunk (or whatever your merge target is). These modifications are then transfered to the repository via a normal commit and the source information (history in branch) is forgotten. In later SVN versions (>=1.5) merge behavior improved, SVN now remembers which revisions of a branch were merged and which not, but the base problem still exists.
OTOH GIT will tell you happily in its log that some lines of your code originate from branch xyz and that they are modified in revision a, b and c of the branch. This makes it extemely easy to do crazy merging stuff, like creating a branch, working on it, update to the mainline, do some more work,merge into mainline, branch the branch, and so on without any problems.
UPDATE:
Bottom line: SVN and GIT are just to different in the way they track modifications that SVN merging could become as cool as in GIT without becoming GIT.