Microsoft Visual SourceSafe Best Practices??

  • Can anyone point me to a place where I can read up on more VSS best practices beside what's posted in MSDN? Perhaps even some overall design tips, etc. That would help create a clean, efficient use of VSS?

    I know VSS is a little... iffy by many people but our client is using it and we want to learn how to make a sustainable system from it.

  • I have always been a user so here is my take make sure you check in everything including your SQL Server backup and stored procs because that saved us a lot when our SQL Server was down twice in one month.

    What I find bad is VSS will decide your current development folder is not valid without any reason so I have to create a new one. I had developer permissions so your experience maybe different.

    Kind regards,
    Gift Peddie

  • Most people I know don't really like VSS. SourceGear, SVN, PVCS, etc, are better systems.

    If you need to use SourceSafe, I'd start here: http://msdn.microsoft.com/en-us/library/bb509342(VS.80).aspx

    http://www.softsteel.co.uk/tutorials/vss/index.html

  • Be aware that VSS is designed for use in small to (at most) medium sized environments. If your shop has 30+ developers, it is likely you are too big to use VSS safely.

    If you try to push too much data through VSS, it has a nasty habit of loosing things. These can include your updates, or links that say what is the most recent update. This is inherent in the use of a Jet (MS-Access) database within VSS - Jet just does not cope with high-volume use. It was having these type of issues with VSS that finally got us the approval to move to TFS.

    The official Microsoft solution to all this is TFS (Visual Studio) Team Foundation Server, which uses a real database (:D SQL Server 😀 ) to manage source control. Although TFS copes with just about whatever workload you can give it, it does cost more and needs a lot more planning before you can get the best out of it.

    I am not a TFS expert, but there are TFS forums you can ask for best practice advise on using TFS and VSS.

    Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.

    When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara

  • EdVassie (9/11/2008)


    Be aware that VSS is designed for use in small to (at most) medium sized environments. If your shop has 30+ developers, it is likely you are too big to use VSS safely.

    If you try to push too much data through VSS, it has a nasty habit of loosing things. These can include your updates, or links that say what is the most recent update. This is inherent in the use of a Jet (MS-Access) database within VSS - Jet just does not cope with high-volume use. It was having these type of issues with VSS that finally got us the approval to move to TFS.

    The official Microsoft solution to all this is TFS (Visual Studio) Team Foundation Server, which uses a real database (:D SQL Server 😀 ) to manage source control. Although TFS copes with just about whatever workload you can give it, it does cost more and needs a lot more planning before you can get the best out of it.

    I am not a TFS expert, but there are TFS forums you can ask for best practice advise on using TFS and VSS.

    Where not a big development team, 6-8 max given the right circumstances. The only reason why I ask about VSS is because one of the clients we have already have VSS in place as source control. I've been reading up on it and it doesnt seem like the postives are all that many. We have a basic system in place at the moment but were looking to tighten that and try to reduce data corruption if it indeed did arise in the future.

    As for TFS, I dont know how integrated VSS is with the other departments of the client company so Im not sure if there is enough pull to suggest and put TFS in to the works. Which so far sounds like a safer choice but again, were not a big development team.

  • As always the answer is 'it depends', but in my experience VSS should be OK to handle the workload of 6 to 8 people.

    Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.

    When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara

  • We ran a fairly busy shop with 9 people and had no issues. I didn't mind VSS, but we kept things simple and it worked well for 2-3 medium sized web projects and a bunch of smaller ones.

  • In your experience, what would be the best method to push development stages?

    We have each of our release phases on different servers, DEV => TEST => PROD. I'm not 100% clear on VSS's sharing and branching features but i can I share the DEV release and branch it over to TEST to have them segregated from each other and ready to go? Then when we want to publish to TEST we just get the latest version of the build from the TEST folder and run it, or am I reading in to it wrong?

    I know when I was testing out this very question I 'branched' (dragged and dropped) the build from DEV on to TEST and then checked out a file in DEV that it checked out the TEST file as well.

  • VSS does not do branching very well. You can make a branch, but there is very little help if you want to rejoin that branch to your main code base. If this is a 'must have' then you need to look at TFS or other tools.

    Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.

    When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara

  • I never rejoined code, as an FYI. Stuff branched for a particular release and then remained there. Change were always on the main branch.

    That fit that particular development cycle, but it isn't for everyone. Definitely look at other solutions if you need merge capabilities.

  • We use code promotion so once DEV is ready for TEST, in a perfect world, we would branch the code out to TEST to, well test and then once that's good and ready it would branch out to PROD. Im just sketchy on how branching works in VSS.

    Correct me if Im wrong here, but the release has to be shared before it can be branched. Once its branched its supposed to be two different builds, right? However, when I checked out a DEV file it also checks out the same file in TEST. Is this because the branches have shared histories for merging later on or is it a VSS anomally? My understanding was that they both became seperate, so why the need to check both files out?

    Again, I could be running off ignorance here I just want to know what's happening behind the scenes. I'm new to the inner clockworks of VSS and I dont want to hit a bump in the road that could become costly.

  • It's been awhile, so someone with more recent experience might need to explain this, but

    a share is supposed to be a common copy. I think we used shares to track the release and then made a branch once the release was set. I believe that made a separate copy and you checked out that and it was separate from the original in the main branch.

Viewing 13 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic. Login to reply