Changes between Version 24 and Version 25 of SVN

Timestamp:

Mar 21, 2011, 2:16:30 PM (13 years ago)

Author:

Anna Tomanek

Comment:

Text enhancement and proof-reading

SVN

@@ -6 +6 @@
 http://svn.ckeditor.com
 
-The SVN contains the "development version" of CKEditor. It doesn't reflect the contents of public distributions. Actually, some files are not present in the public downloads (like the "_dev" folder or the compressed "js" files, for example). 
+The SVN contains the '''development version''' of CKEditor. It does not reflect the contents of public distributions. Actually, some files are not present in the public downloads (like the {{{_dev}}} folder or the compressed {{{.js}}} files, for example). 
 
-'''We don't recommend using this version on production'''. There are also security implications on doing so. To make the SVN version "production safe", it must be processed with CKReleaser (available inside _dev). A safer and easier option is to simply use the Nightly Build, which is already processed.
+'''We do not recommend using this version in a production environment'''. There are also security implications in doing so. To make the SVN version "production safe", it must be processed with CKReleaser (available inside the {{{_dev}}} folder). A safer and easier option is to simply use the Nightly Build, which is already processed.
 
 == Nightly Build ==
 
-Every night, at 0:30 PST, a "'''Nightly Build'''" is generated, from the SVN version. Visit the following web site to download it:[[BR]]
+Every night, at 0:30 PST, a "'''Nightly Build'''" is generated from the SVN version. Visit the following web site to download it:[[BR]]
 http://nightly.ckeditor.com/
 
