Hi,
First, some commentary. I realized that the previous specification was
absolutely terrible and I do appreciate everyone's patience with me
(esp Philip Martin, Philipp Marek and Julian Foad). Their commentary
made me realize that all the while, I had a small monkey on my back.
Over the period, it had grown to become a little too heavy. Anyway,
I think I've gotten it off my back. This time around, it should be
a better piece of work (ok, at least it should be better than the
previous piece.) Still learning the tricks of the trade.
"Learning without thought is labor lost; thought without
learning is perilous. " - Confucious
Btw, thanks to Stefan for indirectly helping me to understand that
most of the stuff on that old functional specification wasn't called
for. Merge. What has that got to do with setting the 'mtime'? Why
did I think it had anything to do with 'mtime'. Or does it?
[Rhetorical question, really]
[Yes. There should be an attachment to this e-mail.]
Now, the log:
[[[
Added the mtime functional specification submission to the notes
directory for RFC.
* notes/mtime_specs.txt
Added
Patch by: Edmund Wong ed{_at_}kdtc.net
Suggested by: julianf
Reviewed by: Philipp Marek
Philip Martin
]]]
Index: notes/mtime_specs.txt
===================================================================
--- notes/mtime_specs.txt (revision 0)
+++ notes/mtime_specs.txt (revision 0)
@@ -0,0 +1,169 @@
+OUTLINE OF A
+
+FUNCTIONAL (BEHAVIOURAL) SPECIFICATION FOR
+
+MTIME PRESERVATION (ISSUE #1256)
+
+
+* Introduction
+
+Issue #1256 was entered into the Subversion issue tracker on 24th April
+2003 and has been opened since then. A few patches have been submitted;
+but, have not been applied to the source code due to the insufficiency of
+said patches in one way or another. In the meantime, users have made
+comments on the issue and several discussions have been put forth within
+the mailing lists; all to no conclusion.
+
+This functional specification which will be submitted for RFC on the dev
+list:
+
+ 1) To generate a practical and user-friendly resolution to the issue.
+ 2) To formulate an implementation plan to allow the developers
+ a clear-cut specification to work with.
+
+
+* Current Subversion behaviour
+
+The mtime of any file is the time when the file is checked out, updated
+or merged. Subversion does not save the mtime upon commit, so a file which
+is commited loses its mtime and when checked out, the mtime is set to the
+checkout time. This behaviour is nonconducive to users who want to keep
+track of the mtimes of each file and/or directory.
+
+There is a work-around to this issue (taken from IcePic's user response
+on IRC). Suppose we have a file called foo.txt and we wish to maintain its
+mtime attribute. We create a pre-commit script which takes the mtime (and
+other information) of foo.txt and store it in another file, say mtime.txt
+and then commit foo.txt plus mtime.txt. Then when updating or merging,
+another script grabs foo.txt and mtime.txt and then gets and saves the
+original mtime for foo.txt as retrieved from mtime.txt. This is not
+efficient and quite a tedious way of working around this issue.
+
+* High-level semantics we are trying to achieve:
+
+ - Whenever Subversion puts or modifies a file (or directory) in
+ the WC, it shall set the node's mtime in the WC to the mtime
+ recorded for that node as given by the server.
+
+ - Whenever Subversion modifies a file (or directory) in the WC, and
+ there are local changes to that node, such as when updating a file
+ that the user has been editing, it shall update the mtime property.
+
+ - Backward compatibility issues:
+
+ o If the mtime/origmtime property hasn't been set for a node
+ (most probably because it was stored in the repository
+ prior to this feature being implemented), the mtime/origtime
+ can be set to the current date of modification.
+
+* Specification of the behaviour in all the cases:
+
+Data Storage:
+
+ Mtime shall be stored in a versioned property named 'svn:mtime'.
+ Any file or directory may have this property. The format of the
+ property value is 'YYYY-MM-DDTHH:MM:SS.UUUUUU' of which the time
+ is UTC.
+
+Behaviour of Each Action:
+
+ The behaviour of each svn action that may affect a node in the
+ WC, is for x where x is a member of {file, dir}:
+
+ CT = current time
+ M(x) = mtime of x
+ R(x) = recorded mtime 'svn:mtime'
+
+ All initial values prior to the actions are set to NULL and it is
+ assumed that all the following functions are done with all the
+ necessary checking, such that as an example, after doing a
+ 'svn add', svn will complain if the user repeats the command.
+
+ - import
+ Let f_import(x) be the following process:
+ 1a) if x is already versioned, exit.
+ 1b) Otherwise, get M(x)
+ 2) Set R(x) = M(x)
+
+ o if x = file, then f_import(x).
+ o if x = dir, then recursively f_import(x)
+
+ - checkout
+ Let f_checkout(x) be the following process:
+ 1) Get R(x)
+ 2) Set M(x) = R(x)
+
+ o if x = file, then f_checkout(x).
+ o if x = dir, then recursively f_checkout(x)
+
+ - commit
+ Let f_commit(x) be the following process:
+ 1) Get M(x)
+ 2) Set R(x) = M(x)
+
+ o if x = file, then f_commit(x).
+ o if x = dir, then recursively f_commit(x)
+
+ - rename
+ [Feature not yet available. Equivalent to
+ a) svn cp x y
+ b) svn del x
+ but there should be a historical link between
+ y and x. See issue #898.]
+ i.e. svn rename x y
+ Let f_rename(x,y) be the following process:
+
+ 1) Get R(x).
+ 2) Set R(y) = R(x)
+
+
+ If the 'svn:mtime' property does not exist for a file or
+ directory, it means either it (file or directory) is not
+ versioned, or it existed in the repository and WC before
+ this feature was created. Since the original information
+ pertaining to the file/directory is lost, the options are
+ either to store the current mtime as the original mtime
+ or completely ignore the 'svn:mtime' property for this
+ file or directory. This functional specification takes
+ the tact of setting the 'svn:mtime' property to the current
+ mtime as it will give the user at least a starting point
+ to which to make their statistical/informational mtime references.
+
+* Controlling the behaviour:
+
+ Since 'svn:mtime' is a property, its behaviour can be controlled
+ with any command that deals with properties, i.e. svn pset.
+
+ For instance, the user wanting to set the 'svn:mtime' for an
+ already versioned file which has none of the 'svn:mtime' properties
+ set.
+
+ svn pset svn:mtime '11-11-2009T12:22:00.000000' foo.txt
+
+ "How does it interact with the "use-commit-times" option?"
+
+ With this option, use-commit-times will override all Subversion
+ conditions as mentioned above.
+
+* Concerns
+
+ From the desc4 of Issue #1256,
+
+ " 1) Preserving file timestamps on import and add, so when
+ the file is checked out again, the working file gets the
+ same timestamp as when it was imported/added. "
+
+ When it means 'added', the author takes the position of when
+ the file/directory is 'committed'. The rationale is as
+ follows. The question is whether the user wishes to keep the
+ mtime of the add or is the commit 'mtime' sufficient enough?
+ This stems from the fact that the scheduled 'add' datetime
+ is not the same as the actual commit datetime. A developer
+ can schedule an add and one day later, commit the actual changes.
+ Should there be another option for allowing the user to use the
+ add 'mtime' and not the commit 'mtime'? If the add 'mtime'
+ is requested, where is this information stored? It does
+ require a temporary storage. This convolutes the whole
+ issue and since only one 'mtime' was requested, it would
+ simply matters by just using the commit 'mtime'.
+
Received on 2010-02-05 03:55:58 CET