Re: VB Project & SourceSafe question
From: Bryan Dickerson (txprphan_at_netscape.net)
Date: 02/28/05
- Next message: Ken Halter: "Re: How to become a MVP"
- Previous message: Jeff Johnson [MVP: VB]: "Re: Problem with mscal.ocx"
- Next in thread: Ralph: "Re: VB Project & SourceSafe question"
- Reply: Ralph: "Re: VB Project & SourceSafe question"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 28 Feb 2005 09:58:19 -0600
Sounds good, I'll give it some thought.
What about versions of OCXs, DLLs, EXEs vs. time-stamps?? Do you favor one
over the other? Right now I favor time stamps, 'cause I don't check out the
project file everytime I re-build the file and let it increment the version
number. I actually used to try and do that and found that the number that's
incremented is the build number, not the Major or Minor version so that the
version that gets on the OCX, DLL or EXE is likely to be the same as the one
before that I was trying to fix. That's my experience, at least.
"Ralph" <anonymous@discussions.microsoft.com> wrote in message
news:0b1201c51c22$3f282af0$a501280a@phx.gbl...
>
> >-----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
- Next message: Ken Halter: "Re: How to become a MVP"
- Previous message: Jeff Johnson [MVP: VB]: "Re: Problem with mscal.ocx"
- Next in thread: Ralph: "Re: VB Project & SourceSafe question"
- Reply: Ralph: "Re: VB Project & SourceSafe question"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
