VSS - Timezone difference between VSS client and server

Vipul Patel — Thu, 04 Aug 2005 16:53:00 GMT

Imtiyaz says:

From: Imtiyaz Alamshah
Sent: Wednesday, August 03, 2005 6:03 AM
To: Vipul
Subject: Query- Timezone difference between VSS client and server

Hi Vipul,

I have one query regarding VSS.

We have VSS server at onsite and working from india(OffShore) there is time difference of 4 and half hour between Onsite and OffShore.

We have problem with Time Zone difference. Suppose we check-in our changes at 5:30 PM (1:00 PM Onsite) then at 2:00 PM Onsite (6:30 PM OffShore) somebody label it to Version2.0. Our changes are not included in that label as time of label is 2:00Pm which is before check-in time 5:30 PM.

Can you please let me know if there is any solution available for it.

I believe that VSS server should consider Time Zone also as we are in +5:30 time zone and server in +1:00.

Is there any setting we can do at server side so server should consider time zone also with system time.

Thanks in Advance

Imtiyaz

Solution:

http://groups-beta.google.com/group/microsoft.public.vsnet.vss/browse_thread/thread/7e9056ec6730ab7f/c0ec004e840646e1?lnk=st&q=VSS+timezone+issue&rnum=1&hl=en#c0ec004e840646e1

One has to be careful using SourceSafe over different time zones. The Time Stamp on the files being checked in are marked according to the client's configuration clock. One way around this problem is to sync all computers interacting with sourcesafe acroos time zones to a common time. Another way is to use a third party add -on SourceOFFSite www.sourcegear.com.

Extract>

VSS - Allow multiple developers to work on the same file - VSS project structure best practices

Vipul Patel — Wed, 03 Aug 2005 22:14:00 GMT

Got a mail from Narendra asking me about VSS project management:

Excerpts from the mail as below:

----- Start of email

-----Original Message-----
From: Narendra Bisht
Sent: Wednesday, August 03, 2005 5:30 AM
To: vipul_d_patel@hotmail.com
Subject: Hi Vipul : Query on VSS

Hi Vipul,
How are you doing? I was reading your Webchat transcript QA session at http://msmvps.com/vipul/articles/48606.aspx. It was really quite informative. I have got few queries which are not related to VSS as such directly but more to management of Projects in VSS. Let me give you a brief overview of our current development environment.

We are into software development and develop solutions for our clients. As a typical SDLC, you might be aware that after implementation of application at client site, we had to resolve bugs whenever they occur, and for few projects after implementation, while we are supporting them we also have to do some fresh development/enhancement for the client. So as a result of this at times one file might be required by multiple developers, like one developer is fixing a bug while the other developer is doing some enhancement in the same file. And on top of this, we have to test the application by merging both the changes (bug fixing & fresh development). Now my query to you is that wha is the best project structure that we can create to handle such scenarios? We should also be able to keep track of our releases.

Right now, everything is a in a confused state, one developer have to wait for the other developer for finishing his work then only he can check out it and starts working. We are not able to finalise a structure where it will make the code version management a lot easier and quite smooth. Our proposed structure is defined below:

$Root
|
+----------Shopping Cart - Development (Project )
        |
        +____Code
        +____DB
        +____Images etc

+---------Shopping Cart - Enhancement (Project)
        |
        +-----Code
        +___DB
        +___Images

+---------Test
---same structure as above------
+--------Release
---same structure as above------

Pros of this structure:
1. We can seperate out bug fixing and enhancements related to a project seperately and later on can merge them, once successfully merged we send it to Test (create same project structure), test it and then release it to Release.

Cons of this structure:
1. Here there is lot of movement of files from one project to other project and we have to maintain 4 Projects for one single Project.

2. It also occupies a lot of space, if the project size is big.
3. It is also possible that lets say there were 4 bugs, now the developer has corrected 2 bugs and he is working on the remaining bugs, a second team member needs this file on which the developer has fixed 2 bugs coz he had some dependency on this file and since the 2 bugs has been fixed the second developer can resume his work with this file with these two changes, now we have to release this to a central place so that other developers can take it for their reference/dependency.

Hope you will be able to understand what I am trying to describe here. So, can you please suggest some project structure for the above mentioned problems, so that we can carry on bug fixing and enhancement as well as smooth partial and complete testing and then a smooth release of the application with proper RELEASE versioning.

Hoping to hear from you soon.
Thanks & Regards
Narendra

----- End of email

My solution

Narendra, first and foremost, you can have multiple people working simultaneously on the same file.

How to enable it? VSS Admin > Tools > Options > Enable multiple checkout.

This will enable multiple users to checkout the file. More details regarding the process to do this is available at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/tdlg_ch6.asp. Search for “Multiple File chechout” and you should be there. More info is available at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/guides/html/vstskcheck_out_multiple_files.asp

Dont forget to check out how to resolve merge conflicts at http://msdn.microsoft.com/library/en-us/guides/html/vstskresolve_merge_conflicts_with_visual_merge.asp and http://msdn.microsoft.com/library/en-us/guides/html/vstskresolve_merge_conflicts_without_visual_merge.asp

