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

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

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-11-28 17:05:03 CET

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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 28 17:32:27 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.