Sorry to get this late into the discussion.
There've been some q&a (and tips) regarding this feature and it's
implementation.
My thinking goes currently along this lines:
- The "simple" approach is, well, the simplest. But no information is saved or
used.
- The behaviour in the "complex" approach on exiting the repository may be
splitted into two parts: export and update. (I hope that checkout is just a
fancy kind of update, in that there is no previous version).
- On update a behaviour well suited to the build system has to be used.
- On export the *full* information can be restored, with (almost) no need to
care about the build system - this is done for archival or distribution.
- The saved timestamp should be versioned and absolute.
I want to know which file was edited when, even when checking out revision
HEAD - 57 two years later. A versioning system is about *conserving*
information, not losing it. Ideally *all* file information should be saved -
unix rights, NT acl's, ... I believe a hash of the file is stored now.
- I'll disregard client clock synchronization problems for a moment -
> From: Jack Repenning
>
> On the other hand, clock skew is *not* a problem for either approach,
> because anyone asking for timestamp preservation already understands
> this, and has heard of NTP.
- If you just have everything in the repository (sources, intermediate files,
and output files) *and* their timestamps, you don't have a problem with the
build system. (At least no more than the committer).
Note: this is a point where my patch is incomplete, see below.
- If you change a file, it will eventually be committed. If this change causes
other files to be changed, too, they will be committed, too (if they are in
the versioning system).
If they are not, then they will have to be built on a clean checkout. So, no
problem here.
- If you update your tree and only parts are changed, they may as well get the
current time. If you update only sources, the build system should know which
parts to reconstruct. If you make no changes to the updated files, their
(wrong regarding to the repository) timestamps won't ever be committed and so
not be seen by anybody else. If you make changes, the file will have a
meaningful mtime.
Note: I know that I contradict myself in two of the above points: have the
*entire* tree in the repository, or only the sources. See below.
- And last but not least: SVN advertises itself "better" than CVS. Ok, let's
make it so :-)
The behaviour of my patch is currently as follows (partly because of style,
partly because of laziness - guess which is which)
- On import, add and commit the mtime is stored as property.
- On export the files get their stored mtime set
- On update the "old" behaviour (ie, use current time) is still active.
- On checkout the current time is used. Note: This is where problems may arise
(or not ???). If I do a clean checkout of the tree I should get the saved
time-stamps. This is *not* in my patch - will have to be done.
I see only one major problem point - and that would arise if parts of the tree
have a wrong date. When can that happen? Only if you have a working copy, and
due to user action some source files get a timestamp in the past, or
intermediate (or target) files get a timestamp in the future (relative to the
corresponding intermediate/source files).
I believe this problem can be solved in two ways:
- Only keep source files in the repository, and on update use the current
time. This is how my patch would work now.
- If your tree is so large that intermediate/target files *have* to be kept in
the repository, then it should work, too.
- if you update a file to an older version, and this file gets a current
timestamp, the target will be rebuild. This is ok.
I may be a bit lost trying to argument all possible ways and problems - it's
very likely that I've forgotten something.
Comments, please :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 20 07:07:12 2003