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 Sat, 19 Nov 2011 11:59:00 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:

  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
+ the sha1 of the 'parent' commit. This is cryptographically strong and the same sha1 on each
and every GIT repository. This allows 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__ ||

View raw message