On Aug 30, 2006, at 02:13, Duncan Murdoch wrote:
> On 8/29/2006 6:51 PM, Ryan Schmidt wrote:
>
>> On Aug 29, 2006, at 22:25, Duncan Murdoch wrote:
>>
>>> I would guess that it wouldn't be impossible to write wrapper
>>> scripts for svn that put the last mod date into a property just
>>> before a commit, and then modified the date based on that
>>> property just after a checkout or update. Tricky decisions
>>> would be what to do if an update resulted in a merge (presumably
>>> keep the merge time as last mod time), and recognizing cases
>>> where someone checked something in without using your script (so
>>> you'd need to fall back to the commit time).
>>
>> The problem with that is obviously the initial import: If I'm
>> importing a project that's been developed without version control
>> over the past two years, I don't suddenly want all of the files
>> in the project to have today's (or any other) modification date.
>> I want each file to remember the date on which that file was
>> modified. As has been explained by others, this is useful
>> information.
>
> Wouldn't my hypothetical script be able to add the property after
> importing? As far as I know, an import doesn't touch the files.
> Now, if you could do a substitution of a keyword %FILEMODDATE% in
> an auto-prop, this would be easy.
Oh, I see. You're thinking of a versioned property, like what's used
in the text-time branch. Yes, if you wrapped both commit/import and
update/checkout to do the right thing in either direction, it sounds
like that could work.
I was thinking of an unversioned property, specifically the svn:date
property of the revision, of which there's of course just one for the
entire revision. If you check in (or import) multiple files in a
single revision, they all have the same svn:date.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 30 10:05:53 2006