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
- application/pgp-signature attachment: stored
Received on Fri Mar 25 09:35:32 2005