[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Timestamp Issues

From: Scott Palmer <scott.palmer_at_2connected.org>
Date: 2004-11-30 02:52:27 CET

On Nov 29, 2004, at 4:44 PM, Kris Deugau wrote:

> Patrick Smears wrote:
> Hmmm. I think you've got this scenario a little backwards. If you
> make
> changes to a source file, and commit it; then someone else makes
> changes elsewhere (changes that don't interfere with yours) and
> commits,
> *that* version of the file is the "correct" (newer) one - not the one
> in
> your local WC.
> When you svn up, if someone has committed changes to a file, that file
> should have a newer timestamp either way - and if the changes from
> someone else's change conflict with changes you've made since your
> commit, the timestamp on your file will be newer still once you've
> resolved that.

I think the case that SVN is trying to handle is this:

File A.c has a timestamp of 0:45
User A modifies A.c , it ends up with a timestamp of 1:00 in his
working copy
User A hasn't checked in A.c yet.

User B does an update at 1:01
this gets a working copy with A.c and it's previous timestamp 0:45
User B builds and A.c is compiled to A.o which gets the current
timestamp of 1:02

User A checks in the new A.c with the 1:00 time stamp.

User B updates and gets the new A.c with a timestamp of 1:00

User B builds, but A.o is not rebuilt because 'make' thinks A.o is
already up to date.
User B now has a broken build.

By modifying files on checkout/update subversion makes sure that files
that change in a working copy get re-built by tools like 'make'



To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 30 02:54:37 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.