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

 


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

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>