From 53b947df484159f5934898ba6c0aa69a9c869007 Mon Sep 17 00:00:00 2001 From: Ido Hadanny Date: Thu, 22 Sep 2011 21:30:13 +0300 Subject: added stuff --- roombacomm-client/docs/SVN_Info.html | 176 +++++++++++++++++++++++++++++++++++ 1 file changed, 176 insertions(+) create mode 100644 roombacomm-client/docs/SVN_Info.html (limited to 'roombacomm-client/docs/SVN_Info.html') diff --git a/roombacomm-client/docs/SVN_Info.html b/roombacomm-client/docs/SVN_Info.html new file mode 100644 index 0000000..02c270c --- /dev/null +++ b/roombacomm-client/docs/SVN_Info.html @@ -0,0 +1,176 @@ + + + + + SVN_Info + + + +

Getting started (for the Subversion unaware):

+ +

The O'Reilly Media book +(free on line, but you can buy it too)
+Good parts to read first: (What +Is Subversion?, Fundamental +Concepts )
+

+ +

A few SVN quotes:

+ +

+ref: +svnbook.red-bean.com, Chapter 4. Branching and Merging +

+ +
+For projects that have a large number of contributors, it's common for +most people to have working copies of the trunk. Whenever someone needs +to make a long-running change that is likely to disrupt the trunk, a +standard procedure is to create a private branch and commit changes +there until all the work is complete.
+
+ +

ref: +What is a branch?

+ +
This is the basic concept of a branch-namely, +a line of development that exists independently of another line, yet +still shares a common history if you look far enough back in time. A +branch always begins life as a copy of something, and moves on from +there, generating its own history (see Figure 4.1, Branches +of development).
+ +

ref: +What's the point of a branch?

+ +
You should +remember two important lessons from this section. First, Subversion has +no internal concept of a branch-it knows only how to make copies. When +you copy a directory, the resultant directory is only a "branch" +because you attach that meaning +to it. You may think of the directory differently, or treat it +differently, but to Subversion it's just an ordinary directory that +happens to carry some extra historical information.
+
+Second, because of this copy mechanism, Subversion's branches exist as normal filesystem directories in the +repository. This is different from other version control systems, where +branches are typically defined by adding extra-dimensional "labels" to collections of files. The location +of your branch directory doesn't matter to Subversion. Most teams +follow a convention of putting all branches into a /branches directory, but you're free to invent +any policy you wish.
+
+ +

A few words about this project's tree managment approach:

+ +The structure will be as follows:
+ +/roombacomm
+ +  ../trunk
+ +     This is where the bleading edge development +and believed to be fully working code for this project can be found. +The structure should be +usable as an SVN checkout  for the project source tree. In general +the idea is that /trunk will be usable at all times. More deatils about +the structure of the project in a seperate document.
+ +
+ +  ../branches
+ +     These branches are planed to be of one of two +types: experemental or releases.
+ +    Experemental branches:
+ +     This is where long running development efforts +will take place for the project. Each branch should follow the projects +naming +convention based on the type of branch. (See "SVN policies of this +project" for details) In general, these branches should be considered +"under development" or "experimental" and under the control of a +developer. When the branch reaches a stability point, where the code +implmentes the changes that are desired for the branch, has implemented +any now needed testing code, and the code still passes all tests for +the project then the branch is +ready to be merged back into the trunk.
+ +    Release branches are points of code development +where it has been tested, prepaired, and packaged as a step forward for +the project.
+ +
+ +

SVN policies of this project:

+ +
    + +
  1. all svn commits should have comments/log entries. (prefereably +identifying each file that was altered and in laymen terms what was +changed in that file)
    2. +
  2. the keyword Id should be included in a comment in every file (do +not forget to set the svn:keywords property on the file too.)
    3. +
  3. /branches/release-N.N.N will be official releases of the project
    4. +
  4. experemental branches are encouraged when any or all of the following +is true: + + + + + + + + + + + + +
    the +development effort will +take more than one commit to achieve
    the change is +likely to +break any backwards compatibility in +the current/previous release
    automated +testing failed, +or the changes are not yet covered by +automated testing
    +
    5. +
  5. code in compiled form should not be in SVN unless it is at +least one of the following: + + + + + + + + + +
    an outside +library that is +included for simplicity/compatibility (best done with a Vendor +Branch)
    it is in a +packaged release for the +project
    +
    6. +
  6. All new features developed must include automated testing code to +validate the function.The tests should be constructed in accordance with the format and approach that +the project is using for automated testing.
    +
    7. +
+ +

More general SVN references:

+ + + +


+

+ + \ No newline at end of file -- cgit v1.3.1