SVN:Rules

Contents 1 Main Page 2 SVN Rules 3 Checkouts and Updates (Downloading) 3.1 Updating 4 Committing (Uploading) 4.1 Getting an Account 4.2 One AddOn Per Commit 4.3 One "Idea" Per Commit 4.4 Path Names 4.5 Commit Notes / Comments 4.6 Don't Spam 4.7 Test Before You Commit 4.8 Common Courtesy

SVN Rules

Please abide by these simple SVN rules, they will keep everyone happy and sane.

Checkouts and Updates (Downloading)

Updating

Now I know your first urge is to just select all and choose update. This is okay, if you don't do it often. If you are doing this more than, say, once a day, please take the time to watch the commit log. Pay attention to what addons have actually changed, and only update those.

Committing (Uploading)

Getting an Account

Look here http://code.google.com/p/support/wiki/FAQ#Accounts

You only need an account if you want to commit (upload) files and changes to Google Code

One AddOn Per Commit

Simple rule, one addon, one commit. Don't commit multiple addons in the same operation.
If you didn't check out the entire repo, this shouldn't even be possible for you anyway.

There are some special cases where an admin will mass-edit many items in the repo.
Please do not do this, those who do know what they're doing, and it's usually a change that must be applied to everything in the repo.

One "Idea" Per Commit

This is not a rule, but more of a "good practices" guideline
Generally when you commit code to the SVN, especially when more than one person is working on the project, you want to only work on one idea, or area of the project.

I myself (Zanix) hardly ever follow this rule, but that doesn't mean it isn't a good idea

Path Names

Second simple rule, use consistent path names.
We have quite a few addons on our SVN, we need to keep them in order.
You should only every commit into one of three paths, trunk, tags, and branches.
For each of these examples I will use a fictional addon called 'SomeAddOn'

trunk

This is where the "main version" of your mod should go.

The current build, if you will.

This path is simple.

/trunk/<addon name>/
/trunk/SomeAddOn/

tags

Tags are a sort of snapshot of your code, a bookmark if you will.

Most authors will tag specific milestones in their code, major versions, release candidates, even the final build of an abandoned project.

You are encouraged to tag your mods as often as you want, even if it's just some simple reminder to yourself.

Tags follow a slightly different path.

/tags/<addon name>/<Tag name>/
/tags/SomeAddOn/v1.0/

branches

Branches are a sort of "side development" from the trunk.

An author might branch their addon to convert it to new libraries, or another author may branch to give some code rewrites to another author.

We highly encourage the use of branches to share changes to other authors' works unless you already have consent from that author to edit their trunk versions.

Branches have a naming scheme similar to tags.

The branch name is, in most cases, can simply be your user name.

/branches/<addon name>/<Branch name>/<addon name>/
/branches/SomeAddOn/Zanix/SomeAddOn/

Commit Notes / Comments

Every commit you make will ask for notes. Do not leave this blank!
Commit notes should always contain the name of the addon you're editing at the start.
This is followed by a description (simple or long) of what changes you made.
Most authors will use a format like:

SomeAddOn: Updated externals

or

SomeAddOn:
- Fixed notice error on line 42
- Mixed in some berries

If you keep with this format, commit logs are much easier to read.

The SVN may reject commits that have no notes.
To ensure that your commit is accepted, the note must entered.

Don't Spam

If you are making many changes to an addon, please make all the changes and test them for simple syntax errors before you commit.
If you are making the same change across many addons, please space out your commits a little bit. for our sanity and others.
This will not only reduce the spam, but it'll allow the server a moment to run it's post-commit scripts.
If the edits are minor and don't effect performance, you might be better off just waiting until you have a significant change to commit up.

Test Before You Commit

This one's a simple request, run your code on your local server, or personal site before you commit.
This will reduce "fixed typo" spam commits we all just LOVE to see.
If you're coding somewhere where you cannot test like this (say at work or at your father's brother's nephew's cousin's former roommate's house), then you should probably note in your commit message that these changes are "drycoded".
This tells other authors and users that the code will probably be buggy since you could not test it.

Common Courtesy

The SVN repository is open to anyone with commit access
We ask that you respect others' works and not make changes to their code without notifying the author.