Import and tracking of svn on github

[Tim Abell]

They replied, for anyone who is interested.
http://support.github.com/discussions/email/1811-import-and-tracking-of-svn-on-github

------- Original Message --------
From: 	GitHub Support <no-reply at github.com>
Subject: 	Re: Import and tracking of svn on github [Email]
To: 	tim at timwise.co.uk


From: Tekkub
Subject: Import and tracking of svn on github

Full svn mirroring is something we would like to add.  It's not a very high priority though as we don't have git mirroring yet either.  It's likely that both will be implemented at the same time.


----

Tim Abell wrote:
> 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>
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel