See also Git.
What is Git
Git git-scm.org is a widely used distributed version control system. It is used by the Linux Kernel, X.org, Android, Perl, Qt, Gnome, and other projects.
Git gives each developer a local copy of the entire development history (while being space efficient). Git is very fast and scales well even when working with large projects and long histories. This is great for vxl-scale. It is hard to imagine how liberating it is to have the entire project history at hand, mere fractions of a second away, until you have experienced it.
Git branching is very cheap, effectively making for a completely new development style. The developer can work on many features in parallel, without one code branch interfering with the other. For each feature the developer is working on, he can work with sub-teams of other developers before having to commit to the central server. Merging of all these branches is an easy, fast, and well-defined operation. Support for cherry-picking changes is very good.
This guide assumes you already know Git. One roadmap to learn Git it is to read, in order:
* Git Crash Course for SVN users * Git Tutorial * Pro Git: an extensive book about git. Online version is available. Read all of it, esp. chapters 2 and 3, skimming through the last chapters.
Honestly, learning Git is not just mapping commands from Subversion. It is a more powerful system, with new concepts that must be learned by careful reading and experimentation.
Basic user info:
$ git config --global user.name "FirstName LastName" $ git config --global user.email firstname.lastname@example.org
$ git config --global color.diff auto $ git config --global color.status auto $ git config --global color.branch auto
Interfacing to VXL
$ git svn clone --username mysourceforgeuser -v -s https://vxl.svn.sourceforge.net/svnroot/vxl
This can literally take hours or even days to finish. But it is only a first time procedure.
The -s option above assumes the layout is: branches, trunk, tags.
Like a Subversion checkout, you now have a local copy of your project. Unlike a Subversion checkout, you also have a local copy of the entire history of the project.
Periodically, you should get online and fetch the latest changes from the svn server:
$ git svn rebase # think "svn update"
Submit your commits to the server with:
$ git svn dcommit # think "svn commit"
Although you can easily do local branching and merging, it’s generally best to keep your history as linear as possible by rebasing your work and avoiding doing things like simultaneously interacting with a Git remote repository.
Example of workflow
Create a new branch (I name it 'work'), do all my off-line work in that branch and then merge work into master and then do svn dcommit.
$ git checkout -b work # create a new branch .....# work and make commits $ git checkout master $ git svn fetch $ git rebase master work $ git checkout master $ git merge work $ git svn dcommit
If the commit fails you can simply do -
$ git reset --hard HEAD # clean the index $ git rebase master work # follow the rest of the commands from above after resolving the problems
Git is space efficient. As of October 2009, the git repository (with full history) is 238 MB, while the svn checkout is 295MB.
The initial import took about 9h from the West Coast, according to a developer, as of October 2009. Mirroring the subversion repository and only then importing to Git would be a faster approach.
* Pro Git: an extensive book about git. Online version is available. * Google Open Source Blog.
If your lab has a private CVS repository, you can also use Git. See the wiki page GitCvs.
If you have any questions, feel free to contact Ricardo Fabbri (ricardofabbri at users.sf.net) or the vxl-users list.