Import and tracking of svn on github

[Tim Abell]

An open letter to support at github.com
<mailto:support at github.com>---------------

Hey there!

Firstly thanks for a fantastic service.

I would like to politely encourage you lovely people at github to 
support tracking of public subversion (svn) servers.

I appreciate your sentiment that not supporting svn meta data is "/our 
gentle way of saying it's time to move to git full-time/" as stated in 
your comment on the relevant github blog entry 
<http://github.com/blog/156-subversion-importing>, and I agree that full 
migration to git is a desirable result.

I am making some presumptions about what drives github (as many [paying] 
users as possible?), and I am aware there would be work involved for 
yourselves, however I will present some reasons why I think it would be 
good for github to support central tracking of public svn servers, both 
for github, and for the wider community.

I will use the gnucash project as an example, as this is what I've been 
attempting to work on recently.

For many open source projects using svn, the core developers who have 
svn commit rights are likely to be more or less comfortable with the 
status quo. They are already able to easily maintain versioned code for 
their project, and git offers only a minor practical gain for them. 
There is also likely to have been a reasonable investment in 
infrastructure around the svn server, such as build servers, irc bots, 
mailing bots, maintaining committer lists, web based svn access and 
documentation of the development process.

This means it is unreasonable for an outsider like myself to 'demand' 
that an established project move to git for source code management 
(scm), a move which as highlighted above is extra work for those 
volunteers for little benefit to them.

So this leaves a potential new contributor to a project such as gnucash 
with a steep barrier to creating any significant contributions. When 
creating and testing anything more than a relatively simple patch, it is 
highly desirable to be able to track changes in a local scm. As you are 
no doubt aware, svn offers no support for non-core developers to manage 
their code. The central commit rights model also makes it less useful to 
experiment, as there is a large barrier to publishing experimental 
changes and gaining an audience. This is damaging to the open source eco 
system.

I have tried several approaches when attempting to create, manage and 
publish modifications to gnucash, none of which are entirely satisfactory:

    1) Using github to clone the svn server directly.
    This is fine for a one off migration, but without a complete move by
    the core developers the lack of svn metadata means that the git
    repository is forever stuck in time and becomes decreasingly useful
    as the svn version moves ahead. I think most people who would like
    to use github to track a public svn server or open source project
    will get no further than this.

    2) Local import from the svn server, followed by a push to github.
    This is effective, and allows one to continue to track the svn
    server. The original clone of a project such as gnucash (11k
    commits) takes considerable time (eight hours or more), and due to
    the non-portability of the svn metadata this process effectively has
    to be repeated by every new user who wishes to use this clone
    without falling behind the svn server (unless we rely on the
    original importer to keep grabbing changes). I suspect this is too
    much to expect from many casual new contributors.

    3) Using a bazaar (bzr) branch on launchpad.net
    <https://code.launchpad.net/>.
    Launchpad will centrally clone and track a public svn server
    <https://help.launchpad.net/Code/Imports>. Personally I am not keen
    on bzr, and I'd take a wild guess and say you guys and gals prefer
    git too. I also ran into issues with the build scripts of gnucash
    expecting to be run from either an svn or a git working copy (a sign
    that at least one core developer is already using git privately).

    4) Publishing patches on the bug tracker or mailing list.
    This is an inferior model to the git method of sharing changes, and
    makes it hard to collaborate on new features outside of the core
    development group.

This currently leaves bzr/launchpad as a potentially attractive solution 
for new contributors, which I would imagine is not your ideal scenario.

If your objective is as stated to encourage projects to move from svn to 
git, then I suggest to you that providing a continuous pull from the 
primary svn server would ease the transition for many projects. If there 
were to be a single central git repository on github that tracked the 
svn server, then it would make it easier for both new contributors and 
existing developers to begin working on the code primarily with git. 
This would include merging suggested changes or patches from new 
contributors to those with commit access using the excellent git model 
of publish and pull. Once this is the norm on a project it becomes much 
easier for the project to move completely to git as all the core 
developers can say "hey, we're all using git most of the time now, let's 
drop svn completely" and make the final jump.

So in summary, I believe that providing continuous import from svn to 
github would encourage /more/ projects to migrate to github, not less. 
And that providing this service would be an enormous boon to the open 
source eco system.

I hope I have made a persuasive argument, and look forward to your response.

Relevant links:

    * github blog on svn imports
      <http://github.com/blog/156-subversion-importing>
    * github svn import guide
      <http://github.com/guides/import-from-subversion>
    * launchpad svn import information
      <https://help.launchpad.net/Code/Imports>
    * gnucash bazaar branches <https://code.launchpad.net/gnucash>,
      including one tracking trunk
    * me on github <http://github.com/timabell>, including various
      gnucash import attempts
    * gnucash wiki page on git <http://wiki.gnucash.org/wiki/Git>, which
      describes the trials of maintaining both in parallel
    * my git-svn ramblings <http://timwise.wikispaces.com/git+svn>


Yours

Tim Abell
http://www.timwise.co.uk/
tim at timwise.co.uk <mailto:tim at timwise.co.uk>