>>>>> "Graeme" == Graeme Thompson <Thompson> writes:
Graeme> Ok,
Graeme> But what I *really* want is the actual file modified date
Graeme> time.
That seems reasonable. But doing that will tend to break stuff.
Example:
1. At t1, I check out a working directory.
2. At t2, someone else modifies a file.
3. At t3, I do a build in my working directory.
4. At t4, I update my working directory (so now I get the change from
t2)
5. Now I do another build.
If the files end up in the working directory with their original
last-change time -- or, for that matter, with the commit time -- then
the build at step 5 will NOT rebuild the affected dependent files,
because they have a timestamp of t3. However, the default rule in SVN
will give the changed file a timestamp of t4, and its dependencies
WILL then be rebuilt.
Graeme> I have a strong belief that a version control system should
Graeme> not alter the files in any way. i.e. you will get out of the
Graeme> system *exactly* what you put in, how it stores this
Graeme> internally is irrelevant, and you should be able to get back
Graeme> every single version of a file that you checked in.
Again, that seems like a theoretically reasonable argument -- even if
it stands in the way of successful builds. But I find it hard to
understand your point that this *has* to be supported before you can
consider SVN.
Incidentally, the only way I see of having "original" timestamps and
still having "make" work is the Clearcase approach, where dependent
files are marked as to which version of source they came from, and any
change at all in the source -- timestamp (or version) change either
forward OR backward) -- forces a rebuild. That sort of thing is very
nice indeed -- and quite hard to do.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 11 16:10:35 2005