[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Is there really no way to keep the file modification time intact?

From: Frans Knibbe <frans_at_geodan.nl>
Date: 2007-02-28 12:07:24 CET

Erik Huelsmann wrote:
>> I really don't know which tools use the time and which don't. There
>> probably are a few that use file modification time in some way. I know
>> for sure my brain uses the file modification time. For example, if I see
>> a file that was last modified in 1999, I know for sure that there aren't
>> any calls to Windows Vista functions in that code. Also, I sort files on
>> modification time a lot, just to see which files were recently edited.
> Right, but if we solve this issue, we'll need to determine whether a
> Subversion update to a file is a modification itself or not. Does an
> update to the file's metadata mean an update to the file itself? It's
> possible to change only metadata in a commit.
I think maybe the best way to look at it is to look at how Subversion
handles other metadata. I think the file name also is metadata, but that
is a special case because Subversion uses this as the file identifier,
right? If I change the name of the file using the OS, subversion has
lost track of the file. So maybe it is better to look at the execute bit
as an example of comparable metadata. It is stored in the property
svn:execute. As far as I understand, subversion sets this property to
the right value on every commit and sets the execute bit right when a
file is copied from the repository. I can not check this, as I am on
Windows XP, which does not have execute bits for files.

I think this would probably the best way to handle the file modification
time. Define a new reserved property, something like
svn:modification-time and have it automatically set on commits.

I don't know if you just change a file's execute bit (on a UNIX or Linux
system) this is reason for Subversion to create a new revision upon
commit. But in the case of the file modification time, it probably does
not matter because if the OS has changed this time, the file itself will
have been modified. So a new revision will be needed anyway.

> For example: when you merge a change into your - otherwise unchanged -
> working copy, which modification time do you assign to the file? That
> of the merge? That of the current time? Maybe the merge makes the file
> identical to some other file somewhere in the repository? What do we
> do then?
I think Subversion should always use the modification time as provided
by the Operating System.
> Well, as you can see, versioning the modification time is not as
> simple as it may sound.
I certainly can imagine that it is not easy. If it was easy, maybe issue
1256 would have been resolved earlier.



To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 28 12:30:36 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.