Hi Philip,
Sorry for the long delay in response. Year end issues and
problems prevented me from making a decent response to your
post.
Philip Martin wrote:
Edmund <edm...@belfordhk.com> writes:
+* 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. It also saves
+ the mtime to a different 'read-only' property, say 'svn:origmtime'.
+ Furthermore, to allow users to keep track of file/directory
+ information, a few other -mtime properties can be included:
+
+ * 'svn:addmtime' for Add
+ * 'svn:commtime' for Commit
+ * 'svn:impmtime' for Import
Those names are horrible; if we were to adopt this we should use names
like svn:commit-time.
Minor aesthetic change, but one I do agree. One concern I also
had was "am I complicating matters more by introducing so many
different mtimes?"
Attempting to make properties read-only on the client is going to be
tricky, because you can't control all the clients. If some other
client changes svn:origmtime are you really going to ignore that
change? If you use a client that does this it means that checking out
rN and updating to rN+1 might not be the same as checking out rN+1.
A read-only property is likely to need server-side support.
This is one of the major concerns I had. It would be nice; but,
I really hoped that the clients would abide by rules or restrictions
as dictated by the library. Of course, one can't be sure a
client would do such a thing.
The question I had was would it be a 'valid' restriction?
So filesystems that support sub-second timestamps are not supported?
A standard Ubuntu 9.10 installation uses ext4 with sub-second
timestamps.
I understand that, but Windows (afaik) can't seem to handle
sub-seconds and it was my understanding that using a common
denominator would be, for lack of a better word, better.
Having the mtime's sub-second information set to 000
was my intention (it's a far better compromise than not
having the mtime stored at all).
(I'm getting a feeling here that someone will say, "Obviously,
you don't know what you're talking about. Clearly I can
obtain the sub-seconds from a Windows system using this
method."") My response: I admit. My knowledge at getting the
sub-second on a Windows system is lacking and would appreciate
further clarification/education in this matter.
+ - checkout
+ Let f_checkout(x) be the following process:
+ 1) Get current time, CT
+ 2) Is S(x) == NULL,
+ Yes: 'svn:*mtime' properties were not set
+ for x; therefore,
+ 1.1) set S(x) = CT
You plan to store property modifications during checkout? Do those
modifications show up in 'svn st'? Can they be committed?
I'm now unsure whether that was a correct decision. What I wanted
to express was that when checking out, the mtime of the file
that is saved into the filesystem is the one returned from R(x).
+ 1.2) set M(x) = CT
+ No: set M(x) = S(x)
+
+ o if x = file, then f_checkout(x).
+ o if x = dir, then recurisvely f_checkout(x)
If you do support ext4 sub-second timestamps what happens when I
checkout on my ext3 machine which cannot represent those timestamps?
I should have been more clear in my description. Sub-second
timestamps wouldn't be supported. (*Again, that voice is going to
prove me wrong*)
+ 2) If x was locally changed with conflicts, then another
+ set of conditions are checked:
+
+ If to resolve conflicts,
+ 2a) 'theirs-full' is used then M(x) = G(x).
+ 2b) 'mine-full' is used, then G(x) = M(x).
+ 2c) manual conflict resolution is needed, then
+ to simplify the process, R(x) = M(x).
+
+ 3) If x was not locally changed, then G(x) = R(x).
Does the user have to resolve svn:*time property conflicts manually?
Does this happen automatically? Does this mean that a user with a
non-svn:*mtime aware client cannot easily run merge?
Good point. At this moment, I'm considering that the user will
have to do conflicts manually, which (atm) might be considered
a pain if there were lots of files with lots of *time attributes.
+
+ - revert
+ 1) if no local changes, then ignore command.
+ 2) if R(x) == NULL, then set R(x) = M(x).
So there are property modifications *after* revert? Do those
modifications show up in 'svn st'? Can they be committed?
My thoughts on this is if the file's *time properties don't
exist on a revert (most likely the server was upgraded
after the file/directory's existence), then the origmtime
should be set to the newest mtime. Of course, this
brings us to your question. Sorry I didn't think more
clearly on this. On second thoughts, perhaps a revert
doesn't deserve a change in the *mtime, since it's a local
change. My mistake here.
+ ### Might this help with 'svn rename x y' and keeping
+ ### history?
$ svn co http://... wc
$ touch wc/foo
$ svn st wc
$ svn ci wc
Does wc/foo show up as modifed? Can the mtime modification be
committed? What happens when the wc filesystem cannot support the
timestamp resolution in the svn:*mtime properties? Do all the files
show up as modified?
On the assumption that mtime has been implemented, then the following
would happen.
# svn co http://... wc
#
# results:
# All files/directories are saved to wc with their mtimes
# stored. If the repository existed prior to the upgrade
# of a mtime-enabled server, then the mtime of the files/
# directories will be the current mtime.
# touch wc/foo
#
# results:
# A file foo is created with the current mtime.
#svn st wc
#
# results:
# st reports unknown status file in wc/foo.
#svn ci wc
#
# results:
# wc/foo is checked in and its mtime is stored
# C(x) is set. R(x) is set. S(x) is set.
# A(x) is NULL because it was not 'added'.
# (this might be a slight nitpick though).
Thanks for the comments, Philip.
Edmund
