I'll comment below, will consolidate later.
(snip)
> > - 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?
My vote is "yes". They do have filestamps in Windows file systems too.
>
> > - 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.
That would depend on the OS abstraction layer. Subversion uses the Apache
Portable Runtime I think, and then I guess it'll just have to be designed
within the limitations of that and trust that it does "the right thing".
>
> > - 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.
Right. That's why there are cases below where "create" is not available.
>
> I don't know much about Windows, can a file's create time be modified?
Yes.
> Can the modifed time be earlier than the create time? Such
> things are likely to happen to the meta-data.
Yes, as far as I know there's no such limitation in any Windows version. I
believe that the repository should not try to correct errors in the
meta-data, it should just store and restore them faithfully.
>
> > - 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?
Either it's a configuration error, i.e. use of conflicting options (my
choice), or they are used in priority. If file-times are available, they
have priority - but if they are not available the commit-times may be used
instead. (I do not favor this - too hard to understand).
>
> > - 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?
Conflict is naturally resolved by having the latest win.
>
> If the user changes a file's timestamp but doesn't change the
> text or any properties, should Subversion detect that?
Yes. In fact that's what it does today, no? It uses the file-times on the
client to detect any change, it does not run any diffs or hashes on the
sources to detect changes.
> 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.)
Yes, such change should be commitable, naturally. The Unix command "touch"
would then have it's result commitable, which should be a "good thing", and
also in line with the design goal: retain file time-stamp meta data through
an import/commit - export/checkout cycle.
>
> 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?
Here, I'm not quite sure I follow. A copy is a copy, right? Why should not
the copy retain the file time-stamps as well as the file names and the
contents?
> What about merges that add new items?
This I'm not too sure about either. The new items will have their own time
stamps, or am I missing something?
>
> How should revert behave? Should it affect the working copy
> timestamps?
Yes. Once again - a revert should of course try to restore "as if nothing
happened". That includes the time stamps.
>
> 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?)
As you say, this issue must already exist/be solved with use-commit-times.
Anyone know how that is handled there?
Svante
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 19 18:15:18 2005