Tardif, Sebastien wrote:
>I like this: some momentum.
>
>So let me resume my frustration:
>From the point of view of a user, Subversion is just a tool that should
>be transparent as possible. The only common knowledge my mommy and I
>know about computer is that files as a name and a modification date. In
>the perspective of knowing that subversion know about the UNIX security
>flag
>
Which it doesn't know about, of course.
> but doesn't know about the original modification date is quite
>perplexing.
>
>Other thread asked this important question: "While should we care about
>the commit date of a specific file instead of it's modification date?".
>This should set the answer to: "What should be the default behavior?"
>
>
The catch here is that 99% of the time, the commit time _is_ the
modification time, as far as the repository is concerned. I also suspect
that in most cases when people import files into the repository,
original modification times have no meaning.
Storing the original modification time on import would only make sense
if "svn co" and "svn up" set file timestamps to the times stored in the
repository. But this is a bad idea in most cases if those files are
program sources, because most build systems use file modification times
to decide whether dependent files should be rebuilt.
On the other hand, since SVN is a version control system, not a source
control system, there are many valid cases where the opposite is true.
The trick is to decide which behaviour should be the default, and
whether it should be controlled on the server or client, per-repository,
per-working-copy or even per-file.
I think the only sensible solution would be to control it per-file (or
per-subtree), but controlling such behaviour in a sensible way probable
requires server-side config and/or inheritable properties, a can of
worms we've avoided crossing so far...
>A+ to SourceSafe :-)
>
>
Go wash your mouth with carbolix acid... :)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 28 21:41:20 2005