"Svante Seleborg" <svante@axantum.com> writes:
> - Design goal: Import followed by export/checkout from the same client
> system should be a no-operation affecting nothing of file contents
> bit-for-bit or the meta data "file name" and "file timestamps".
Directories also have timestamps, on Unix at least, should these be
stored as well?
> - When checking out on a different file system than imported from, the best
> possible approximation should be done. Filenames are treated as today.
> Timestamps are rounded to the nearest value in the target file system
> resolution. If exactly half, always round up to a more recent time (err on
> the side of a non-existing update rather than the other way).
Subversion doesn't know what resolution a filesystem supports, it can
only attempt to set the timestamp and then see what result it gets.
> - Add two more meta-data (properities I suppose) to the repository:
> time-last-modified and time-created.
Most Unix filesystems don't have a "create" time, they usually have
"modified" and "access" times.
I don't know much about Windows, can a file's create time be modified?
Can the modifed time be earlier than the create time? Such things are
likely to happen to the meta-data.
> - Default behavior at import is use what is available on the local file
> system for time-last-modified and time-created. If only one timestamp is
> available use it only for time-last-modified , and leave time-created
> undefined.
>
> - Default behavior at export is use available properties. If time-created is
> available use it for that. If time-last-modified is availabled use it for
> that. If the local file system only supports one time stamp, use
> time-last-modified and ignore time-created even if available. If neither
> time-last-modified or time-created is available, use current behavior.
>
> - Default behavior at checkout is current behavior (for compatibility). Add
> a client-side switch analogous to the use-commit-times, use-file-times
> perhaps. When set, both export and checkout use the defined behavior.
Suppose both use-commit-times and use-file-times are set, what should
happen?
> - Store times with resolution and time zone information (UTC I presume) as
> is now done for commit times.
>
> - If time-last-modified or time-created is in the future from the view of
> the server at import/export/checkout do nothing, just accept it (possibly
> inform). (If the user for whatever reason wants this - that's her choice.
> The repository should not police such a situation).
>
> I'm sure there are file system quirks, and possible SVN design issues, that
> makes some things need to be handled differently than above, please comment
> on this.
Merge is likely to cause conflicts in the new properties, is that
acceptable? Should Subversion automatically "resolve" such conflicts?
If the user changes a file's timestamp but doesn't change the text or
any properties, should Subversion detect that? Should it be possible
to commit such a change? What, if anything, should status show? (The
svn:executable property has a similar problem and I don't like the
"solution" used there, but then I rarely use it.)
How should copies behave? Should a WC->WC or URL->WC copy set the
timestamps on the new items to match those of the copy source, or
should the new items get their own timestamp? What about merges that
add new items?
How should revert behave? Should it affect the working copy
timestamps?
On Unix only the owner of a file can change it's timestamp to anything
other than the current time. To allow multiple users to share working
copies it might be necessary to do the "move-copy-delete" dance to get
ownership. (I wonder if this affects the existing use-commit-times
code?)
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 19 17:34:14 2005