Versioning...VSS question

GriffithsJ · Joined: 04 Oct 2007 Posts: 14

I previously posted the following message to the SourceSafe news-groups, but
afterwards thought that maybe I should have posted it to the VB Enterprise
news-group to reach a more related target audience.

Any pointers would be most helpful

Thanks

Griff
---------------------
Hi

I'm going to be setting up SourceSafe for a fairly large n-tier "enterprise"
application. It will be a component-based application and we therefore
envisage many hundreds of separate projects (in truth, this already exists
but we're fairly convinced it was set up with very little thought....). So,
any comments on the following, particularly concerning merging will be of
great benefit, particularly if they're along the lines of "you don't want to
do that..."

I imagine that we would do the following:

Create the following project hierarchy
$\OurApplication\Development\

All components, MDI shell etc, etc will be build under these, so for
example:
$\OurApplication\Development\Component1
$\OurApplication\Development\Component2

These would be developed aiming towards the first release. Imagine that the
versions to be released of Component1 is v1.0.0.0111 and Component2 is
v1.0.0.005. We would then create the following directory structure:
$\OurApplication\Version1\
and then share and branch the code into this.

Continual development would continue under the \development\ directory and
bug-fixes, updates under the Version1\ directory structure. When Version2
is ready, we'd do a similar sharing/branching from the development
directory.

However, imagine that since version 2, there have been numerous updates to
the development code and also numerous patches applied to Version1 and
Version2. If someone then reports a "serious" bug that has to be fixed in
Version1, Version2 and Development, then what's the best way to go about
this? Would it be best to bug-fix the three applications independently, or
would we want to fix it in one and then try the "merge" facility? I'd be a
bit worried about doing anything too automated, since the majority of the
code differences will be nothing to do with this specific bug fix. Any
ideas/suggestions?

Many thanks in advance

Griff

Archived from group: microsoft>public>vb>enterprise

Ken Halter · Joined: 04 Oct 2007 Posts: 8

Personally, I set up SourceSafe using a structure that's as close to my development PC as
I can get it so it's easy to navigate around in. A rough outline would look something
like....

Source
MajorProject1
Part1
Part2
MajorProject2
Part1
Part2
CommonComponents
SomeReusableDLL
SomeHandyOCX
MiscClassesMods <--- These can be shared between any number of projects (through
sourcesafe)
SomeClassIAlwaysUse
SomeBasMod

We don't get too fancy with SourceSafe versioning. Since we ship our PCs fully
loaded/configured, we make a drive image right before shipment. When I *really* want to
freeze a project in time, I use WinZip. Zip comments are pretty handy along with a zipped
ReadMe to explain why the project was frozen at this point. That zip contains the source
and compiled components to recreate that point in time. When needed, unzip, register
everything and you're set.
About the only version we force ourselves to do in SourceSafe is labelling the shipped
version. I really think WinZip is better all around for this though. At least it's far
easier to understand exactly what it is that you have. I haven't had a corrupt zip file
yet.
I check in often. I don't care if my first release happens to be version 50 in source
safe. It's just a number. Higher numbers are newer. That's how much effort I put into
versioning . As soon as I get something working the way I want, I check it in and
usually check it right back out to continue work. I do this because I get distracted quite
often at work and it's usually easier to just undo the checkout and start over than it is
to remember where I left off and take a chance at really messing things up. It's also
handy for those late nights when you've been typing code for 4 hours and suddenly you say
"what the hell am I thinking!?.... undo checkout!"

--
Ken Halter - MS-MVP-VB - http://www.vbsight.com
Please keep it in the groups.
"GriffithsJ" wrote in message
news:%23Z6rchCfDHA.944@TK2MSFTNGP11.phx.gbl...
> I previously posted the following message to the SourceSafe news-groups, but
> afterwards thought that maybe I should have posted it to the VB Enterprise
> news-group to reach a more related target audience.
>
> Any pointers would be most helpful
>
> Thanks
>
> Griff
> ---------------------
> Hi
>
> I'm going to be setting up SourceSafe for a fairly large n-tier "enterprise"
> application. It will be a component-based application and we therefore
> envisage many hundreds of separate projects (in truth, this already exists
> but we're fairly convinced it was set up with very little thought....). So,
> any comments on the following, particularly concerning merging will be of
> great benefit, particularly if they're along the lines of "you don't want to
> do that..."
>
> I imagine that we would do the following:
>
> Create the following project hierarchy
> $\OurApplication\Development\
>
> All components, MDI shell etc, etc will be build under these, so for
> example:
> $\OurApplication\Development\Component1
> $\OurApplication\Development\Component2
>
> These would be developed aiming towards the first release. Imagine that the
> versions to be released of Component1 is v1.0.0.0111 and Component2 is
> v1.0.0.005. We would then create the following directory structure:
> $\OurApplication\Version1\
> and then share and branch the code into this.
>
> Continual development would continue under the \development\ directory and
> bug-fixes, updates under the Version1\ directory structure. When Version2
> is ready, we'd do a similar sharing/branching from the development
> directory.
>
> However, imagine that since version 2, there have been numerous updates to
> the development code and also numerous patches applied to Version1 and
> Version2. If someone then reports a "serious" bug that has to be fixed in
> Version1, Version2 and Development, then what's the best way to go about
> this? Would it be best to bug-fix the three applications independently, or
> would we want to fix it in one and then try the "merge" facility? I'd be a
> bit worried about doing anything too automated, since the majority of the
> code differences will be nothing to do with this specific bug fix. Any
> ideas/suggestions?
>
> Many thanks in advance
>
> Griff
>
>