[Matroska-devel] moving from Subversion to Git & Github.com?

Moritz Bunkus moritz at bunkus.org
Sat Dec 29 23:52:14 CET 2012


Hey,

On Sat, Dec 29, 2012 at 11:29 PM, Steve Lhomme <slhomme at matroska.org> wrote:

> I also use git a lot and prefer its convenience over svn too. The issue here
> is that many people/project may link directly to the svn repository. All
> these people will have to change their process for us.

To be honest I've never heard of a single person really linking their
processes to the Matroska Subversion repo. To the release tarballs,
yes, but not the Subversion repo.

> They may also be using svn:externals which has no equivalent in git.

Not exactly true. I'm already hosting Git repos of both libebml and
libmatroska in my own github account, and mkvtoolnix' git repo uses
git's "submodules" feature for pulling those two in. Git's
"submodules" work differently than Subversion's externals, but fir
simple purposes it's comparable enough.

> One solution would be to automatically commit whatever is pushed on git to
> the old svn.

Sure, we could set something up, however, I don't know if spending
that much effort is worth it. Like I said above I don't know of a
single person outside of our small circle actually using our
Subversion at the moment, so such work would be for nothing.

Other projects have changed VCS in the past as well, and people simply
adjusted. It's not that much of a hassle.

> Why would we move to github rather than use SF's git then ?

I don't have any hard facts against SF in this regard. I simply like
github's services a lot (I've used them extensively). At the same time
SF has always been rather slow to access for me -- pretty consistently
for the past years. However, I haven't worked with SF's git feature
yet. It's more of a gut feeling for me that choosing github.com would
be the better option.

I would definitely not let SF do the conversion. I'd like to split up
the huge Subversion trunk into individual projects. We could also drop
certain projects that are completely unmaintained and outdated:

- Perl.Parser: pretty incomplete, and there are actually modules on
CPAN that do a better job
- MatroskaPack: completely outdated, should be killed

Not sure about the others; I'd keep them for the time being. Meaning
we would have ~ 16 new git repos to convert to (I'd do the work
myself).

Kind regards,
mosu


More information about the Matroska-devel mailing list