I just wanted to throw my 2 cents in. First, on the move from CVS to Subversion. I know there have been fears circulating about learning a new vcs, but I've used both CVS and SVN, and I have to say I find subversion much easier to use in my opinion. It was written by the same author as CVS to replace CVS and to address many issues CVS had. I use subversion for my koha-tools repository on Sourceforge. Put simply, I fully endorse a move from CVS to Subversion. As for switching to Google Code. I do not believe that Google is evil. I believe they have reliable hardware, and I also believe that they fully endorse open source and are trying to benefit the FOSS community while benefiting themselves. I think we should be backing up our VCS whatever it may be on a weekly or nightly basis. That way, I whoever is hosting the repository were to dissapear overnight, we wouldn't lose our code history. Kyle On 3/15/07, Dan Scott <denials@gmail.com> wrote:
On 14/03/07, Joshua M. Ferraro <jmf@liblime.com> wrote:
Hi folks This is the kind of email I hate to have to write. We're facing some urgency on a rather important issue: Savannah has been down for two days now, and we're going to have to make some quick decisions to avoid losing any more work time.
This also comes at a point in time when we've decided to pick a new version control system to replace CVS.
I caught paul/hdl this morning, and we feel a move to SVN with hosting from Google is the best solution:
http://code.google.com/hosting/
Here are the likely questions, and our answers:
Q: why SVN and not git, arch, etc.? A: while a distributed repository makes good sense in theory, we fear that it will be a barrier to entry for new library software developers and we'll end up spending a disproportionate amount of time teaching and managing version control
Q: why not host a SVN repo at koha.org or koha-fr.org? A: we're software developers, not proper sys admins, and at this point in our community development it's not fair to place the burden of managing the repo on any one development team.
Q: why google instead of gna.org, etc. A: hosting at a project like gna.org, could result in the same situation we're in now in a few months. With Google, we get a Subversion implementation backed by Google's massively scalable, highly available storage technology, and some of the best sys admins in the world.
Q: what about licensing? A: Google is acting as a code repository, they are not assuming copyright on the code, or changing the license. We're sticking with GPL version 2 or greater.
Any questions, see Google's Terms of Use:
http://code.google.com/tos.html
Q: What about losing all our version history? A: A move to Google will mean we'll lose our version history, that's true. Personally, I can't imagine we'd want to roll back any of the code in either rel_2_2, dev_week or head.
I'd like to arrive at a concensus today about this issue if at all possible, so we can get back to work ... so please send your comments/suggestions/flames asap.
Just don't forget that code.google.com only offers 100MB of SVN hosting per project. Probably not an issue with Koha, but I thought it would be worth mentioning.
Dan Scott
_______________________________________________ Koha-devel mailing list Koha-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel
-- IT Tech Crawford County Federated Library System