Coordinated User-made Content Development Project (with SVN)

Discussion and development of scenarios and campaigns for the game.

Moderator: Forum Moderators

fabi
Inactive Developer
Posts: 1260
Joined: March 21st, 2004, 2:42 pm
Location: Germany

Re: Coordinated User-made Content Development Project (with SVN)

Post by fabi »

Please make this thread sticky.

Greetings,
Fabi
User avatar
Iris
Site Administrator
Posts: 6797
Joined: November 14th, 2006, 5:54 pm
Location: Chile
Contact:

Re: Coordinated User-made Content Development Project (with SVN)

Post by Iris »

Done.

I don't see what's the gain though. [/humble]
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
fabi
Inactive Developer
Posts: 1260
Joined: March 21st, 2004, 2:42 pm
Location: Germany

Re: Coordinated User-made Content Development Project (with SVN)

Post by fabi »

Shadow Master wrote:Done.

I don't see what's the gain though. [/humble]
Well, having a svn repository for campaign developers is something that could make a really step forward for wesnoth.
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
User avatar
Iris
Site Administrator
Posts: 6797
Joined: November 14th, 2006, 5:54 pm
Location: Chile
Contact:

Re: Coordinated User-made Content Development Project (with SVN)

Post by Iris »

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. :P

Okay, that was random. :P

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.
User avatar
Iris
Site Administrator
Posts: 6797
Joined: November 14th, 2006, 5:54 pm
Location: Chile
Contact:

Re: Coordinated User-made Content Development Project (with SVN)

Post by Iris »

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.
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
User avatar
Iris
Site Administrator
Posts: 6797
Joined: November 14th, 2006, 5:54 pm
Location: Chile
Contact:

Re: Coordinated User-made Content Development Project (with SVN)

Post by Iris »

Edited the first post with a ToS revision by ESR.
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
User avatar
Iris
Site Administrator
Posts: 6797
Joined: November 14th, 2006, 5:54 pm
Location: Chile
Contact:

Re: Coordinated User-made Content Development Project (with SVN)

Post by Iris »

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.
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
User avatar
Iris
Site Administrator
Posts: 6797
Joined: November 14th, 2006, 5:54 pm
Location: Chile
Contact:

Re: Coordinated User-made Content Development Project (with SVN)

Post by Iris »

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:
  • 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
Similar stuff in trunk:
  • 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.
If you want your content to be fully translatable, pay attention to the issues, fix them, and set translate=yes in your .pbl when you publish it in the add-ons server. If you see warnings about "not bound to any textdomain" and you don't have translatable strings in the particular files, it's safe to ignore them.
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.
AI
Developer
Posts: 2396
Joined: January 31st, 2008, 8:38 pm

Re: Coordinated User-made Content Development Project (with SVN)

Post by AI »

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. ;)
User avatar
Turuk
Sithslayer
Posts: 5283
Joined: February 28th, 2007, 8:58 pm
Contact:

Re: Coordinated User-made Content Development Project (with SVN)

Post by Turuk »

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.
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
User avatar
Iris
Site Administrator
Posts: 6797
Joined: November 14th, 2006, 5:54 pm
Location: Chile
Contact:

Branching

Post by Iris »

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:
  • /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
Since Wesnoth-UMC-Dev follows the mainline development status for practical and administration purposes, the mainline branching must be reflected in Wesnoth-UMC-Dev at some point. We, the admins, have decided to use the following schedule for branching. All times are GMT-03:00 (Chile Continental + DST) because I'm too lazy to do the conversions to UTC or Wesnoth Standard Time (GMT+01:00). The items in bold green are completed. The items in bold olive are work-in-progress as of this writing (Thursday March 5th, 2009, 21:28 CLST).
  • 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
Each item requires some detailed explanations. Please read them carefully before asking questions. Please read the Subversion Book as well before asking what branches or tags are.


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
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:
  • 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.
Therefore, we decided to branch each add-on as soon as its active maintainer (if any) replies to this massive message answering the following questions:
  • 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"?
[/list]

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.
grrr
Posts: 252
Joined: May 25th, 2007, 9:49 pm

Re: Coordinated User-made Content Development Project (with SVN)

Post by grrr »

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.
User avatar
Iris
Site Administrator
Posts: 6797
Joined: November 14th, 2006, 5:54 pm
Location: Chile
Contact:

Re: Coordinated User-made Content Development Project (with SVN)

Post by Iris »

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.
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.
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.
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).

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.
AI
Developer
Posts: 2396
Joined: January 31st, 2008, 8:38 pm

Re: Coordinated User-made Content Development Project (with SVN)

Post by AI »

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)
grrr
Posts: 252
Joined: May 25th, 2007, 9:49 pm

Re: Coordinated User-made Content Development Project (with SVN)

Post by grrr »

Yeah, I guess I am just spoiled.
Locked