RE: Re: Keeping last-modified dates

> -----Original Message-----
> From: Andrew Webb [mailto:andrew.microi@gmail.com]
> Sent: Tuesday, August 29, 2006 10:38 AM
> To: Greg Thomas
> Cc: Ryan Schmidt; Erik Huelsmann; users@subversion.tigris.org
> Subject: Re: Keeping last-modified dates
>
>
> > 1-Aug: Alice checks out file foo.c, modification date 1-Aug.
> > 2-Aug: Bob modifies, commits foo.c
> > 3-Aug: Alice does a make. foo.c is compiled,
> > creating foo.o timestamped 3-aug.
> > 4-Aug: Alice does a 'svn update'. foo.c arrives timestamped 2-Aug
> > Alice does a make. foo.c is not compiled, despite being
> > changed since the last compilation, as foo.c is timestamped
> > 2-Aug (when Bob made the change), which is before foo.o was
> > created (3-Aug).
>
> I understand.
>
> But shouldn't Alice have done an 'svn update' on the 3rd as well?

Replace days (1-Aug) with hours or minutes.

I build revision 100 at 12:00. The build takes 30 minutes.
Bob checks in revision 101 at 12:01.

If I run 'svn update' on my working copy to pick up the revision 101
changes, the build won't rebuild the 101 files unless I'm very very
lucky.

This can make things like continuous integration a bit dicey if you're
not using 'make/ant clean' or if 'make/ant clean' is buggy.

> But shouldn't Alice have done an 'svn update' on the 3rd as well?

> I mean, if she does an update followed by a make on the 4th (seems
> reasonable), why only do a make on the 3rd?

Reality trumps "Should've" and "seems reasonable."[1] You CM build
processes need to be very defensive and not assume that people can be
trusted to do the right thing 100% of the time.

[1] Refer to www.dilbert.com

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA624

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 29 18:13:48 2006