Chris, I know your pain. I have worked several places that tried to do things the way you indicate and as someone who is quality conscious, has risk aversion, and a role is software configuration manager, your scenario drives me insane. Unfortunately, my experience has taught me that the people that you are dealing with will not change even if you come up with great empirical evidence that their processes and methodology is putting you and your customers (internal or external) at risk. Maybe if you can get your manager to read a book like "Software Configuration Management Patterns" and accept it as "best practices" I think you might be able to advance your position.
In hopes of helping you sway the wrong headedness of your team, I'll throw in a point about each of the topics you brought up...
1) Using private workspaces if tough with SourceSafe, so you are partially hamstrung by your tool. There actually are only a few tools that allow you to have a private workspace to commit your individual changes before then committing them to something like an integration branch. There are a lot of ways to make this happen regardless of the tool, but it can add some work and discipline. When I did use SourceSafe I had scripts that I would create a "branch" (i.e. new copied project from the mainline. Once that release had gone to Production it would be merged back into the main codeline and any other open branches derived from the same codeline. Takes some dedicated work to do this, but certainly saved our bacon on more than one occasion. I strongly believe in branches per project and in larger teams (more than 2-3) feel that branches per user is highly desired. I never tried to use the shadow directory feature of SourceSafe, so cannot speak to it's effectiveness, or areas where it might have issues. With regard to a continuous history, any time you branch a file it's history although ancestral, will also branch. Thus, when you merge from a branch you are only going to get the change at time of commit...but that means that the mainline will still have a consistent history with regard to project iterations. And since you don't "delete" a branch (you can archive without loosing the history), you can go back to a branch and see the specific change history for the iterations within that project.
2) I'll reiterate...I like to branch the codebase for each project, thus you have the entire codebase for the product (at some point you need to project or productize the structure of the repository). I don't see how only having individual files that are not all inclusive is a good thing, but than I'm also used to automated builds and continuous integration, where you do need the whole codeline to do your compilations. There may be less motivation or need to do this if the code base is old school html/asp.
3) SQL "code" is treated as source code as well. All SQL should be scripted and committed to the repository as part of the project, thus it can be manged, versioned, tagged (labeled). Seems like a lot of database developers have a hard transition from looking at the SQL as objects because a lot of them do the changes in a database instead of first scripting them and then executing them.
4) There are a couple of approaches to the documentation. One of the problems with keeping big fat .doc, .ppt, xls docs in a source repository is that it bloats your repository...not an issue if you are using and enterprise system, but SourceSafe is NOT that system. Depending on your code base and supporting documentation, you can easily bloat the SourceSafe database so that even nightly runs of analyze won't fix all the problems and it will ultimately corrupt. Depending on the nature of the documentation, we kept things both in our repository as well as is SharePoint. The way I like to look at it is that any docs that I need to build and/or deploy the release I want in the repository...all the other project related supporting documents can go into another document management system that doesn't require giving up valuable licenses (for purchased source control systems). Since we use Subversion, we can dump just about any file system object that we desire into the repository...
I've no doubt you will get some other thoughts on all this...probably some of them contrary to what I've written.
Best of luck,
~Robert Smith
On Jan 31, 2008 10:41 PM, Chris Judge <
cjudge1966@...> wrote:
Hi all,
I'm working on a project in which SCM is mostly limited to source code
access control using MS SourceSafe. My manager (in case he reads
this) is great at managing people, but he doesn't have a technical
(software engineering) background so when arguments flare up, he
doesn't necessarily know who is right.
The problems:
1. We are not using private work-spaces. I have tried to explain to
the other programmer that by using a common workspace we "step on each
other's toes", but he maintains that it is better to have a common
workspace. I told him that SourceSafe provides a "shadow directory"
that works as a sort of integration directory where the current stable
build can reside, but he refuses to budge.
2. Same programmer insists on creating a new project for each release.
I have tried to explain that we lose the historical continuity of
each file, but again, he insists that a clean break on each release is
better. I told him that we can use labels to identify baselines, but
he refuses to budge (this is a common theme). Another side-effect of
creating a new project for each build is that each "project" does not
contain all files that make up the system - instead, each "project"
only contains those files that changed during that particular build.
3. Same programmer insists that SQL stored procedures do not need to
be maintained in SourceSafe.
4. Same programmer insists that documentation (requirements, design
documents, etc.) do not need to be maintained in SourceSafe.
I argue that these are bad practices, other programmer (who,
incidentally, thinks an unrolled, nested loop is easier to maintain
than a nice, compact nested loop) thinks I am insane. Manager doesn't
know who to believe.
Help!
cj
--
~Robert
Having problems with message search?
Offline 
Send Email