Add SourceFileEdit.time field.

pkg/analysis_server/tool/spec/spec_input.html

Index: pkg/analysis_server/tool/spec/spec_input.html
diff --git a/pkg/analysis_server/tool/spec/spec_input.html b/pkg/analysis_server/tool/spec/spec_input.html
index 54c0a58782ad9429eebb25d5e70e594fe7518407..4409e3f6a2bc3709067fe7b6965ad778b9d5c857 100644
--- a/pkg/analysis_server/tool/spec/spec_input.html
+++ b/pkg/analysis_server/tool/spec/spec_input.html
@@ -2880,6 +2880,14 @@
               The file containing the code to be modified.
             </p>
           </field>
+          <field name="time">

[Brian Wilkerson, 2014/09/15 23:28:46]

I don't think this does what we need it to. I think the goal is to allow clients
to know when a file has changed since the edit was created in order to know when
it might not be safe to apply the edit. The problem is that the time stamps on
files are not monotonically increasing. Certain operations can change the time
stamp to be less than the previous value. The only safe way to test for
"changed" is to use a not-equal comparison. Therefore, I think the time stamp
included in the API needs to be the time stamp of the file at the time it was
last analyzed, not the time at which the change was created.

Also, this doesn't describe the convention we discussed of using a special value
(like -1) to indicate a file that is expected to not exist.

[scheglov, 2014/09/16 00:57:25]

Agree.

+            <ref>int</ref>
+            <p>
+              The time in milliseconds since the "Unix epoch" when this change
+              was created. The client may use it to make sure that the file was
+              not changed since then, so it is safe to apply the change.
+            </p>
+          </field>
           <field name="edits">
             <list><ref>SourceEdit</ref></list>
             <p>