You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128
  1. 20090324_M First stab at describing the structures and dev rules
  2. we will employ on our SVN server. I'm sure this will evolve ;-)
  3. This is the repository startup readme. When we create a new SVN
  4. repository on the svn.microneil.com server we populate it with
  5. this ReadMe file so there is something useful to check out the
  6. first time.
  7. This ReadMe should be replaced when the repository is populated.
  8. There probably should be a ReadMe file in the root of /trunk/
  9. so that folks using the repository understand what is there and
  10. what rules apply to the project.
  11. Projects (repositories) should be structured according to the
  12. following rules:
  13. ** In general the root of /trunk/ for any project should be as
  14. empty as possible containing at most the ReadMe file and possibly
  15. the most current "golden version" of the project's goal.
  16. All rules have exceptions and the exception to this rule is the
  17. first project type (below) - source libraries.
  18. __________________________________________
  19. For Source Code Modules / Source Libraries:
  20. The /trunk/ should contain just the source code, data, ReadMe,
  21. and other parts that are considered part of the module. Modules
  22. are meant to be re-used and so they will be imported as external
  23. SVN references in other projects where they are consumed.
  24. We would expect to see something like:
  25. /trunk/source.h
  26. /trunk/source.cpp
  27. /trunk/ReadMe
  28. In general, source modules are imported by external reference and
  29. are never manipulated directly for themselves. For example, while
  30. developing a source library the repository for that source would be
  31. externally referenced by a Test module (below). The developer would
  32. build the test application while exercising the source library and
  33. making changes to that library (presumably in a branch). When they
  34. are satisfied that their updates are working correctly according
  35. to the test application they would commit the Test module project
  36. and the imported source module project.
  37. ________________
  38. For Test Modules:
  39. Test modules are special applications that exercise other modules.
  40. They are also, essentially, applications so they share the application
  41. model. The /trunk/ should contain a sub directory that holds the
  42. source code specific to the test application. Other modules that are
  43. under testing and development are referenced as svn:external so that
  44. they reside under /trunk/ as additional source directories.
  45. We should expect to see something like:
  46. svn:external /Module/trunk/source.h Module
  47. svn:external /Module/trunk/source.cpp Module
  48. /trunk/Tester/source.h
  49. /trunk/Tester/source.cpp
  50. /trunk/Tester/docs/stuff-to-read
  51. /trunk/Tester/data/stuff-to-input
  52. /trunk/tester/data/stuff-to-output
  53. /trunk/ReadMe
  54. In the above example interpret Module to be the appropriate name for
  55. a source library. There can be as many of these re-usable components
  56. as needed. Note that they don't actually appear in the SVN server but
  57. since they are a property of the repository they will be checked out
  58. when this repository is checked out so they will appear in the local
  59. file system at the same level as Tester.
  60. ______________________________________
  61. For Applications or Compiled Libraries:
  62. Similarly to Test Modules (above) the root of /trunk/ should contain
  63. ReadMe describing what is there and how it works. ALSO, however the
  64. final product of the build will be at the root of /trunk/. This will
  65. represent the current state-of-the-art for the application. It may be
  66. a .DLL file, a .o, a .a etc.
  67. Subdirectories under /trunk/ contain the source directories, test
  68. application sources (in the case of a binary or library type project
  69. such as a DLL, .o, .a, .exe or other binary).
  70. Presumably the developer would create a workspace on their local
  71. file system where they would then import the repository's /trunk/ and
  72. along with it the associated external references. Then in a different
  73. directory in their workspace they would build various debug and
  74. production versions of the final product for testing. When they were
  75. happy with the results then they would place the new "golden" version
  76. in their local copy of the repository and commit (repository, and
  77. externals with any changes, and new golden version).
  78. Develpers of applications or binary libraries should avoid the urge
  79. to make direct updates to source libraries. That work should be done
  80. separately where it can be well focused.
  81. ________________________
  82. For Distribution Pakages:
  83. Distribution packages are used to build distributions that are released
  84. to customers. The package includes everything that is needed to build
  85. the final distribution (tarball, zip) and/or installer (.msi, .exe)
  86. file that will be delivered to customers.
  87. Distribution pakages follow a similar methodology to Applications
  88. except that they most likely reference specific revisions of libraries,
  89. projects, and documentation, and then combine that with subdirectories
  90. that contain package specific content such as documentation, build
  91. scripts, and other "glue".
  92. In the top directory we expect to find the usual ReadMe for the project
  93. as well as the latest golden version of the distribution.
  94. The build process and structure here is much the same as for other
  95. applications except that what is tested is the ability to deliver and /
  96. or install the application on the various target platforms with the
  97. desired results. The applications themselves are always built elsewehere
  98. in their own projects even though the repositories for those projects
  99. might be imported in their entirety via external references.
  100. Developers of distribution packages should avoid the urge to make
  101. updates to the applications or other imported content directly. That
  102. work should be handled seperately where it can be focused.