Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed

Thompson, Graeme (AELE) wrote:
> My expectations of the logical working of this feature are:
> 
> Import and checkin:
> 
>   Configuration:
>     Global:
>        - Option to store the modified datetime for all files. On =
> stores datetimes.
>          Default: on (See requirements 3)
> 
>     Per file:
>        - The ability to set a flag to say to store the modification
> datetime.

And: if the flag is set, then the mtime is stored.  If the flag is not set, 
then the mtime is not set, and presumably any mtime that was previously stored 
for the file is deleted.  (I say this in the context of the time being stored 
in an ordinary property, as the property will persist from one revision to the 
next unless the code explicitly deletes it.)

>          Default: Not set
[...]
> 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.

Please can you clarify how (3) and (4) differ.  How does "if this was stored" 
differ from "if the storage flag is set"?  What does (4) do if the flag is not set?


This whole message was a nice presentation of your requirements, and quite 
reasonable ones too.  Perhaps you could re-post it with the above clarications 
included, rather than just answer them in-line, so that we have a copy of your 
proposal to refer to.

- Julian