Index: source/en/tsvn_ch04.xml
===================================================================
--- source/en/tsvn_ch04.xml (revision 1563)
+++ source/en/tsvn_ch04.xml (working copy)
@@ -1551,6 +1551,85 @@
+
+ Creating and Applying Patches
+
+ patch
+
+
+
+ For open source projects (like this one) everyone has read
+ access to the repository, and anyone can make a contribution
+ to the project. So how are those contributions controlled?
+ If just anyone could commit changes, the project would be permanently
+ unstable and probably permanently broken. In this situation the
+ change is managed by submitting a patch file
+ to the development team, who do have write access.
+ They can review the patch first, and then either submit it to the
+ repository or reject it back to the author.
+
+
+ Creating a Patch File
+
+ First you need to make and test your changes.
+ Then instead of using "Commit" on the parent folder, you use
+
+ Create Patch...
+
+ This will produce a single file containing a summary of all the changes
+ you have made since the last update from the repository. If you create a
+ patch file, make some more changes and then create another patch, the
+ second patch file will include both sets of changes.
+
+
+ Just save the file using a filename of your choice.
+ Patch files can have any extension you like, but by convention they
+ should use the .patch extension.
+ You are now ready to submit your patch file.
+
+
+
+ Applying a Patch File
+
+ Patch files are applied to your working copy. This should be done
+ from the same folder level as was used to create the patch.
+ If you are not sure what this is, just look at the first line of
+ the patch file. For example, if the first file being worked on was
+ doc/source/english/chapter1.xml
+ and the first line in the patchfile is
+ Index: english/chapter1.xml
+ then you need to apply the patch to the
+ english folder.
+
+
+ In order to apply a patch file to your working copy, you need
+ to have at least read access to the repository.
+ The reason for this is that the merge program must
+ reference the changes back to the revision against
+ which they were made by the remote developer.
+
+
+ From the context menu for that folder, click on
+
+ Apply Patch...
+
+ This will bring up a file open dialog allowing you to select the
+ patch file to apply. By default only .patch
+ files are shown, but you can opt for "All files". Open the file
+ and TortoiseMerge runs to merge the changes from the patch file
+ with your working copy. A small window lists the files which have
+ been changed. Double click on each one in turn, review the changes
+ and save the merged files.
+
+
+ The remote developer's patch has now been applied to your working copy,
+ so you need to commit to allow everyone else to access the changes
+ from the repository.
+
+
+
+
+
Relocating a working copy
@@ -1698,6 +1777,10 @@
This option tells TortoiseSVN to set the filedates to the last commit time
when doing a checkout or an update. Otherwise TortoiseSVN will use
the current date.
+ If you are developing software it is generally best to use current date
+ because build systems normally look at the datestamps to decide which
+ files need compiling. If you use "last commit time" and revert to an
+ older file revision, your project may not compile as you expect it to.