Wesnoth-UMC-Dev’s switch to SourceForge’s new Allura platform is now complete. The repository should be working as usual, with the exception of the web interface to SVN, which is currently lagging behind.
Contributors with existing Subversion checkouts of any portion of the repository will need to run a simple command to switch/relocate the base repository URL as required by the migration:
svn switch --relocate https://wesnoth-umc-dev.svn.sourceforge.net/svnroot/wesnoth-umc-dev NEW_URL
Or for Subversion 1.7.x and later:
svn relocate NEW_URL
The value of NEW_URL depends on whether you are a regular contributor with commit access or just a user with read-only access. Contributors should use
svn+ssh://USERNAME@svn.code.sf.net/p/wesnoth-umc-dev/code as NEW_URL (replacing USERNAME with your SF.net username). Users should use either
For graphical/alternative Subversion clients, you should consult the documentation for the software you are using for information about switching/relocating a checkout’s repository.
Feel free to direct specific support inquiries about the migration process to our support thread in the Wesnoth forums.
In order to avoid nasty surprises for our repository contributors at an indeterminate point in the future, we are preparing to switch Wesnoth-UMC-Dev to SourceForge’s new Allura platform before automatic upgrades for active projects begin on the 22nd. You can read more details about SourceForge’s upgrade plan in their blog post if you are interested.
We have decided to perform this step ourselves at a determinate time instead: April 20th, 19:00 UTC.
But what does this mean for users and contributors to Wesnoth-UMC-Dev?
Basically, the repository will be closed down for commits at the appointed time. No more commits should be pushed to the repository after that point. Because of the new platform’s design, the URLs used to access our Subversion (SVN) repository will change. The upgrade process itself will take an unspecified amount of time to complete, hopefully no more than eight hours. After that is completed, contributors with commit access will receive a notification email specifying the new URL for the Subversion repository. However, we will keep the new repository closed until we have ensured that everything is in order.
Once the upgrade is complete, users and contributors must reconfigure their SVN checkouts according to instructions we will post on this same channel.
The Wesnoth-UMC-Dev staff members are proud to welcome inferno8 and the Era of Magic and To Lands Unknown development team (a.k.a. Infernal Studios) to our project, along with their groundbreaking add-ons to enrich your Wesnoth experience!
It’s always great to see more big add-ons joining us, after the Ageless Era entered the repository in July 2010. Era of Magic sports nearly 200 units and over 1,800 frames of animation; its first official campaign, To Lands Unknown, boasts scenarios with large, complex environments built around the game’s terrain graphics builder engine, featuring visual and auditory weather effects, epic animated cutscenes, a mysterious, new world, and more.
These cool add-ons have been around for a while, and TLU is one of the few complete campaigns ever added to our repository, with 16 scenarios in total.
Currently, EoMa is provided for the 1.8 stable branch and 1.9.x development versions, whereas its campaign proper is only available for 1.9.x. You can obtain them both from the official add-ons server, add-ons.wesnoth.org, or you can check them out with SVN to track the latest revisions:
svn co https://wesnoth-umc-dev.svn.sourceforge.net/svnroot/wesnoth-umc-dev/trunk/Era_of_Magic svn co https://wesnoth-umc-dev.svn.sourceforge.net/svnroot/wesnoth-umc-dev/trunk/To_Lands_Unknown
The trunk tree for EoMa is also compatible with Wesnoth 1.8 at the moment.
We believe that the addition of EoMa and TLU to the Wesnoth-UMC-Dev Project will enable better coordination between their developers and mainline as our staff ensures compatibility with these add-ons and the technologies used by them in the future.
In other news, the repository HEAD is currently over 9,000 (*grin*) as I recently announced in Twitter, minutes after noticing the progress made in SVN. We have just a bit less than 970 commits left to reach the next milestone with the 10,000th commit!
Despite the sad state of mainline Wesnoth’s development versions due to various bugs and loose knots plaguing trunk, we believe this will be a very productive year for the UMC developers community, eagerly awaiting version 1.10 to be released in the near future.
A hardly ever mentioned facility hosted by the Wesnoth-UMC-Dev Project at Sourceforge.net is the issue tracker, which is linked in the least appropriate manner possible in our site’s front page.
Following SF.net’s, err, “quaint” redesign of the web interface, the trackers are reachable by going into our project page, click on the Develop link, and then checking the Tracker item; or just following this neat direct link. Or you can paste this URL in your address bar:
You’ll notice we have three issue trackers available for your use:
- Bugs. This area is intended for users to report bugs on our hosted user-made content. Assigned add-on maintainers are supposed to watch this area.
- Feature requests. Guess what this is! Users are intended to be able to post wishlist items, suggest enhancements and such to this list.
- Patches. People can propose patches here, potentially for any filed bugs or FRs.
Truth to be told, our issue trackers are mostly unused at the moment, because they haven’t been advertised enough by the few add-on maintainers who have opted to have categories created in them, or by our project staff.
This can be easily fixed, though. If you are a maintainer of one of the add-ons hosted at the Wesnoth-UMC-Dev repository, you can contact our staff and request a new category for your UMC, so users can select it when filing new items. But this also requires some involvement with us! As an add-on maintainer, you must advertise our tracker URL in your official contact forum thread or web site, and teach your users about how they should use it — in other words, what category they should select for your add-on, and what your own guidelines for submitted items are.
Of course, if you do this you’ll also be allowed by our admins to manage the tracker so you can assign/reassign items, close and reopen them, and much more! Just don’t forget that with great power comes great responsibility!
I have just published a new guide on the “do’s and do not’s” of translator-friendly campaign design:
Our hosted add-ons are occasionally checked for textdomain inconsistencies using one of our tools. Unfortunately, textdomain_check is undocumented and unmaintained, and until I can replace it with something cleaner we can’t provide help with using it — which would be a good idea for content authors otherwise.
Nonetheless, I hope this little guide helps to promote the WesCamp-i18n Project by teaching the audience what they must and must not do to get their content properly translated. As usual, comments or corrections are welcome in our forum discussion thread or our IRC channel.
Today I bring you a smallish website update including a minor fix in the Contact page that rendered AI0867 email-less, and new documentation.
In this opportunity I’ve decided to talk about one of the tools we admins run on add-ons from time to time, particularly when checking them into the repository — wesnoth-optipng, an image file recoding/optimization tool used by the mainline Wesnoth project to try to reduce image files’ size as much as possible for distribution.
It’s not rocket science, but Linux users may be interested in trying it out by themselves. Thus you can find a little explanation of what it does and how to use it in the Documentation section.