views:

226

answers:

4

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?

+1  A: 

Are you aware of the improved merging capabilities in Subversion since 1.5? It's much richer than it used to be. I've not had an issue with merging since moving to 1.5. I'd be interested in seeing what features GIT has that later versions of Subversion lack.

Rich Seller
From provided link I see that: 1.) mergeinfo is not shown/used by default in "svn log" and "svn blame", 2.) treats trunk and branch differently: `--reintegrate` option, 3.) cannot deal with criss-cross (cyclic) merges, 4.) has problems with file and directory renames 5.) isn't svn:mergeinfo stored on client instead of on server (i repository)?
Jakub Narębski
A: 

Git and SVN are two completely different ways of solving the same problem, one is distributed one is centralized so you can't just plug the GIT code into SVN. It would be like trying to integrate JQuery with a legacy VB6 application.

Jared
I know both systems are built around very different concepts. My thought is that one of the important advantages of GIT seems transferable to SVN.
Niels Basjes
See highest voted answer for a more detailed version of my answer.
Jared
+6  A: 

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.

sebasgo
A: 

Take note that mentioned Google Talk about Git (BTW you can read transcript on Git Wiki: LinusTalk200705Transcript) took place before Subversion 1.5. At that time Subversion simply didn't store required for intelligent Git-like merging merge tracking information (unless you used svnmerge extension, or SVK which is (semi)distributed SCM on top of Subversion).

Jakub Narębski