Coordinated User-made Content Development Project (with SVN)
Moderator: Forum Moderators
Re: Coordinated User-made Content Development Project (with SVN)
Please make this thread sticky.
Greetings,
Fabi
Greetings,
Fabi
Re: Coordinated User-made Content Development Project (with SVN)
Done.
I don't see what's the gain though. [/humble]
I don't see what's the gain though. [/humble]
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
Re: Coordinated User-made Content Development Project (with SVN)
Well, having a svn repository for campaign developers is something that could make a really step forward for wesnoth.Shadow Master wrote:Done.
I don't see what's the gain though. [/humble]
Something like "Small step for men but a big step for menkind".
So, having this great news sticky looked like a good idea to me.
Greets, Fabi
Re: Coordinated User-made Content Development Project (with SVN)
Reminder of repository's structure:
Since one of our coadmins insists on trying to use git-svn for management of this repo (influenced by a group of mad mainline developers whose names I won't mention), I thought I may as well publish my defense for my choice of the repository's structure.
When I decided upon the structure of the repository, I kept in mind the usual organization of Subversion repositores:
/branches
/trunk
/tags
However, that organization wouldn't work within this project's repository very well since all UMC hosten within it share a common repository root. What did I do instead? Well, I defined that the root /trunk should contain user-made add-ons maintained/developed for the current Wesnoth development branch (which as of this writing is 1.5.x). The trunk would contain subdirectories only, each named per add-on (i.e. trunk/After_the_Storm, trunk/Legend_of_Wesmere, and so on).
The /branches directory would have only subdirectories as well, this time pertaining to two separate groups:
1) Maintenance branches: content maintained for a stable mainline series should live under a dedicated /branches subdirectory named according to that mainline series. Under that dir, the content names define the subdirectories. For instance, 1.4 content would be hosted under /branches/1.4 - there we have /branches/1.4/Era_of_Strife, /branches/1.4/Invasion_from_the_Unknown, etc.
Consequence of this: when mainline trunk/ gets branched into a new stable series (which usually happens right after the new stable release gets tagged, say 1.6.0), all authors of UMC in our repository are notified to migrate their UMC residing in trunk/ to the corresponding branch in our repository; if they do not do this within a reasonable time span, the admins are in charge of moving the trunk/ subdirs into the new branch, which would be branches/1.6/ for our hypothetical example.
2) Resource and tool branches: as an exception to the rules, the admins may deem required to upload source code of tools, or other resources of interest to UMC developers, to dedicated branches. At the moment, we have two branches of this kind - /branches/maintenance-toolchain (where scripts such as build-external-archive.sh and set-version live) and /branches/irc-bots (the home of the Shikadibot 0314 for IRC freenode.net #wesnoth-umc-dev channel). Nobody should create new branches of this kind without authorization from the admins - doing so will result in deletion depending on the nature of the content under such unauthorized branches.
So far so good. The /trunk and individual branches are so designed to make it easier for add-ons in the repository to act as a coherent bunch, that can be easily added to the game by checking out the whole trunk, or a whole branch. This is great when add-ons are setup depending one upon another, which is the planned case for Thunderstone Era (TE) and derivated/demo campaigns for it. I hope it'd eventually be the case for the Era of Strife (EoS) too.
Now, the problem arises. Although it is easy to keep maintenance branches or development trunk tied together in the hiearchy since every add-on is a unit by itself, that does not apply to release version tags in /tags.
Every add-on has its own release cycle - this is something that I don't intend to change. I won't force every author to effectively use the tags tree either, since every author is supposed to have liberty in regards of their development practices too. So it is not possible in first instance to have a /tags/X.Y.Z/ directory containing the tags of every add-on for version X.Y.Z of UMC release cycle.
For this reason the tags directory was decided (by me as usual) to be a partial replica of the rest of the repository hiearchy. The /tags tree contains in first place the 1.4 and trunk subtrees now. The 1.4 subtree is, unsurprisingly, the tags tree for /branches/1.4 add-ons. Inside the 1.4 subtree you'll find subdirectories named by the add-ons they contain release version tags for. This is, for instance, /tags/1.4/Invasion_from_the_Unknown will contain subdirectories (release tags) named 1.9.1, 1.9.2 and so on; the version labeling of course varies from add-on to add-on (although as a mainline developer, I am enforcing a convention for add-on versioning in 1.5.x).
Our pecular design of the /tags tree may sound alien and wicked at first, but I hope the explanation above gives the expected sense to its nature.
An idea I was thinking of while writing this document, is that we could very well, as a project, offer from time to time packages of all add-ons at release level for a mainline series - that is, for instance, all add-ons for 1.6.x which are more or less finished and have no release-critical (RC) bugs could be tagged together in a, say, /tags/1.6/Master_Release-X.Y.Z/ tree and packaged for regular users, certified to work well together and individually. Of course, if you have read the Debian documentation you'll have already noticed that I copied much of these ideas from their development cycle.
Okay, that was random.
I remind you that we are above the 1400th revision. Keep up the good work! I am particularly delighted to see the variety of authors and content using this project to coordinate development within their teams, or just to have a backup storage area, or just to take advantage of the version control facilities provided.
Since one of our coadmins insists on trying to use git-svn for management of this repo (influenced by a group of mad mainline developers whose names I won't mention), I thought I may as well publish my defense for my choice of the repository's structure.
When I decided upon the structure of the repository, I kept in mind the usual organization of Subversion repositores:
/branches
/trunk
/tags
However, that organization wouldn't work within this project's repository very well since all UMC hosten within it share a common repository root. What did I do instead? Well, I defined that the root /trunk should contain user-made add-ons maintained/developed for the current Wesnoth development branch (which as of this writing is 1.5.x). The trunk would contain subdirectories only, each named per add-on (i.e. trunk/After_the_Storm, trunk/Legend_of_Wesmere, and so on).
The /branches directory would have only subdirectories as well, this time pertaining to two separate groups:
1) Maintenance branches: content maintained for a stable mainline series should live under a dedicated /branches subdirectory named according to that mainline series. Under that dir, the content names define the subdirectories. For instance, 1.4 content would be hosted under /branches/1.4 - there we have /branches/1.4/Era_of_Strife, /branches/1.4/Invasion_from_the_Unknown, etc.
Consequence of this: when mainline trunk/ gets branched into a new stable series (which usually happens right after the new stable release gets tagged, say 1.6.0), all authors of UMC in our repository are notified to migrate their UMC residing in trunk/ to the corresponding branch in our repository; if they do not do this within a reasonable time span, the admins are in charge of moving the trunk/ subdirs into the new branch, which would be branches/1.6/ for our hypothetical example.
2) Resource and tool branches: as an exception to the rules, the admins may deem required to upload source code of tools, or other resources of interest to UMC developers, to dedicated branches. At the moment, we have two branches of this kind - /branches/maintenance-toolchain (where scripts such as build-external-archive.sh and set-version live) and /branches/irc-bots (the home of the Shikadibot 0314 for IRC freenode.net #wesnoth-umc-dev channel). Nobody should create new branches of this kind without authorization from the admins - doing so will result in deletion depending on the nature of the content under such unauthorized branches.
So far so good. The /trunk and individual branches are so designed to make it easier for add-ons in the repository to act as a coherent bunch, that can be easily added to the game by checking out the whole trunk, or a whole branch. This is great when add-ons are setup depending one upon another, which is the planned case for Thunderstone Era (TE) and derivated/demo campaigns for it. I hope it'd eventually be the case for the Era of Strife (EoS) too.
Now, the problem arises. Although it is easy to keep maintenance branches or development trunk tied together in the hiearchy since every add-on is a unit by itself, that does not apply to release version tags in /tags.
Every add-on has its own release cycle - this is something that I don't intend to change. I won't force every author to effectively use the tags tree either, since every author is supposed to have liberty in regards of their development practices too. So it is not possible in first instance to have a /tags/X.Y.Z/ directory containing the tags of every add-on for version X.Y.Z of UMC release cycle.
For this reason the tags directory was decided (by me as usual) to be a partial replica of the rest of the repository hiearchy. The /tags tree contains in first place the 1.4 and trunk subtrees now. The 1.4 subtree is, unsurprisingly, the tags tree for /branches/1.4 add-ons. Inside the 1.4 subtree you'll find subdirectories named by the add-ons they contain release version tags for. This is, for instance, /tags/1.4/Invasion_from_the_Unknown will contain subdirectories (release tags) named 1.9.1, 1.9.2 and so on; the version labeling of course varies from add-on to add-on (although as a mainline developer, I am enforcing a convention for add-on versioning in 1.5.x).
Our pecular design of the /tags tree may sound alien and wicked at first, but I hope the explanation above gives the expected sense to its nature.
An idea I was thinking of while writing this document, is that we could very well, as a project, offer from time to time packages of all add-ons at release level for a mainline series - that is, for instance, all add-ons for 1.6.x which are more or less finished and have no release-critical (RC) bugs could be tagged together in a, say, /tags/1.6/Master_Release-X.Y.Z/ tree and packaged for regular users, certified to work well together and individually. Of course, if you have read the Debian documentation you'll have already noticed that I copied much of these ideas from their development cycle.
Okay, that was random.
I remind you that we are above the 1400th revision. Keep up the good work! I am particularly delighted to see the variety of authors and content using this project to coordinate development within their teams, or just to have a backup storage area, or just to take advantage of the version control facilities provided.
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
Re: Coordinated User-made Content Development Project (with SVN)
Minor update:
I have created a category for wesnoth-umc-dev posts in my blog:
http://shadowm.nfshost.com/blog.pl/wesnoth-umc-dev
Basically I'll use it to mirror any important announcements made here, and also to make other minor announcements that need not to be in this thread.
I have created a category for wesnoth-umc-dev posts in my blog:
http://shadowm.nfshost.com/blog.pl/wesnoth-umc-dev
Basically I'll use it to mirror any important announcements made here, and also to make other minor announcements that need not to be in this thread.
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
Re: Coordinated User-made Content Development Project (with SVN)
Edited the first post with a ToS revision by ESR.
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
Re: Coordinated User-made Content Development Project (with SVN)
We have enabled the bug tracker, feature request tracker, and patch trackers for the whole Wesnoth-UMC-Dev project. At the moment, artifacts may be classified only for certain add-ons/categories:
* Invasion from the Unknown
* Delfador's Memoirs
* The Silver Lands
* Unrest in Elfland
The trackers' may be found at https://sourceforge.net/tracker/?group_id=221284. Non-authenticated posts are not allowed to avoid spam. Posts not pertaining to any of the above categories will be removed in sight.
* Invasion from the Unknown
* Delfador's Memoirs
* The Silver Lands
* Unrest in Elfland
The trackers' may be found at https://sourceforge.net/tracker/?group_id=221284. Non-authenticated posts are not allowed to avoid spam. Posts not pertaining to any of the above categories will be removed in sight.
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
Re: Coordinated User-made Content Development Project (with SVN)
I have written a small Perl script that checks whether add-ons are compatible with Torangan's wescamp-i18n (essential if you want to have your campaign translated), along with other textdomain sanity checks, and I got disappointed at the current state of things.
The following add-ons in /branches/1.4 are in trouble:
The following add-ons in /branches/1.4 are in trouble:
- A New Land: no textdomain declaration
- Era of Myths: no textdomain declaration
- Era of Strife: no textdomain declaration
- Ooze Mini Campaign: no textdomain declaration
- The Conquest of a Dark Queen: the [textdomain] path= attribute is missing. (The textdomain name doesn't match the tree either.)
- The Silver Lands: the textdomain id wesnoth-TSL is incompatible; change to "wesnoth-The_Silver_Lands" instead to match the UMC directory name
- Trolls: *** warning (Trolls/units/Fighter.cfg): not bound to any textdomain
*** error (Trolls/units/Guardian.cfg:1): bound to textdomain wesnoth-Extended_Era, which is not a core or self textdomain
*** warning (Trolls/macros/basic.cfg): not bound to any textdomain
*** warning (Trolls/macros/deaths.cfg): not bound to any textdomain - Forgotten Legacy:*** warning (Forgotten_Legacy/terrain/terrain-graphics.cfg): not bound to any textdomain
*** warning (Forgotten_Legacy/utils/fl_items.cfg): not bound to any textdomain
*** warning (Forgotten_Legacy/units/naga/Poseidons_Mistress.cfg): not bound to any textdomain
*** warning (Forgotten_Legacy/units/saurians/Skald_Chieftain.cfg): not bound to any textdomain
*** warning (Forgotten_Legacy/units/saurians/Saurian_Headhunter.cfg): not bound to any textdomain
*** warning (Forgotten_Legacy/units/saurians/Soothsayer.cfg): not bound to any textdomain
*** warning (Forgotten_Legacy/units/saurians/Skald_Hunter.cfg): not bound to any textdomain
*** warning (Forgotten_Legacy/units/saurians/Skald_Maniac.cfg): not bound to any textdomain
*** warning (Forgotten_Legacy/units/saurians/Headhunter_Champion.cfg): not bound to any textdomain
- After the Storm:*** error (After_the_Storm/terrain-graphics/_final.cfg:1): bound to textdomain wesnoth-Invasion_from_the_Unknown, which is not a core or self textdomain
*** error (After_the_Storm/ai/macros.cfg:1): bound to textdomain wesnoth-Invasion_from_the_Unknown, which is not a core or self textdomain
*** error (After_the_Storm/ai/_main.cfg:1): bound to textdomain wesnoth-Invasion_from_the_Unknown, which is not a core or self textdomain
*** error (After_the_Storm/ai/fake/npc.cfg:1): bound to textdomain wesnoth-Invasion_from_the_Unknown, which is not a core or self textdomain - Conquistadors: the textdomain id wesnoth-conquistadors is incompatible; change to "wesnoth-Conquistadors" instead to match the UMC directory name
- Delfador's Memoirs: (Delfadors_Memoirs/utils/journey.cfg): not bound to any textdomain
- Era of Myths: too much stuff, see attachment.
- Pandemonium: no [textdomain] path attribute.
- Quenoth-Sandbox: no textdomain declarations.
- Role Playing Construction Set: no [textdomain] path attribute.
- The Dark Hordes: (The_Dark_Hordes/utils/journey.cfg): not bound to any textdomain.
- The Silver Lands:*** error (The_Silver_Lands/units/imps/Gutwrencher.cfg:1): bound to textdomain wesnoth-Invasion_from_the_Unknown, which is not a core or self textdomain
*** error (The_Silver_Lands/units/imps/Gutwrencher.cfg:43): bound to textdomain wesnoth-Invasion_from_the_Unknown, which is not a core or self textdomain
*** error (The_Silver_Lands/units/imps/Blood.cfg:1): bound to textdomain wesnoth-Invasion_from_the_Unknown, which is not a core or self textdomain
*** error (The_Silver_Lands/units/imps/Armageddon.cfg:1): bound to textdomain wesnoth-Invasion_from_the_Unknown, which is not a core or self textdomain
*** error (The_Silver_Lands/units/imps/Imp.cfg:1): bound to textdomain wesnoth-Invasion_from_the_Unknown, which is not a core or self textdomain
*** error (The_Silver_Lands/units/imps/Minor.cfg:1): bound to textdomain wesnoth-Invasion_from_the_Unknown, which is not a core or self textdomain
*** warning (The_Silver_Lands/units/gargoyles/Gargoyle_Marlgoyle.cfg): not bound to any textdomain
*** warning (The_Silver_Lands/units/gargoyles/Gargoyle.cfg): not bound to any textdomain
*** error (The_Silver_Lands/units/monsters/Giant_Spider_Lesser.cfg:1): bound to textdomain wesnoth-Invasion_from_the_Unknown, which is not a core or self textdomain
*** error (The_Silver_Lands/units/monsters/Bear.cfg:1): bound to textdomain wesnoth-Invasion_from_the_Unknown, which is not a core or self textdomain
*** error (The_Silver_Lands/units/monsters/Giant_Ant.cfg:1): bound to textdomain wesnoth-Invasion_from_the_Unknown, which is not a core or self textdomain
*** error (The_Silver_Lands/units/monsters/Abomination.cfg:1): bound to textdomain wesnoth-Invasion_from_the_Unknown, which is not a core or self textdomain
*** error (The_Silver_Lands/units/monsters/Cockatrice.cfg:1): bound to textdomain wesnoth-Invasion_from_the_Unknown, which is not a core or self textdomain
*** error (The_Silver_Lands/units/monsters/Chimera.cfg:1): bound to textdomain wesnoth-Invasion_from_the_Unknown, which is not a core or self textdomain
*** error (The_Silver_Lands/units/monsters/Hound_Hell.cfg:1): bound to textdomain wesnoth-Invasion_from_the_Unknown, which is not a core or self textdomain
*** error (The_Silver_Lands/units/monsters/Hound_Chaos.cfg:1): bound to textdomain wesnoth-Invasion_from_the_Unknown, which is not a core or self textdomain
*** error (The_Silver_Lands/units/monsters/Water_Serpent.cfg:1): bound to textdomain wesnoth-Invasion_from_the_Unknown, which is not a core or self textdomain
*** error (The_Silver_Lands/units/monsters/Eyestalk.cfg:1): bound to textdomain wesnoth-Invasion_from_the_Unknown, which is not a core or self textdomain
*** error (The_Silver_Lands/units/monsters/Fungoid.cfg:1): bound to textdomain wesnoth-Invasion_from_the_Unknown, which is not a core or self textdomain
*** error (The_Silver_Lands/units/monsters/Hound_Demonic.cfg:1): bound to textdomain wesnoth-Invasion_from_the_Unknown, which is not a core or self textdomain
*** error (The_Silver_Lands/units/vampires/Mistress.cfg:1): bound to textdomain wesnothThe_Silver_Lands, which is not a core or self textdomain
*** error (The_Silver_Lands/units/vampires/Blood_Manipulator.cfg:1): bound to textdomain wesnoth-TSL, which is not a core or self textdomain - Thunderstone:*** warning (Thunderstone/era.cfg): not bound to any textdomain
*** error (Thunderstone/terrain-graphics/precedence.cfg:1): bound to textdomain wesnoth-Invasion_from_the_Unknown, which is not a core or self textdomain
*** warning (Thunderstone/factions/shaxthals.cfg): not bound to any textdomain - Unrest in Elfland: the textdomain id wesnoth-Unrest is incompatible; change to "wesnoth-Unrest_in_Elfland" instead to match the UMC directory name.
- Wesbowl Reloaded: no textdomain declarations.
- Attachments
-
- era_of_myths_report.gz
- the trunk EoM's report
- (1.84 KiB) Downloaded 335 times
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
Re: Coordinated User-made Content Development Project (with SVN)
EoS's 1.4 branch is no longer maintained. I made a conscious decision *not* to have it added to wescamp.
As for TDH, there's a "wmllint: no translatables" pragma there, maybe you should check for those.
As for TDH, there's a "wmllint: no translatables" pragma there, maybe you should check for those.
Re: Coordinated User-made Content Development Project (with SVN)
This as much for your benefit as mine, so that I can have a place to keep track of what I have fixed in TCoaDQ.
_Main.cfg
Abilities
Movetypes
Races
Scenarios
Units
Utils
Yay for learning SVN. This is all of it, I do believe, but let me know what I missed.
_Main.cfg
Abilities
Movetypes
Races
Scenarios
Units
Utils
Yay for learning SVN. This is all of it, I do believe, but let me know what I missed.
Mainline Maintainer: AOI, DM, NR, TB and THoT.
UMC Maintainer: Forward They Cried, A Few Logs, A Few More Logs, Start of the War, and Battle Against Time
UMC Maintainer: Forward They Cried, A Few Logs, A Few More Logs, Start of the War, and Battle Against Time
Branching
Hiho!
As many of you know already, Wesnoth 1.6.0 is approaching, and the mainline development team has released one Release Candidate for it already. I must remind you that in mainline, the repository is branched whenever a major stable tree is created, roughly as follows:
1. Supertrees
The /trunk supertree is where development of add-ons for the current development series of the mainline Wesnoth game engine takes place. When this repository was created, /trunk held add-on trees for stuff that was being written for Wesnoth 1.5.0-svn (not even a released version).
The /branches and /tags supertrees are organized as follows:
In practice, any add-ons that have been actively maintained for an entire mainline development series (/trunk right now) are supposed to be compatible with the new stable series (/branches/1.6), unless the add-on maintainers say otherwise. For instance, Invasion_from_the_Unknown has been actively maintained since Wesnoth 1.5.4 - the maintainer is still alive and kicking, and has ensured that the campaign works with the Wesnoth 1.6 betas and RCs (Wesnoth 1.5.9 - 1.5.12), therefore the add-on is necessarily compatible with Wesnoth 1.6 and can have its 1.6 branch.
2. Branching
In mainline, the 1.6 branch is created from /trunk using the SVN 'copy' command (or its equivalent in a graphical frontend such as TortoiseSVN) as soon as /trunk reaches the required quality level/schedule for a new release past the last intended/appropriate Release Candidate version.
This time it'll probably be done some days after 1.5.13 (1.6 RC2) is released - most likely on March 14th or 15th. When it happens, users and developers tracking /trunk will be tracking Wesnoth 1.7.0-svn; to track the changes in the maintenance branch they must switch or make new checkouts for /branches/1.6.
The mainline developers are only allowed to fix bugs requiring non-intrusive engine changes (as in, not breaking MP client interoperatibility, add-on usability, and not requiring to rewrite any part of the engine) in the 1.6 branch ("maintenance" branch). New features and engine changes should go to mainline /trunk. Developers fixing bugs in 1.6 must port their patches and apply them on /trunk, or alternatively post them in patches.wesnoth.org so other devs can do their job if they really cannot do it themselves. Bug fixes in /trunk that apply to bugs present in 1.6 also require porting, in the inverse direction.
We'll use the term cherry-picking to refer to the process of taking SVN patches/changesets from the trunk or a branch, and porting them for a different branch (or trunk).
In Wesnoth-UMC-Dev, add-on maintainers are free to establish their own feature-freeze/string-freeze policies for their own add-ons if they think it is appropriate - one can decide to continue adding features to /branches/1.6/Invasion_from_the_Unknown despite the status of mainline in that regard. More often than not, string-freezes or feature-freezes for add-ons are unnecessary and evil.
However, we still require maintainers to clarify what Wesnoth development/maintenance series work with their add-ons in such a way that a simple 'svn ls' command can reveal. This is the purpose of branching.
After the mainline 1.6.0 release, add-ons being actively maintained in Wesnoth-UMC-Dev's trunk are assumed to be maintained with Wesnoth 1.7.x in mind. Add-ons that have a tree in /branches/1.6, regardless of their level of maintenance activity, are assumed to be maintained with late Wesnoth 1.5.x or any Wesnoth 1.6 release in mind.
We, the admins, won't patrol each and every add-on ensuring, e.g. that a /branches/1.6 tree isn't using a Wesnoth 1.7.1 WML feature, etc. However, doing that will confuse your users/comaintainers/successors and possibly us too, if we ever decide to handle your add-on due to release-critical bugs in it.
Initially, we planned to branch all add-ons from trunk, after contacting their active maintainers to ask them for permission to do the branching, in a single step, removing commit permissions from everyone but the admins, doing the svn branching procedure, and casting tree locks on the /trunk directories afterwards so the add-on maintainer could declare himself/herself ready to maintain it for 1.7.x.
This plan failed for the following reasons:
If your answer to any of the following question is yes, then we'll branch the add-on for you using the latest revision in /trunk, or, if you may require it, any other revision you specify in your answer. Only admins are allowed to do the branching - anyone else doing or trying to do it may mess things up. (Short version: let the admins do the branching; do it yourself and you'll get flamed or banned.)
While your add-on is branched, we will drop your commit permissions until we are done with it - don't worry, you'll get them back in (at most) a few hours.
Before replying with a "yes" to the aforementioned questions, forward this message to your co-maintainers and include a list of them in your reply to us, so that we can also drop their permissions temporarily. If you require some time to do all the necessary changes for the 1.6 branching, tell us and we can delay the branching. If you don't want to maintain your add-on for 1.6, tell us and /trunk will stay as-is.
Zookeeper's add-ons (Brotherhood_of_Light, PickYourRecruits_Era) and AI's (Era of Strife, The Dark Hordes) have already been branched with their permission.
3. Cherry-picking and maintenance in two trees
Maintaining an add-on for trunk and a branch, or trunk and two branches in the most extreme case (1.4, 1.6 and trunk), can be highly tedious and time-consuming. Or disk-consuming. However, it is necessary if you don't want to have lots of bugs fixed in 1.6 and lots of bugs created and never fixed in trunk. It is necessary if you want to be serious about this stuff and not just produce random half-assed add-ons as many (but not all) non-managed authors do for stable Wesnoth series.
You can receive assistance from the admins to port changesets from /trunk to a branch and vice versa if you submit a task to the Wesnoth-UMC-Dev tracker with a diff or revision number and "cherry-pick" in the task subject line. These will be eventually handled by an admin (Shadow_Master, AI0867, Turuk), or, possibly, a cherry-picking assistance if we find a developer capable and willing to take care of that task.
We consider this to be repository administration tasks of the lowest level, so if you want to do this in an efficient manner, please consider doing it yourself. Feel free to ask us for assistance with commit cherry-picking (e.g. how to use svn merge efficiently? what's the best way to manage multiple branches? etc.)
Best regards
-- The Wesnoth-UMC-Dev admins.
As many of you know already, Wesnoth 1.6.0 is approaching, and the mainline development team has released one Release Candidate for it already. I must remind you that in mainline, the repository is branched whenever a major stable tree is created, roughly as follows:
- /trunk is at version 1.5.12+svn)
- /trunk is branched to 1.6 using
Code: Select all
svn cp <repository URI>/trunk <repository URI>/branches/1.6
- /trunk is at version 1.7.0-svn
- /branches/1.6 is at version 1.6.0
- The tag at /tags/1.6.0 is created from /branches/1.6, and the Release Manager generates the 1.6.0 tarball
- 1.6 is added to the SF.net downloads section, packagers produce the binaries for the major platforms (MacOS X, Debian GNU/Linux, MS Windows - 32 bits)
- Several days pass so that the SF.net mirrors are completely populated with the 1.6 binary and source packages
- 1.6.0 is publicly announced at Wesnoth.org and the forums
- Create the supertrees /branches/1.6 and /tags/1.6
- Branch each add-on under /trunk in an opt-in basis
- Open the task tracker at SF.net for managing requests for patch cherry-picking from /branches/1.6 to /trunk and vice versa
1. Supertrees
The /trunk supertree is where development of add-ons for the current development series of the mainline Wesnoth game engine takes place. When this repository was created, /trunk held add-on trees for stuff that was being written for Wesnoth 1.5.0-svn (not even a released version).
The /branches and /tags supertrees are organized as follows:
Code: Select all
/branches
-> /branches/1.4
development of add-ons for BfW 1.3.x/1.4.x *after* BfW 1.4.0 is released
-> /branches/1.6
development of add-ons for BfW 1.5.x/1.6.x *after* BfW 1.6.0 is released
-> /branches/1.8
development of add-ons for BfW 1.7.x/1.8.x *after* BfW 1.8.0 is released
-> /branches/backports/1.4, /branches/backports/1.6, /branches/backports/...
similar to the /branches/<major version> trees, but these are usually forks built from scratch from add-ons at /trunk. Only TDH has used this.
-> /branches/testing/1.4, /branches/testing/1.6, /branches/testing/...
holds test-case add-ons for reproducing or supporting bug reports from wesnoth-umc-dev or mainline
-> /branches/maintenance-toolchain
repository and add-on maintenance scripts written by Shadow_Master, AI
-> /branches/irc-bots
source code of the bots used for the #wesnoth-umc-dev IRC channel @ Freenode.net
-> /branches/wml-tools
source code for WML maintenance tools not specific to the repository, that are not in mainline
-> /branches/resources
add-on non-specific artwork, music, sounds or code available for add-on authors
-> /branches/resources/deprecated_mainline
artwork, music, sounds or code that was once in mainline but got replaced/removed from its repository
/tags
-> /tags/1.4
release tags for add-ons from /branches/1.4
-> /tags/1.6
release tags for add-ons from /branches/1.6
-> /tags/1.8
release tags for add-ons from /branches/1.8
-> /tags/trunk
release tags for add-ons from /trunk (may be replaced by /tags/1.5 et al in the future
2. Branching
In mainline, the 1.6 branch is created from /trunk using the SVN 'copy' command (or its equivalent in a graphical frontend such as TortoiseSVN) as soon as /trunk reaches the required quality level/schedule for a new release past the last intended/appropriate Release Candidate version.
This time it'll probably be done some days after 1.5.13 (1.6 RC2) is released - most likely on March 14th or 15th. When it happens, users and developers tracking /trunk will be tracking Wesnoth 1.7.0-svn; to track the changes in the maintenance branch they must switch or make new checkouts for /branches/1.6.
The mainline developers are only allowed to fix bugs requiring non-intrusive engine changes (as in, not breaking MP client interoperatibility, add-on usability, and not requiring to rewrite any part of the engine) in the 1.6 branch ("maintenance" branch). New features and engine changes should go to mainline /trunk. Developers fixing bugs in 1.6 must port their patches and apply them on /trunk, or alternatively post them in patches.wesnoth.org so other devs can do their job if they really cannot do it themselves. Bug fixes in /trunk that apply to bugs present in 1.6 also require porting, in the inverse direction.
We'll use the term cherry-picking to refer to the process of taking SVN patches/changesets from the trunk or a branch, and porting them for a different branch (or trunk).
In Wesnoth-UMC-Dev, add-on maintainers are free to establish their own feature-freeze/string-freeze policies for their own add-ons if they think it is appropriate - one can decide to continue adding features to /branches/1.6/Invasion_from_the_Unknown despite the status of mainline in that regard. More often than not, string-freezes or feature-freezes for add-ons are unnecessary and evil.
However, we still require maintainers to clarify what Wesnoth development/maintenance series work with their add-ons in such a way that a simple 'svn ls' command can reveal. This is the purpose of branching.
After the mainline 1.6.0 release, add-ons being actively maintained in Wesnoth-UMC-Dev's trunk are assumed to be maintained with Wesnoth 1.7.x in mind. Add-ons that have a tree in /branches/1.6, regardless of their level of maintenance activity, are assumed to be maintained with late Wesnoth 1.5.x or any Wesnoth 1.6 release in mind.
We, the admins, won't patrol each and every add-on ensuring, e.g. that a /branches/1.6 tree isn't using a Wesnoth 1.7.1 WML feature, etc. However, doing that will confuse your users/comaintainers/successors and possibly us too, if we ever decide to handle your add-on due to release-critical bugs in it.
Initially, we planned to branch all add-ons from trunk, after contacting their active maintainers to ask them for permission to do the branching, in a single step, removing commit permissions from everyone but the admins, doing the svn branching procedure, and casting tree locks on the /trunk directories afterwards so the add-on maintainer could declare himself/herself ready to maintain it for 1.7.x.
This plan failed for the following reasons:
- Sourceforge.net does not allow SVN tree locks, nor "disabling the repository for everyone but the admins".
- The admins may not have enough time to do this in a single day, the eve of the mainline 1.6 branching.
- Is your add-on usable for Wesnoth 1.6 and its 1.5-numbered Release Candidates?
- Do you plan to maintain it, or simply declare its latest revision in SVN trunk as "Ready for 1.6"?
If your answer to any of the following question is yes, then we'll branch the add-on for you using the latest revision in /trunk, or, if you may require it, any other revision you specify in your answer. Only admins are allowed to do the branching - anyone else doing or trying to do it may mess things up. (Short version: let the admins do the branching; do it yourself and you'll get flamed or banned.)
While your add-on is branched, we will drop your commit permissions until we are done with it - don't worry, you'll get them back in (at most) a few hours.
Before replying with a "yes" to the aforementioned questions, forward this message to your co-maintainers and include a list of them in your reply to us, so that we can also drop their permissions temporarily. If you require some time to do all the necessary changes for the 1.6 branching, tell us and we can delay the branching. If you don't want to maintain your add-on for 1.6, tell us and /trunk will stay as-is.
Zookeeper's add-ons (Brotherhood_of_Light, PickYourRecruits_Era) and AI's (Era of Strife, The Dark Hordes) have already been branched with their permission.
3. Cherry-picking and maintenance in two trees
Maintaining an add-on for trunk and a branch, or trunk and two branches in the most extreme case (1.4, 1.6 and trunk), can be highly tedious and time-consuming. Or disk-consuming. However, it is necessary if you don't want to have lots of bugs fixed in 1.6 and lots of bugs created and never fixed in trunk. It is necessary if you want to be serious about this stuff and not just produce random half-assed add-ons as many (but not all) non-managed authors do for stable Wesnoth series.
You can receive assistance from the admins to port changesets from /trunk to a branch and vice versa if you submit a task to the Wesnoth-UMC-Dev tracker with a diff or revision number and "cherry-pick" in the task subject line. These will be eventually handled by an admin (Shadow_Master, AI0867, Turuk), or, possibly, a cherry-picking assistance if we find a developer capable and willing to take care of that task.
We consider this to be repository administration tasks of the lowest level, so if you want to do this in an efficient manner, please consider doing it yourself. Feel free to ask us for assistance with commit cherry-picking (e.g. how to use svn merge efficiently? what's the best way to manage multiple branches? etc.)
Best regards
-- The Wesnoth-UMC-Dev admins.
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
Re: Coordinated User-made Content Development Project (with SVN)
I like this project. But what I absolutely dislike is the constant tagging horror that is done for IftU, for every minor "stable release". Keep in mind that svn terribly sucks at tagging, and that we constantly check out the same old images of IftU everytime. It gets boring after the first million time. If you really need proper tagging (which would be branches, anyway) then please use a sane (D)VCS.
Edit: It seems every add-on release gets tagged. This is really overkill. Stop it. The branches are more than enough.
Edit #2: Yes, it might be the way I use git-svn for this repo. Since I use git-svn only when I have to I am not entirely sure. Given that svn branches appear as git branches here at least some thing was set up correctly. I guess it is just the "overhead" you get with fetching all the objects. Of course, in a proper git repo tags would only be pointers to named commits ... I just cant imagine I am the only one using git-svn for this repo though.
Edit: It seems every add-on release gets tagged. This is really overkill. Stop it. The branches are more than enough.
Edit #2: Yes, it might be the way I use git-svn for this repo. Since I use git-svn only when I have to I am not entirely sure. Given that svn branches appear as git branches here at least some thing was set up correctly. I guess it is just the "overhead" you get with fetching all the objects. Of course, in a proper git repo tags would only be pointers to named commits ... I just cant imagine I am the only one using git-svn for this repo though.
Re: Coordinated User-made Content Development Project (with SVN)
First of all, regular SVN users must not checkout the whole of any of the three hives (/branches, /tags, /trunk) unless they really have plenty of disk space to spare. This is also mentioned in the website as a bad practice.
However, if your git master branch seems to contain all three hives then it may surely be a problem - I only use git-svn for individual add-ons (TDH, IftU and AtS) skipping their /tags locations so I'm not sure what a git svn set-up for this repository should be like.
Also, consider that the repository was built around mainline practices, and the mainline repository does have a /tags tree that possibly has a multi-gigabyte on-disk size. Nobody seems to have problems with avoiding to check out the entire repository.
(As a reminder: we recommend to join [url=irc://chat.freenode.net/#wesnoth-umc-dev]the IRC channel #wesnoth-umc-dev at chat.freenode.net[/url] regularly so we can help you quickly with any issues that may arise.)
grrr wrote:Edit #2: Yes, it might be the way I use git-svn for this repo. Since I use git-svn only when I have to I am not entirely sure. Given that svn branches appear as git branches here at least some thing was set up correctly. I guess it is just the "overhead" you get with fetching all the objects. Of course, in a proper git repo tags would only be pointers to named commits ... I just cant imagine I am the only one using git-svn for this repo though.
git svn rebase
should fetch commits to the current branch only. git svn fetch
will fetch commits for all branches. The mainline developers using git-svn for the mainline Gna! repository seem not to have any problems, but I personally avoid running fetch
.However, if your git master branch seems to contain all three hives then it may surely be a problem - I only use git-svn for individual add-ons (TDH, IftU and AtS) skipping their /tags locations so I'm not sure what a git svn set-up for this repository should be like.
We have considered switching to git for very different reasons which will not be disclosed, but we are still not sure since the existing Windows-based git clients seem to be very unfriendly/difficult to configure compared to e.g. TortoiseSVN (a Windows-based SVN client).grrr wrote:Keep in mind that svn terribly sucks at tagging, and that we constantly check out the same old images of IftU everytime. It gets boring after the first million time. If you really need proper tagging (which would be branches, anyway) then please use a sane (D)VCS.
Also, consider that the repository was built around mainline practices, and the mainline repository does have a /tags tree that possibly has a multi-gigabyte on-disk size. Nobody seems to have problems with avoiding to check out the entire repository.
(As a reminder: we recommend to join [url=irc://chat.freenode.net/#wesnoth-umc-dev]the IRC channel #wesnoth-umc-dev at chat.freenode.net[/url] regularly so we can help you quickly with any issues that may arise.)
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
Re: Coordinated User-made Content Development Project (with SVN)
Also, if you don't want the tags, then don't clone them. It's perfectly possible to only check out the trunk and branches for an add-on. (or the whole repo, but you don't want to check out the whole repo except for backup purposes)
Re: Coordinated User-made Content Development Project (with SVN)
Yeah, I guess I am just spoiled.