renegade files again (concrete steps to repro)

If you are having a problem using SourceOffSite, post a message here.

Moderator: SourceGear

Post Reply
jt

renegade files again (concrete steps to repro)

Post by jt » Wed Oct 26, 2005 1:09 pm

was "all my recently checked in files are now renegade" to which Linda had replied.

here is some more specific info about the problem, easy to reproduce:

sos 4.1.2 server on a Win2000 SP4 server (also hosts the VSS 6.x database)
sos 4.1.2 client on a WinXP Pro SP2 laptop
NTFS on both systems
set vss and sos clients to use "file modified" dates.
note that the majority of my files in the VSS database were previously added using the VSS 6.x client.

1. with both systems in same timezone, I did a full sync in both VSS client and SOS client (into 2 different brand new directories, e.g. c:\source.vss and c:\source.sos)

2. point sos client at the local vss directory (c:\source.vss) and every file goes renegade!
why? it appears it's because the vss get keeps seconds on the file timestamp, while the sos get truncates the timestamp's seconds portion to zero. Note you usually have to do a right-click Properties to see the seconds in the timestamp
e.g. a file that was previously checked in using VSS with a modified timestamp of 12/23/03 14:03:22 has that timestamp when gotten via vss client, but 12/23/03 14:03:00 when gotten via sos client
BUG!?!?

3. point sos client back to the local sos directory (c:\source.sos) and the renegade status disappears.

4. exit sos client. change timezone through control panel (e.g. from original PDT to EDT). restart sos client.
=> every file is now renegade!!!
BUG!?!?

5. repeat step 4 but change back to original timezone.
=> files are no longer renegade!

More notes:
- if I check in a file using sos client, the seconds portion of the timestamp gets set to zero (so if I then do a get using vss client, the seconds portion is zero and the first issue above doesn't happen)
- the "Remote Date" column in the sos client seems to indicate the actual time of checkin, not the file's modification date

So there you have it, renegade problems without anything touching the files!!!

thanks,
Jan

jt

Post by jt » Wed Oct 26, 2005 2:41 pm

an annoying side-effect of the seconds getting reset upon checkin is that my editor tells me the file has changed outside the editor and aske me if I want to reload it, which of course is annoying because the file didn't really change!

lbauer
Posts: 9736
Joined: Tue Dec 16, 2003 1:25 pm
Location: SourceGear

Post by lbauer » Wed Oct 26, 2005 3:39 pm

Thanks for the details. I wasn't able to reproduce the renegade status when switching working directories. I used an SOS Server 4.1.2 on a Win2000 machine and SOS 4.1.2 and VSS 6.0c clients on XP.
2. point sos client at the local vss directory (c:\source.vss) and every file goes renegade!
why? it appears it's because the vss get keeps seconds on the file timestamp, while the sos get truncates the timestamp's seconds portion to zero. Note you usually have to do a right-click Properties to see the seconds in the timestamp
e.g. a file that was previously checked in using VSS with a modified timestamp of 12/23/03 14:03:22 has that timestamp when gotten via vss client, but 12/23/03 14:03:00 when gotten via sos client
The VSS automation component does not return the seconds in the modification time, so SOS is unable to display the seconds. However, I don't think this is what causes the files to go Renegade.

When I changed the SOS working directory to the VSS working directory for the same project, my file status was Unknown, which is expected behavior. Unknown status means that the files in the working directory were the same names as the files in the database, but the SOS didn't have information about them in the SOS Client cache file. When I used checksums, the file status became blank again. When I changed the folder back to the SOS working directory, the status was Unknown again. I couldn't get the Renegade status by changing working directories.

Changing the timezone DID create Renegade files, but this is also expected behavior. When SOS retrieves files into the working directory, it writes to the databaseX.sos file (database cache). If the timestamp on the file in the working directory is different than the time the file was retrieved, files have a Renegade status. I noted that when I changed the timezone, the Modification time of the files in the working directory stayed the same but the Creation time changed. This could account for the Renegade status.
- the "Remote Date" column in the sos client seems to indicate the actual time of checkin, not the file's modification date


That is correct. Remote date is always the date the file was checked in, based on the timezone of the SOS Server.

I'm not sure why you're getting a Renegade status instead of Unknown status when you change working directories. Perhaps your client settings are different than mine, or I've missed something in the steps you described.

If you would like to pursue this further, send me screenshots of the settings under Tools->Options->Files (or Local Files in VSS) in each of the following:

-- The SOS Client on your laptop
-- The VSS client on your laptop
-- The VSS client on your SOS Server machine

Email the screenshots to Linda at SourceGear.com and we'll try again to reproduce this.
Linda Bauer
SourceGear
Technical Support Manager

lbauer
Posts: 9736
Joined: Tue Dec 16, 2003 1:25 pm
Location: SourceGear

Post by lbauer » Wed Oct 26, 2005 3:45 pm

I was working on my previous post when you posted again.

The additional information is helpful. It's quite possible that when your editor is reloading the files, it is changing the creation date or modification date, and causing the files to go renegade. My post above describes how the client determines Renegade status.

The SOS Server uses the VSS automation component to communicate with the VSS database. Unfortunately, the automation component does not give us the file time in seconds, so there's probably not much we can do to change the file times when files are retrieved with SOS.
Linda Bauer
SourceGear
Technical Support Manager

Post Reply