subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ed>
Subject Re: [RFC] mtime functional specification notes
Date Mon, 04 Jan 2010 03:59:58 GMT
Hi Philip,

Sorry for the long delay in response.  Year end issues and
problems prevented me from making a decent response to your

Philip Martin wrote:

> Edmund <> 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.


View raw message