> > More precisely, if the file does not exist in the WC, it gets
> > last-commit-time, if it is patched, it gets current-time. This has
> > the advantage of playing nice with make(1). Any solution which
> > opens a hole for make figuring out whether a file has changed gets
> > scorn from me. -- justin
>
> What happens if I build at say rev X, update to rev A < X where a file
> does not exist, then update to rev B < X where that file does exist?
> If that file gets last-commit-time, make will not rebuild, even though
> it should, which will cause whoever implemented it that way to be
> tarred and feathered ;-)
After all this discussing I still believe that the stored properties should be
used *only* on export, so that build tools see which data has changed.
But the use-case where non-source files are versioned (1), and these files are
in a format which prohibits saving a version in them (2), leads me to think
whether there should be a property (3) which says "on updating, if the file
has no local modifications (ie, clean from the repository), use the mtime of
this file's version; if it's modified, use the current time."
So the user can decide on a per-wc-base if it's source-files where the
timestamp in needed in the tool-chain, or if it should be restored with the
file(s) for easier version tracking by the user. (as it is common to say
"this file is from march" instead of "I have version 515 of that file" - and
in svn many numbers will mean the same file, unlike cvs, which makes
comparing the files by revision nearly useless)
1) that is, there are no files depending on the versioned files, eg.
text-documents or spreadsheets
2) eg. binary files like pdf, MS-Word, ... I know that most file formats have
a version field nowadays, but patching this into a word document is a
liiittle bit beyond the things svn should do :-)
3) directory-property and inherited to the files, and/or for the subdirs,
overrideable per file
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 24 18:50:05 2003