setup

git-svn-id: https://svn.microneil.com/svn/ClamAid/trunk@1 8757e9ce-5a84-4d4a-bdc3-9e03c192a350

ReadMe

+20090324_M First stab at describing the structures and dev rules
+we will employ on our SVN server. I'm sure this will evolve ;-)
+
+This is the repository startup readme. When we create a new SVN
+repository on the svn.microneil.com server we populate it with
+this ReadMe file so there is something useful to check out the
+first time.
+
+This ReadMe should be replaced when the repository is populated.
+
+There probably should be a ReadMe file in the root of /trunk/
+so that folks using the repository understand what is there and
+what rules apply to the project.
+
+Projects (repositories) should be structured according to the
+following rules:
+
+** In general the root of /trunk/ for any project should be as
+empty as possible containing at most the ReadMe file and possibly
+the most current "golden version" of the project's goal. 
+
+All rules have exceptions and the exception to this rule is the
+first project type (below) - source libraries. 
+__________________________________________
+For Source Code Modules / Source Libraries:
+The /trunk/ should contain just the source code, data, ReadMe,
+and other parts that are considered part of the module. Modules
+are meant to be re-used and so they will be imported as external
+SVN references in other projects where they are consumed.
+
+We would expect to see something like:
+
+/trunk/source.h
+/trunk/source.cpp
+/trunk/ReadMe
+
+In general, source modules are imported by external reference and
+are never manipulated directly for themselves. For example, while
+developing a source library the repository for that source would be
+externally referenced by a Test module (below). The developer would
+build the test application while exercising the source library and
+making changes to that library (presumably in a branch). When they
+are satisfied that their updates are working correctly according
+to the test application they would commit the Test module project
+and the imported source module project.
+
+________________
+For Test Modules:
+Test modules are special applications that exercise other modules.
+They are also, essentially, applications so they share the application
+model. The /trunk/ should contain a sub directory that holds the
+source code specific to the test application. Other modules that are
+under testing and development are referenced as svn:external so that
+they reside under /trunk/ as additional source directories.
+
+We should expect to see something like:
+
+svn:external /Module/trunk/source.h Module
+svn:external /Module/trunk/source.cpp Module
+/trunk/Tester/source.h
+/trunk/Tester/source.cpp
+/trunk/Tester/docs/stuff-to-read
+/trunk/Tester/data/stuff-to-input
+/trunk/tester/data/stuff-to-output
+/trunk/ReadMe
+
+In the above example interpret Module to be the appropriate name for
+a source library. There can be as many of these re-usable components
+as needed. Note that they don't actually appear in the SVN server but
+since they are a property of the repository they will be checked out
+when this repository is checked out so they will appear in the local
+file system at the same level as Tester.
+
+______________________________________
+For Applications or Compiled Libraries:
+
+Similarly to Test Modules (above) the root of /trunk/ should contain
+ReadMe describing what is there and how it works. ALSO, however the
+final product of the build will be at the root of /trunk/. This will
+represent the current state-of-the-art for the application. It may be
+a .DLL file, a .o, a .a etc.
+
+Subdirectories under /trunk/ contain the source directories, test
+application sources (in the case of a binary or library type project
+such as a DLL, .o, .a, .exe or other binary).
+
+Presumably the developer would create a workspace on their local
+file system where they would then import the repository's /trunk/ and
+along with it the associated external references. Then in a different
+directory in their workspace they would build various debug and
+production versions of the final product for testing. When they were
+happy with the results then they would place the new "golden" version
+in their local copy of the repository and commit (repository, and
+externals with any changes, and new golden version).
+
+Develpers of applications or binary libraries should avoid the urge
+to make direct updates to source libraries. That work should be done
+separately where it can be well focused.
+
+________________________
+For Distribution Pakages:
+
+Distribution packages are used to build distributions that are released
+to customers. The package includes everything that is needed to build
+the final distribution (tarball, zip) and/or installer (.msi, .exe)
+file that will be delivered to customers.
+
+Distribution pakages follow a similar methodology to Applications
+except that they most likely reference specific revisions of libraries,
+projects, and documentation, and then combine that with subdirectories
+that contain package specific content such as documentation, build
+scripts, and other "glue".
+
+In the top directory we expect to find the usual ReadMe for the project
+as well as the latest golden version of the distribution.
+
+The build process and structure here is much the same as for other
+applications except that what is tested is the ability to deliver and /
+or install the application on the various target platforms with the
+desired results. The applications themselves are always built elsewehere
+in their own projects even though the repositories for those projects
+might be imported in their entirety via external references.
+
+Developers of distribution packages should avoid the urge to make
+updates to the applications or other imported content directly. That
+work should be handled seperately where it can be focused.
+
+