Jump to: navigation, search

Migration to SVN

Revision as of 12:11, 17 September 2007 by Askehill.iona.com (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Introduction

Work in Progress This page outlines a proposal to migrate the STP code from its current CVS repository over to a Subversion (SVN) repository. We'll first look at the reasons why this is being considered. Following this will be an outline of the impact on components using STP source, the build system, and finally a proposal as to how the directory structure will appear in the new repository.

Why Migrate

There are pro's and con's with either version control system, this wiki page wont spend too long discussing the topic. A number of references are included below

"Interesting Devx article comparing CVS and SVN" "Redhat.com article on CVS SVN" "Online SVN Handbook"

From experience gained with both CVS and SVN, SVN's ability to version control directories & better management of branches / tags / copying resources it is a much better system to work with. The migration to SVN is fairly straightforward for CVS developers as most of the concepts and commands are the same.


Impact on STP Developers

Impact on components dependent on STP source

Any project that uses STP source code as a basis for their tooling development will be impacted by this change. If they rely on published builds this will not impact them.

Impact on the build system

The build system will be heavily impacted by this migration. The basis of our build system is documented at STP_Build_101 but the key highltight here is the dependency of the map files to go to a CVS repository and checkout the version of the code that is required to be built. All these map files will need to be updated to point to the location of the new SVN repository. However, once the checkout operation is done, the rest of the work of the build system is largely unaffected.

Impact on the directory structure