SeCSE’s Sourceforge subversion structure

Version 0.5

History

Version / Date / Author / Comments
0.3 / 10/05/2007 / Marcel (EMIC) / Initial
0.4 / 11/05/2007 / Marcel (EMIC) / Naming conventions and bins folder added
0.5 / 14/05/2007 / Marcel(EMIC) / licenses.txt added
0.6 / 29/10/2008 / Marcel(EMIC) / Adapted to OSOR

Introduction

There are 3 reasons why the usage of Subversion ( will be beneficial:

  1. Subversion supports directory renames, whereas CVS doesn't
  2. Subversion offers fast branching and tagging
  3. Subversion is being actively developed and enhanced, whereas CVS isn't.

However, when it comes to branching and tagging, Subversion and CVS and very different. The Subversion approach is far simpler conceptually. For a start, there is no difference between a branch and a tag. Both are simply a snapshot of a tree at a given point in time, and it is possible to then start committing changes to that copy (if you intend to commit changes then you would think of it as a branch, otherwise you would think of it as a tag, but Subversion makes no such distinction).

When you branch/tag in Subversion, a complete copy of the tree is made, but Subversion is clever enough to do this virtually on the server so the operation is immediate and uses very little extra disk space i.e. it does not actually make a full copy of the tree. This is very appealing, as we like to tag every single build of our software that goes to a customer or prospect.

The main problem for most users moving to subversion is deciding how to structure the repository to handle this approach to branches and tags. In CVS, branches and tags don't affect the repository structure - multiple branches and tags can co-exist in the same structure but in a different dimension. In Subversion, each branch and tag is a complete directory.

Subversion structure

The documentation suggests that at the root of the repository there should be 3 directories:

  • Trunk/
  • Branches/
  • Tags/

The idea is that development pretty much always happens on the "Trunk" copy of the code, and where required, branches can be created in the "Branches" directory and so on.

SeCSE uses the following scheme for its branches and tags:

  • /Branches/: contains all official branches, where people still develop stuff. Generally, those branches happen after a release, so that backporting of bugfixes from /trunk doesn't bring untested code.
  • /Tags/: You can use it for internal tags.
  • /Releases/: contains all official releases. That is, when you make a public release and you want to mark the revision in which it happened, you create a tag here.

We will add some other directories which should contain the binary distributions of the modules in order to avoid the need to compile and produce an executable installation infrastructure and a doc folder to put some general documents (like this one).

  • /Bins/: Please put the packages for download here!In the bins folder is for each module (SDE, ASD, ESD …) a sub folder which contains all binary releases as zip files.
  • /doc/: All general documents, like the license file, the license schema or this document.

Naming Conventions

In Bins/, Branches/ and Tags/, the naming convention is like this:

  • /Releases/<modulename>-<branchversion (example: /Branches/ESD-3.4)
  • /Tags/<modulename>-<releaseversion>-<smallcomment> (example: /tags/ESD-3.3.2-bugfix)
  • /Bins/<modulename>/<modulename>-<releaseversion>-<small comment>_bin.zip (example: /tags/ESD3.3.2-bugfix_bin.zip)

Branch and release versions should have the following format:

  • <majorrelease.<minorrelease.<patchrelease (example: 1.2.3)

Module-Structure

Each of our modules (SST, ESD …) has a separate module-folder under the trunk folder. The module-folder should be structure as follows:

Readme.txt
VersionInfo.txt
build.xml/ pom.xml/ etc.
licenses.txt
docs/
lib/
etc/
src/ / Covers important information about requirements etc.
Overview of the last versions, bugfixes, and new features
[Optional] if possible provide a build.xml or other to be used with ANT/ Maven etc.
This file covers all information about used 3rd party and used OSS licenses
for all docs, like user guide, installation …
third parts libraries
for configuration files
source tree starts here

This is the minimum structure. It is up to the owner to add folders or files if needed!

Repository structure example

+ Root

|--+ Trunk

|-- this document!

|--+SST

|-- Readme.txt

|-- VersionInfo.txt

|-- licenses.txt

|-- build.xml

|--+ docs

|--+ libs

|--+ etc

|--+ src

|--+ESD

|-- Readme.txt

|-- VersionInfo.txt

|-- licenses.txt

|-- build.xml

|--+ docs

|--+ libs

|--+ etc

|--+ src

|--+ Registry

|-- Readme.txt

|-- VersionInfo.txt

|-- licenses.txt

|-- build.xml

|--+ docs

|--+ libs

|--+ etc

|--+ src

|--+ …

|-- Readme.txt

|-- VersionInfo.txt

|-- licenses.txt

|-- build.xml

|--+ docs

|--+ libs

|--+ etc

|--+ src

|--+ Releases

|-- Registry-2.3

|-- Registry-2.4

|-- ASD-1.0

|--+ Tags

|-- SDE-0.4

|-- SDE-0.4.1

|-- Registry-2.4-b101

|-- Registry-2.4-b102

|-- Registry-2.4-patch-customer-xyz

|--+ Bins

|--+SDE

|-- SDE-0.4_bin.zip

|-- SDE-0.4.1_bin.zip

|--+Registry

|-- Registry-2.4-b101_bin.zip

|-- Registry-2.4-b102_bin.zip

|-- Registry-2.4-patch-customer-xyz_bin.zip

Access to SeCSE’s subversion on OSOR

Subversion Server:

Path to Repository:

/svn/secse

Username: Your OSOR username for SVN write operations, none will be requested otherwise.

Password: Your OSOR user password for write operations none will be requested otherwise.

SVN Limitations[1]

Case Sensitivity in File and Directory Names: The SVN server stores files in a way that is case sensitive. That is, a file with the name 'FILE' is distinctly separate from a file with the name 'File'. Developers who have a potential audience using Operating Systems that are case-insensitive should be aware of this, and select case-insensitive filenames. The case insensitive hook script may be useful to check for this.

Speed: While we are taking all efforts to ensure our infrastructure is configured optimally, SVN is not as fast as CVS. This difference shouldn't affect most users doing normal daily operations in any meaningful way.

File and Directory Removal: Files and directories cannot be removed in their entirety from a SVN repository. This limitation is documented in Version Control with Subversion. To remove a file from a SourceForge.net Subversion repository, one would have to:

  • Get a copy of their repository backup
  • Create a SVN dump file from the repository backup
  • Filter out the undesirable data
  • Import the resulting SVN dump file back into the project's SVN repository, replacing its existing content.

File Naming Limitations: File and directory names should not contain spaces; not all platforms handle spaces well. Commonly-reserved filenames should also be avoided. Some reserved filenames follow (treat all as if they are case insensitive, don't use them with a different case):

  • Windows: con, aux, com, com1 - com9, prn, lpt1 - lpt3, nul, a: - z:, clock$, _svn
  • All: .svn

Subversion clients

The following list is a sub-list taken from :

  • For Windows user I recommend TortoiseSVN!
  • For Eclipse user I recommend Subclipse!
  • AnkhSVN - A Subversion addin for Microsoft Visual Studio .NET
  • KDESvn - A Subversion client for KDE
  • KSvn - A Subversion client for KDE -- a plugin for Konqueror
  • Netbeans - Sun's open source Java integrated development environment. Includes a Subversion integration module.
  • SCPlugin - Subversion integration for Mac OS X Finder
  • Subclipse - A Subversion Eclipse Plugin
  • TortoiseSVN - A Subversion client, implemented as a windows shell extension

[1] Taken from