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? If changes have been made
so the update will do a merge, which date should be used?
Duncan Murdoch
>
>> -----Original Message-----
>> From: Andrew Webb [mailto:andrew.microi@gmail.com]
>> Sent: 29 August 2006 19:01
>> To: Duncan Murdoch
>> Cc: Steve Fairhead; users@subversion.tigris.org
>> Subject: Re: Keeping last-modified dates
>>
>> So... it seems that for some this proposed feature of retaining files'
>> last-mod date is a must-have, and their processes, make procedures and
>> so on can cope. For others, the opposite is true.
>>
>> Say for argument's sake it is implemented as an option in SVN 1.5.
>> What form should the option take? Is this a affects-whole-repository
>> flag? Or does it need to be more granular?
>>
>> Andrew
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: users-help@subversion.tigris.org
>>
>>
>> ______________________________________________________________________
>> CAUTION: This message was sent via the Public Internet and
>> its authenticity cannot be guaranteed.
>>
>> ______________________________________________________
>>
>
> ******************************************
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 30 14:55:05 2006