VB Project & SourceSafe question

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Ralph (anonymous_at_discussions.microsoft.com)
Date: 02/26/05 

Date: Sat, 26 Feb 2005 08:43:06 -0800

>-----Original Message-----
>Here at my company, I am the primary VB programmer, and
I have one other guy
>that is my "backup" when I'm out. We use SourceSafe for
all company-related
>projects, except unless there are some additional
references or components
>to add to a project, I don't check out the Project file
to make changes to
>the various forms, etc. Thus I assume (I know that's
dangerous, but...)
>that the version number doesn't get incremented when I
make a new EXE,
>correct? So I've recently run into some interesting
challenges when doing
>updates via installation software that I suddenly
realized were depending on
>version numbers, not timestamps. (Cue Homer
Simpson, "DOH!!").
>
>My question is this: How do others of you do versions of
programs when there
>are teams of programmers potentially working on one
project?
>
>TIA!
>Bryan
>

Bryan,

IMHO, the only sane way to manage multiple developers is
to create a separate 'playpen' for each developer and
maintain a main storage separate from the developers, all
within the same database.
e.g, a small project with one control and two components
would look like this...
$Top Database
     /Main
          /Exe_Main Project
          /Dll_1 Project
          /Dll_2 Project
          /Ocx Project
     /Developer_1
          /Exe_Main Project
          /Dll_1 Project
          /Dll_2 Project
          /Ocx Project
     /Developer_2
          /Exe_Main Project
          /Dll_1 Project
          /Dll_2 Project
          /Ocx Project

In addition you will want to assign each programmer their
own VSS user and keep most administrative duties to
the 'Admin'. (Sidenote: Don't load a project in the IDE
and modify as an Admin. Save Admin for
production/deliverable builds out of main storage only.)

Manage the playpens using pins and shares from main
storage.

Make sure each developer labels any significate changes.

Never check any items back into main storage that aren't
complete, unit tested, and ready. This is
called 'breaking the build' and stiff penalities should
be enforced for breaking it. - beer for the team,
standing on a chair and singing, wearing a SpongeBob T-
shirt to all meetings. &etc.

As Ken noted, confining major work to one project per
developer at a time will ease most of your problems, but
can still get ugly if you are not careful and don't have
a reliable main source to go back to.

One trick we use is lay-out an entire project in the
beginning with essentially dummy components - Ocxs that
draw a large box with the text "Watch This Space" or
bitmap of controls, components with interfaces and
signatures, but no functionality, etc.

We then 'pin' these versions, so every programmer will
have all components in their copy of main. When the
component is finished, checked in and tested, the pin is
removed, and ou la the component is there and working
(hopefully) with no real intervention on the part of a
developer to "add" the 'new' component, or louse up his
compile or 'build'.

Having 'playpens' also keeps developers from accidently
trespassing on others property, yet allows anyone to act
out "What If" scenarios without danger to the main source.

Rather vague, but should get you started.

-ralph

Quantcast