[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: Kris Deugau <kdeugau_at_vianet.ca>
Date: 2004-11-29 22:44:09 CET

Patrick Smears wrote:
> The reason for the default behaviour is that any other behaviour
> tends to confuse utilities like 'make' that depend on timestamps on
> files to determine which file has been changed most recently (e.g. if
> someone else commits a change to a file, then I do a 'make', then I
> update my WC to pull in their change - I want the changed file to
> have the time of my update, not the time of their commit or the time
> they changed the file, or else 'make' won't know to rebuild targets
> that depended on the changed file...).

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.

Assuming, of course, that everyone's system clocks are in some state
resembling synchronized. <g>

-kgd

-- 
Get your mouse off of there!  You don't know where that email has been!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 29 22:47:17 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.