On Aug 29, 2006, at 11:47 AM, Mike Brenner wrote:
> Excellent points, Ian. However, they assume that
> you stay in the development environment past
> the coding stage and throughout the testing and
> deployment stage.
>
> My example of testing involved
> making a cold start, i.e., recompiling
> all the files from scratch on a clean disk,
> in order to begin a fully configured test.
Surely a clean, from-scratch build won't require certain modification
dates in order to work properly. That would be incredibly fragile,
since there are a number of things that can change a modification date.
>
> As part of that process we check off the
> modified date of each file, to enhance
> the security that svn gives that it
> designates a copy of the correct file.
Honestly, I'd trust what Subversion told me before I'd trust a
modification date. Modification dates are a lot easier to fake than
the output of Subversion, and if you can't trust the results of
"diff" then you certainly can't trust significantly more complex
tools like your build system and compiler.
>
> Similarly, for certain non-developmental,
> never-changing files that get configured
> in order to include them in the final product,
> changing the date makes it very wierd
> to say this file bears today's date,
> but I promise you, no one has modified
> it in the last 5 years.
A quick "svn log" will show the last time a file was committed, which
will be five years if the file truly hasn't been modified in five
years, and an "svn status" will quickly show whether the file in your
working copy is the file that was checked out.
-Bill
>
>
> Ian Brockbank wrote:
>> Hi Mike,
>>> Stability and debugging often depend on
>>> having an original, unmodified file
>>> for everything except the unit under test.
>>>
>>> We should evolve subversion towards
>>> keeping the modified date.
>> Conversely, if I'm trying to investigate a problem in an old
>> version, I
>> need to be able to roll back and play around with the old code. With
>> subversion's current timestamp behaviour, I just need to update to
>> the
>> correct version and rebuild. If the timestamps were set to the
>> check-in
>> time or similar, Visual Studio would see that they were older than
>> the
>> object files and skip over them. I have wasted hours in the past
>> trying
>> to work out why my code wasn't doing what I expected only to find the
>> code hadn't been rebuilt. Yes, in some ways trivial, but under
>> pressure
>> it's the simple things you miss.
>> That's the issue subversion's current behaviour avoids. Fine, get it
>> added as an option, but please don't force me to use it.
>> Cheers,
>> Ian Brockbank
>> Senior Applications Software Engineer - Corporate
>> e: ian.brockbank@wolfsonmicro.com / apps@wolfsonmicro.com
>> scd: ian@scottishdance.net
>> t: +44 131 272 7145
>> f: +44 131 272 7001
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 29 20:20:38 2006