Ви не можете вибрати більше 25 тем Теми мають розпочинатися з літери або цифри, можуть містити дефіси (-) і не повинні перевищувати 35 символів.

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127
  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 (DEV-) 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 Module
  47. /trunk/Tester/source.h
  48. /trunk/Tester/source.cpp
  49. /trunk/Tester/docs/stuff-to-read
  50. /trunk/Tester/data/stuff-to-input
  51. /trunk/tester/data/stuff-to-output
  52. /trunk/ReadMe
  53. In the above example interpret Module to be the appropriate name for
  54. a source library. There can be as many of these re-usable components
  55. as needed. Note that they don't actually appear in the SVN server but
  56. since they are a property of the repository they will be checked out
  57. when this repository is checked out so they will appear in the local
  58. file system at the same level as Tester.
  59. ______________________________________
  60. For Applications or Compiled Libraries:
  61. Similarly to Test Modules (above) the root of /trunk/ should contain
  62. ReadMe describing what is there and how it works. ALSO, however the
  63. final product of the build will be at the root of /trunk/. This will
  64. represent the current state-of-the-art for the application. It may be
  65. a .DLL file, a .o, a .a etc.
  66. Subdirectories under /trunk/ contain the source directories, test
  67. application sources (in the case of a binary or library type project
  68. such as a DLL, .o, .a, .exe or other binary).
  69. Presumably the developer would create a workspace on their local
  70. file system where they would then import the repository's /trunk/ and
  71. along with it the associated external references. Then in a different
  72. directory in their workspace they would build various debug and
  73. production versions of the final product for testing. When they were
  74. happy with the results then they would place the new "golden" version
  75. in their local copy of the repository and commit (repository, and
  76. externals with any changes, and new golden version).
  77. Develpers of applications or binary libraries should avoid the urge
  78. to make direct updates to source libraries. That work should be done
  79. separately where it can be well focused.
  80. ________________________________
  81. For Distribution (PKG-) Pakages:
  82. Distribution packages are used to build distributions that are released
  83. to customers. The package includes everything that is needed to build
  84. the final distribution (tarball, zip) and/or installer (.msi, .exe)
  85. file that will be delivered to customers.
  86. Distribution pakages follow a similar methodology to Applications
  87. except that they most likely reference specific revisions of libraries,
  88. projects, and documentation, and then combine that with subdirectories
  89. that contain package specific content such as documentation, build
  90. scripts, and other "glue".
  91. In the top directory we expect to find the usual ReadMe for the project
  92. as well as the latest golden version of the distribution.
  93. The build process and structure here is much the same as for other
  94. applications except that what is tested is the ability to deliver and /
  95. or install the application on the various target platforms with the
  96. desired results. The applications themselves are always built elsewehere
  97. in their own projects even though the repositories for those projects
  98. might be imported in their entirety via external references.
  99. Developers of distribution packages should avoid the urge to make
  100. updates to the applications or other imported content directly. That
  101. work should be handled seperately where it can be focused.