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-re...@github.com>
Subject: Re: Import and tracking of svn on github [Email]
To: t...@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 supp...@github.com
<mailto:supp...@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/
t...@timwise.co.uk <mailto:t...@timwise.co.uk>
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
