Re: dates, checksums, and so

Olaf Hering <olh@suse.de> writes:

> > There is no single "correct" behaviour. Propagating the transaction
> > timestamp onto checked out files is a valid alternative to the current
> > approach, essentially that is the way ClearCase behaves, but keep in
> > mind that doing this will interact in "interesting" ways with the
> > traditional make approach to building derived objects (e.g. I could do
> > an update, have the modified files move backwards in time, and not get
> > anything rebuilt).
>
> How can this happen? If you did not touch the file then it will have a
> newer timestamp after the 'svn up'. The timestamp of a file that has
> local changes must get a new timestamp.

Perhaps I confused you, by "modified files" I meant the files changed
by the update, not files with a local change.

The problem I was pointing out is that if the commands checkout,
update, revert, and switch set the working copy timestamps to that of
the commit then it is possible for an update to generate timestamps
that are earlier than the timestamps of any object files derived from
the working copy. This can happen even if we ignore any clock
differences between client and server and simply update a working copy
to a newer revision on the same branch. I thought it was obvious, but
apparently not, so consider

- Checkout HEAD to get a wc with timestamp T1
- Build the wc to get objects with a variety of timestamps t1, t2, t3,
  etc.
- Between the checkout and the end of the build a new revision is
  committed.
- Update the working copy to get a wc timestamp T2. There is no
  guarantee that T2 is later than t1, t2, t3, etc.
- Complain bitterly when the build doesn't realise that some objects
  are invalid.
- Complain even more bitterly when told to run 'make clean' after
  every update.

Now if Subversion produced timestamps like this it would be a useful
for some scenarios, anything where the versioned items are the final
product for instance. For projects that have some sort of traditional
make-like build to produce derived objects it doesn't work. ClearCase
has ClearMake that does more than simple timestamp comparisons, I
believe it uses the versioned filesystem to determine exactly which
versioned items contributed to any particular derived object.

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