[AG-DEV] SVN or GIT?

[Andrew Danson]

Hello Everyone,

After the discussion this morning in the test session I took it upon myself to find out a bit more about GIT and how it is different to SVN. I've used subversion in the past and found it to be a good tool for what I use it for. I tend to use it on my own small projects and to keep up to date with project source that I'm monitoring. So most of my repositories usually have myself committing to them and no-one else. In observing larger projects such as one from a previous client with a large set of documents it can work quite well in the circumstance that branching doesn't happen too often. However I've also seen some open source projects (one in particular) with a lot branching that don't work so well, became cluttered, and are a problem.

Having used SVN for a while, it's a good tool for version control if:
- you have a small team
and/or
- there is relatively little branching that can be easily managed.

creating patches and committing them into the repo is fairly simple with SVN, but merging branches is much more complicated.

GIT on the other hand seems to be built with branching in mind. 

>From reading the documentation for GIT I found that these things are an advantage/improvement with GIT
- The data is distributed - every one always has copies of the full repository as long as they have synced with it recently. The repository is therefore safer from data/server failure.
- you seem to be able to do a lot more work with GIT whilst offline and not able to connect to the server
- versions can be tagged so we can find particular versions of the software in the repository without finding a revision number like in SVN. We can use our own version numbers!
- You can set it up to sync remotely to people that you collaborate closer with. (requires being set up though)
- Branching is much more useful and merging is simpler than SVN. You can still get merge conflicts but most of the data management is done for you :-)

There are also a few downsides.
- If the repository is large it could become a large download for even a small project. This really probably won't be a huge problem for us.
- There seems to be quite a learning curve to get your head around how branching and a few other aspects work. 
- because you can do a lot of work offline, and have to specifically push branches (and commits) to the origin server. We could lose branches or work done if they aren't pushed to the origin server regularly. This is a matter of making sure people commit their branches regularly!

Whether it's really worth changing will depend on how we structure future development of the code, and how we allow people to contribute. It may turn out that SVN is adequate for the development model we want to use, in which case it would be better to stick with it. SVN is well suited to having a few people maintaining the repository and testing branches and development branches for coders to work in. Then having anyone else submit patch files when they want to contribute. But if we want to take a different approach GIT will probably be a better option as it allows for better collaboration and branch management across a larger dev team.

So perhaps we need to decide on what kind of development model we use? How we deal with changes to code, and what sort of testing they have before being deployed to the main stable version will change what we need from the version control system. We also need to consider the impact of people having to learn to use GIT if we adopt it. For the most part I think this should be a secondary consideration as the benefits of choosing GIT would be important (if we need them that is!)

We should probably document the development workflow and put it on our website so anyone getting the repository knows how to contribute in either case.

I haven't been able to determine if we can retain the repository history within GIT, but given how it works and it's structure I'd be surprised if it's not possible. If it isn't possible we could still maintain a SVN repository with the original data as of now for archival purposes as Jason suggested. Perhaps someone experienced with GIT could answer this.

realistically the advantages out weigh the disadvantages. So I'd be in favour for switching to GIT if everyone else thinks it's ok. Do we have anyone (or enough people) with experience using GIT to get it set up and use it?

Cheers
Andrew



>>> Jason Bell <j.bell at cqu.edu.au> 25/06/2012 12:27 pm >>>
Colleagues

Over the weekend, I was having a discussion with a colleague in regards to software repository in general.

Anyway, this bought up the topic of moving the AG code to sourceforge and using SVN.  It was recommended to me that a "distributed version control system" and that something like GIT should be considered over SVN.  Given my very limited understanding of either SVN or GIT, I was then brief on the benefits for moving away from SVN.

This topic was discussed this morning at APAG general test session and few observations were made:

*	Given we are moving the repository, it would be a good time to "change", if deemed appropriate;
	- Note, SourceForge supports both;
*	Given the AG project is "relatively small", maybe SVN will suffice;
*	Many past AG contributors have used SVN, so they will have to "learn" a new system (if switching to using GIT), if they contribute in the future;
*	We currently use SVN, once we get the "repo dump", will we lose all the "history" if we switch to GIT;
	- maybe an archive of history could be maintained;
*	Within the AG community - we don't want to change "because someone suggested it", or "for the sake of it", but because people would rather use it;

Therefore, I would like to invite a general discussion to the developer community on which would they prefer to use?  I guess, if we "get enough votes" for GIT, then it will be strongly considered.  Hence, have your say and provide feedback and "vote"!

Many regards,
Jason.

-------------------------------------------------------------------------
Jason Bell, B.I.T. (Honours)

Video Collaboration Champion
Queensland Cyber Infrastructure Foundation
http://www.qcif.edu.au/ 

ARCS eResearch Collaborative Services
http://www.arcs.org.au/  

Senior Research Technologies Officer
Information Technology Directorate 
CQ University Australia
http://www.cqu.edu.au/ 

E-mail : 	j.bell at cqu.edu.au 
           		j.bell at qcif.edu.au 
         		jason.bell at arcs.org.au 
Work   : 	+61 7 4930 9229
Mobile : 	0409 630897
Postal : 	Building 19, Room 1.55
         		Central Queensland University
         		Bruce Highway
         		Rockhampton, Queensland, Australia, 4702
-------------------------------------------------------------------------
Patience is a virtue.

But if I wanted Patience,
I would have become a Doctor.
-------------------------------------------------------------------------