Dear wiki user,

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

The page "SVNvsGIT" has been deleted by JoanTouzet:

The GIT migration is old now, and this page is nothing new.

- == 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.
- This matrix should also help to understand when a project might choose GIT or 
better shall stick to SVN. As an example: If you have a heavily modularized 
project where each module has it's own lifecycle, then better stick with SVN. 
In GIT this scenario would require to create an own GIT repository for each and 
every submodule, which would make releasing them as a bundle a real nightmare!
- ||<tablewidth="903px" tableheight="203px"> ||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! ||
- ||Revisions ||Each SVN server maintains a ticket counter which gets increased 
while assigning the revisionNumber in every commit. ||For each commit, GIT 
creates a unique sha1 of the diff of the commit combined with the sha1 of the 
'parent' commit. This is cryptographically strong and results in having the 
same sha1 for a specific commit on each and every GIT repository. This 
effectively enables all the distributed nature of GIT. ||
- ||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 not possible to have a 'hidden' branch which is only 
readable by certain people. Otoh one can create pre-commit hooks to only allow 
certain people to push to some specified branches.y ||
- ||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. ||
- || || || ||

Reply via email to