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 <edmund_at_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
Received on 2010-01-04 05:17:58 CET