Search
Navigation
Discussion Forums
GIT vs. Subversion
I would like to get your opinions on what is better for open sourcing the software under.
Do you prefer GIT or Subversion?
What are the advantages and disadvantages of each?
Thanks.
Avinash
If I had to choose between those two, and only those two, apps, I'd have to choose SVN because it uses atomic commits. I'm not a Git user, but there are a lot of anecdotal comments about commits failing halfway through, through no fault of Git. A partial commit can cause a lot of problems later in the process.
More important, from my perspective, neither of these apps facilitate requirements traceability implemented through an issues management system. The ability to tie code changes through an issue to a stated software requirement is critical to building software development processes which adhere to current best practices. The choice of CM backend is critical to the stability of the project and I would personally recommend a wider search for a suitable product.
In my experience, there are for-profit companies out there that can be persuaded to part with a package for a sufficiently visible and professionally managed non-profit. It's a good thing for them to do in an absolute sense. It makes them look good. In many cases they can get tax breaks for their actions.
Using either is going to be tricky because of how distributed the project will end up being and how many developers there will be. I have used both, and am currently using Git for a work project. I have found Git to be very quick, and allows offline work to be done rather nicely without having to hit the central repository for every thing. Each person basically has their own repository to work in, create branches...etc. So I can pull the code onto a laptop and work while not on a network. Then branches can be pushed back to the "origin" repository for an integrator to merge.
I agree with kumabear2000 though that without an issue tracker, integration will be a nightmare. We've used Redmine (http://www.redmine.org/), but that doesn't enforce anything. We handle integration through convention. Each developer takes an issue off Redmine and then creates a branch using the issue#. When the issue is resolved, the branch is pushed to the origin repository where it can be integrated by an integrator who can review the branch, do diffs, run unit tests, and decide if it should become part of the baseline.
I (also?) prefer Git due its decentralized approach, which is much more compatible with an open source workflow.
I used Svn for a project I did a couple of months ago mainly because I developed from two different computers (one home, one at work) and didn't want to wander around with usb sticks :D. When it came to decide which version control system I should use I chose with two things in mind:
1) Which is supported from my IDE (it was QTCreator)
2) Which could be easily installed (the server)
In the second i didn't really get how I should do it for GIT, and since I lost some portion of an old project with cvs I was frightened (!!) to use something that I don't feel sure about it!
Beyond this, many complex and crowded (lots of developers) projects use git, so it must be good.
Closing, I will use whatever suits best to the project :D
I've never used Redmine, but it looks like a competent app. I'm currently using AccuRev/AccuWork after too long using CVS. It has been my experience in highly distributed environments that the "Wild West" mentality can get acculturated and it becomes nigh on to impossible to figure out which code chunks are written in response to which initial requirement, which have been written to respond to an issue, and which are rework based on an earlier issue response. A CMS which tightly controls all of those interfaces without putting impediments in the way of the developer should be a primary goal after defining the underlying processes.
Actually, subversion has a fairly powerful hooks system that lets you write custom scripts (in just about any language) that will let you hook into the commit system, and I believe, the ability to make branches and tags.
It's pretty tightly integrated into Google Code's issue system, as well as the open source project management application "Trac".
I primarily use SVN but I think GIT will probably suit the needs of the project a little better than SVN
My initial thinking was to select a CMS, then find a hosting environment that supports that CMS. We would then choose an issue tracker that is supported by the hosting environment. But, what I am hearing is that we might want to make the decision together, rather than sequentially. And one solution is to use Redmine with GIT. We will be making this decision in late May to early June. So, any other thoughts would be very useful.
Thanks.
Avinash
I always get a little nervous when the discussion turns to tools prior to a discussion of the software development process. The process should never be shoe-horned into utilization of a particular tool. The process should be well-defined and understood with particular emphasis on workflow from requirements definition through coding, testing/QA, rework, and integration, and then a tool selected which supports that process with as little modification as possible. Is there a plan to generate controlling documents like a Software Development Plan and a Software CM Plan, or do they already exist in some form?
A project this distributed and coordinated primarily through the web is new to me. I'm used to an office environment, and have never tried an open source project. So I'm looking forward to what we agree on.
We do need to agree on a basic workflow. The question is how much process is enough? At minimum we need to know what issues are out there, who it has been assigned to, and how we review and check it back in. We probably want some agreed upon unit test format to go with each module as well.
We can put hooks in Git or Svn to enforce our workflow; I think some customization is always required. But I agree it should be minimal.
Does the SETI team already have some workflow and tools they are already using? Where is your existing code base kept? How is it tested?
We do have processes - although they are not as robust as what a commercial development environment would have. As an example, our requirements are not formally captured. The development team continues enhancing the software; the same team tests the software.
The software repository was originally under CVS, and our processes were geared around that.
In preparation for open sourcing the software we have migrated to GIT. And, we have mixed feelings on it. Some of our team really like it, others suggest that we should move to SVN, hence this forum discussion.
I too like the approach of finding the tool that fits your processes, rather than adapting your processes around the tools. But, sometimes tools provide good sets of reference processes - so that we don't have to reinvent the wheel. Since we are making changes anyway, we are willing to migrate to processes and tools that have proven to be successful in open source.
I was talking with a friend who pointed out that Goddard Space Flight Center is developing their new General Mission Analysis Tool (GMAT) on SourceForge. GMAT is "a space trajectory optimization and mission analysis system developed by NASA and private industry. GMAT contains new technology and is a testbed for future technology development. (http://gmat.gsfc.nasa.gov)"
The project is housed at:
http://sourceforge.net/projects/gmat/
There are lots of similarities here including an open design that allows Matlab code and other software chunks to be hooked to the GMAT source. The bulk of the code is in C++.
b
Site Map | Terms of Use | Contact
189 Bernardo Ave., Suite 100 - Mountain View, CA 94043 - Phone 650.961.6633 - Fax 650-961-7099
Copyright © 2011. SETI Institute. All rights reserved. Unless otherwise indicated, the documents and graphics stored on this Web server, seti.org, are copyrighted.
Links to these documents are permitted and encouraged. No copies may be made without permission.