Thompson, Graeme (AELE) wrote:
> (Amendments at the request of Julian Foad)
>
> 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.
> Default: Not set
[...]
> Storage:
>
> - The modified timestamp for the file will be stored for every
> revision of a file. i.e. if it is set ten the modified datetime will be
> stored whenever a file delta is stored. And if it is not set then the
> global flag behaviour is used.
Oh, I understand now: the global option is an override: it forces the time
stamps to be stored for all files regardless of their per-file flags. I had
originally assumed it was an enabler.
That's fine in concept. In practice, we would have to define "global", and we
don't really have any mechanism to implement what you would probably want it to
mean (something like "per repository, defined by the administrator"). I
believe the only use for this global flag is as an optimisation to save a bit
of time and space if time stamps are not wanted at all. I would advise just
storing the time stamps for all items, and accepting the cost (which I believe
will be tiny).
So, that would leave the per-file flag just applying to export/checkout. The
per-file flag is stored with each file separately from the time stamp itself,
in contrast to P Marek's design where the very presence of the timestamp
indicates that the timestamp should be updated and used.
> (It would not be a good idea to remove
> the modification datetime from the checkins that had this flag set as if
> this is accidentally set then you will have permanently lost information
> from the repository and thus if you reverted to revision 1234 you would
> not get the same results as before the flag was removed and readded.)
I think I confused you by talking about removing a timestamp property. I
wasn't talking about changing the recorded history; we never do that. I was
saying that if the time stamp were saved in a normal, user-editable sort of
property, and then we disabled the "save time stamps" options and checked in
the file again, then we would want Subversion to remove the old mtime property
from the latest version of the file, rather than just keeping the previous
value. But I perhaps shouldn't have mentioned it: it's kind of an
implementation detail. And the point is moot if we always store the mtime.
> Export and checkout:
[...]
> (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.)
OK, thanks.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 28 18:49:54 2005