Itms

That is something everyone can activate, @abian can activate PRs on their fork. I do not think there is an option to activate that by default and I'm not sure it's desirable (in terms of UI clutter).

ChatGPT is a tool designed to generate text. It is not a search engine and it cannot be trusted to give correct information. You can do so if you wish, but I share all of Stan's reservations expressed in the above post.

Hi andy, what is this gist? Who wrote that? I see no information anywhere about Gitea having a "wiki pull requests" feature. I agree it would be desirable.

I feel like some command invocations are redundant, but as long as it covers all ways of getting users out of trouble, I don't really mind. The top-left button brings you to the root of the subdomain, https://gitea.wildfiregames.com. I think any other destination would be very unexpected for a top-left button, it would certainly confuse me. However, I could definitely add a "Main repository" button in that top bar. I can even make it a 0ad-wheel-logo instead of a text button. I would place it in second position, just right of the WFG logo button. Would that sound good to you guys?

I sent you a forum PM.

No, they don't, and I don't have a good idea to do that properly/automatically.

@Obelix Unfortunately, I confirm it is not possible Those are two different repositories, with extremely different histories, even though they contain roughly the same files in the HEAD revision. When a repository is moved to another address, the "SVN Relocate" command will save you from having to re-clone, but this is not the case here. Even if I had decided to create the nightly repo inside the "public" set of repos, using "SVN Switch" would have re-downloaded everything, as public/nightly wouldn't have any common history with public/ps.

Hi @Grapjas, I signed the mod! Amazing work. I would love to see the sandstorms in the vanilla game!

It is a git workflow, on a single repository. SVN is still used as a storage solution for two things, but not for storing the development history, i.e. it is not our VCS anymore. We still have some bundled libraries for building the game, they are stored in SVN but we'll get rid of that over time. It's a bit arcane and as a contributor you should not be concerned about it. Additionally, we continuously deliver a nightly built version of the game so that players can test the latest version without any knowledge of git. This uses SVN because our community is used to it by now. SVN allows users to update their nightly build incrementally, without having to re-download everything daily. Release bundles will also be automatically packaged using the nightly build.

Ahoy, sorry for not answering sooner. You'll have to use the command-line only once so that your clone is aware of the existence of the "upstream" repository 0ad/0ad. (I'm a bit baffled to see this is not supported by Github Desktop (and everyone is pissed off in their bugtracker), but alas.) Go to your clone, and inside of it, right click and open Git Bash. Run the command git remote add 0ad https://gitea.wildfiregames.com/0ad/0ad.git and exit Git Bash. Now in Github Desktop, you can rebase in two steps. First, click the "Fetch origin" button at the top. It should display in quick succession "Fetching origin" then "Fetching 0ad", the latter indicates that it becomes aware of changes in the main repository. Then, in order to rebase your own branch, you use Branch > Rebase current branch, and you select 0ad/0ad as the base branch. Let me know if something is afoot.

Done! I grouped together all the features in a single script. In an up-to-date git clone, you can run the script "binaries/system/get-nightly-binaries" to download the built game, the translations, and the Vulkan shaders. All of those files are ignored by git and will not interfere with your workflow as artists.

I think you'll grow used to the new fork/update workflow after a few tries. That part is not really more difficult than what we had with SVN+Phabricator, it's just very different. However, editing/testing across the SVN and the git repo does sound like a pain, I still think it's a valid workflow for small one-time contributions, but it's too impractical for team artists. And we're not going to require you to learn and build the game. I'm going to add a script for copying the nightly windows prebuilt files into the git repo. That way you would be able to modify in the git repo and test there without back and forth. I already did that for pulling translations and spirv shaders, I could also do that for the built game (it would obviously be Windows-only, but that would cover team artists).

I fully second Justus' comment: it looks elegant and is a very nice touch, but will probably go unnoticed in the UI. (Necroposting this thread, that I just discovered after an interaction with abian)

