Jump to content
balduin

Why not moving to Git?

Recommended Posts

jonbaer    73

https://github.com/0ad/0ad

https://github.com/0ADMods

Curious, was there ever a discussion about moving everything to Github @ any point?  I tend to find Trac under large histories to be extremely slow while doing queries (even w/ small teams).  Something that Github developed which might help w/ large blobs ... https://git-lfs.github.com/

I don't do enough game development to give opinion but just curious where previous discussions might have ended up.  

  • Like 2

Share this post


Link to post
Share on other sites
feneur    1,430

Moving to Github was not really considered because we want to be in control of things ourselves and not have to depend on another service working or even existing years down the line.

  • Like 4

Share this post


Link to post
Share on other sites
FeXoR    376

@feneur Thanks for making that clear!

While GIT may be an alternative revision controll system for us to use (as main repo) we definitely should have the project on our "own" server.

(Also there should be a clone on a PC physically owned by a team member)

  • Like 1

Share this post


Link to post
Share on other sites
jonbaer    73

Good point about GitHub ... a friend recently moved a rather large project from Trac to GitLab (which is like a self hosted GitHub, probably even better) but his only reason was that pull requests were easier to manage than manual patches.  Will leave the links here (but this sounds like a case of - the process is not broken, so don't fix it ;-) It seems like SVN/Trac has been used here for so long.

https://about.gitlab.com/

https://github.com/moimael/trac-to-gitlab 

  • Like 1

Share this post


Link to post
Share on other sites
fcxSanya    392
On 10/20/2016 at 1:12 AM, jonbaer said:

<...> but his only reason was that pull requests were easier to manage than manual patches

Btw, it's possible to clone 0ad repo on github, create a branch for some feature and in any moment have a SVN-compatible patch for these changes.

I'm currently slowly working on #2305, I initially attached a SVN patch for it, but then realized that I want to do a lot of small incremental updates to it, a final version won't be ready soon and it would be much more convenient to have a git branch for an interim period: the latest version is published as soon as I push a new commit, all changes are visible as separate commits with messages and diffs and the ticket isn't cluttered with a lot of intermediate patches (it's already cluttered enough with all those research results, current state reports and discussions :)).
'Comparing changes' page allows to see both overall diff and log of all commits present in the branch: https://github.com/0ad/0ad/compare/master...AlexanderOlkhovskiy:stk-stun
Diff can be downloaded and applied to SVN copy using the same link (with appended '.diff'):

curl https://github.com/0ad/0ad/compare/master...AlexanderOlkhovskiy:stk-stun.diff | patch -p1

 

  • Like 2

Share this post


Link to post
Share on other sites
stanislas69    1,926

If you want you can use the git clone on git hub. Biggest issue with git is binary files which if hosted on their local server would reduce HDD space drastically. AFAIK @Itms is looking for a way to avoid that but until then no git migration will be made.

Share this post


Link to post
Share on other sites
FeXoR    376
1 hour ago, balduin said:

Have you thought about using Git Large File Storage (Git LFS): https://git-lfs.github.com/.

If we use that we don't have the files on our server - which is what we want to avoid.so that's not an option IMO.

  • Like 1

Share this post


Link to post
Share on other sites
balduin    76

@FeXoR In this case I misunderstood the problem. However, what is so different besides using SVN and Git for large files? I mean yes, small changes on big binary files require to rewrite the files and create a lot of traffic, but how is SVN different or more efficient?

Share this post


Link to post
Share on other sites
leper    707

(I guess I should write a slightly longer answer to this and related questions since this seems to pop up regularly.)

TL;DR: SVN works. Why don't you use git, you can do so right now (either one of the clones on github/gitlab, or via git-svn)?

Why (still) SVN?
It works.
More details: Partial checkouts are supported (which some contributors needed due to network limits), it doesn't require users to download the whole history (same reasoning), checkouts can be resumed (helps with unstable network connections). Apart from using shallow clones or incremental shallow clones this isn't possible with git. Keeping autobuilds for windows users (which is needed for artists) in the repo is not an issue (yes, there have been discussions and plans for how to solve this for git; but that is some work nobody has volunteered for yet).

Why not git?
There's a git clone (github and gitlab) so nothing stops you from using it right now, and we do accept git patches just the same as svn patches. If you don't like that you can use git-svn directly (which works fine). Educating users about git is more work than doing the same for svn, also this question ignores artists and modders and increases the barrier of entry for new contributors. Also most git GUIs are quite bad, which is somewhat important for those users. Programmers should be able to use their tools and can already use git right now.

