couchdb-commits mailing list archives

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

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

The "Git_At_Apache_Guide" page has been changed by MarkStruberg:

  This is a work in progress.
+ ASF GIT repositories are currently hosted at
+ == 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. ||
+ || || || ||

View raw message