balduin Posted October 18, 2016 Report Share Posted October 18, 2016 Hello, why are you still use SVN for the development and not git? Trac does support Git: https://trac.edgewall.org/wiki/TracGit 4 Quote Link to comment Share on other sites More sharing options...
Stan` Posted October 18, 2016 Report Share Posted October 18, 2016 A migration to git is planned, also there is an official repo on github. See:http://trac.wildfiregames.com/ticket/1814 http://trac.wildfiregames.com/ticket/1816 http://trac.wildfiregames.com/ticket/1819 Until those are done, no final migration will be done. 5 Quote Link to comment Share on other sites More sharing options...
jonbaer Posted October 18, 2016 Report Share Posted October 18, 2016 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. 2 Quote Link to comment Share on other sites More sharing options...
feneur Posted October 18, 2016 Report Share Posted October 18, 2016 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. 4 1 Quote Link to comment Share on other sites More sharing options...
FeXoR Posted October 19, 2016 Report Share Posted October 19, 2016 @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) 1 2 Quote Link to comment Share on other sites More sharing options...
jonbaer Posted October 19, 2016 Report Share Posted October 19, 2016 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 1 Quote Link to comment Share on other sites More sharing options...
fcxSanya Posted October 20, 2016 Report Share Posted October 20, 2016 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 2 Quote Link to comment Share on other sites More sharing options...
balduin Posted January 13, 2017 Author Report Share Posted January 13, 2017 Is there any news or anything one could do to help to make the transition from SVN to Git possible? Quote Link to comment Share on other sites More sharing options...
Stan` Posted January 13, 2017 Report Share Posted January 13, 2017 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. 1 Quote Link to comment Share on other sites More sharing options...
balduin Posted January 13, 2017 Author Report Share Posted January 13, 2017 Have you thought about using Git Large File Storage (Git LFS): https://git-lfs.github.com/. 1 Quote Link to comment Share on other sites More sharing options...
FeXoR Posted January 14, 2017 Report Share Posted January 14, 2017 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. 1 1 Quote Link to comment Share on other sites More sharing options...
balduin Posted January 14, 2017 Author Report Share Posted January 14, 2017 @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? 1 Quote Link to comment Share on other sites More sharing options...
leper Posted January 14, 2017 Report Share Posted January 14, 2017 (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. 12 Quote Link to comment Share on other sites More sharing options...
feneur Posted January 14, 2017 Report Share Posted January 14, 2017 I pinned this topic as it's one that comes up often and Georg's reply explains things nicely. 1 1 Quote Link to comment Share on other sites More sharing options...
FeXoR Posted January 14, 2017 Report Share Posted January 14, 2017 Maybe also set @leper's last post as "Best answer"? 1 Quote Link to comment Share on other sites More sharing options...
feneur Posted January 14, 2017 Report Share Posted January 14, 2017 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 1 Quote Link to comment Share on other sites More sharing options...
niektb Posted January 16, 2017 Report Share Posted January 16, 2017 re: git GUI: for Mac and Windows there is a fairly non-programmer client available: https://desktop.github.com/ 1 Quote Link to comment Share on other sites More sharing options...
Clockwork-Muse Posted August 21, 2017 Report Share Posted August 21, 2017 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. 1 Quote Link to comment Share on other sites More sharing options...
Loki1950 Posted August 21, 2017 Report Share Posted August 21, 2017 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 1 Quote Link to comment Share on other sites More sharing options...
xan2622 Posted August 22, 2017 Report Share Posted August 22, 2017 (edited) 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. 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 August 22, 2017 by xanax 1 Quote Link to comment Share on other sites More sharing options...
Stan` Posted August 22, 2017 Report Share Posted August 22, 2017 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. Quote Link to comment Share on other sites More sharing options...
xan2622 Posted August 22, 2017 Report Share Posted August 22, 2017 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). 2 Quote Link to comment Share on other sites More sharing options...
Stan` Posted August 22, 2017 Report Share Posted August 22, 2017 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 ? Quote Link to comment Share on other sites More sharing options...
GunChleoc Posted August 22, 2017 Report Share Posted August 22, 2017 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. 2 Quote Link to comment Share on other sites More sharing options...
xan2622 Posted August 25, 2017 Report Share Posted August 25, 2017 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.