Why not git-lfs or git-annex or git-whatever?
Those are third-party extensions and require more administration work. Of course we could move all to some third-party hosting platform, but those might impose arbitrary limits or just cease to exist. Also that seems to counteract one of the main advantages of a DVCS namely being distributed and not being locked to a single central repository. (These approaches tend to have issues with having the full history available locally, which makes bisecting issues harder. Also they do list merge conflicts for binary files as one of the rough edges. (I'm not sure how those would interact with signing commits, which would be one of the things to consider if switching to git.))

But I want to submit pull-requests?
No. Diffs work, man git-format-patch might be worth reading.

Why not just merge things?
A merge-based workflow creates issues with bisecting issues, so one would have to educate users about rebasing their work on top of the main branch. (Not very entertaining in the long run (and that refers to both points).)

What could be done instead?
Reroll the git clones in a nicer way by excluding all build artifacts (the current clones have a few incremental stages, and are likely not excluding everything). However this should be planned carefully, since this is going to break the "upstream" for a lot of people and I would strongly recommend against doing this more than once.

  • Like 10

Share this post


Link to post
Share on other sites
feneur    1,430

I pinned this topic as it's one that comes up often and Georg's reply explains things nicely.

Share this post


Link to post
Share on other sites
feneur    1,430
21 minutes ago, FeXoR said:

Maybe also set @leper's last post as "Best answer"?

That would require changing the settings for this forum, and I generally don't think it's going to be a matter of questions and answers very often here. Feel free to convince me otherwise though :)

Share this post


Link to post
Share on other sites

Part of the problem migrating is that there's a bunch of stuff in the repository that shouldn't be in a code repository at all.  Plus

  • We have all of the "default" 0AD mod/resources in the same repo as all engine code.  These are really orthogonal, and belong in separate repositories.
  • We have many dependencies in the repository.  These do not belong in a code repository, but some sort of binary repository/dependency management system (eg, Nuget in the C# world, or maven for Java).  C++, however, has not traditionally used one of these systems.  
  • The final, built binaries, are in the repository.

Ideally, we should probably be doing something like:

  • Git repository for main engine code (+ some small default resources).  This can be self-hosted, or use an existing provider and backup a copy every day.
  • Dependency management repository for code artifacts.  There are some out there for C++, although we will likely have to host at least some of our own.
  • Git repository for the "default" 0AD mod code
  • Repository/ies for art source files.  Note that the goal would be to have no "built" items in a live repository, instead:
  • Dependency management repository for built art files.  This also gets used by:
  • Binary repository that combines art files and mod + engine code into the finished product.

 

.... which would be quite some work to set up.  I think the best first step, though, would be to start getting dependencies out of the main repository and into a package management system.

  • Thanks 1

Share this post


Link to post
Share on other sites
Loki1950    254

Which package management system remember that we support three separate platforms so three systems would be needed and who would by necessity code them they do not exist for Windows or OSX those binaries are only for Windows as most of our users share that OS and very few have the knowledge to build from source these users are also mod developers that need access to the latest build.This has been proposed several times and the consensus has been it's to much work for minimal benefit we already have have a Git mirror though it does trail the main SVN repository by a few commits.

Enjoy the Choice :)

  • Like 1

Share this post


Link to post
Share on other sites
xanax    19
On 16/01/2017 at 7:32 PM, niektb said:

re: git GUI: for Mac and Windows there is a fairly non-programmer client available: https://desktop.github.com/ 

SmartGit is much more user-friendly, it supports Git & SVN, it's free for personal use (you just have to enter a fake email during the setup/installation process).
PS: no, I am not affiliated in any way with them. :rolleyes:    I have just tested many git GUIs.

 

Regarding "moving to github", while I understand the arguments for not moving the whole repository to github (and I agree with most of the points), I still think it would be interesting (in term of "ease of use", speed, sorting options) to just move the bug tracker to Github. There are tools to perform this task : https://github.com/robertoschwald/migrate-trac-issues-to-github

Frankly, Trac is sooo slow and so un- user-friendly. It's sort of a pain to use it.

With Github, you can create milestones, tags (labels), assign developers to issues, link other issues in comments by just typing the issue ID, get donations for fixing issues (with Bountysource), mute comments, embed code lines in comments, ... but the speed and ease of use guys, frankly it's night and day.


 

Edited by xanax

Share this post


Link to post
Share on other sites
stanislas69    1,926

As I said the main issue is that if githubs decides to shutdown one day we're screwed. We could also host our own gitlab, but that sounds like uneccessary work.

Share this post


Link to post
Share on other sites
xanax    19

Do you think that the most known and largest open-source code hosting platform & version control system in the world would shutdown just like that?

Without warning the 20 million users and maintainers of 57 million repositories

The company announced, on 29 July 2015, that Github raised $250 million in funding and at the time, some financial reports valued the company at approximately $2 billion... I don't think they will shutdown anytime soon.... ^_^

CodePlex shut down but measures were taken for the migration and no developer was taken by surprise.

I understand your point to keep control of your repository and bug tracker but by doing that, you continue to use outdated and inefficient tools while you could increase your productivity and interactivity with your contributors by using modern tools like the Github bug tracker. You are afraid of a possible future Github shutdown but it's not going to happen before many many many years.. (if that happens).

Share this post


Link to post
Share on other sites
stanislas69    1,926

Trac is not outdated :) https://trac.edgewall.org

I'm wondering though how using the github bugtracker here would help in efficiency ?

Phabricator though was a great tool for productivity
 

Quote

You are afraid of a possible future Github shutdown but it's not going to happen before many many many years.. (if that happens).

 

Not likely indeed, but who knows maybe 0ad will still be in developpement for the next 50 years ? :P

 

Share this post


Link to post
Share on other sites
GunChleoc    238

There were 2 instances of big platforms creating problems in the last few years:

  • SourceForge chose to replace installers with their own and added ads/additional software to them
  • Google Code shut down (to be fair to them, they made it easy to migrate to GitHub)

Also, GitHub (as opposed to Git) isn't free/libre.

So, as long as Wildfire Games has the manpower and money to maintain their own, they should stick with it. And a webserver maintainer isn't necessarily an application programmer as well, so maintaining the thing probably doesn't take that much away from development time.

Personally, I'm a big fan of Bazaar because the commands are dead easy, but sadly their tools are seriously undermaintained these days.

  • Like 1

Share this post


Link to post
Share on other sites
xanax    19
On 22/08/2017 at 2:15 PM, stanislas69 said:

I'm wondering though how using the github bugtracker here would help in efficiency ?

Just an example: clicking on Active Tickets takes ~ 20 seconds just to display the page...

And I am not talking about how painful it is to create custom tickets queries.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×