> -----Original Message-----
> From: Peter McNab [mailto:mcnab_p@melbpc.org.au]
> Sent: 28 November 2005 13:11
> To: dev@subversion.tigris.org
> Subject: Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed
>
> Malcolm Rowe wrote:
>
> >On Mon, Nov 28, 2005 at 06:59:18AM -0500, John Szakmeister wrote:
> >
> >
> >>Properties change a lot less than the underlying file, so I
> believe the
> >>number of deltas involved would be considerably smaller
> than what you would
> >>expect for a file.
> >>
> >>
> >
> >If we're storing the mtime of the file in a revision, we'd expect the
> >property to change on every commit.
> >
> >Regards,
> >Malcolm
> >
> >
> I'm not and never will be an svn developer so please go easy.
> Because svn stores folder information could the file time be
> stored more
> efficiently in the svn folder structure information?
>
> I would expect file times at import and at "add" to be
> preserved on the
> subsequent Checkout / Update but on those files only.
> Same, if the "TakeOver" feature eventuates.
I would expect the file datetime to be always preserved as it is
information about the file at the time of checkin.
> Whilst it might seem consistent to also preserve the last
> modified time
> for commits there is a strong case to always stamp files
> existing in the
> WC with the update time. (Time at which the local copy is
> updated from
> the repo)
>
> Consider the situation where two clients are simultaneously
> working on a
> project, compiling only if the source file date is newer than an
> intermediate file e.g. .obj or .dcu etc.
> Client A modifies file x and commits the change.
> Client B updates file x and it's date is stamped with Client A's last
> modified date/time.
> But Client B's intermediate file is newer than Client A's
> modified file,
> so the compiler skips the new source and re-uses the now out of date
> existing intermediate file again. That looks difficult to detect.
> Same situation can also occur even if the file is stamped
> with the time
> of commit into the repository by Client A.
>
That is the current behavior of subversion. What is being proposed here
is to extend the functionality to
allow for the saving of the modification time when a file is commited to
then give the user three
options of what to set the file datetime to:
1) The current time
2) The time of the repository checkin
3) The original File datetime.
> my 2c worth
>
> Peter
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
******************************************
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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 28 15:52:37 2005