[AG-DEV] SVN or GIT?

Jason Bell j.bell at cqu.edu.au
Mon Jun 25 19:30:19 CDT 2012


Doug

Your suggestions sound perfectly reasonable by me. 

The reason why I raised this issue was to ensure future development is encouraged and what "options" we currently having "moving forward".  Given we are migrating, I thought it might be a good time to consider options and potentially "switch/change".  I didn't want to source code to migrate and then be stuck with that as our only option, or having to spend significant time migrating again (I like only doing things once).

But I think your option of "We could setup and populate a GIT repository later and perhaps make it the master repository, then perhaps sync to the SVN repository using a cron job (e.g. 'git svn dcommit') for those people that prefer SVN and only want to do checkouts" sounds like the best way to go for now.

Anyone else have anything to add?

Cheers,
Jason

-----Original Message-----
From: Douglas Kosovic [mailto:doug at uq.edu.au] 
Sent: Monday, 25 June 2012 07:22 PM
To: Andrew Danson; Jason Bell; ag-dev at lists.mcs.anl.gov
Subject: RE: [AG-DEV] SVN or GIT?

Hi,

Andrew has raised a number of interesting points about GIT.

SourceForge supports a number of source control services which can be enabled independently of each other (i.e. CVS, SVN, Bazaar, Mercurial and GIT) within a project.

For the time being, I think the most important thing to import the SVN dumps (once they become available) from the ANL SVN repository into corresponding SourceForge SVN repositories. 

We could setup and populate a GIT repository later and perhaps make it the master repository, then perhaps sync to the SVN repository using a cron job (e.g. 'git svn dcommit') for those people that prefer SVN and only want to do checkouts.


Cheers,
Doug
> -----Original Message-----
> From: ag-dev-bounces at lists.mcs.anl.gov [mailto:ag-dev- 
> bounces at lists.mcs.anl.gov] On Behalf Of Andrew Danson
> Sent: Monday, 25 June 2012 2:27 PM
> To: Jason Bell; ag-dev at lists.mcs.anl.gov
> Subject: Re: [AG-DEV] SVN or GIT?
> 
> 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.
> ----------------------------------------------------------------------
> ---



More information about the ag-dev mailing list