Itms

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

I do not have a strong opinion here: unencrypted IRC is enough for my use case of developing the game. If we wish to move towards a more modern/complex system, I am quite convinced by @s0600204's proposal of using Zulip.

Oh snap. I was wondering about that recently and forgot to check. I think it would be necessary to create a new issue that is clearly titled "Add RSS feed for wiki updates", because that meta-issue you link doesn't seem to get a lot of traction, and only that comment from a random user hints at our use case. The what?

Here is a changelog of my work since last time: numerous infrastructure tweaks for the new server SPIR-V shaders are generated in the nightly build and can be downloaded in a git clone - this removes the need for a spirv mod entirely added git hooks to prevent upload of binary files in case a user hasn't installed git-lfs; to enforce a linear commit history by default; added size limits to git uploads finished all the CI pipelines for Linux, Windows, and macOS finished the workflow refactoring for macOS updated the wiki page for the CI/CD setup fixed references to dropped commits in the history addressed some remarks above as commented, looked into the translation alternative disabled localization of Gitea, since English is supposed to be used for collaboration, and the contents of Gitea (main page, wiki, policies, ..) are not localizable anyway I tested everything I planned to test on the server we will use, so I am ready to perform the migration on the 19th and 20th of August. I have a few nice improvements I will implement in the next couple days (issue templates, code owners, and more). I made sure that sha256 repos are available in Gitea after the migration (they are not available on my PoC due to an older git version). Unfortunately, reposurgeon, which is used to convert the SVN repo into a git repo, does not seem to support SHA-256. Reading the documentation, it looks like the tool internally relies a lot on SHA-1 to work. So I cannot generate a SHA-256 repo. git-filter-repo, with which I rewrite history afterwards, does not propose conversion from SHA-1 to SHA-256 either.

Dear contributors, We plan to perform a long-discussed migration to git as our version control system. We have been very happy with SVN for a long time, for its simplicity and its ability to handle our game assets. But we yearn for the collaborative features of git and for the many git-based tools that would allow for a more efficient development process. We managed to keep using SVN and to collaborate efficiently on Phabricator for the past 6 years, but unfortunately all good things must come to an end, and Phabricator is now unmaintained. We thus decided to take the plunge and to migrate to git, and we have chosen Gitea as our self-hosted git forge. Our historical Trac bug-tracker will become read-only, and its contents (tickets, wiki) will be entirely migrated to our Gitea instance. After some time, Trac will be stopped, and links to Trac will be redirected to Gitea. Access to our Phabricator instance will be restricted so that our contributors can port their open work to Gitea. After some time, all sensitive user data will be deleted from Phabricator, which will become read-only. Please keep in mind that, even though Phabricator holds a meaningful history of important discussions, it constitutes a security liability. We cannot guarantee to keep it online indefinitely. No ready-made tool exists, at this moment, to migrate Phabricator discussions to Gitea. The migration is planned to happen on the 19th and 20th of August (European hours). During these two days, the aforementioned services (Trac, Phabricator) and the SVN repositories will be down. Development progress will be halted. We plan to provide a functional git-based development environment immediately after the migration. Most CI/CD systems are ready to be launched, and user documentation is ready. But the transition to a new development flow will, of course, take some time. We hope that this transition will allow us to make swift progress on the long-awaited release of the next Alpha.

Yesterday I took a look at the Steam page and noticed I could get access to the Playtest. I was very hyped and the game seems to work fine on my PC, which is great. But I can't actually play, there is no single player available, and the multiplayer tells me I don't have a network connection. @wowgetoffyourcellphone do you know more about that? By the way, when starting the game demo for the first time, I was presented with the variety of accessibility options, including the possibility of navigating with WASD and of disabling the auto gathering for villagers.

It sounds more frequent than the GC, and it looks like the user can trigger the issue through graphics-related events (seeing details, moving the camera), not simulation-related events, so I don't believe it is related to SpiderMonkey.

Since we won't be able to actually LFS-mirror to Github and Gitlab, it sounds like stopping mirroring altogether is the best solution. I would then just archive the historical repos without renaming them. Codeberg can allocate storage upon request, so I would still like to contact them after the migration, asking if we could have a mirror there, in order to show mutual support. Having a mirror on that Forgejo instance would also be a good way to keep in touch with the Forgejo community in case we want to replace Gitea or to stop self-hosting.

Yes, I'm currently testing a mirror-push to Github, and seeing how it takes times, it's definitely uploading the LFS contents. Oh... GitHub and GitLab both have a low LFS usage limit on the free tier (1 GiB and 5 GiB respectively). It is one more proof that we needed self-hosting. However that creates issues with mirroring, that's bad.

Ha, with the translations thing, past week became this week No, I think it's better to rename the current repos to something like old_git-svn_mirror in order not to break forks, archive them, and but up a big bold ugly notice about the migration and the new repo. People will be able to migrate their repos when they wish to Gitea, I'm not doing it as part of migration. By the way I think the mirroring to github/gitlab should wait for a couple days after the migration. Yes, I'm currently testing a mirror-push to Github, and seeing how it takes times, it's definitely uploading the LFS contents. Great idea! I just reserved the 0ad name I can add you as owner if you PM me your Codeberg username.

Yes, I also liked Blue Ocean for displaying stage output, but unfortunately that project is ended. Blue Ocean will not receive updates and thus will never be able to display a lot of modern Pipeline features I started to put into place. The officially recommended replacement I used, Pipeline Graph View, is still pretty new and rough around the edges, but I'm sure it will get improvements and get better usability as time goes by

No not at all, I have just been too lazy to set up anonymous access to all the jobs I created, deleted, re-created.... I will open them up in the upcoming days, and I will also be able to considerably simplify the access to Jenkins after the actual migration.