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'
Regards,
Scott
---------------------------------------------------------------------
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