On Thursday, June 19, 2003, at 08:37 AM, Ben Collins-Sussman wrote:
> Let's begin by describing exactly what svn does/doesn't do right now:
>
> * Entering the repository (import, add, commit):
>
> We do nothing, no timestamp metadata is preserved. All files in
> the changeset share a single "commit time" as metadata (the
> revision's svn:date property.)
>
> * Exiting the repository (checkout, export, update/switch):
>
> Working-file timestamps are untouched, they reflect the moment
> they were created or updated. Each file's "commit time" is
> metadata in the .svn/entries file.
(First I present motivating use-cases, then Two principles to which
they lead.)
I'm going to have to argue against the status quo approach here, at
least for "simple" users. All of the discussion of what's right for a
build system only takes into account the times when Subversion is used
as a *source code* versioning system. We've seen many use cases
discussed on the mailing list of people who are (going to be) using svn
for things that aren't source code. People who are not dealing with
build systems don't care that the timestamps of a recently svn-updated
or checked-out Word document should be newer than a locally modified
PowerPoint. Instead, they want to know (by looking at the filesystem)
how old the Word document is. With the status quo, a new checkout has
all the files dated Today, and none dated February, no matter how old
they are. Without timestamp preservation, svn may be able to replace
CVS, but it won't be able to replace the dreaded shared folder on a
file server for these users.
Also, when a file is copied out of a working copy, modification date is
the only versioning metadata that is kept with it. (Non source-code
files often aren't text format and so can't be labeled with a $Version$
tag.) If I copy a gif file from my computer to the web server, I only
have timestamp to tell me which version is deployed. If someone else's
working copy has different timestamps for the same version of the
image, they will think it's not the same version of the file. The same
problem will happen if I re-checkout and the timestamps change. This
can lead to unnecessary file uploads (especially if my ftp client is
timestamp sensitive, but isn't rsync), which leads to unnecessary
timestamp changes on the server, which leads to images being
re-downloaded by all clients. Yuck.
Two principles. If I choose the "timestamp preserving" option for my
working copy:
1) Timestamp handling should be easy to explain: The timestamp of a
file should always approximate the date it was last modified. (I don't
care much whether it's the date it was actually last touched, or the
date it was committed -- assuming that for the most common use cases
the two will be similar.)
2) Checkouts and updates should be interchangeable. (If I have no local
mods, why should I have different semantics (timestamps) if I throw
away my working copy and checkout again.) This implies not setting the
timestamp to something different based on the subcommand (co, up,
export) used.
I'm not saying that timestamp preservation is right for everyone, but
it certainly should be an option for those for whom it is. [UI
discussion postponed.]
-David Mankin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 21 08:58:07 2003