Author:halw

Date:2009-11-23T23:00:29.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@363 abb3cda0-5349-4a8f-a601-0c33ac3a8c38

documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/customizing-eiffelstudio-subversion-commands.wiki

@@ -75,5 +75,30 @@ When you execute this command you will see the confirmation prompt in EiffelStud
 If you choose to execute the command, then just press <code>return</code>. If you have second thoughts and want to cancel the command, then do so by clicking the Console tool's stop button ( [[Image:metrics-tool--debug-stop-icon|Stop command]] ).
 
 
+==Defining commands for TortoiseSVN==
+
+If you are using the TortoiseSVN GUI client for Subversion on Microsoft Windows, you may prefer to have TortoiseSVN execute the Subversion commands for you from EiffelStudio. You can do this by starting '''tortoiseproc.exe''', and providing the specifics for each command as shown in [http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-automation.html Appendix D of the TortoiseSVN documentation]. 
+
+Some common Subversion command invocations are shown with their respective command lines below:
+
+
+{| border="1"
+|- 
+| '''Subversion command'''
+| '''Command line'''
+|- 
+| revert
+| start tortoiseproc /command:revert /path:"$file_name" /notempfile
+|-
+| commit
+| start tortoiseproc /command:commit /path:"$file_name" /notempfile
+|-
+| log
+| start tortoiseproc /command:log /path:"$file_name" /notempfile
+|-
+| diff
+| start tortoiseproc /command:diff /path:"$file_name" /notempfile
+|}
+
 
 

documentation/current/method/void-safe-programming-eiffel/what-makes-certified-attachment-pattern.wiki

@@ -12,7 +12,7 @@ Certified Attachment Patterns (CAPs) were described in the section on [[Void-saf
 A simple example is the familiar test for void reference:
 <code>
             if l_x /= Void then
-                l_x.do_something
+                l_x.do_something    -- Valid for formal arguments, local variables, and stable attributes
             end
 </code>
 We know that after the explicit check to make sure <code>l_x</code> is not <code>Void</code>, that the feature application <code>l_x.do_something</code> is void-safe.
@@ -105,7 +105,7 @@ But, if <code>l_string</code> had been a target of an assignment in which the so
             if l_string /= Void then
                 l_string.append ("abc")        -- Valid
                 l_string := my_detachable_string
-                l_string.append ("xyz")        -- Invalid: my_detachable_string could be void
+                l_string.append ("xyz")        -- Invalid: my_detachable_string might have been void
                     ...
 </code>
 
@@ -119,7 +119,7 @@ We've already seen the simple test for void as a CAP:
                 ...
 
             if l_str /= Void then
-                l_str.append ("xyz")
+                l_str.append ("xyz")        -- Valid
             end
 </code>
 
@@ -129,7 +129,7 @@ Additionally, a creation instruction can serve as a CAP. After the execution of
             l_str: detachable STRING
         do
             create l_str.make_empty
-            l_str.append ("xyz")
+            l_str.append ("xyz")        -- Valid
                 ...
 </code>