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

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

From: Thompson, Graeme (AELE) <Graeme.Thompson_at_smiths-aerospace.com>
Date: 2007-02-28 12:27:25 CET

> -----Original Message-----
> From: Erik Huelsmann [mailto:ehuels@gmail.com]
> Sent: 27 February 2007 18:53
> To: Frans Knibbe
> Cc: Matt Sickler; users@subversion.tigris.org
> Subject: Re: Is there really no way to keep the file
> modification time intact?
>
> > 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.

Lots of other verison control systems handle this issue in a sensible
fashion.

Metadata describes the data in the file - metadata is items like:

File name
File size
Modification data time

This metadata information should be preserved through the version
control system.

The modification date time should be the date time that the content was
last changed.

It is possible to have subversion change the content of the file on
checkout, if this
Is the case then the modification data time will only be accurate if it
is set to the
Time that subversion modified the content.

>
> 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?

This was all covered in the design discussion that took place on the dev
list.

It all has logical solutions.

>
> Well, as you can see, versioning the modification time is not
> as simple as it may sound.
>

It is when you apply a set of simple rules.

Graeme

 
************************************************
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.
************************************************

---------------------------------------------------------------------
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:59 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.