Topic: Should we continue to support Kete's Subversion repository?

Topic Type: Topic

Kete will have a GIT based version control repository as of Kete 1.1, should we support a mirror of it in our existing Subversion based repository or make a clean break? Warning, this discussion is quite technical and aimed at developers.

We're fast approaching Kete 1.1.  While we have been developing the new functionality for Kete 1.1, the larger Ruby on Rails community has had a big portion of it switch to GIT (http://git.or.cz/) for its version control system from Subversion (http://subversion.tigris.org/).  After evaluating this for quite sometime, I believe it is time for the Kete project to make the switch, too.
 
Fundamentally, I believe that GIT is a better tool for developing Kete.  It will allow for easier submitting of code from outside developers and for a number of other reasons.  I won't go into them here, because they are well covered in discussions on the Web.
 
My idea is that we only make the source code repository for Kete 1.1 and beyond available as a GIT repository.  We'll maintain the current Subversion repository for 1.0 at svn.kete.net.nz, but won't add anything new to it.  In essence, if you want' to upgrade to Kete 1.1, you'll need to do it with GIT rather than Subversion.
 
Kete 1.1 is already going to be quite a big upgrade process anyway.  So I don't feel that switching which version control system you are using is too much to ask.
 
However, there are some options for maintaining support Subversion in addition to GIT.  So before we make the final decision on how to go about this switch and what it means to those that use Kete 1.0 that will be upgrading, I wanted to open the floor to discussion.
 
Please voice your opinions and concerns via the "join the discussion" link!
 
Cheers,
Walter
Kete Project Lead
 
Creative Commons Attribution-Share Alike 3.0 New Zealand License
Should we continue to support Kete's Subversion repository? by Walter McGinnis is licensed under a Creative Commons Attribution-Share Alike 3.0 New Zealand License
 

Related Items

 
 

Discuss This Topic

There are 5 comments in this discussion.

Read and join this discussion

Walter McGinnis said Installation Guide

It should be noted that we'll document how to make the switch in the Installation Guide. 

Tags: Kete, svn, git, subversion

Kieran Pilkington said Keep svn as an automated git mirror

It shouldn't be too hard to keep the current system running, and setup a cron job to run a script which:

* Removes all files in a copy of trunk ( cd ~/kete_svn/ && svn remove * )

* Commit the removals ( svn commit --message="weekly update removal" )

* Get a copy of git trunk ( cd ../ && git clone git://github.com/kete/kete.git kete_git )

* Copy the files from git to trunk ( cp -a ~/kete_git/* ~/kete_svn/ )

* Remove git files ( cd ~/kete_svn/ && rm -rf .git )

* Commit kete svn (  svn commit --message="weekly update mirroring" )

* Cleanup ( cd ../ && rm -rf kete_git )

Just have to make sure that 1.0 and 1.1 are branched off properly, and once done, no changes are made in trunk (only to branches, otherwise they'll get lost)

Tags: cron, automated, mirror

Walter McGinnis said Automating

Hi Kieran,

Yes, there are ways to automate the updating of a Subversion repository mirror of our new GIT repository.  However, I'm not sure it is a good use of developer time to set up the scripts and configuration to do so.

Note, I actually wouldn't take the approach you suggest.  Rather I would use an intermediary Git repository which pulls daily from our main Git repository and then commits via git-svn to our Subversion repository via cronjobs.

It's actually straightforward, but it is yet another thing to maintain and takes machine and labour resources.

Cheers,

Walter 

Tags: Kete, svn, git, subversion

James Stradling said On support of legacy Kete users

One point that comes to mind on this is that removing SVN access to the Kete repository could add a significant amount of work for people who are tracking Kete trunk for whatever reason. Consider learning Git and/or git-svn to track Kete.

Some members of the community who it seems to me could be affected by this are:

  • Prospective users who have been tracking with SVN in the past
  • Prospective users who are familiar with Git but not SVN
  • Active users who have been tracking with SVN but who in the future will not be able to
Two issues that have been brought up as possible reasons why not to maintain a SVN repository:
  • Effort required: This is valid
  • Manual effort to maintain change-logs: An option here might be to output git-log to a file and commit that to the git-svn repository, then in the commit log state that relevant change log entries can be found there?
Just my two cents

James

Walter McGinnis said Re: On support of legacy Kete users

It should be noted that we are currently supporting both Git and Subversion.  We have a git repository at http://github.com/kete/kete/.  We do all of our work commits, etc. there.  We then periodically manually commit via git-svn to the existing Subversion repository of trunk.

This does incur labor overhead for Katipo.  It also means that the Kete server continues to have to devote computer resources to support http://svn.kete.net.nz/.

So far no one outside of Katipo has commented on this topic.  I would love to hear from the larger community.

My feeling is that we will eventually stop support for Subversion, but that it will be a bit more gradual.

Cheers,

Walter

Tags: Kete, Installation, downloads, svn, git, subversion, version control

join this discussion

 

Tags

Tags: Kete, svn, git, subversion