couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Couchdb Wiki] Update of "SVNvsGIT" by MarkStruberg
Date Fri, 18 Nov 2011 19:55:47 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.

The "SVNvsGIT" page has been changed by MarkStruberg:

New page:

== Main difference between SVN and GIT ==

For understanding the setup of our GIT repositories better, we have to understand the difference
in the mechanics of GIT compared to what we had available before at the ASF.
||<tablewidth="903px" tableheight="203px" tablestyle=""> ||SVN ||GIT ||
||Content ||SVN handles the content on a per-file basis. Each file is basically versioned
on it's own and has it's own history. Moving a file with svn mv will preserve this history.
Just copying the file will not! ||GIT treats all the files in the repository as a big union.
All the commits basically form a tree of diffs which get applied to the initially empty project
directory. There is no 'native history' on a file basis because of that. For producing a git-log
or git-blame, GIT needs to walk through all the commit tree and check whether the given file
is involved. Otoh git can not only automatically track rename-files, but also perfectly tracks
if you move a method from one class to another! ||
||Security ||Handled by SVN itself. It's perfectly possible to have different directories
and files in a SVN repo which have different security rules applied. ||GIT has no own security.
It solely relies on the underlying transport/filesystem. It's imo not possible to have ||
||Branches ||SVN creates an own directory per branch in ./branches/{branchname}/. The main
content is always in ./trunk/ ||GIT treats branches more like the way CVS did. When checking
out a branch, the directory remains the same, only the content will get 'switched'. Each branch
is technically equal. It is NOT possible to only do 'partial' branches (on a partly tree of
the project), instead a branch is ''__always__'' in the whole repository! ||
||Tags ||Similar to SVN branches. They are held in ./tags/{tagname} and basically a read-only
svn copy of trunk. ||Tags in GIT are just a name to a specific commit-sha1. Basically just
a shortcut for the sha1. Like with branches, a tag is always over the __whole__ ||
||Modularisation ||SVN fully supports sparse checkout and treats the checked out content without
any difference whether it is a full project tree or just a sub-project ||GIT originally didn't
know any sparse checkout. This capability only got added in git-1.7.0 and works quite different.
You will still get the whole tree content in your .git/objects. Also all tags and branches
performed on such a sparse checked out project will still cover the whole repo. There is support
for git-submodules, but this is more similar to the flat project mapping of Eclipse than a
real nested project structure. ||
|| || || ||

View raw message