On Feb 22, 2005, at 8:31 AM, Ben Collins-Sussman wrote:
>
> On Feb 21, 2005, at 10:38 PM, Scott Palmer wrote:
>> On Feb 21, 2005, at 9:35 PM, Ben Collins-Sussman wrote:
>>> On Feb 21, 2005, at 8:55 AM, Scott Palmer wrote:
>>>>
>>>> To many people last modified time is superior to a "revision
>>>> number" because it conveys more familiar information and a little
>>>> extra detail.
>>>
>>> We haven't *completely* ignored this need. We have an option to
>>> make working copies reflect the "last modified time"
>>
>> I knew there was something... I thought it recorded the "commit
>> time", not the file "modification time"
>
> Think of it this way: when you're not using version control at all, a
> file's timestamp indicates the last time the file changed in the
> filesystem. When you import a tree into a subversion repository,
> you've moved the project into a "new filesystem".
Ok... that usually (always as far as most OS's file copy operations are
concerned) keeps the modification time exactly the same.
> The "use-commit-times" option will make your working copy timestamps
> reflect the mod-time of each file in *svn* filesystem.
Sure, that's better than nothing, but it behaves as if the versioned
file is a completely different chunk of data.
The use-case that comes up here is for .pdf files or other content
generated by non-programmers who do not directly use subversion. They
hand a file over to the engineering team to incorporate into a build.
On their own computers they have their own organization of the files
and talk in terms of when they last updated the file, not when the
engineering team decided to commit it to subversion. When I have to
answer something along the lines of, "Did you get the changes I made
last Thursday?" I can't go by the commit time that shows the following
Monday because that isn't a strong enough indicator that I have
Thursday's changes. Maybe I got an update on Wednesday and that's what
I committed. If the timestamp (and size, etc.) matched exactly with
the file that the creator has, I'm pretty confident that we are talking
about the same thing.
The other problem with use-commit-times is that it appears to apply to
everything. A property to set on a file-by-file basis would be better,
since then my source code could use the standard strategy that is more
compatible with tools like 'make', but other files can be marked as
having the modification time preserved.
It's just nice to have the ability and to be able to preserve commonly
used metadata.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 22 17:24:58 2005