Difference between revisions of "Subversion"

From OdaWiki
m (Stupid me, RapidSVN is wx, not GTK)
Line 33: Line 33:
 
* [http://subversion.tigris.org/ Subversion]: Command Line client for multiple platforms.
 
* [http://subversion.tigris.org/ Subversion]: Command Line client for multiple platforms.
 
* [http://tortoisesvn.tigris.org/ TortiseSVN]: Windows Explorer extension for Windows.
 
* [http://tortoisesvn.tigris.org/ TortiseSVN]: Windows Explorer extension for Windows.
* [http://rapidsvn.tigris.org/ RapidSVN]: GTK based GUI client for multiple platforms.
+
* [http://rapidsvn.tigris.org/ RapidSVN]: wxWidgets based GUI client for multiple platforms.
  
 
== How is Odamex's repository organized ==
 
== How is Odamex's repository organized ==

Revision as of 00:33, 10 November 2006

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

What is Subversion?

Subversion is the current version control repository used to maintain the Odamex source code. In layman's terms, it allows multiple people to be working on the same project at the same time while giving those same people the facilities to recognize collisions between two contributors code.

How do I access Odamex's Subversion?

Access is restricted based on our Policy. 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).

How do I use a subversion client?

This depends on the subversion client you happen to be using. However, there are some terms that you should recognize that are consistant between clients.

Checkout

The act of checking out means that you connect to the subversion server and it downloads a revision of the code you specify and places it into a newly created subversion filesystem on your local hard drive. By default, the HEAD(latest) revision is the one that is checked out, and probably the one that you are most interested in.

This is how you check out from the command line:

svn checkout <server name> <destination directory>

Update

Once you check out a revision of odamex's source code, your local version of the code stays that way. If a newer version of the code comes out, you have two options. You can either check out a new version of the code into a seporate directory, or you can update the existing code that you already have. Note that any changes you have made to your local copy are kept, and not discarded, and if the version you download from the server collides with any of your changed files, subversion will tell you this, and you must handle the conflict between your local copy and the server's repository manually, usually through a revert, or by creating a new local copy so you don't lose your hard work..

This is how you update from the command line:

svn update <local directory>

Note that you do not need to specify the server, as subversion remembers the server where your local copy originated from.

What Subversion clients are avalable?

There are many, many subversion clients avalable:

  • Subversion: Command Line client for multiple platforms.
  • TortiseSVN: Windows Explorer extension for Windows.
  • RapidSVN: wxWidgets based GUI client for multiple platforms.

How is Odamex's repository organized

Each branch keeps an entire odamex source tree.

  • root
    • trunk - Bleeding-edge development, expect things to break often
    • branches
      • stable - The latest stable version, merged with trunk when features mature
      • ogl_hack - A very experimental attempt at creating an OpenGL-based renderer for Odamex
      • other temporary branches may be created or destoryed
    • tags

How can I be notified when the repository updates?

Any changes to our svn repository are reported in:

Guidelines for maintainers

  • 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
    • Mention related bugs and revisions (see changelog for examples)
    • 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