couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Couchdb Wiki] Update of "SVNvsGIT" by MarkStruberg
Date Fri, 18 Nov 2011 21:55:54 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:
http://wiki.apache.org/couchdb/SVNvsGIT?action=diff&rev1=1&rev2=2

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

Mime
View raw message