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?

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?

--EDIT--

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

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

My thinking is to follow a work flow like:

• 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

Of course 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 have attempted to stick to this workflow but be a little more robust with the separate VSS git branch which I never push to.

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

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?

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

My thinking is to follow a work flow like:

• 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

Of course 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 have attempted to stick to this workflow but be a little more robust with the separate VSS git branch which I never push to.

I have put together the beginnings of a bash script to follow this but I wanted some advice on my proposed workflow before I go any further.

note this question has been split up & moved from other posts, following advice from members apologies if its still too broad, I welcome any advice to improve the question http://stackoverflow.com/questions/26511715/bash-script-for-vss-and-git-interop-review-needed http://codereview.stackexchange.com/questions/67664/bash-script-for-visual-source-safe-and-git-interop-to-use-git-with-a-ss-databa

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

My thinking is to follow a work flow like:

• 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

Of course 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 have attempted to stick to this workflow but be a little more robust with the separate VSS git branch which I never push to.

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