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". The
> "use-commit-times" option will make your working copy timestamps
> reflect the mod-time of each file in *svn* filesystem.
>
>
>
Hi List
I can understand Ben's philosophical viewpoint as it relates to modified
files. However in the situation where an existing project tree is to be
imported and placed under revision control, a considerable amount of
revision history exists by virtue of the create and last modified dates.
I recently inherited a project that commenced over 10 years ago, where
the development team has long since dispersed, the ownership has changed
and the "maintenance" history completely lost. So with just the source
code and operating data plus the original handbook and the hardware
upon which the code runs I need to "sort the beast out". Now there are
over 8000 files, some source, some executable, some data and a bunch of
test and backup routines. Searching through the directories and sorting
on last modified date gives considerable insight into where the code has
been changed to accommodate hardware updates. The data and calibration
files have scattered dates which helps considerably in gleaning what
might have changed recently to cause a nasty fault to emerge. Now I
don't expect to be modifying more than 1 or two files initially so for
me, keeping the original create date and last modified data after
importing into SVN would have been a real bonus. Sadly I have to keep
two copies on the work machine with all the potential for accidental
stuff ups that that brings with it. And I just discovered that having
checked the project out and having deleted the originals that SVN didn't
preserve that vital info.
So it would be nice if that was an offered option. Not all of us are
working on new code with full mod history.
Peter
---------------------------------------------------------------------
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:09:39 2005