You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2004/09/01 14:06:01 UTC

Re: Bug in File Info Tab: LastDateChanged is set to the Date of File-Add to Subversion

On Wed, 2004-09-01 at 03:44, Allessandro Cesario wrote:
> hello developers,
> 
> I think i have found two bugs:
> First:
> If i add a new file to the Subversion Repository,
> the LastDateChanged in the normal Windows FileINfo Tab
> is set to the Date the file has been added to
> Subversion`s Repository. I think that is not very
> useful since the Date of Add (into the Working Copy
> Folder) is already logged.f.ex. The last Date i really
> worked with the File "Vorgehensweise" was the
> 13.August 2004, but Subversion set it to 1.September
> 2004.

Subversion touches the timestamp of a file every time the version
control system does anything with it:  commits, updates, etc.  This is
so that tools such as 'make' work correctly.

Either way, Subversion doesn't preserve permissions, ownership, or
timestamps.  Once you put a file under Subversion's control, it begins a
"new life".

The other option is to set "use-commit-times = yes" in your run-time
config file.  This will force your working copy files to have timestamps
that correspond to the last time a file changed in the repository.  This
might be more useful for you.


> Second:
> If i rename a File, its CreationDate in the FileInfo
> Tab is set to the Rename-Date, let`s say 1.September
> 2004 instead of 12.August 2004.
> I would be thankful if you could change this,

That's because svn doesn't have real renames;  'svn mv' == 'svn cp; svn
rm'.  Because the file's being copied, it gets a new timestamp.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org