Using 4.1, and with the "file modification time" option set
I recently checked in a bunch of files using SOS (ultimately into a VSS server) a few days after editing them.
Both my hard drive and VSS have the file modification time, but SOS shows the "Remote Date" as the time I checked the files in
e.g.
timestamp on 2 files (on my hard disk) are 6/25/05 13:58 and 6/25/05 15:02.
On 6/27/05 at 14:11 I checked them in using SOS.
If I look in VSS, the Date-Time fore those files are the same as my hard disk timestamps; well actually 3 hours different due to timezone)
In SOS, the Local Date is correct, but the Remote Date is equal to the CHECKIN time.
How did that happen? (esp. since VSS has the right modification time)
And more importantly, how do I fix it now?
Note: before this, the timestamps were correct after previous checkins and all my files had a nice blank status column.
thanks,
jt
all my recently checked in files are now renegade
Moderator: SourceGear
The remote time is always the checkin time, as we use the date the file was checked in by the SOS Server. However, the VSS Client shows the modification time as does the SOS Client if you have that option enabled in the SOS Client.
SOS actually uses version numbers, not timestamps to keep track of file versions. The timestamps on files are more for doing accurate builds, etc.
A file is considered renegade when its time stamp has changed and it is not checked out. SOS uses the timestamp to determine if a file has changed. A get latest should set things write. If you continue to get Renegade files, you might investigate what could be changing the timestamps.
SOS actually uses version numbers, not timestamps to keep track of file versions. The timestamps on files are more for doing accurate builds, etc.
A file is considered renegade when its time stamp has changed and it is not checked out. SOS uses the timestamp to determine if a file has changed. A get latest should set things write. If you continue to get Renegade files, you might investigate what could be changing the timestamps.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
Thanks, but that doesn't clarify it for me
I look at one file in particular.
SOS client says Local Date "4/14/2005 15:24:00", Remote Date "4/15/2005 16:07", Status "Renegade"
on my hard disk, the file's "Date Modified" is indeed that Local Date.
If I do a get on the file (whether I delete the local file from my hard drive first or not), the Status changes to blank but the Local Date and Remote Date are still different.
(I did a Refresh File List too)
So what did that "get file" actually accomplish in this case?
So exactly what copy of the file's timestamp do you think changed? In client hard disk, VSS server, or SOS server copy?
my client is on a different timezone than the server if that makes a difference.
Thanks,
JT
I look at one file in particular.
SOS client says Local Date "4/14/2005 15:24:00", Remote Date "4/15/2005 16:07", Status "Renegade"
on my hard disk, the file's "Date Modified" is indeed that Local Date.
If I do a get on the file (whether I delete the local file from my hard drive first or not), the Status changes to blank but the Local Date and Remote Date are still different.
(I did a Refresh File List too)
So what did that "get file" actually accomplish in this case?
So exactly what copy of the file's timestamp do you think changed? In client hard disk, VSS server, or SOS server copy?
my client is on a different timezone than the server if that makes a difference.
Thanks,
JT
It got the latest version of the file in the database and resolved the incorrect "Renegade" status. The local file time rarely matches the checkin time, unless you use "checkin time" for the local file timestamp (Tools->Options->Files). The local file time sets the time on the files when you do a "get latest." It doesn't change the date on files already in the working folder.If I do a get on the file (whether I delete the local file from my hard drive first or not), the Status changes to blank but the Local Date and Remote Date are still different. So what did that "get file" actually accomplish in this case?
The file in the working directory. If SOS thinks the timestamp of the file is different from the time the file was retrieved from the database (based on the cache file), and the file is not checked out, the status becomes Renegade.So exactly what copy of the file's timestamp do you think changed? In client hard disk, VSS server, or SOS server copy?
Sometimes certain editors change the timestamp on a file just by opening it, even though it hasn't changed. A find in files search and replace operation can change the timestamp of files.
Daylight savings time or resetting the clock on the client machine can cause renegade file status.
This doesn't make a difference. SOS is designed to work across time zones. All checkins are server times, not client times. Each checkin increments a file version.my client is on a different timezone than the server if that makes a difference.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
Hi Linda
you wrote: "A file is considered renegade when its time stamp has changed and it is not checked out. SOS uses the timestamp to determine if a file has changed. A get latest should set things write. If you continue to get Renegade files, you might investigate what could be changing the timestamps."
which timestamp exactly should I be investigating?
as far as I can tell, the timestamps didn't change (no on my client machine).
It hasn't done it again to recently edited files, but it's not a good omen that all my files went renegade and I'd like to figure out why.
thanks,
JT
you wrote: "A file is considered renegade when its time stamp has changed and it is not checked out. SOS uses the timestamp to determine if a file has changed. A get latest should set things write. If you continue to get Renegade files, you might investigate what could be changing the timestamps."
which timestamp exactly should I be investigating?
as far as I can tell, the timestamps didn't change (no on my client machine).
It hasn't done it again to recently edited files, but it's not a good omen that all my files went renegade and I'd like to figure out why.
thanks,
JT