[continuing from [forum.vcmi.eu/t/forum-issues/65/1) ]
The topic of the migration to Github has been raised a number of times over the last few years. Over the time, the support for this proposal has been steadily raising and now it is the time to make the decision.
The proposal is to:
change version control system from SVN to Git
change repository host provider from sourceforge to github
Rationale:
Git is superior over SVN in several important ways:
your local working copy is a repository itself. You can commit intermediate changes without sending them to the central repository. This significantly helps in developemnt and storing various experiments.
better support for branches, making it much easier to develop features over extended period of time without breaking the trunk. It is also much easier to develop several features concurrently.
local copy stores the full history, so operations like log or blame are de facto instant
Github is superior over Sourceforge in several important ways:
support for “pull request” — easy way for contributors outside the core team to submit their changes
sane repository and commit browser
support for reviewing the code
The main drawback of Git that was poor Windows support is now largely gone:
Visual Studio 2013 features built-in Git support. It is incomplete but quite convienient for the most common operations (pulling changes from repo, committing and pushing your own changes; branches management).
TortoiseGit is ugly and inconvenient. Yet, it allows doing everything that you need in a familiar GUI (for those, who used TortoiseSVN).
So the only serious drawback I see is that we’ll end up with ugly hashes for identifying commits instead of revision numbers that I like so much. Well, that can’t be helped.
Please let me know:
if you’re OK with the migration (feedback so far has been either neutral or positive, however I want to be sure)
if you have any preferences when the migration should occur
if you have suggestions on how the migration should be technically realized (I don’t have any experience and will rely on whatever the google spits out)
Neutral towards git, although I like features that distributed VCS can offer (like better branches). And quite positive towards github features specifically.
Anytime you want. Worst thing that may happen is that I’ll have to move some diff’s from svn repo to git.
As for migration:
I remember something about line endings - github does not like mixing Win/Unix line ends or something like that. Anyway it is probably a good idea to unify line endings during (or immediately after) migration.
It seems that right now only you and me have full access (thanks BTW). Does anyone else needs to post their profile names or you’ve handled this already?
Github offers its own issue tracker and wiki. What we should do with them?
Wiki - disable completely or place redirect to wiki.vcmi.eu? Don’t see any use in it for us.
Tracker - disabling it is easy. Or maybe keep it as well as Mantis? So it can be used by those who are too lazy to register on Mantis and/or for github-specific issues (like that Travis support)
Readme file. Completely useless in current form. Github displays it below repository so quite a lot of people will see it. I think it can be considered as front page of repository. Somebody must rewrite it completely. Example of nice readme in a similar project: github.com/zinnschlag/openmw
Since with git it is possible to develop new features in branches perhaps we should decide how master branch should be used? And document this properly ofc. For example:
before merge somebody must review, preferably with different compiler (gcc or clang vs msvc)
keep one feature/bugfix per commit. Commits can be done locally and then merged to master as part of (bigger) branch without spamming commit log as we had in svn.
Debatable, but perfect time for such changes. I would also support reorganization of our source tree - right now our root directory is quite a mess.
remove some garbage files like NEWS (empty) or COPYING (one-liner that refers to license.txt)
create “src” directory and move client, lib, server, etc in it
create “data” directory and move config and Mods in it
move project files into separate “projects” directory, if possible?
Re Github’s tracker: I suggest to choose only one option. We, in SuperTuxKart, had github tracket and Trac and it was such a mess when tickets started to be duplicated.
@Tow:
I’m new to Git, so I informed me about the different kinds of workflows you can use with Git. This page has a good introduction to Git including a few examples: atlassian.com/de/git/workflows (in german). The part about pull requests is written in english. There a few nice advantages for Git over SVN. That’s the typical workflow when adding a new feature or fixing a greater bug:
A developer creates the feature in a dedicated branch in their local repo.
The developer pushes the branch to a public repository.
The developer files a pull request.
The rest of the team reviews the code, discusses it, and alters it.
The project maintainer merges the feature into the official repository and closes the pull request.
Copied from the site mentioned above. The review and discussion part is great. Currently I’m moving some level up logic from server to lib and a few things should be reviewed or discussed before commiting to master / trunk. So it would be nice if work in progress can be reviewed by others, while keeping trunk or master in a working stable state. BTW, will write PM to you Tow, soon
I would vote for unix/linux and mac line endings:)
Perhaps someone could also rewrite AUTHORS file. The site you mentioned has a nice authors file as well.
Good point! I don’t really like it if I get some compiler errors about template stuff:)
I would say new features, experiments, greater refactorings or greater bugfixes should be done on a new branch. For the rest it’s OK to work directly on master.
+1! Is it possible to locate CMakeLists in separate directories? I think it should be possible for MSVC. Where should we locate our package subfolders rpm, osx and debian?
Mixed line endings don’t cause any trouble. The Git provides an option to automatically convert line endings on commit/checkout, so every developer can have line endings native to his system when developing and they are converted to the normalzied ones when uploading changes. help.github.com/articles/dealin … ne-endings stackoverflow.com/questions/3206 … ent-operat
Yes, I’ll need to collect github account names and e-mails of all contributors. Please PM me.
I hope Github will properly join commits with the accounts after import.
Noted.
At the moment I see no use for them.
Mantis remains our bugtracker. If we decided to accept reports via github issues tool, we would need someone who would be responsible for creating a paired report on Mantis. I see your point about people not wanting to be bothered with registering on our bugtracker but I don’t think we should at the moment concern ourselves with that.
The same problem is present also in VCMI-related threads on various forums. Eg. I see a number of bugreports in our HC thread that don’t make to the Mantis. I’d say that accepting issues from Github tool is part of bigger endeavour that is “accepting issue reports by other channels than Mantis”. Certainly worthy to be discussed, not necessarily here. [And we’d need a volunteer with some time to manage such reports.]
Yet, I think that we shouldn’t change too much at once. First swithc to git and get accustomed to it while still allowing the “traditional” workflow. More complex workflows and rules can be introduced later.
Not sure how feasible it is in our current team.
Very good, important point. Commits should be focused and atomic. It makes later much easier track when the bug appeared or to revert one particular change.
Possible. MSVC projects can live happily anywhere.
AFAIR it was once decided that Unix (single LF byte) line endings should be used.
I’ve been developing a lot using git in the recent half year. I think the Gitflow Workflow is the easiest to grasp coming from SVN, and I guess I also really like it overall. Basically you have two fixed branches, master and develop where *develop *is a branch of master. *master *is equivalent of the SVN tags and *develop *is equivalent to SVN trunk.
When someone wants to implement a feature they make a branch from develop. When they’re finished they merge, or make pull request for merging, their branch into *develop *so that other developers branching from *develop *can pull these changes into their own branch.
When it’s time to tag a new release, a developer simply makes a pull request from *develop *to *master *with the version number as commit message or equivalent.
If it feels like too much overhead dealing with code reviews and such you can skip having pull requests and just let all developers push directly into *develop *(this would be the same as just commiting to *trunk *in SVN).
