> - the modification time of files is archived as a property, eg.
svn:mtime
> - it is used on checkout
> - on update the newer of current and archived is taken
Isn't "current" (that is, the time when the update happens) *always*
newer than any "archived"? I must be misunderstanding what you meant,
here.
> - if the property is set to "current", the current time is always
taken,
> and the property doesn't get changed on commit.
I'm -0 on this handling (don't think it's the right thing, but don't
object so long as it can be overridden). I think the choice between
whether to use current or archived has to do with what you plan to do
with the files once the update finishes, and perhaps what you suspect
has happened in the repo while you were working out at your desk. For
this reason, it should be controlled by a flag to "update."
The use case that drives the common behavior of setting "current" at
update goes like this:
T1: userA performs checkout of the project
T2: userB commits a change to foo.c
T3: userA runs a build
T4: userA updates, receiving userB's changes to foo.c
T5: userA runs another build
At this point, userA's existing foo.o is newer than the archived
timestamp on his fresh foo.c, and a time-based build tool will choose
not to rebuild. But this is of course wrong: it should rebuild, because
foo.c has changed. So this use case definitely wants the current time
stamp on the updated foo.c.
OTOH, if your update is for the purpose of capturing a certain snapshot
of the repo itself, then the archive date has some significance (it
should, at least, be preserved until the point of use of the snapshot,
where the final determination can be made). And especially so, if
you've been versioning generated files as well as sources; this is the
automake case discussed in your reference:
http://www.contactor.se/~dast/svn/archive-2002-12/index.shtml#346
It seems to me that a team of developers working actively on the product
would want "current" behavior when they update sources for work, and yet
"archived" behavior when the update the distribution copy--same files,
different behavior, depending on intent.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 8 17:55:43 2003