On Mon, 2010-01-04, Ed wrote:
> 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?"
I'm not 100% clear what those properties are for, but I'm pretty sure
you are complicating matters too much by suggesting them.
> > 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.
I don't know Windows well but I know that some Windows file systems
support sub-second precision and others don't, and of course there is an
API for getting the info. It's not a Windows-specific issue, since Linux
and other operating systems also support several file systems that have
different precisions.
> >> + - 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.
I think Philip's example was assuming that 'foo' was a versioned file
that was checked out, and this step is modifying its mtime but not its
content, and wondering what status that would show and what would happen
at commit time.
> #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).
- Julian
Received on 2010-01-04 11:39:12 CET