Differences between revisions 1 and 2
Revision 1 as of 2011-11-17 20:48:02
Size: 101
Editor: brln-d9badfba
Comment: Go!
Revision 2 as of 2011-11-18 19:29:21
Size: 2816
Editor: chello080108122184
Comment:
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:

ASF GIT repositories are currently hosted at http://git-wip-us.apache.org/

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

||<tablestyle="width: 903px; height: 203px;"> ||SVN||GIT||

||<tablestyle="width: 903px; height: 203px;">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. ||
|| || || ||

This page collects the guidelines established in the git experiment.

This is a work in progress.

ASF GIT repositories are currently hosted at http://git-wip-us.apache.org/

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.

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.