3

My employer still uses VisualSourceSafe6. Everything is checked-in into the main project directory in VSS. They are not using branching in VSS. Check-in's are supposed to be ready for release to QA and should not break the build (not enforced).

I want to use git as my local repository so I can track changes per feature (branch) and have history of my changes before I commit them to VSS. I need this because some of the changes might span more than 3-4 days before they can be checked-in to VSS.

NOTE: my understanding for some git concepts is very new and might be offbase.

After reading these similar questions:

Following is what I was thinking of doing:

C:\VSS\ProjectA where I perform VSS specific actions get-latest-version, chechout, and checkin etc. The solution/project file will have bindings to VSS since other developers will still use VSS and some might use git with VSS like me.

C:\MY\ProjectA where I will be doing my development work and using git workflows.

To setup the folders I did:

  • Get latest version from VSS into C:\VSS\ProjectA
  • C:\VSS\ProjectA>git init and C:\VSS\ProjectA>git add ., this becomes my master branch
  • git clone C:\VSS\ProjectA C:\MY\ProjectA, this becomes my development clone

Q: If I have VSS bindings in my solution/project file, VisualStudio will try and connect to VSS even from my git cloned folder C:\MY\ProjectA. So I need to remove the VSS bindings after cloning, correct?

When working on a feature I need to:

  • get latest version from VSS into C:\VSS\ProjectA
  • Q: do I need to commit the changed file to the master git repository?
  • C:\MY\ProjectA>git fetch and C:\MY\ProjectA>git checkout, Q: correct?
  • do whatever branching, commits, merge, rebase etc in my development repository
  • get diff of my development repository and master repository and checkout those files in VSS
  • C:\MY\ProjectA>git push, Q: correct?
  • C:\VSS\ProjectA>git checkout, Q: correct?
  • C:\VSS\ProjectA>git commit, Q: correct?
  • checkin changed files to VSS

UPDATE it seems git for windows (VisualStudio2015) does not yet support pushing to non-bare local repositories, is there any workaround?

3
  • 1
    Don't. You will eventually get the wrong version of a file and reintroduce bugs that have been corrected earlier or remove functionality made by others.
    – Bent
    Aug 30, 2016 at 12:33
  • @Bent that's what I am afraid of, overwriting some change in VSS by mistake. But I really need a staging area where I can work on features and track changes before I can checkin to VSS Aug 30, 2016 at 12:37
  • this is a good idea. I know there's a TFS to Git utility, there should probably be a VSS to Git utility out there somewhere. As an alternative, you might want to try using Git in the VSS checkout, then killing the git directory etc when you get ready to check-in, and using git init on your next checkout to manage your changes between check-ins
    – deltree
    Aug 30, 2016 at 14:08

1 Answer 1

2

My way with VSS 2005 for your reference.

On project Day 1,

  1. Check out the whole project Recursively to a directory named projVss, e.g.
  2. Undo the checkout to release it to others.
  3. Copy the directory projVss to another named projMy
  4. Do git init both projVss and projMy

On any day N,

  1. Work on projMy. Do any versioning you like and leave projVss alone.

To submit your work,

  1. Commit your work and Cleanup any uncommitted files in projMy
  2. Check out the whole project Recursively to projVss. Commit changes that checked in by others to projVss without necessary review.
  3. Copy and overwrite the working files from projVss to projMy. Discard the changes from your files of old version and merge others' codes.
  4. Generate a patch by

    git diff lastSubmitVerHash head --name-only | zip ../projPatch.zip -@

  5. Apply the patch to projVss by extracting it and overwriting

  6. Commit the patch in projVss. Review the merges.
  7. As VSS does not add files automatically when checkin, generate a patch of newly added files by

    git diff lastSubmitVerHash head --name-only -diff-filter=A | zip ../projPatchNew2Vss.zip -@

  8. Similarly, as VSS does not remove files automatically when checkin, list out files to be deleted by

    git diff lastSubmitVerHash head --name-only -diff-filter=D

  9. Check in recursively in VSS.

  10. Extract the files in projPatchNew2Vss.zip to VSS
  11. Delete files according to 14, manually, that's what I do, since it should not be many.

On day N+1, repeat 5 - 16, you should be able to do 8 - 14 quickly to enable a short check-out(locking) time.

The problem

You still need to pay attention to VSS Checkout warnings, for the file(s) you need to update. If it is being checked out by others, you still need to ask your teammate to release it.

Your Answer

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

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