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

Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed

From: Peter McNab <mcnab_p_at_melbpc.org.au>
Date: 2005-11-28 14:11:18 CET

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.
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.
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.

my 2c worth


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 28 14:12:41 2005

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

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