> -----Original Message-----
> From: Duncan Murdoch [mailto:murdoch@stats.uwo.ca]
> Sent: 30 August 2006 13:49
> To: Thompson, Graeme (AELE)
> Cc: Andrew Webb; Steve Fairhead; users@subversion.tigris.org
> Subject: Re: Keeping last-modified dates
>
> On 8/30/2006 4:41 AM, Thompson, Graeme (AELE) wrote:
> > There was a design discussion a little while ago, This
> would probably be
> > a good starting place to improve on if required.
> >
> > http://svn.haxx.se/users/archive-2005-11/1101.shtml
>
> I haven't read all the messages in that thread, they're
> broken up into
> several different places. But one problem with the recommendation is
> that it lacks a discussion of behaviour on updates. It gives these 4
> options for export and checkout:
>
> > Export and checkout:
> >
> > Configuration:
> > - 4 options available to the client for the setting of the
> > modification datetime:
> > 1) Use the current datetime
> > 2) Use the checkin datetime
> > 3) Use the original file datetime. If this was not
> stored in the
> > repository then the current time should be used (this can
> then be used
> > by the user to know that there was no modification datetime
> available)
> > 4) Use the original datetime for all files that have
> the per file
> > storage flag set. To allow for the people who want the docs
> with their
> > original modification datetime but the source with the
> current datetime.
> > (This differs from 3 in that if the global store datetime flag is on
> > then this will give the client the ability to get the
> behaviour as if
> > the global store datetime flag was off when a file was
> checked in. i.e.
> > for developers that want to use the current datetime for
> source files
> > that are stored on a server that is storing the modified
> datetime for
> > all files.)
>
> Updates are trickier, because the file in the working copy
> will have its
> own modification date. If the file has been modified since the last
> checkout, but a binary compare says there are no net changes: should
> the date be changed back to the old one? If it has no local
> changes but
> is being updated, which date should be used?
Then the modified date-time has been localy changed without any content
changes thus the data-time should be reset to the archive date time.
> If changes have
> been made
> so the update will do a merge, which date should be used?
>
In this case you are in fact changing the content of the file to one
that does not exist anywhere else, thus the modified date-time should be
set to the current time.
I will update the design with this issue and any other that people can
think of.
--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 Aug 30 16:02:54 2006