85 lines
4.1 KiB
Plaintext
85 lines
4.1 KiB
Plaintext
SVN checkin process:
|
|
|
|
1) All checkins should include a log message. Included in the log
|
|
message should be what changed (files), why it changed (what new
|
|
feature or bug was fixed).
|
|
|
|
It is not necessary to go into a long exposition, and pasting the actual
|
|
changes is not generally useful. But this log message should be useful for
|
|
someone looking over the logs at a future point to see what did change.
|
|
Having a log like 'various skill stuff' isn't very useful. A log message like
|
|
'prevent abuse with the literacy skill, and increase chance of singing' is
|
|
much more useful, and not a lot more words.
|
|
|
|
One of the main uses of the log entries is when bugs are reported where
|
|
behaviour changed between version X and Y to be able to look at the log
|
|
entries and get an idea of what specific revision may have caused that
|
|
change.
|
|
|
|
If doing a commit of several different files at each time, and the commits
|
|
are different in nature, do try to at least mention what is changing in
|
|
each file.
|
|
|
|
Do not refer to other files or other log messages. Saying 'see changes
|
|
file' is not useful, nor is a message like 'continuing with last set
|
|
of commits'. Such messages are not useful when trying to look back through
|
|
the logs at a future point.
|
|
|
|
There is no excuse for not having a good log entry. Worst case, cut and
|
|
past from the CHANGES file or those prior commits. My typical method
|
|
of doing commits is filling out the CHANGES file, and then
|
|
copying/pasting from that when I do the commit.
|
|
|
|
Please also update the CHANGES file for the appropriate distribution -
|
|
this is very useful to look through to get an idea of everything that
|
|
has changed since some release. Very minor things (eg, fixing typos,
|
|
or other things that don't actually effect how the program runs) do not
|
|
need to be in the CHANGES file.
|
|
|
|
2) All checkins should go through at least minimum testing:
|
|
For source code, this means it compiles and at least a basic test has
|
|
been done (for example, if it is a new spell, have you tried casting
|
|
the spell?) This basic testing implies the code at least compiles
|
|
also. I realize it is very difficult to do 100% testing of code, but
|
|
at least a basic test should be done.
|
|
|
|
All source code should also be ANSI & POSIX compliant. Don't use // for
|
|
comments. Be careful of new library calls that are not being used
|
|
elsewhere in the source - there may be a reason they are not being used.
|
|
"it compiles on my system" is not justification for writing code that does
|
|
not work elsewhere. It is understandable that you may not know that the
|
|
code written is non portable, but once this is learned, it should be
|
|
corrected.
|
|
|
|
For archetypes, this testing should involve rebuilding the arch file and
|
|
running with the new file. There should be no errors in the loading
|
|
of the archetype files.
|
|
|
|
For maps, this means that the map should load, and the exits should lead
|
|
back and forth. Note that maps in the unlinked directory are more
|
|
work in progress so can be checked in a more experimental state.
|
|
|
|
3) Style & Balance: Your changes may work, but do they fit in with the
|
|
rest of the game. This basically means following the files guides
|
|
that already existing, eg doc/programming_guide, doc/mapguide
|
|
|
|
There really is no arch guide, but take common sense. Does the
|
|
object fit in with the game (ie, a blaster rifle would not), is this
|
|
arch very unbalancing, etc.
|
|
|
|
4) Before starting a big project, send a note to the mailing list asking
|
|
for opinions. While it is not possible to prevent someone working on
|
|
whatever they may want, if the general consensus is that it is a bad idea,
|
|
you may want to find that out before spending a lot of work on it only
|
|
to find out that your idea will not get added to the game.
|
|
|
|
5) Take responsibility for your code. If you check in something and a bug
|
|
is reported in it, go an fix it.
|
|
|
|
6) Look at the testplans, and if your code may benefit from them, use them.
|
|
Likewise, if you develop a testplan for your code, record it in the
|
|
testplan directory.
|
|
|
|
Mark Wedel
|
|
May 12, 2001
|