All project content is available for reading, but you need to be a member of the project for Subversion checkout of source code, or to create/modify any information.
Login if you are a member. Apply here to request membership (open to all).

Using the Subversion Project Repository

Each Code project has its own independent repository based on the Subversion Source Code Management system.

Please also check out the Subversion section of the FAQ (Frequently Asked Questions).

Get a Subversion Client

In order to access the repository for reading and writing, a Subversion client is required. There are a number of clients available, both as standalone and integrated solutions:

  • TortoiseSVN -- A Windows Shell (Explorer) integration that can be used without any IDE. For Windows users this is the preferred client.
  • RapidSVN -- A cross-platform GUI front-end for the Subversion revision system written in C++ using the wxWidgets framework.
  • Subclipse -- An Eclipse plugin that adds Subversion integration to the Eclipse IDE.
  • AnkhSVN -- A Subversion addin for Microsoft Visual Studio .NET.

Please read the documentation and web pages for the client of your choice.

The examples and information below are based on TortoiseSVN.

Get Code

The root of any the project repository is available at https://www.coderesort.com/svn/<projectname> - where <projectname> is the name of the project you are working with. The name is always displayed in the top menu as Current project: . To get the Code from the sandbox project, the URL would be https://www.coderesort.com/svn/sandbox for the repository root.

TortoiseSVN offers two alternatives for getting source code; either Export or Checkout. The difference is that the Export will just put a clean, unlinked copy on your machine, while Checkout will maintain the link and a local copy of unmodified version in special .svn folders. If you want to be able to Update the local code from the central repository or Commit changes, a Checkout is required.

Tutorial - Checkout Sandbox /testhere directory:

  1. Create an empty folder on local harddrive where you want the code placed. Assuming below this is created at c:\svn\sandbox-testhere.
  2. Right-click in Windows on the folder, and the TortoiseSVN context menu should be available. Choose SVN Checkout..., and for URL use https://www.coderesort.com/svn/sandbox/testhere.
  3. All information in the Sandbox /testhere directory is now available locally, files and directories can be added, changed or deleted.
  4. The local copy should be identical to the repository as viewed through the project's [Browse Source] menu item.

Tip: Feel free to leave this page now if you are only looking to get a copy of some code in one of the projects, and don't intend to maintain links, create patches or update the repository. Visit back for further insight once the need arises.

Note: Please read next section before making any changes!

Learn more about Subversion

Before committing code, it may be wise to get some more information about Subversion and working with source code repositories. The most useful and complete reference is the online Subversion Book that provides a wealth of information and best practices.

