Build on check in is taking place an hour after check in

I have got TeamCity finally set up, but I still have one outstanding issue, in that when changes are checked into VSS (yes I know VSS is crap, believe me, I've been trying to get them to change), the build is kicked off just over 1 hour aletr (about 1 hr 1 min).

I am guessing that this may be something to do with Daylight savings time, but I have tried messing about with the settings for this on the build machine with no luck.

At my last company we had SVN linked to TeamCity and builds were kicking off straight away.

Does anyone have any ideas on this? It would be nice to know that something that has been checked in is causing an issue rather than making other changes on already bad code etc..

Thanks

Rich

14 comments
Comment actions Permalink

TeamCity VSS integration utility reports time from VSS in GMT +0 format as number of seconds since 1/1/1970. Java reads this time and uses it according to it's settings. To check changes TeamCity uses current time that is transferred to VSS.

What time zone do you use? There could be patches to OS/Java to support recent DST changes

Does VSS UI shows right file modification time?

There is an option in VSS 2005 for TimeZone used in the project. Please run SourceSafe administrator, open Tools/Options... and select Time Zone tab

You may check there is no record in srcsafe.ini like:
[TimeZone]
Name = (GMT+05:30) Chennai, Kolkata, Mumbai, New Delhi
TZ_Bias = -330
TZ_DaylightBias = -60
TZ_DaylightDate = 0000/00/00 00:00:00.000
TZ_StandardBias = 0
TZ_StandardDate = 0000/00/00 00:00:00.000
TZ_UseDaylightSavingTime = Yes


I suppose you may try adding such record to that file, but note this change will affect all users.

0
Comment actions Permalink

Thanks for the reply.

I am using GMT with daylight savings time, the VSS UI shows the correct time of check-in, as does using the command line utility (ss.exe).

I have just installed the latest Java runtime, but it doesnrt look like that has helped.

Unfortunately we're using VSS 6 rather than 2005.

Rich

0
Comment actions Permalink

Could you please check TimeZone settings for user account that is used to start TeamCity windows service.

Actually, I found Microsoft KB article on possible VSS 6 issue. Could you please have a look if the is relatefd to you issue
http://support.microsoft.com/kb/931804

Thanks!

0
Comment actions Permalink

As we're based in the UK, the changes to the US timezone shouldnt affect us anyway. All machines that are accessing VSS or TeamCity are set to the same timezone, in Visual SourceSafe 6.0, time stamping occurs on the client computer.

I tried changing the use the 2 TeamCity services run under so I knew for certain that they were using the same time zone (GMT with Daylight savings) and it still has the same problem.

Thanks

0
Comment actions Permalink

What time does reported for changes that are detected by VSS?

Does that bug occures for every commit? Could it be connected with user machine from what commit was performed?

Could you please try query ss.exe to fetch changes within an hour.

Please try comitting from this machine to VSS and check the reported timestamp from ss.exe and TeamCity.

Attach server logs from <TeamCity server install path>/logs/teamcity*.log

0
Comment actions Permalink

What time does reported for changes that are detected by VSS?

Not sure what you mean here, the ui of vss shows that changes have been made and displays the correct time, TeamCity is showing there were changes an hour later than they actually were.

Does that bug occures for every commit? Could it be connected with user machine from what commit was performed?

Happens with every commit, from each user.

Could you please try query ss.exe to fetch changes within an hour.

Made a change to results.cs file @ 10:08 on my pc, ss.exe on the build machine reports that it was changed @ 10:08. Team city hasnt yet noticed the change (it is currently 10:15, am expecting it to kick off at around 11:08)

Please try comitting from this machine to VSS and check the reported timestamp from ss.exe and TeamCity.

Checked out, made change and checked in from build machine @ 10:17, ss.exe reports it was checked in at 10:17, no build being run as yet (@10:22)

Attach server logs from <TeamCity server install path>/logs/teamcity*.log

Attached logs.


Thanks



Attachment(s):
teamcity-vcs.log
teamcity-server.log
teamcity-activities.log
0
Comment actions Permalink

Could you please open teamcity-server.log and check if the latest record time is about the system time.

Please enable logging as described in http://www.jetbrains.net/confluence/display/TCD4/Reporting+Issues and attach logs again.

Start <teamcity server>/temp/tc-vss-*.exe with the follogin arguements:

   tc-vss-native-*.exe /log a.txt b.txt <path to srcsafe.ini>\srcsafe.ini /login:<login> /pwd:<password> history $/SynBio 1246883320226 1247486058611

Attach a.txt, a.txt.log, b.txt to the request too.

Open a.txt, does reported times for the files matches the times reported by ss.exe?

Thanks!

0
Comment actions Permalink

Have turned on logging etc..

teamcity-xmlrpc.log also had data in it this time, but havnt attached it due to the 5 file limit, let me know if you need it.

The latest record time is about the system time in the teamcity-server.log.

I think we're getting closer...

b.txt is empty, so didnt attach it.

the dates in a.txt are an hour out from the date reported by vss.

eg..


<history_item type="File" time="1247483868000" version="11">
   <file><![CDATA[$/SynBio/ProtoCOL/Controls/ResultsTable/ManualZoneDialog.cs]]></file>
   <user><![CDATA[Richardhopwood]]></user>
   <action><![CDATA[Changed]]></action>
   <comment><![CDATA[Test Check In on Build Server @ 10:17]]></comment>
   <rdate>13.07.2009 11:17:48</rdate>
</history_item>

That is being reorted as checked in at 10:17 in vss (and was checked in at 10:17 on both the local machine and the build machine).


Thanks

Rich



Attachment(s):
teamcity-vcs.log
teamcity-server.log
teamcity-activities.log
a.txt.logs.txt
a.txt
0
Comment actions Permalink

Hello,

Could you please check you set up GTM timezone for UK. I saw several timezone with GMT + 0 but without DST

I've created a custom build of VSS-NATIVE.exe tool for you. Could you please repeat the same commandline call with
new tool. Please run the new tool with the following commandline:
  vss-native.exe timeA.txt timeB.txt debug_time 1247483868000

Please attach results of both runs.

Thanks!



Attachment(s):
vss-timefix.zip
0
Comment actions Permalink

Morning Eugene,

I am currently logged into the build machine as the same user that teamcity is running under, and in the Date/Time Properties it is displaying GMT and the automatically adjust for DST is checked. Is there somewhere else that this setting may need to be set?


Have attached the log files you requested (b.txt, timeb.txt were empty)

Thanks

Rich



Attachment(s):
timeA.txt
a.txt.logs.txt
a.txt
0
Comment actions Permalink

Hello,

Seems my fix is working for you. Could you please try replacing VSS-NATIVE exe in TeamCity. For this, please do the following:
  - stop TeamCity service
  - open <teamcity server>/webapps/root/web-inf/plugins/vss/server.jar
  - backup it
  - replace /bin/vss-native.exe with new version from my previous post
  - start server

Does it able to detect changes in the right way now?

0
Comment actions Permalink

  - stop TeamCity service
Done
  - open <teamcity server>/webapps/root/web-inf/plugins/vss/server.jar

This doesnt exist, do you mean <teamcity server>/webapps/root/web-inf/plugins/vss/server/vss-support.jar? What do you want me to do, run it?

  - backup it

Back up the vss-support.jar?

  - replace /bin/vss-native.exe with new version from my previous post

I am unable to find this file in the current installation, does running the .jar file create it?

Thanks

Rich

0
Comment actions Permalink

Sorry,

That file is <teamcity server>/webapps/root/web-inf/plugins/vss/server/vss-support.jar

I mean to ask you to copy original server.jar to some anothe folder (onside TeamCity installation).
I should have written more details about /bin/vss-native.exe. Please open vss-support.jar as .zip archive and you will find mentioned file inside.
You may simple rename it to .zip, update and that rename back to .jar

0
Comment actions Permalink

Thankyou, thankyou, thankyou.. builds are now running immediately.

You are a Star!

Rich

0

Please sign in to leave a comment.