Move repo to git?

[ssteinerX]

I don't want to start a holy war here, but is there any reason that the repo is still in Subversion?

I'm pretty sure SourceForge supports git these days and it's Soooooooo much easier to collaborate on projects with a DVCS.

If you're annoyed by git (which I was!), please try SourceTree from Atlassian.  After a year and a half of not "getting" git, SourceTree made it real and I've never looked back.  I can't imagine going back to Subversion or even Mercurial which I used for over a year.

For consideration, at any rate.

Thanks,

ssteinerX

[hailstone]

I like to use GitExtensions on Windows. From a quick glance it looks similar to SourceTree.

[ssteinerX]

Good to know that there's a good Windows GUI for git.

Git just makes collaboration so much easier.

Once you get used to the workflow, it's really hard to go back to a non-DVCS.

S

[will]

Resurrecting this old thread:

proposal:

• Titi and softcoder register the user megaglest at github
• They upload their normal public keys to it
• Someone (me?) commits mg to github.  There are tools for converting svn history etc, but I think in this case the history is not very interesting.  Simpler and smaller if we just start from fresh clean upload of sourcecode.
• The megaglest user clicks on the fork button on this repo, so this repo is now in the megaglest user's repo list too
• The game data will be stored in a separate github repo.  Rather than using a 'git submodule' to link to it, the folder will be in the .gitignore and there is a new get_game_data script in the root that will git clone it, and update it.  My reasoning is to avoid a developer who is both modifying the code and modifying the data from putting them both in the same commit.
• Anyone wanting to make changes will fork the megaglest/megaglest repo and, eventually, submit a pull request.
• And everyone, even softcoder and titi, use accounts in their own names for development.  People with the megaglest keys will only use that for merging in pull requests.
• This will be quick work; the very next step will be to use the github releases system to store all the 3.9.0 binaries for people to be able to download.
• And we update the developer instructions.
• If you want to start using github issues, wiki, web-page-hosting etc you can too.

[softcoder]

We would really like to move the history with us. pabs (from the debian games team) worked on this a while back and i ftp'd the scripts to an archive at:

http://softcoder.megaglest.org/megaglest-svn-to-git-scripts_only.7z

If possible please see if you can modify the svn and git urls to use a) the new sourceforge svn report url and b) a test git repo and see if the script does what we need.

Once we know the state of that we can start looking at these other steps. (I don't have the bandwidth to be able to run these scripts)

[will]

Thanks Debian Games Team!  The import worked a charm.

There are now three github repos:

https://github.com/williame/megaglest-source
https://github.com/williame/megaglest-data
https://github.com/williame/megaglest-data-source

These are in my name.  This is not a problem.  You just 'fork' them if you want to change them.  You do need a github user account though.

I recommend softcoder and titi make a megaglest user so that we can give out urls like https://github.com/megaglest/megaglest-source

You'd also have static file hosting on http://megaglest.github.io if you wanted to use it for anything.

[Omega]

Thanks Debian Games Team!  The import worked a charm.

Awesome! SVN is a pain to work with sometimes, especially if you are used to git's convenient branching and tagging.

[tomreyn]

So thanks a lot to (primarily) Will and Pabs for helping us migrate to Git and GitHub. There is now a "MegaGlest" organization on GitHub which hosts our repositories.

We should now decide
(a) when (and based on what) we'll declare the repository migration complete (and when that's the case should update any links and notify any third parties) and
(b) what to do with the remaining content left on sf.net.

About (b) we have:

Past (packaged) releases: those should be copied to GitHub and attached to release tags there. We have some binary files on sf.net which are not specific to a certain release, such as the Windows build dependencies and tools. Those could be moved to dl.megaglest.org (archer).

issue trackers: feature requests, bug reports, patches. sf2github was originally written to migrate from the old SF.net interface "Alexandria" (data in XML format) to GitHub, but it seems it can now also handle migrations from the new SF.net platform "Allura" (data in JSON format) to GitHub (or can it?). Once issues are created on GitHub they cannot be deleted, though, so we need to test this on a test repository first. We'll also need to split up those issues on the target repositories depending on whether they refer to game engine or data (this can likely not be done in an automated way). We should also evaluate whether or not we need to continue having issue trackers on both forums and GitHub.

Mailing lists: megaglest-announce (one-to many = newsletter), megaglest-developers (both discussion and announcement list),  megaglest-translations (translator / Transifex discussion and announcement list). GitHub does not provide mailing list hosting, so the following options come to mind: keep mailing lists at sf.net, migrate to freelists.org (also GNU Mailman), optionally use MailChimp for the announcement newsletter (2000 recipient limit); I think all of these options involve a sponsor message attached to each and every e-mail you send, but that's the same we used to have at sf.net

That's all I can think of now, but also enough. ;-)

[GunChleoc]

We should also evaluate whether or not we need to continue having issue trackers on both forums and GitHub.

We could keep the bug reports forum so poeple who are uncertain if something is a bug or not can post there first, and if it has been confirmed open an issue on GitHub then

[Omega]

We should also evaluate whether or not we need to continue having issue trackers on both forums and GitHub.

We could keep the bug reports forum so poeple who are uncertain if something is a bug or not can post there first, and if it has been confirmed open an issue on GitHub then

I agree, given how we often tend to get bug reports from new members that are caused by problems on their end (and are resolved in the FAQ).