On 3/1/07, Neville Franks <webinfo@getsoft.com> wrote:
> I am baffled by the use of Date's in TSVN, which is likely a
> Subversion issue, not a specific TSVN issue.
>
> When I commit a file it uses the current system date/time for the file
> date in the repository and not the actual file date/time as it is for
> the file in the 'working copy'.
>
> If I then Checkout the file to another PC or folder or Update it on
> another PC its date/time isn't as per the original 'working copy' file
> date/time.
>
> This means the exact same file on different PC's have different time
> stamps, which messes up backups that utilize time stamps, and can mess
> up build processes.
>
> I've done some searching for info on this, but so far I've come up
> empty.
It's fairly well-known and documented (and often discussed to death on
the Subversion mailing list) that Subversion doesn't maintain
last-modified dates as part of the versioned data. At one time there
was a series of patches to do this and some other metadata, but I
don't think it's maintained anymore.
You can configure your client(s) to set the date/time of items in your
WC to the time the files were committed by setting use-commit-times =
yes in the [miscellany] section of your config file.
Why are your backup tools (at least on Windows) relying on date/time
to decide whether a file has been updated, instead of looking at the
archive bit?
If your build process is this sensitive to dates, I'd start worrying
about how reliably it builds what you think it's building. The build
tool I'm using (AnthillOS, for Java web apps) does a fresh checkout as
its starting point for each build, so everything is always known to be
clean from Subversion (nothing locally modified).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Thu Mar 1 12:05:43 2007