Benefits

Using the trunk, branches, and tags structure on the SVN repository at IgorExchange has three benefits. It provides well-defined places

• to store working copies of project files and to create snapshots or releases of a project
• for users to obtain specific versions of your project
• for the IgorExchange server to automatically manage the administration of your project

Let us look at the repository from three perspectives: one as a developer, one as a user, and one as the computer server. To keep the discussion simple, only the most useful options are presented.

-- trunk

Developer
A developer can

• store and access working copies of files here (via SVN operations from his local computer)
• manually generate official releases (as tags) originating from here (via the IgorExchange Web site)
• manually start new developments (as branches) originating from here (via the IgorExchange Web site)

User
A project user has no access to any files in this directory.

Computer
The IgorExchange SVN server reads and documents any changes that are made to the files in the trunk. It updates the SVN files associated with the project to reflect those changes. It changes NOTHING on the actual project files in here.

-- branches

Developer
A developer can

• store and access working copies of files here (via SVN operations from his local computer)
• manually generate official releases (as tags) originating from here (via the IgorExchange Web site)
• manually initiate development snapshots (as branches) to originate from here or from the trunk (via the IgorExchange Web site)

User
A project user may have access to certain files here. Specifically, any branch folder that has been designated as a development snapshot can subsequently be made available for a user to download.

Computer
The IgorExchange SVN server reads and documents any changes that are made to the files in the various branches. It updates the SVN files associated with the project to reflect those changes.

The SVN server also automatically creates a ZIP archive of any branch that is designated as a development snapshot.

Finally, the SVN server automatically updates all project files in all development snapshots. The updates are taken from the original source of the snapshot, either the trunk or a certain branch folder.

-- tags

Developer
A developer can only initiate official releases to originate from here (via the IgorExchange Web site). He or she cannot make changes to the files in this directory.

User
A project user may have access to certain files here. Specifically, any tag folder that has been designated as an official release can subsequently be made available for a user to download.

Computer
The SVN server automatically creates a ZIP archive of any tag that is designated as an official release.

Development Strategies

Based on the above list of benefits, three methods of project development should be considered with regard to the use of the SVN repository and its directory structure. You are welcomed to choose whichever of these methods best suits your needs. The first is recommended for beginners with SVN. The second and third methods are for increasingly more seasoned users of SVN. Alternative methods to those below are certainly available for folks who can do the equivalent SVN work of skiing on the double black diamond trials :-).

Method 1: Generate ONLY Official Releases
This method is recommended for projects where the number of files are few and/or changes to the files are made infrequently. In this method, you decide to make no snapshot releases. Instead, whenever a project file is changed, you generate a new official release.

When you develop a project in this mode, you ONLY makes changes to files in the trunk. From your local computer, your working copy should always point to the repository trunk.

Every time you want to create a new release, you do so as an official release. All official releases are generated (manually) from files in the trunk and are stored in the appropriate folder in the tags directory. You NEVER create development snapshots, so you NEVER have any need to create folders in the branches directory.

Method 2: Also Generate One Ongoing Development Snapshot
This method presumes that your project development is somewhat linear, meaning that every step you take creates an improved version of the project designed to replace the prior version(s). In essence, you want to release the project officially at certain stages, but you also want to give your users the advantages of access to improvements that you make along the way.

In this mode, you still develop your project ONLY in the trunk. From your local computer, your working copy should always point to the repository trunk.

You also create ONE branch folder for your project. The branch folder originates from the trunk and is subsequently designated as a development snapshot. By doing this, you essentially mirror all files in the trunk to the given branch folder. Every time you make an update to the files in the trunk, they will automatically be updated in the branch folder. Every night, the computer will update the files and create a new ZIP archive (development snapshot) for your users to download.

When you want to create an official release, you do so in an appropriate folder in the tags directory from files originating in the trunk.

Method 3: Also Generate Variations to the Main Project
This method is best used when you know that your project development will take various routes, perhaps going off on tangents or perhaps spawning other ideas. Here, you want to release the project officially at certain stages and you want room to explore options that may or may not be successful in the project development. Alternatively, you may want to significantly change an existing version of a project, essentially creating a new version of it.

In this mode, you are still best to start the development of your project in the trunk. From your local computer, your working copy should initially point to the repository trunk.

Every time you have a desire to explore options on your project, you can create a new branch using files that originate from the trunk. Immediately when you do this, you could also create a development snapshot originating FROM THAT BRANCH (not from the trunk). You are then free to work on files in the branch (ie, reassign your working copy to it) or in the trunk. The development snapshot that originated from the branch will always be updated automatically from the files in the branch. Your users would always see the latest issues of your ongoing branch development. You can choose to release files from the trunk or from a branch. Finally, you can merge files from a branch back into the trunk to create the enhanced version of the project.