Yes, I had to add such a filter to Trac in March and I also activated it for Phabricator during the migration. So far Gitea is not targeted (enough) for this to be visible on our end.

Hello gameboy, my friend, for your use case, you must use the Nightly Build. It works exactly like the old SVN, but you have to redownload it. Delete your copy of the old SVN. Then in TortoiseSVN, use SVN Checkout, and use the URL https://svn.wildfiregames.com/nightly-build/trunk It will work like previously.

Hey Yes, but that's a new "SVN" called the Nightly Build. It is updated daily with latest system files, translations and whatnot, it is based on the latest version of the Gitea repo. Unfortunately the former SVN repo and the nightly build are incompatible, you have to redownload. Checkout the nightly build using SVN (see the wiki). Then, if you still have some work lying around in the former SVN checkout, you can manually move it to the nightly build, or to a clone of the Gitea repo, without issue. After that backup, you can delete the old SVN repo, it won't receive any updates anymore.

Looks very nice @Vantha

Oh, yes please! I wrote that before we decided to just archive those.

Hello there! After fixing a very nasty network issue yesterday, I was able to publish the first nightly build this morning! This officially concludes the migration, all outstanding issues have been fixed. There will be more discovered I'm sure, please report them here along the way. It will also take some time for the development flow to adapt to the new environment. I will improve some documentation and prepare posts to reach a wider audience about the migration, over the weekend. In a nutshell: If you are a regular player just regularly testing the latest development version: you should ditch your svn copy and instead clone the new "nightly-build" svn repository at https://svn.wildfiregames.com/nightly-build/trunk. Use "svn update" as usual to get the latest changes daily. If you are used to compiling the game (either because you are a Unix user, a maintainer, or interested in contributing): please note that the build process has changed a bit, you now have to get/build libraries using the correct script under libraries/, before the usual update-workspaces and subsequent build. If you were working on something on Phabricator: please port your work to a new PR on Gitea, post a short message on the diff you ported, and close it. If you have some work in a github/gitlab clone: the new git repo is not compatible and can't be added as a remote. You should export your work (for instance with git-format-patch) and reimport it in a fresh clone of the new repo. You can then ditch your clones of the github/gitlab repo, which will not receive updates anymore, and will be archived soon.

Yes, but only for you, with a lock next to it saying "This is only visible for you and administrators".

Status report: The Phabricator search index is still not rebuilt, as we're hitting a Phabricator bug. I'll look into this when I have time, but I consider it less urgent.

After investigating with sera's help, it looks like users were imported from Trac without the "Hide Email Address" ticked in the Preferences, however email addresses were not disclosed. The Gitea instance is configured not to display addresses in users' profiles, regardless of that checkbox. The checkbox is only used to disclose, or not, your email when you create a commit or a wiki change from the Web UI. I set all users to have "Hide Email Address" set to true, please disable it if you want your account to be associated with your commits and wiki changes (as the tooltip informs you).

Hello, the config is set to hide user emails by default. It was the same config during the PoC. I do not see any emails when I'm not logged in. Can you explain how it was possible to show your email before you hid it? By PM if it's sensitive. Well some things keep crashing but I'm fixing issues as they come

The migration is done! The last part of it was quite rough, as we had an unplanned and unrelated server outage this morning, which set me off track. Please expect some features to be still partly activated while I go through things in the upcoming days. NOTE: Phabricator is down for the night (it redirects to the "ariadne" tool for now). It is trying to rebuild its search index, which incurs a huge load on the server. I'll let it run overnight while activity is low. Now you can issue a password reset, email is activated NOTE: Those are the Trac accounts, not Phabricator ones. (don't hesitate to PM me if you have a doubt about your email address). Thanks for the praise, it means a lot!

Nothing has thwarted the migration project, so it will happen as planned during the upcoming two days Here are the final improvements performed over the past weeks: Added missing "Patch By" credits in a number of commits Set up issue templates Set up code owners Devised an alternative way of tracking a release process (using issue templates) fixed issue search after the Trac import