I am going to be working with VSS but I am much more productive and diligent with GIT.

I have to fit within the workflow of VSS and keep good history in VSS. The standard work flow here with VSS is

  • get working copy
  • do work
  • right click on folder -> show differences
  • in that view:
    • checkout (without overwriting local changes)
    • checkin (keeping write access)
    • Add comment with specific template

Personally I think this is already side-stepping the intended workflow of VSS and potentially overwrites any changes made by other people.

I think I can prevent the possible overwrite, but are there any other potential problems that I should be aware of with this workflow?


It's worth mentioning that in this case VSS is only used on legacy projects, and its largely treated with scorn by both the people that use it and the people that maintain it.

80% of the people that use it, use it alongside another version control system (some git, most mercurial)

When I asked the sys admin what my workflow should be, I was told "whatever your preference". I have kept them up to date with my thinking and they are interested in the results.

I would not recommend using any extreme methods (such as my script below) unless you have discussed it with whoever maintains VSS

  • You'd better spend your energy moving them to SourceGear Vault, a much better VCS which is targeted at those using VSS.
    – Andy
    Nov 24, 2014 at 20:51
  • 1
    Convince management to upgrade to TFS. I don't know if the migration tools Microsoft provides can go directly from VSS to the TFS (2013+) implementation of Git, but they have fantastic tools to move from VSS to TFVC, which is still miles ahead of VSS.
    – ravibhagw
    Nov 24, 2014 at 21:21

3 Answers 3


You're forgetting something - standard workflow with VSS is:

  • checkout working copy
  • (optionally complain others have some files locked)
  • do work on files
  • (optionally deal with complaints that you have files locked)
  • checkin files.

What you need to understand is that while you can get a read-only copy, you cannot change files or commit changes unless you have a checkout which locks files so no-one else can modify them. So while your concept of working independently by migrating a working copy to git regularly is laudable, I doubt it'll work in practice. You will have to perform a checkout (that locks files) at the last moment, merge these latest files from VSS into your git repo, and then checkin the resulting merge into VSS.If someone else is working on these files when you decide you want to merge, you'll have to wait for them to finish. Also you'll have to lock all the files, as you won't (easily) know which have been changed since you took your last read-only copy.

Its better to organize the work you're doing, or the files you're working on, with your colleagues and just use the tool as it was intended. The important part of that is to communicate and organize the team's development work rather than work independently like you want to do using git.

  • some very good points made, my problem with using VSS on its own, is the standard practice here is to commit when there is a "build". hence why i want to keep my "feature work/"experiments" in a git branch Oct 23, 2014 at 12:33
  • 1
    You might as well just keep them in a different directory - if you don't have a remote repo, a local git is only going to give you history. You woudl be far better off helping them migrate to a different SCM - I'd recommend SVN as the step from VSS to git is HUGE, whereas VSS to SVN isn't nearly as daunting from a sysadmin or management PoV. In a couple of years you can then migrate them again to Fossil, or git if absolutely necessary.
    – gbjbaanb
    Oct 23, 2014 at 13:00
  • local git gives me the ability to revert, bisect, jump between branches etc. All these things that i would struggle without now :p. I simply don't develop software without git anymore even at home, for personal projects that stay local. I agree I would be better off getting them to migrate the project, but that's unlikley, they did migrate to synergy a few years back but only for new projects, old projects like the one i am working on are in VSS. I can't really comment on whether they should replace synergy as I have not used it yet. Oct 23, 2014 at 15:29
  • 1
    gbgbaanb, I disagree about the migration. Folks new to the industry learn git and how it works. Making folks switch source control twice within a couple of years is unproductive imho. I would even make the case that vss directly to git is suitable precisely because the gap is go big. Just learn the new thing, not something 'close' to it. I've also seen huge number of svn users get really confused when moving to git as the same words mean different things. For those folks I wish they'd never learned svn at all to avoid that confusion. imho and ymmv of course :) Oct 29, 2014 at 11:51
  • 1
    @MichaelDurrant I sometimes wish I had never had SVN, but more because it got me hooked on a GUI! I spent the first few months with git searching for a GUI I liked. Now I find myself going straight to the VSS command line help :p Nov 3, 2014 at 9:40

I'm going to answer, "don't do this." The workflows are quite different, and you'll not have considered one and end up causing yourself, or worse your team, a lot of grief. Learn VSS, if nothing more than to make you appreciate other VCS more.



I have been using this bash script with a lot of success :)

Also I would now recommend 2 directories instead of 2 branches. It's a lot cleaner :)

If you have the support of your VSS admin, then you can follow something like below.

Otherwise you can use git for your own branches and general workflow and use VSS as intended, but in that case I would recommend a clean separation, not the interop solution I have gone for. My solution is more suitable as a migration step but even then I would use with caution.

  • Get working copy from VSS
  • git init
  • create a "vss_branch" branch
  • branch a "dev" branch from master
  • branch dev for each individual feature/bug
  • on feature completion, rebase to clean up comments (if I have been naughty)
  • merge into dev when features/bugs are ready
  • test dev
  • if all good merge dev into master
  • Synchronize my master branch with VSS
    • switch to vss_branch
    • get working copy from Visual Source Safe
    • commit into vss_branch with "ss history" as comment
    • pull vss_branch onto master
    • test master Synchronise VSS with master
    • "ss checkout" files I have changed (don't overwrite working copy)
    • "ss checkin" files I have changed (adding git comment as label)
  • pull master into dev

I have attempted to stick to our VSS workflow but be a little more robust with the separate VSS git branch which I never push to.

  • Fighting what your employer does won't win friends, and is unlikely to influence people. Either try and make a case for change (and if you lose, accept that with good grace); or accept that opinions differ. This is a WORKPLACE which has much more going on in it than personal preferences. Part of being in a workplace is accepting that there are some things you can't change. Nov 25, 2014 at 1:32
  • 2
    I totally agree, but I probably should have mentioned that 30% of the workforce already have a git/vss workflow, another 50% have a mecurial/vss workflow and the rest just avoid using VSS untill its time to submit a build. I am not going completely against stream here and I have actually discussed this with the sys admin and he is interested to see the results Nov 25, 2014 at 8:56
  • 2
    Oh dear oh dear. Now there is a disfunctional workplace! Nov 27, 2014 at 7:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.