I'm sure others will have better replies, but here is my take on what
you've presented:
>
> 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.

Managing programmers with all different sorts of personalities is a
key aspect of SCMing. Oftentimes we are seen as junior programmers,
when in fact we are closer to system architects. Respect can be a
factor, and you'll have to continue working hard being firm on these
crucial points.

Getting resistance from some programmers is fairly common. It is
really crucial that your manager, or as high up the chain of command
as you can get, make it very clear company-wide that conformance to
the CM plan is vital and WILL happen. (If you don't have a CM plan,
really focus on getting one, even for small teams). The cost is to
the manager and the development effort first and foremost when things
go wrong in sourcesafe and release management, so it is in everyone's
best interest to make sure everyone conforms to one standard.


>
> 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.

I agree that shadow directories are a step in the right direction,
although SourceSafe is inherently limited in what it can do. Other
arguments I would use would be 1) ability to back out selected code
changes more easily when necessary (it is always necessary at
some point, after all), 2) ability to smoke test builds, giving both
a 'latest' sandbox and a 'stable' sandbox, 3) Ability to phase in
newer, larger development efforts.


>
> 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.

I kind of agree with the programmer on this one, but mostly because of
VSS's limitations, not because of your arguments (which are quite
valid). I think if I was in your place, I would step back and have a
big meeting with the programmers and the manager, and define the real
requirements of your build system. The programmer is trying to make
project branches, which VSS can't really do (only getting deltas in
new projects, like you've seen). There could be valid reasons for
branching that outweigh history needs. Others here may have elegant
VSS solutions for this, but I would seriously look at migrating away
from VSS at this point to something like CVS or Subversion that can
handle branching and merging.

>
> 3. Same programmer insists that SQL stored procedures do not need to
> be maintained in SourceSafe.

Database CM is a common point of contention, too. I will back off on
WHAT repository as long as the requirements of the CM Plan are
maintained (i.e. the programmer has to prove that the sprocs ARE
maintained in a version controlled space somewhere, that they DO have
meta-data attached to builds,releases, that you/he can audit and
recover them quickly, that they ARE backed up daily at the latest,
that they ARE migrated to QA in conjunction with builds in a
pre-approved manner, etc.). If the CM Plan states that SCM personnel
need to have full control over all code, then that includes DB code,
and you have to have access to, audit, and approve the programmer's
sproc repository/release system. Consequently, you should have the
power to demand they version controlled in your system if he can't
provide an adequate one, and QA should obviously team up with you not
to accept anything that is not properly version controlled and
tracked.

>
> 4. Same programmer insists that documentation (requirements, design
> documents, etc.) do not need to be maintained in SourceSafe.

Same answer as above. The repository is negotiable, but the SCM
system is not. Management needs to enforce a process for the
project's own well-being. If SCM is allowed to be by-passed by
"agile developers", then get out of that job, quickly. It is a
guaranteed train wreck.

> 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.

Manager needs some SCM training. There are some great books out
there, and some good articles on the MSDN. Again, I would push the
PMP angle. There is a reason SCM exists, and it is exactly because of
problems that will definitely occur with quality and deliverability
when CM processes aren't followed. That is also why CM practices are
largely integrated into all ISO and CMMI requirements.

>
> Help!
>
> cj

Good luck, and hang in there. You're doing the right things.

-buildpuppy (with 15 years SCM experience in every kind of programming
shop imaginable)