SVN revert maybe should not revert timestamp with use-commit-times enabled

[Adam Gibson <ag...@ptm.com>]

With use-commit-times set to yes a checkout will change the checked out 
files timestamps to the last change for that file(I want that).  It also 
modifies the timestamp to the commit time for a revert too which causes 
incorrect builds when a project is under heavy development and the 
developer does not remember to touch the reverted file to update the 
timestamp to now(part that I don't want).  It is not always noticeable 
that a file was not rebuilt without careful scrutiny because other files 
could have been changed and get rebuilt.

Scenario...
1. Checkout project
2. edit file1
3. build the project with make
4. revert file1 (timestamp of file1 now changed to an old time)
5. edit file2
6. file2 gets rebuilt but file1 does not.

Building the project shows some output with make because a second file 
was modified making it hard to know(without manually checking each file 
that was compiled in the terminal window's back buffer and comparing it 
with what you know should have been built).  The binary file you just 
compiled is not the correct binary.

The quick fix is to make sure and remember to touch any reverted files 
but that is hard to keep up with in practice.

Because of this it would be nice if use-commit-times only modified the 
timestamp of files for a checkout.  From my development perspective a 
revert is a change on the local file so it should get the current time 
for the timestamp.

I dont want to disable the timestamp feature because it is real handy to 
have an idea how old a checked out file is just by looking at the 
timestamp(other people without svn can get a general idea how old files 
are too).


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: SVN revert maybe should not revert timestamp with use-commit-times enabled

[Saulius Grazulis <gr...@akl.lt>]

Hi all,

On Tuesday 22 March 2005 18:01, Adam Gibson wrote:

> ... It is not always noticeable
> that a file was not rebuilt without careful scrutiny because other files
> could have been changed and get rebuilt.
>
> Scenario...
> 1. Checkout project
> 2. edit file1
> 3. build the project with make
> 4. revert file1 (timestamp of file1 now changed to an old time)
> 5. edit file2
> 6. file2 gets rebuilt but file1 does not.

Unfortunately, there is one more situation where similar problem would appear 
-- I realized this only after reading Adam's scenario:

Scenario2: (use-commit-times=yes for all users)

1. Alice checks project out
2. Bob checks project out too
3. Alice modifies file2.c
4. Bob modifies file1.c
5. Alice commits file2.c (<-- race condition here...)
6. Bob makes (builds) the project (<-- and here...)
7. Bob updates his working copy
8. Bob says 'make' and -- BANG -- his file2.c will not get recompiled because 
his object file (file2.o) is more recent that Alice's committed file2.c 
source :(

I was intending to use text-time feature to fight this problem. In my 
particular case it helps (we commit built files as well), but unfortunately, 
it will not help unless Alice also commits file2.o into the repository which 
I guess few people do...

> Because of this it would be nice if use-commit-times only modified the
> timestamp of files for a checkout. From my development perspective a
> revert is a change on the local file so it should get the current time
> for the timestamp.

At the first glance my intuition revolted against this -- revert should be 
revert, with times and all, shouldn't it? ;) 

But the more I think the more I see the point in touching files automatically 
on revert.

After all, inconsistent build problem is really bad and should be addressed 
somehow...

> I dont want to disable the timestamp feature because it is real handy to
> have an idea how old a checked out file is just by looking at the
> timestamp(other people without svn can get a general idea how old files
> are too).

POSSIBLE SOLUTION:

With the default setting (use-commit-times=no) svn should ensure that files 
are committed and checked-out in the order of their creation, oldest files 
first, newest files last.

This would always ensure a correct ordering of the files if the make-built 
files must be kept in the repository.

HOW THE SCENARIOS CHANGE:

Those who need actual timestamps on files stored in the repository (like me 
and Adam), should then import and add files with their actual creation dates 
(use-commit-times=yes, enable-auto-props=yes, [auto-props] * = 
svn:text-time), and use the same settings for the *first* checkout of the 
repository. However further updates and reverts should then use 
checkout/revert time for the files (use-commit-times=no).

This scheme ensures that:

a) in each working copy, a file that has never been edited in the repository 
will have it's actual creation date. This is handy for files that were 
imported from other projects or for data files that contain measurement 
results from scientific equipment (like in my case) -- file creation date is 
important piece of information in this case.

b) upon check-in, update, revert or checkout, all files maintain correct 
"older-younger" relations, so 'make' will not be fooled into remaking files 
when this is not necessary.

c) Every changed file will be touched by checkout and the files that depend on 
it will be remade correctly. (race condition from Scenario 2 will no longer 
be true).

d) for files that were created and maintained using subversion in busy 
projects, check-out times are pretty close to actual creation times, so no 
important information would be lost. ;)

e) we eliminate problems with out-of-sync clocks on the working copy 
machines ;)

Sorry for a long post.

What others think about this possibility?

-- 
Saulius Gražulis

Visuomeninė organizacija "Atviras Kodas Lietuvai"
P.Vileišio g. 18
LT-10306 Vilnius
Lietuva (Lithuania)

tel/fax:      (+370-5)-210 40 05
mobilus:      (+370-684)-49802, (+370-614)-36366