Here’s some stuff about ( yeah, I know – ‘geeks, stop migrating from svn and git and vise versa – just developer code and don’t spent time on this!‘ ) svn and git comparison.
What do we have : git and svn installed on a same server, empty both svn and git repositories – I will add same data and provide same changes in both repositories, and also, in another folder, I will checkout how update changes works – so in this tests I’m going to figure out how it works for ‘commiters’ and for ‘those who update changes’. My tests deal with typical operations with version control systems – checkout time for adding, pushing and pulling various types of data and checkout how update for them will work – test’s detailed information is below table. For git I use git+ssh protocol, for svn I use svn protocol. I don’t provide any special configuration nor for git nor for svn – all settings is about to be default. Also I would like to note that this tests is partially incomplete – I don’t checkout how delete, branching, merging and some other functions works – so in future I will try to add these points onto this test. Main result of this test – git is faster than svn about a 2-3 times in typical configuration. There’s only one really bad points – git works bad on pretty big files ( > 300 mb size), for some big size ( ~1gb ) it git even can exit with error about memory leak – there’s some special git-related project – like git-bigfiles – this stuff should help you to work with git and big files together.
|
svn |
git |
svn/git |
| Test 1 : adding boost 1_43 |
add ( 1 sec )+ commit ( 600 sec ) = 601 sec |
add ( 3 sec ) + commit ( 86 sec ) + push ( 612 sec ) = 701 sec |
0.85 |
| Test 2: checkout repository after Test 1 |
svn co = 109 sec |
clone = 18 sec |
6.05 |
| Test 3 : small changes in sources – add first line with comment to some files – 346 files changed |
svn commit = 5 sec |
commit(2 sec ) + push ( 2 sec ) =4 sec |
~1 |
| Test 4: update after this Test 3 |
svn update = 15 sec |
git pull ( 7 sec) |
~2 |
| Test 5: bigger change – add first line with comment to 5363 files |
svn commit = 103 sec |
commit ( 6 sec ) + push ( 18 sec ) = 24 sec |
4.29 |
| Test 6: update after Test 5 |
svn update = 28 sec |
git pull = 12 sec |
2.3 |
| Test 7: real-life project add ( 2.6 gb of data ) |
svn add(21) + svn commit(1h 2m 25s) = 3 766 sec |
add (38 ) + commit ( 1m23 ) + push ( 18m28 ) = 1 m 51 + 18m 28sec= 20 m 19 sec = 20 m 19 sec = 1 219 sec |
3.1 |
| Test 8: update after Test 7 |
svn update ( 11m 58 sec ) = 718 sec |
git pill = 5m 27 sec = 327 sec |
~2.2 |
| Test 9: source change (change namespace visibility) |
svn commit ( 1m 28 sec ) = 98 sec |
commit (5 sec ) + push ( 3 sec) = 8 sec |
12.25 |
| Test 10 : update after Test 9 |
svn up = 22 sec |
pull ( 9sec) |
2.4 |
| Test 11: full checkout project |
svn co 12m 45sec = 765 sec |
pull ( 4 min 3 sec ) = 243 sec |
3.14 |
| Test 12: big file test : apache log ( 50 mb ) |
svn add(3) + commit (1m 27s ) = 1m 30 sec = 90 sec |
add (3) + commit(6) + push (1m 18 sec) = 1m 17 sec = 77 sec |
1.16 |
| Test 13 update after test 12 |
up = 26 sec |
pull = 17 sec |
1.52 |
| Test 14 : big files test: c++ sources in one file ( 70 mb ) |
add(3) + commit(1m 15 sec) = 1m 18 sec = 78 sec |
add (2) + commit (2) + push ( 56 sec ) = 1 m = 60 sec |
1.3 |
| Test 15 : update after Test 14 |
up = 28 sec |
pull = 14 sec |
~2 |
| Test 16: 100 MB xml with encoded data |
add(3) + commit (8m 37 sec)= 8m 40 sec = 520 sec |
add (9 sec) + commit (1) + push ( 24m 34 sec) = 24 m 44 sec = 1484 |
0.35 |
| Test 17 : update after Test 16 |
up = 52 sec |
pull = 47 sec |
1.10 |
| Test 18 : 300 MB xml with encoded data |
add ( 1 ) + commit( 9 m 26 sec )= 9m 27 sec = 567 sec |
add (3) + commit(8) +push (17m 12 sec) = 17 m 33 sec = 1053 sec |
0.53 |
| Test 19: update after test 18 |
1m 39 sec |
pull= 1m 29 sec |
1.1 |
| Test 20 : 1200 MB xml with encoded data |
1h 24m 34s |
failed |
? |
| Test 21 : update after Test 20 |
5m 47 sec |
failed |
? |
| |
|
|
~2.6 |
So – In common we have that git is about 2.6 faster than svn.
I understand that this is may be very non-precious tests and also I don’t check how delete or branching works, but anyway I checkout my own most used operations during this test. In common we can see that git is more than 2 times faster than svn – everything looks fine with git, except one really bad thing – work with big ( more than 100 mb size ) files – for this type of file svn is really works faster, and for too big ( more than 1 GB files ) git even crashed during ‘git push’ command with ‘fatal: Out of memory, malloc failed‘ message.
Test1 boost 1_43 C++ library : 29135 files and 31609 objects including folders, 286 Mb summary size
Test 3
I just add first line to some cpp files :
find ./ -name "*a???.cpp" -exec sed -i 1i"//test comment `date` : {}" {} \;
Test 5
Change all *.cpp files in the same way :
find ./ -name "*.cpp" -exec sed -i 1i"//big test comment2 `date` : {}" {} \;
Test 7: Add real-life repository : many sources in cpp, perl, erlang, makefiles, bash scripts, MS word documents, images, pdf’s, compiled binaries, resource files, etc, in sum it contains 4605 files, size is about 2.6G
Test 9:
Refactoring simulation : make to use “std::” specifier for all cerr and cout. Not sure it’s really safe in real-life-development, but it’s okay for test purpose.
find ./ -name "*.h" -exec sed -i "s/ cerr/std::cerr/g" {} \;
find ./ -name "*.cpp" -exec sed -i "s/ cerr/std::cerr/g" {} \;
find ./ -name "*.cpp" -exec sed -i "s/ cout/std::coutr/g" {} \;
Test 11: checkout whole project
Test 12: adding 50 mb text file – apache logs
Test 14: adding 72 mb file – many c++ sources concantenated in one big file
Test 16: small xml : 100 mb – xml file sample from real life
Test 18: medium xml : 300 mb – same ( but bigger ) real-life xml fil
Test 20: large xml : 1200 mb – sample of pretty big real-life xml
git push failed with error message of memory leak ( as I can see ) : “fatal: Out of memory, malloc failed”
I collect some usefull information about different source text repositories version control systems : git, svn, cvs, mercury links – take a look on this if you’re interested in different VCS system using.