On 10/1/07, Steve_Whitehead@jbhunt.com <Steve_Whitehead@jbhunt.com> wrote:
> Does Subversion has any option that we can set so that it will us the time
> stamp of the file instead of the time stamp when the file was checked out.
> Here is the reason why I am asking this question,
> I have added Delphi project to SVN repository.All the files in this project
> were modified some time in April 2007 or before . But when I checked out
> this files from SVN the time stamp on all this files is showing as current
> time stamp.
> This might cause a problem while we build Delphi packages. Normally during
> our Delphi build process, we will compile all the source code and get
> dcu's(Delphi compiled units .. just like class files in java), Delphi will
> give you the dcu's for the files that have changed, based on this DCU's we
> will be able to decide which packages to build for the changes made and
> promote only those packages.
> But if the time stamp on the source file is changed Delphi will try to
> compile all the DCU's and we will have to build all the Delphi packages
> every time .
From what you describe, you version the DCU files too. The current
operating assumption in Subversion is that you only version files
which are 'sources'. With 'sources' I mean files which can't be
regenerated with your toolset.
When working that way, you'll always need to regenerate DCUs on a new
checkout, but only a few when updating to a newer or older revision.
Subversion sets the update time to 'now' because some tools don't
regenerate 'DCUs' for sources which are older than the DCU. Now, say
you're on r12 (with the associated DCU) and you need to test with
some-file.pas from r11, replacing that file with the r11 one will
replace a file with a timestamp before that of the DCU with another
one, also with the timestamp before that of the DCU, hence your DCU
won't get rebuilt.
Now, in the current scheme it works this way: you have the situation
as before (some-file.pas:r12 older than DCU), but now when updating to
r11, some-file.pas is newer (timestamp wise) than the DCU, thus
triggering a rebuild.
Conclusion: the current scheme, although maybe not intuitive at first,
ensures that rebuilds are triggered whenever something changes (and
not only when you move forward in time on the revision-axis).
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Oct 3 14:28:05 2007