Am I right to assume by the apparent death of this thread that we will be sticking with Subversion for the time being?  For the record, I have no experience with git but would be willing to give it a try if it provides an easier path to more frequent stable releases. 


On Wed, Feb 22, 2012 at 9:15 AM, Matt Leotta <> wrote:
On Wed, 2012-02-22 at 12:18 +0000, Ian Scott wrote:

> My experience of switching between branches in SVN has not been happy.
> Keeping track of which branch I'm on, and making sure my colleagues and
> I commit to the correct one has been difficult. And in particular, when
> working on two branches, it has been very difficult to apply updates
> back and forth between the two. Updates fail (or worse get applied twice
> without a detected collision) because bits of them have been cherry
> picked from the other branch. Keeping track of which versions, or tags
> are the right ones to describe that last sync has been slow and error-prone.
> We like the idea of regular branching in principle, and know at some
> point in our commercial future we are going to have to get better at it,
> but none of our experience with multiple working branches on SVN has
> been encouraging. I have even considered hiring someone and dedicating
> 0.1-0.5 of their time just to manage multiple builds, branches and
> releases within the company. If you could confirm that GIT makes all
> this trivially easy, without making other aspects of the update, commit,
> diff-checking for debugging cycle any harder, then I'd be happy to give
> GIT a go.


The short answer is yes, git makes all this easier without making the
other stuff harder.  Now that we at Kitware live in this world of
branchy development in git, it's hard to imagine how we functioned
without it.

The caveat is that developers need to follow good practices about which
branches to branch from and which branches to merge into.  Git provides
all the tools but doesn't enforce any particular work flow.  Each
project must define a set of guidelines to follow to avoid unnecessary
merge conflicts and avoid, for example, accidentally pulling in someone
else's new features when trying to merge your bug fix into a release
branch.  I suggest reading this article:

We may want to use a similar work flow to the one in the article above.
If anyone wants to do more reading about git and work flows we have a
bunch of information on Kitware public wiki related to git and how git
is used in our various open source projects.


Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
Vxl-maintainers mailing list