home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 14 Text / 14-Text.zip / srcsafe.zip / QA_TIM.ZIP / QA_TIME.TXT < prev   
Text File  |  1993-11-15  |  5KB  |  105 lines
  1. SourceSafe Q & A: The File Modification Date
  2.  
  3. ** SourceSafe Question **
  4.  
  5. I'm confused by the modification date/time that SourceSafe gives my files when
  6. it retrieves them to a local directory.  How does it work, and why?
  7.  
  8. ** What Modification Date/Time SourceSafe Gives Your Files **
  9.  
  10. When you Get a file (or Checkout a file, or in any other way copy a file from
  11. SourceSafe's database to your local directory), SourceSafe uses the following
  12. rules to determine the date/time it gives your file.
  13.  
  14. 1. If you already have a local copy of the file; and if that file is identical
  15. to the file you are getting; SourceSafe does nothing.  In that case, the file's
  16. timestamp remains unchanged.
  17.  
  18. 2. If SourceSafe does have to get the file, it gives it the current date/time;
  19. that is, when the Get is performed.
  20.  
  21. The latter case may occur if you do not have the file in your current
  22. directory; or, if your copy or the file is different from what you are getting.
  23.  The key point here is that whenever SourceSafe actually has to copy the file
  24. to your directory, the file's date of last modification is set to right now. 
  25. This may not be what you would expect at first, and it is worth saying a few
  26. words about why the system works this way.
  27.  
  28. ** Why SourceSafe Works This Way **
  29.  
  30. The modification date/time is used by many compilers and make systems as a
  31. signal of whether a file has changed, and therefore needs to be remade. 
  32. SourceSafe's use of the date/time is designed to optimize this process,
  33. ensuring that you will compile when you need to, and not when you don't.
  34.  
  35. Consider the following example.  A C programmer has the file HELP.C in
  36. SourceSafe, and in his local directory.  His compiler will turn this code file
  37. into the object module HELP.OBJ.  At any given time during the development
  38. cycle, both files--HELP.C and HELP.OBJ--probably exist in the same directory. 
  39. Each time the developer types MAKE, his Make utility compares the date/time
  40. stamp of HELP.C with HELP.OBJ to determine if it should compile, using the
  41. following rules.
  42.  
  43. 1. If HELP.C is more recent than HELP.OBJ, the code has changed, and a
  44. recompile is necessary.
  45.  
  46. 2. If HELP.OBJ is more recent than HELP.C, the code has already been compiled,
  47. and no recompile is necessary.
  48.  
  49. This behavior is simple, logical, and relatively universal; it ensures that
  50. every Make builds the entire program, from the most recent version of the code,
  51. as quickly as possible.
  52.  
  53. Now consider the ramifications for SourceSafe.  You compile HELP.C into
  54. HELP.OBJ, giving the latter a new date/time.  If you Make again without
  55. changing anything, HELP.C will not be recompiled.  Satisfied with your changes,
  56. you Update HELP.C into SourceSafe; and the next morning, you Get HELP.C again.
  57.  
  58. If HELP.C has not changed, SourceSafe recognizes that its own copy and yours
  59. are identical.  It does not do a Get, the file date/time does not change, and
  60. the file is not recompiled--which is as it should be.
  61.  
  62. If another developer has changed HELP.C, SourceSafe recognizes that the file is
  63. different.  It does get HELP.C, and makes its date/time now.  When you make,
  64. the file is recompiled--which, again, is as it should be.  Hence, whether
  65. someone has changed the file or not, SourceSafe's behavior sends the correct
  66. signal to the Make utility.
  67.  
  68. To take one final example: suppose that you now Get an old version of HELP.C. 
  69. If SourceSafe did what you might expect, and gave the .C file its old
  70. date/time, the file would not recompile, since the .C file would be older than
  71. the .OBJ.  In this case, you might wonder why your program was not doing what
  72. it used to--when in fact, the reason is that you are still using an object
  73. module from a previous compilation!  However, this is not what happens. 
  74. Instead, SourceSafe recognizes that what you are getting (the old version) is
  75. different from what you have (the most recent), and gets the file, giving it
  76. the current date/time.  This forces a recompile, thus ensuring that the program
  77. you build is in line with the code you got.
  78.  
  79. ** Changing SourceSafe's Use of the Date/Time Stamp **
  80.  
  81. The behavior described above is SourceSafe's default behavior; however, like
  82. most assumptions made by SourceSafe, this can be changed if your needs are
  83. different.  There are two ways to modify SourceSafe's use of the file
  84. modification time.
  85.  
  86. The first is through the SS.INI variable Restore_ModTime.  If the following
  87. line is placed in your SS.INI file, SourceSafe will always give files the
  88. date/time of their actual last modification, instead of the current date/time.
  89.  
  90. Restore_ModTime = Yes
  91.  
  92. As with all INI variables, this can be set per-user in SS.INI or globally in
  93. SYSTEM.INI; and it can be set project-by-project or generally.  See the
  94. description of SS.INI in the SourceSafe User's Manual or On-Line Help for more
  95. details.
  96.  
  97. The other option, available from the SourceSafe command-line only, is to change
  98. SourceSafe's use of the file timestamp for an individual command.  This is done
  99. via the -GM parameter.  If you use the -GM parameter with a command such as Get
  100. or Checkout, the file will be given the timestamp of its actual last
  101. modification.  If you have Restore_Modtime set to Yes by default, you can use
  102. the -GM- parameter to override it for an individual command and give the files
  103. the current date/time.
  104.  
  105.