Ok,
I agree, but you have the -B option in make to say to ignore the
timestamps.
But my point is that we work using the timestamps of the original files,
and a key part of a version control system for us is that it maintains
these timestamps. All I want is the Option, not necessarily the default
one, to be able to maintain them. Thus you would be able to work with
the timestamps always getting mangled to the current time and then using
make and I would be able to work be getting the source with the actual
modified timestamp and doing a make -B.
Also as other people have pointed out, not all files that are being
stored in subversion are source files that will be going through a make
like tool, and this argument for mangling the modified datetimes in this
case doesn't hold water.
Graeme
-----Original Message-----
From: Paul Koning [mailto:pkoning@equallogic.com]
Sent: 11 November 2005 15:06
To: Thompson, Graeme (AELE)
Cc: subversion-2005@ryandesign.com; users@subversion.tigris.org
Subject: RE: Potential New User questions
>>>>> "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
******************************************
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: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 14 09:50:52 2005