The only drawback of this solution is that the developer needs to understand how to resolve merge conflict , lest it create more bug than to fix it.

Regarding the multiple folders which Narendra suggests in his email, I would not recommend them. Every branch in the VSS project seems to add a burden in the backup and restoring process and hence, I would like to keep as few maintainable branches as possible. Also if you use sharing feature in VSS, then you need to do periodic checks to verify the integrity of the VSS structure. That alone is the deterent.

But Narendra has different requirements as per his mail

From: Narendra Bisht
Sent: Wed 8/3/2005 8:41 PM
To: Patel, Vipul
Subject: RE: Hi Vipul : Query on VSS

Thanks Vipul for a prompt reply, but your solution doesn't fulfill my all the requirements, it is good for allowing multiple checkouts for a particular file but I had asked for VSS structure of the Project (basically best practices for organizing your project structure in VSS), so that we can handle bug-fixing, enhancements, their testing and finally Release of the application.

Hope you will be able to help me.

Thanks and Regards

Narendra

So here is what I suggested

-----Original Message-----
From: Patel, Vipul
Sent: Thursday, August 04, 2005 9:35 AM
To: Narendra Bisht
Subject: RE: Hi Vipul : Query on VSS

Hi Narendra,

the problem is that repeated branching affects the performance

BUt here is what will help you..

The solution assumes that the directory structure that your have outlines is being used.

Work on Shopping Cart - Development (Project ) is complete. Developer checks in all the relevant files to this stream. Release engineer then does a Get latest of this directory structure to the local path of the "Test stream". And then he checks whether new code is buildable. If yes, then he goes ahead and builds a release for an internal release. After building the release, he gives it to the testing team. The testing team verifies whether the developement effort is in the build or not. If yes, then this code is checked in to the Test stream. If not, the bug is reported and the developer is asked to work in the Shopping Cart - Development (Project ) stream and once again the cycle is repeated.

Once the test has confirmed that the build is good, the code can be checked in to the "Release stream".

The same cycle will repeat for the "Defect fixing" cycle.

Essentially your suggestion for the streams is good and workable.

Regarding the cons of this structure: (inline)

1. Here there is lot of movement of files from one project to other project and we have to maintain 4 Projects for one single Project.

Since you require such a functionality, this is an necessray evil. The good thing is the specific groups will touch the specific stream. Developers will touch only the Shopping Cart - Development (Project ) and the Shopping Cart - Defect Fixing (Project ). Testers will take code from the Shopping Cart - Development (Project ) and the Shopping Cart - Defect Fixing (Project) and check in into the Testing Stream. Release enginner will take baselined code from the Testing stream (after approval from the test team) and check it into the Release stream.

2. It also occupies a lot of space, if the project size is big.

To reduce the space consumption, remove all .bin files, temporary files from the source control. If your project is a VS.NET project, do a clean project and do the diff between the folders on the VSS and your local drive. Any files which are not present in the local drive need to be removed. This will reduce a lot of space.

3. It is also possible that lets say there were 4 bugs, now the developer has corrected 2 bugs and he is working on the remaining bugs, a second team member needs this file on which the developer has fixed 2 bugs coz he had some dependency on this file and since the 2 bugs has been fixed the second developer can resume his work with this file with these two changes, now we have to release this to a central place so that other developers can take it for their reference/dependency.

This is a necessary evil. But you dont want a developer to use a dependency file which is not tested, do you?

Regards

Vipul

From: Narendra Bisht
Sent: Thu 8/4/2005 4:14 AM
To: Patel, Vipul
Subject: RE: Hi Vipul : Query on VSS

Hi Vipul, got ur prompt reply, one last thing, do u suggest that we should keep the same project structure along with all the files in all the 4 different projects e.g. Development, Defect Fixing, Testing and Release. If yes, then the size of the VSS will increase. And if we maintain 4 diff. projects in VSS for one SINGLE project then we will have so many projects. If we have 10 different Client projects then we will have 40 projects (10 X 4).

What do you suggest?

Thanks

Narendra

From: Patel, Vipul
Sent: Thursday, August 04, 2005 7:08 AM
To: Narendra Bisht
Subject: RE: Hi Vipul : Query on VSS

Hi Narendra,

Create a separate VSS database for each client project.... And you can create thse databases on the same PC.. That will ensure that you only need only one server dedicated for CM activities.

Alterbately, switch to VSTS Foundation Sever. It has the solution to your projetc. i.e. it is like Rational Clearcase, which allows streams to be created.

Regards

Vipul

Web chat transcript - Configuration Management using Visual SourceSafe

Vipul Patel — Tue, 24 May 2005 07:41:00 GMT

This webchat was conducted on 9th Feb 2005. The copy of the transcript is available at http://msmvps.com/vipul/articles/48606.aspx and and also on the Microsoft India Technical Community site at http://www.microsoft.com/india/communities/chat/12.aspx

C#, VS Deployment and all geek talk : VSS

VSS - Timezone difference between VSS client and server

VSS - Allow multiple developers to work on the same file - VSS project structure best practices

Web chat transcript - Configuration Management using Visual SourceSafe