subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache subversion Wiki <comm...@subversion.apache.org>
Subject [Subversion Wiki] Update of "MtimePreservation" by JulianFoad
Date Thu, 01 Mar 2012 11:56:57 GMT
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.

Mime
View raw message