-You may also test the nightly online directly [http://nightly.ckeditor.com/demo here].
+You may also directly test the nightly build online [http://nightly.ckeditor.com/demo here].
 
-The nightly is processed for public distribution. As the fixes and features available on nightlies are still under testing and development, it may be used on production systems at your own risk.
+The nightly build is processed for public distribution. As the fixes and features available on nightlies are still under testing and development, it may be used on production systems at your own risk.
 
 == Working with SVN ==
@@ -25 +25 @@
 == Testing Old Revisions ==
 
-There are occasions during the development, when bugs are introduced by recent changes in the code. To precisely understand and find when things changed, we have created a dedicated web site with a list of all revisions available for the trunk:
+There are occasions during the development, when bugs are introduced by recent changes in the code. In order to be able to determine when things changed, we have created a dedicated website with a list of all revisions done to the trunk:
 
 http://rev.ckeditor.com/
 
-The list in the above site is quite similar to the [log:CKEditor/trunk trunk log page], with the exception that it contains and additional column called "Test". A link can be found there to open the sample pages of CKEditor, generated for each precise revision.
+The list on the above site is quite similar to the [log:CKEditor/trunk trunk log page], with the exception that it contains an additional column called "Test". A link can be found there to open the sample pages of CKEditor generated for each precise revision.
 
 == Repository Structure ==
 
 {{{
-CKEditor -----------+ Every subproject will have a directory in the root.
+CKEditor ------------+ Every subproject will have a directory in the root.
     trunk -----------+ This is the development place.
     branches
@@ -49 +49 @@
 All subprojects in the repository will present a structure similar to the above.
 
-=== The "trunk" ===
+=== The "Trunk" ===
 
-The trunk is the effective place we'll be working everyday. Usually we'll have local working copies of the trunk only (and possibly some branches).
+The '''trunk''' is the effective place we will be working with everyday. Usually we will have local working copies of the trunk only (and possibly some branches).
 
-Starting from version 2.4, the trunk will always have stable code which we can publish to the public SVN, and eventually release officially. So, only important bugs and small changes will be committed here, while more delicate and extensive developments will be done in a "branch".
+Starting from version 2.4, the trunk will always have stable code which we can publish to the public SVN, and eventually release officially. As a result, only important bugs and small changes will be committed here, while more delicate and extensive developments will be done in a "branch".
 
 === Branches ===
 
-Branches give us isolated environments for development, and once tested and confirmed a new work is ready, it can be simply merged in the trunk.
+'''Branches''' give us isolated environments for development, and once tested and confirmed a new code chunk is ready, it can simply be merged into the trunk.
 
-For code that doesn't bring instability, like trivial fixes or small features, there is no need to work on a separated branch. It can be committed directly to the trunk if you feel the code is ok and it is well tested. It makes the management easier.
+For code that does not bring instability, like trivial fixes or small features, there is no need to work in a separated branch. Such code can be committed directly to the trunk if you feel the code is OK and it is well tested. This approach makes the code management easier.
 
 The branches could be created in the following spaces:
 
- * '''branches/developers''': each developer may have a private branch under this directory. The directory name is the developer name (fredck, for example). The developer himself can decide to use it or not, and have complete freedom for it.
- * '''branches/features''': if a feature is too big and complex, a developer could decide to create a dedicated branch for it.
- * '''branches/versions''': there could be branches for future versions, waiting while previous ones are being tested and released.
+ * '''{{{branches/developers}}}''': each developer may have a private branch under this directory. The directory name is the developer name ("fredck", for example). The developer himself can decide to use it or not, and have complete freedom for it.
+ * '''{{{branches/features}}}''': if a feature is too big and complex, a developer can decide to create a dedicated branch for it.
+ * '''{{{branches/versions}}}''': there could be branches for future versions, waiting while the previous ones are being tested and released.
 
 ==== Merging Branches ====
 
-A common task during a branch development, is to '''merge changes made in the trunk to the branch''', leaving it always up to date with the trunk. Remember that merges must be done from the last revision merged, starting from the revision from which the branch has been created.
+A common task during the branch development is to '''merge changes made in the trunk to the branch''', leaving it always up to date with the trunk. Remember that merges must be done from the last revision merged, starting from the revision from which the branch was created.
 
-When '''merging branches to the trunk''', first merge the trunk to the branch and check that everything is ok. Make the necessary changes and commit the branch. Then switch to the trunk and merge the differences between the branch HEAD and the last trunk revision you have just merged to the branch (usually HEAD). Then, if the branch is not anymore needed, just delete it (SVN delete I mean).
+When '''merging branches to the trunk''', first merge the trunk to the branch and check that everything is ok. Make the necessary changes and commit the branch. Then switch to the trunk and merge the differences between the branch {{{HEAD}}} and the last trunk revision you have just merged to the branch (usually {{{HEAD}}}). Then, if the branch is not needed anymore, just delete it by using SVN delete.
 
-If you are unsure, don't be afraid of asking others to execute this task for you.
+If you are unsure about the process, do not be afraid of asking others to execute this task for you.
 
-TortoiseSVN offers a nice tool to track the creation an life-cicle of branches. It is called "Revision graph". The SVN log can also be used for it.
+TortoiseSVN offers a nice tool to track the creation and life cicle of branches. It is called "Revision graph". The SVN log can also be used for it.
 
 === Tags ===
@@ -83 +83 @@
 == Committing ==
 
-Try to make a single commit for each fix or feature. Avoid making big commits with lots of changes. This separation makes each commit an isolate thing. It makes code review and merge tasks easy.
+Try to make a single commit for each fix or feature. Avoid making big commits with lots of changes. This separation makes each commit an isolated thing. It makes code review and merge tasks easy.
 
-The commit log message is very important. Don't underestimate it. It must be well written and informative. Whenever possible, make references to related Trac items, like tickets or changesets. You may use one of the "standard" messages, like the following examples:
+The commit log message is very important. Do not underestimate it. It must be well-written and informative. Whenever possible, make references to related Trac items, like tickets or changesets. You may use one of the "standard" messages, like the following examples:
 
  * !#81: IE has a DOM bug that caused FCKDomTools.RTrimNode to break. 
@@ -96 +96 @@
 http://tortoisesvn.tigris.org/
 
-'''Subversion''': the official SVN command line. Windows binaries can be found in the download page:[[BR]]
+'''Subversion''': the official SVN command line tool. Windows binaries can be found on the download page:[[BR]]
 http://subversion.tigris.org/
 
-Book - '''Version Control with Subversion''': a good book about SVN:[[BR]]
+Book - '''Version Control with Subversion''': a recommended book about SVN:[[BR]]
 http://svnbook.red-bean.com/