VXL version tracking and development is hosted by Git. Please select a task for further instructions:
VXL has transitioned from Subversion to Git for source code version control. Our workflow using Subversion (and CVS before that) involved a linear development path with a single branch (trunk) on the sourceforge subversion repository. All developers pulled updates from trunk and committed changes back to trunk.
Git is a much more powerful tool for version control than Subversion. It allows for a large variety of workflows. Git workflows are often built around creating topic branches for each independent change and merging them back into one or more integration branches when they are complete. The revision history in these topic branches may be local to a developer's computer, shared among a small team, or shared publicly with the whole community. Branches can be reviewed and merged by other developers. And outside developers can request that project maintainers pull their topic branch and merge them back into the project.
Git is also a distributed version control system. The Sourceforge server is no longer the sole copy of VXL's history. In fact, all developers get a complete copy of the history when they clone the VXL Git repository. The Sourceforge server will remain the official copy of the history, but this does not prevent groups of developers from maintaining other copies of the history on other public services (like GitHub) or on private servers. Other shared copies of the history can help facilitate shared development within a small team and provide other services (e.g. code review tools) not provided by Sourceforge.
While Git does provide a large array of possible workflows, it also has a steep learning curve. Many VXL maintainers had never used Git before the transition and were only familiar with linear development options provided by Subversion and CVS. As a result, the VXL Git workflow will initially be quite simple and similar to the previous subversion workflow. Over time we may adapt more advanced workflows to improve release management, use code review tools, etc.
The official copy of the VXL repository contains exactly one integration branch named master. This master branch replaces the role of trunk in the previous subversion repository. Maintainers commit changes to the master branch using one of the workflows discussed below. For now, releases are still made by tagging the master branch with a release version number at relatively stable points and packaging up the source code. For now, the nightly and continuous dashboards should operate as before, except they should build the Git master branch instead of the Subversion trunk branch.
Developers that are new to Git can follow instruction on getting setup and cloning the repository. If you've only ever used CVS or Subversion then the distributed model of Git will take some getting used to. Once you have wrapped your mind around the concepts of distributed version control you'll find it hard to go back. There are numerous tutorials online. A partial list of resources for learning Git can be found here.