Re: timestamp preservation design (issue 1256)

Philip Martin wrote:
> In essence I would like the timestamp behaviour to mean that the
> timestamps in a working copy do not depend on how the working copy was
> obtained, whether by checkout, update or modify-commit the timestamps
> are the same.

A little light just went on in my head on the subtleties with the interaction
between versioned source files and derived files. I'm still more interested in
not losing the timestamp information, but I can now see how it likely to be very
difficult to get it 100% right.

<Anyone who has already made this conceptual leap should just hit delete>

Say I am working on a project with 1 other person on a project. I commit a
change to a file and then 30 minutes later (after having made some other changed
and committing again), I run make (possibly again). My directory now looks like
this:

-rw-r--r-- 1 jpeacock jpeacock 6615 Jun 22 11:23 util.c
-rw-r--r-- 1 jpeacock jpeacock 7304 Jun 22 11:54 util.o

But, unbeknownst to me, my partner also changed that file around that time, so
his directory looks like this:

-rw-r--r-- 1 otherusr otherusr 6625 Jun 22 11:43 util.c
-rw-r--r-- 1 otherusr otherusr 7324 Jun 22 11:44 util.o

Then I `svn up` and my directory looks like this

-rw-r--r-- 1 jpeacock jpeacock 6625 Jun 22 11:43 util.c
-rw-r--r-- 1 jpeacock jpeacock 7304 Jun 22 11:54 util.o

Note that the source file is newer, but not newer than the compiled version, so
the makefile will not rebuild it.

Yes, the correct order should be `svn up; make` or `make realclean; make` but
for really large projects, the second is a real pain, and for small changes, the
first is annoying (since it might result in a conflict).

I don't know the right answer; I just wanted to document that I understand the
question better now and maybe give someone else a better idea...

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org