Changes between Version 8 and Version 9 of TracDev/DevelopmentWorkflow

Timestamp:

Mar 2, 2016, 5:52:35 AM (8 years ago)

Author:

Ryan J Ollos

Comment:

Minor reword.

TracDev/DevelopmentWorkflow

@@ -58 +58 @@
 If the changes were staged in a Git or Hg repository, some additional steps are needed to commit the changes to Subversion. The steps will be described for a Git repository, but will be similar for an Hg repository.
 
-You should first interactively rebase (`git rebase -i`) your changes to get them in a form that is appropriate for committing to the Subversion repository. In doing so, consider how you'd like the changes to be represented in the repository history, taking into account that we frequently interrogate the repository history to discover the cause of regressions or understand the purpose and intent of code. For example, logically related changesets may be squashed if they were staged as multiple changesets to ease the process of codereview. However, unrelated changes and refactorings should be pushed as separate changesets, so they don't obfuscate other changesets.
+You should first interactively rebase (`git rebase -i`) your changes to get them in a form that is appropriate for committing to the Subversion repository. In doing so, consider how you'd like the changes to be represented in the repository history, taking into account that we frequently interrogate the repository history to discover the cause of regressions or understand the purpose and intent of code. For example, logically related changesets may be squashed if they were staged as multiple changesets for the purpose of easing code review. However, unrelated changes and refactorings should be pushed as separate changesets so that they don't obfuscate functional changes.
 
-Next, reword your log messages in a form that is appropriate for committing to the Subversion repository, prefixing each log message with the target version (e.g. `1.0.10dev:`), and referencing the appropriate ticket(s). See the [/log log] for examples.
+Next, reword your log messages in a form that is appropriate for the central repository: prefix each log message with the target version (e.g. `1.0.10dev:`) and reference the appropriate ticket(s). See the [/log log] for examples.
 
 Once you've interactively rebased your Git branch and prepared your log messages, the process to push changes to Subversion is:
+* Rebase your staging branch against the HEAD of the branch you'll be committing to
 * Checkout an svn working copy of the branch you'll be committing to
-* Rebase your staging branch against the HEAD of the branch you'll be committing to
 * Copy the svn metadata directory (`.svn`) of the working copy into the root of your git repository
-* Step through checkouts of your repository changesets and push each of them into Subversion
+* Step through checkouts of your repository changesets and commit each of them to svn
 
 Here are the same steps described in command line form: