[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Re: Keeping last-modified dates

From: Thompson, Graeme (AELE) <Graeme.Thompson_at_smiths-aerospace.com>
Date: 2006-08-30 10:20:23 CEST


> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2006c@ryandesign.com]
> Sent: 30 August 2006 09:01
> To: Duncan Murdoch
> Cc: Steve Fairhead; users@subversion.tigris.org
> Subject: Re: Keeping last-modified dates
>
> 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.

Surly another good approach would be to bring the text-time branch in
line with the latest source, check that it still works as required (See
http://subversion.tigris.org/issues/show_bug.cgi?id=1256) and then
incorporate it into the trunk!

******************************************
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.
******************************************

---------------------------------------------------------------------
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:24:03 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.