You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by Apache subversion Wiki <co...@subversion.apache.org> on 2012/03/01 12:56:57 UTC

[Subversion Wiki] Update of "MtimePreservation" by JulianFoad

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.

The "MtimePreservation" page has been changed by JulianFoad:
http://wiki.apache.org/subversion/MtimePreservation?action=diff&rev1=4&rev2=5

  
  ----
  = Design: MTime Preservation =
+ {{{#!wiki note
+ [JAF] Can you add a section describing the overall rules or invariants of the behaviour?  I'm thinking particularly of the way that you've defined that 'checkout' does not add a text-time prop even where 'use-text-times' says there should be one, but rather 'commit' adds it.  Therefore it looks like there may be a general rule in this design, something like:
+ 
+  * The text-time prop is not necessarily expected to be present during the life of the node in the WC, and so (I guess) when it ''is'' present it's not necessarily expected to be up-to-date.  The svn:text-time is only relevant when the node is in the repository and at the moment of going into or coming out of the repo.
+ 
+ I'm not sure I got that rule 100% right but it looks like there is some such rule, and we should be explicit about the rules so that we can decide how each individual command should behave in all its variations to remain in agreement with the rules.
+ }}}
+ 
  Nearly every modern operating system associated a "modified time" with each file on the system, updating it whenever the file is modified. This metadata can be very important, but Subversion currently offers no way to preserve it.
  
  This design proposes two new properties:
  
   svn:text-time:: This property stores the modified time of each file or directory in UTC time using the format 'YYYY-MM-DDTHH:MM:SS.UUUUUU'. It is automatically generated by Subversion during commit. The name of this property was chosen because it is already used in an identical manner by FSVS and svntar.
   svn:use-text-times:: The user defines this property on a directory as a list of file types for which svn:text-time should be applied. Its syntax is identical to svn:ignore.
+ 
+ {{{#!wiki note
+ [JAF] Here you have two things interacting to specify whether text-time is used: the presence of svn:text-time property on the node, and the matching of svn:use-text-times on its parent dir.  They're both specified by the repository, but affect only the behaviour of a user's local copy.  By contrast, 'use-commit-times' is a user-specified option (in user config file or cmd line).
+ 
+ As we have the 'auto-props' mechanism already, I think we should rely on auto-props to add the 'svn:text-time' property to new files initially, and not invent a new way of doing that.  Auto-props could set it with an empty value, and then the rest of the behaviour would fill in a valid value some time later.
+ 
+ Then perhaps you could simplify this proposal, with the behaviour just depending on whether a svn:text-time property is present but not on svn:use-text-times.
+ 
+ Auto-props is rather limited and would really benefit from being upgraded to e.g. be settable on the parent dir, like your 'svn:use-text-times', but that's a separate issue.
+ 
+ In the cases where svn:text-time is supposed to be enabled for a given path, but the current proposal calls for the prop to be deleted in order to signal that it is not up to date at the moment, we could set it to an empty value instead.
+ }}}
  
  == Definitions ==
   mtime:: Modified time. In this specification, mtime will always refer to the modified time of a file as stored by the operating system. Under this specification, Subversion will sometimes alter the mtime to equal the value stored in svn:text-time.
@@ -19, +39 @@

  == Interaction with use-commit-times ==
  Wherever use-commit-times conflicts with this specification, use-commit-times takes precedence.  This will be defined in more detail in the following operations.
  
+ {{{#!wiki note
+ [JAF] I think an API user should be able to choose the operating mode from:
+  * mtime = text-time on paths where defined, else commit-time
+  * mtime = text-time on paths where defined, else 'now'
+  * mtime = commit time
+  * mtime = 'now'
+ This can be expressed as adding a "use text-times where defined?" option that overrides the use-commit-times option.
+ 
+ The first of these is not in your proposal.  We need not necessarily provide all those options to the user of 'svn', but we should think of the design in those terms.
+ }}}
+ 
  == Operations ==
   * Any operations not listed are presumed to be unaffected by this proposal.
   * For the sake of being succinct, 'svn:' will be elided from 'svn:text-time' and 'svn:use-text-times' in the following operations.
@@ -27, +58 @@

  
  === svn commit ===
   * If use-text-times matches and (mtime differs from text-time or text-time is undefined), text-time = mtime
+ 
+ {{{#!wiki note
+ [JAF] If use-text-times does ''not'' match and text-time is defined, then delete text-time?  I'm thinking your proposal seems to have Subversion (rather than the user directly) in control of creating and deleting the text-time prop, at least in most cases (this should be specified in the Rules section), and it would be inconsistent if it isn't deleted by Subversion in this case.
+ }}}
+ 
+ {{{#!wiki note
+ [JAF] If mtime differs from text-time and that's the only local modification, do we still commit it or should we ignore this?
+ }}}
  
  === svn checkout ===
   * If use-commit-times, mtime = ctime
@@ -46, +85 @@

   * Else, mtime = stime
  
  (Deleting text-time looks wrong, that's a property mod. Better to update BASE.text-time but not attempt to set mtime. --philip)
+ 
+ {{{#!wiki note
+ [JAF] "If local mods exist..." before or after the update?  Usually if mods exist before, then mods exist after, but not always.
+ }}}
  
  === svn merge ===
   * If no conflicts occur, behaviour is identical to svn update.