Difference between revisions of "Subversion"

From OdaWiki
(Access)
(Guidelines)
Line 33: Line 33:
 
** Separate your commits semantically
 
** Separate your commits semantically
 
** Make an informative comment with each commit
 
** Make an informative comment with each commit
 +
** Refer to bugs and revision numbers in your commits (e.g. "fixes bug 1 caused by r1234")
 
** Mention related bugs and revisions (see [http://odamex.net/changelog changelog] for format)
 
** Mention related bugs and revisions (see [http://odamex.net/changelog changelog] for format)
 
** Seek comments on bugzilla and forum before making major changes
 
** Seek comments on bugzilla and forum before making major changes

Revision as of 19:07, 23 September 2006

File:Commits group multi author graph.png
Graph of svn activity up to revision 1254

SubVersion is the current version control repository used to maintain the odamex source code. Access is restricted based on our Policy.

Tested clients

Directory structure

Each branch keeps an entire odamex source tree.

  • root
    • trunk - bleeding edge development, may not always work
    • branches
      • stable - synchronised with trunk when features mature
      • ogl_hack - a half-hearted attempt at accelerating the renderer
      • other temporary branches may be created or destoryed
    • tags

Change notification

Any changes to our svn repository are reported in:

Guidelines

  • Do
    • Regularly update your working copy
    • Commit individual improvements and corrections to the existing code
    • Separate your commits semantically
    • Make an informative comment with each commit
    • Refer to bugs and revision numbers in your commits (e.g. "fixes bug 1 caused by r1234")
    • Mention related bugs and revisions (see changelog for format)
    • Seek comments on bugzilla and forum before making major changes
    • Test your changes before every commit
  • Do not
    • Commit broken code to trunk or stable
    • Commit untested code to stable
    • Make giant monolithic commits
    • Make major changes without consulting maintainers
    • Make frivolous commits
    • Overwrite other people's recent work without asking them
    • Change EOL modes of files, All files should be LF

Access

Those that contribute considerable time to improve the odamex source may be granted full or partial access. Inactive accounts will tend to get frozen or disabled. Generally, the project manager(s) will administrate this access with the guidance of the lead coder(s).