Here are the top 10 things to remember when using Subversion:

  1. Every change committed to the repository is versioned, and no committed information can ever be removed - it can be updated, copied, moved and deleted in later versions, but can always be looked up in the version it was committed. The version applies to the WHOLE repository. This means that an individual file will not change from version 1 to 2 to 3 to 4 etc., but instead might be changed at version 13, 44, 56 and 88 ("revision" in Subversion language). When talking about revision 49 of the repository, what is meant is the repository as it looked at that revision - the file in question would in reality be 44, but it will also be version 49 (as it will not change before 56).

  2. Complementing the "revision" is the "changeset". The Changeset is the actual set of changes that take the repository from one version to the next. It can be as small as a typographical correction in one word, or as large as a complete reorganisation and modifications to all files. Changeset 49 is the set of changes in the repository from revision 48 => 49.

  3. Subversion is a distributed source code management tool. Any number of people might work on the same file at the same time, and changes are merged at line-level - not file level. Locking files is an option, but is rarely (if ever) used for most projects. Using a client, all common tasks can be done without access to the server - execpt actually committing.

  4. "Branching" and "Tagging" are common terms in Subversion. It basically means take a copy of something and put it somewhere else. A Branch is something that is intended as a shared working copy, used for instance to implement feature changes that might make the common code base (referred to as "Trunk") unstable or unusable. A "Tag" is considered a locked, never changing version in time. Commonly tags are named by released version number - new releases might be added ("tagged"), but [Version_1.1.2] of the solution will (and should) forever remain unchanged. This terminology is also the reason why Subversion repositories commonly are layed out as follows:
       |- stable_1.x
       |- rework_architecture-branch
       |- version_1.1.2
  5. Brancing and tagging is "cheap" and easy copies - it does not add any files to the repository; it just creates the equivalent of a *nix "hard-link" at the point of branching - but not afterwards. The file will share a common history with the "base file" up to the point of branching, but when changes are made to both files later their will be treated independently of each other. To get them back in sync the changes need to be moved between files (and directories) - commonly know as "Merging".

  6. When Merging, two different files and/or directories are compared (user decides what) in order to determine the differences - from adding and reorganising folders to making minor changes to a text file.
    • Note: The Merge command can also be comparing the same files/directories at different versions. If a "my_branch" is created by brancing the "trunk" at revision 76, a merge at current revision 98 might as well compare my_branch@76 to my_branch@98 to determine changes made at the branch so far.
    • There is always a third element involved in merging: the location of where the differences are to be applied. A common scenario is trunk@HEAD if the intention is to merge back into /trunk changes made in the branch. Note: This will not change the repository - only the copy on local harddrive. No changes are made before committing changes - and then all changes are treated the same; Subversion do not know whether a change is made by a merge or a manual edit, or even both.
    • Note: When comparing 2 files, the files need to share a history. It needs to be the same file at different times (different revisions), but can be the same base file even at seperate locations as it has been copied at some previous stage. If they don't share history, a common case is that one file will be deleted and the newer one created in order to get two directories synchronised - this is not a merge, and might lead to unexpected results! Two seperately created files with the same name - even though they reside at the same location at different times - will not be the same file as seen by Subversion. And they cannot be merged.
      • Use a third party tool like WinMerge to merge such files and directories, and apply the necessary changes to the local copy of the directory - and commit changes as usual (again, Subversion have no knowledge of how a change in a source file was made).
      • A common use-case for such needs are when external source is used in a project (libraries and so on), and changes to these files and directories need to be merged into the project. It can also be done inside Subversion, but often easier to implement outside and just commit changes to Subversion.

  7. The working copy on local hard disk contains all directories and source - and more. By looking at the location of the checked out repository (example c:\svn\sandbox-testhere) notice that all directories contain a .svn folder. This provides meta information about the directory (location, revision and do on) as well as preserved copies of all the files in the directory at the time of last update. Reverting a file can be done without server access. Because of the importance of the .svn folders, be careful not to modify them or the repository file/directory structure by using features of the operating system. Do NOT move a directory by OS "drag & drop" - in a versioned repository this is actually a copy of the old into the new location and a delete of the old location; changes that needs to be logged and part of a revision. All Subversion clients therefore provide functions to "Rename...", "Delete..." and "Branch/Tag..." (copy).

  8. The Merge command is like the Diff command for changes to a single file, but Diff will not handle directories or structural changes. Any renamed, moved or deleted file/directory will give an error in Diff (like "file missing"), but not by using Merge. Merge allows for reorganising a folder/file structure, and will correctly merge these changes back automatically by deleting files and renaming directories and so on to make all aspects identical.

  9. Binary data can be stored in Subversion. Subversion works at the "byte-level" of files, and handle all files (including text files) as binary data. Executables, documents, pictures and so on can also be stored - and versioned - by using Subversion. And when a change is made to a file (say a Word document), only the actual binary changes are packaged and transmitted for the new commit. The same applies to text files, so that changing 3 MB of textfiles might only result in a commit package of maybe 5k if only small changes are made to each file (updating copyright year on all source files for instance).

  10. Each commit to the repository should be documented by writing a good log entry. The log entry (free text) is the main source of information for most users reviewing or searching for changes. If merging, specify what directories at what revisions where merged; if implementing any feature, mention them in the log. If it closes a certain ticket in the ticket system, refer to the ticket number. Note: The log messages (and changeset/diff information) is available from the project page using [Browse Source], and the log message is actually formatted as Wiki Markup. The following will display with nice bullets and links to Wiki pages and tickets:
    Trunk - New features implemented:
     * Refactored database connection pool according to NewConnectionPool specification.
     * New dynamic menu system as suggested in ticket:23
    1.X_stable branch bugfixes closes tickets #22, #34, #44 and #12.

Commit to the Project Repository

Much information about how to create, update and commit to the repository is described above. However, one thing is reading about it, another thing is doing it.

If you checked out /testhere from the Sandbox project as suggested above, you can now create your own directory and put folders and files into this, commit and make changes as you want. See what happens, see what can be done and how it works. Please do test and learn, but remember a few simple guidelines:

  • Don't interfere with folders belonging to other users.
  • And, remember that all changes and information can be seen by everyone else - even if you delete them later, as previous versions can always be retrieved.

Another option is to create a new repository locally. By creating a folder like c:\svn\mysandbox you can use for instance TortoiseSVN to create a new repository on local disk; Right-click folder and chose Create Repository here... A file-system based repository will be created. This can be used just like a remote repository:

  1. Create a new folder called c:\svn\mysandbox_out.
  2. Choose SVN Checkout..., and enter file:///c:/svn/mysandbox for repository location.

Now you have a fully local setup that can be used for testing Subversion and client functionality using your own code solutions, without ever worring about information being shared.