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