Warning: Rant ahead!

So a question popped up on the MSDN SharePoint developers forum about how to use integrate WSS and Visual Studio in order to save files edited in Visual Studio direct into WSS including using Check In/ Check Out.

After myself and one other suggested using real Source Control tools the OP rejected our advice rejecting TFS as too complex and that SharePoint provided all that they needed being:

“a team of 3 database developers taking care of our SQL databases. Working results mostly are .txt files to control the sql jobs and interfaces”

Below follows my reaction:

<rant>

Version Control is not Source Control.
Version control tracks the changes against a single file.
Source control allows track changesets, ie Dev A checked in these n files at y time, they edited these lines.
I suppose you could publish a list as a published link and use that as a network storage location to save to. I strongly recommend using a real source control system over SharePoint version control. Even for ‘just database scripts’….
Say you have a need to set up a mirror of the current configuration (ignore data) that you have from a point in time a month ago for some reason (this DOES happen), now your DBA have changed many files in the mean time. How do you get the scripts to set that up easily? Using WSS and Version Control it’s going to be hard. Using a Source Control product (even VSS) is better as you can pull the state of the source database at a given point in time.
Version Control doesn’t handle forks or merges.
To use WSS as a source code repository is wrong.
Can you do it? Yes.
Should you? I strongly say NO!
By all means use WSS for collaboration and communication, just for the love of all that is good and right don’t use if for Source Control.
Use VSS, use SubVersion, use CVS, use TFS, hell even use RCS!

Sure TFS might be overkill in this situation, but I’d suggest that using WSS as Source Control is something of an anti-pattern.

<rant />