Sourcesafe's ACCURSED 'share' feature - any workarounds?

Sourcesafe's ACCURSED 'share' feature - any workarounds?

Post by FUspamme » Fri, 05 May 2006 23:23:51

I have to use VSS because it's the standard at the office.

My VB source, class libs, & custom controls are in 3 separate top-level
branches in my hard drive.

You can sense where this is going - whenever I want to include a common
file from another directory, VSS' accursed 'share' features won't let
me keep the common files where they belong.

VSS forces me to make a bombed-out mess of my source code directory,
spewing a copy of every piece of *** there is into it.

Yes, I know VSS supposedly keep track of it all, but anyone who
programs after the age of 12 knows why this is a bad idea. Also I'm
writing some utilities that work with the code itself and having
several copies of the same thing would get very messy.

Is there any workaround to this accursed share "feature" so that I have
only one copy of a common file in my local hard drive even though many
projects use it?

Sourcesafe's ACCURSED 'share' feature - any workarounds?

Post by Ken Halte » Sat, 06 May 2006 00:34:15

You can always set the 'Remove local copy after Add or Check In' option.
Personally, I'd rather have copies everywhere and just make sure I 'Get
Latest' when opening the project. All of our source is on our network.
Nothing is stored locally (except the 'sanity check' backups)

Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..
DLL Hell problems? Try ComGuard -


Sourcesafe's ACCURSED 'share' feature - any workarounds?

Post by FUspamme » Sat, 06 May 2006 02:00:47

Thanks but...but...that still means my directory looks like a mess.

Sure, when everything is checked in and I'm not doing any work and
everything comes to a halt, then yeah, my directories look like I need
them to.

So according to MS, only when I abandon my project and it becomes a
ghost town, does it look orderly?

It's not really necessary to trash your working directory to make sure
you have everything, because from VB you could get or check out the
entire project.

Is there a workaround so that VSS lets you keep things orderly while
doing actual work in your project? You can do this with VB alone, but
not when VSS gets into the picture.

Sourcesafe's ACCURSED 'share' feature - any workarounds?

Post by Ralp » Sat, 06 May 2006 02:29:05

I am assuming you are using VB6 or lower (VBc). If not then you need to post
this query in a dotnet group.

You can safely ignore these first three comments... <g>
[IMHO, complaining about how you think a tool should work, instead of
learning how the tool does work, is a silly waste of time and effort.
Second, when it comes to a SCCS, VBc and VSS are joined at the hip and when
you compare VSS to any other tool available for VBc - it is the best tool.
If I had an evil streak I would recommend StarTeam, PVCS, or WinCVS and let
you discover that on your own.
Third, millions of development organizations have used VSS successfully to
support a wide-variety of configurations, there is no reason you can't adapt
it to fit yours.]

VSS and VBc share one common concept - they are both based on a 'project' or
'deliverable'. You ignore this fact at your peril.

Without knowing more about your problem domain it is impossible to give a
specific solution, but a good place to start is to back up and re-examine
how you have set up your projects in VSS.

You mentioned "Source", "Class libs", and "Custom Controls". Since these
(with the possible exception of the latter - assuming OCXx) are rather vague
descriptions of a 'deliverable', then it appears a good place to start is
reorganizing VSS to create new stores for EXEs, DLLs, OCXs, shared classes,
shared BAS, etc. ie, something based a bit more on logic.

The reason you have "a bombed-out mess" and pieces of "crap" is because you
designed it that way. Garbage in - garbage out.

After you worked with this for a while on a POW or legal pad, several
obvious workable configurations will start to show themselves. I also
suggest you take a look at the 'Pin' feature.

Once you have broken down your VSS projects into 'deliverables' and are
still having trouble, post your design and we can likely help with the


Sourcesafe's ACCURSED 'share' feature - any workarounds?

Post by FUspamme » Sat, 06 May 2006 03:48:56

Okay, oh snarky one, like this :

+ CommonLibraries
- ErrorHandling
- WindowsAPI
+ CustomControls
- AnimatedCommandButtons
- ColorizedSpreadsheet
+ Applications
- SuperWebBrowser
- ExtraCoolMailReader

Obviously if I'm working on the "ExtraCoolMailReader" I don't want
WinAPI header files in the dev\Applications\"ExtraCoolMailReader"
folder,I want them to live and be checked out to the
\dev\CommonLibraries\WindowsAPI folder.

If anyone knows of a workaround, I'd appreciate it.

I have to say Ralph's post was a bit presumptuous and snarky, for
someone who didn't seem to understand my postings.

The bombed out mess comes from the way VSS does things. I'm trying to
do it right, but VSS won't let me.

And if we all bend our knees to the ways things already work, that's a
recipe for stagnation and mediocrity. Does your boss know that's your
engineering philosophy?

Not to mention I'm not exactly going to take my programming cues from

I design no *** or garbage, thankyouverymuch. And yes I know things
are compartamentlized in projects - did you miss the gist of my
posting? But projects also have the capability of referencing each
other. And sometimes they share the same level in the VSS hierarchy.
And VSS makes a mess in your application directory because of it.

Any hints for overriding VSS' crappy garbage way of doing things, I
would be grateful.

Sourcesafe's ACCURSED 'share' feature - any workarounds?

Post by Ralp » Sat, 06 May 2006 04:23:34


"snarky" is very apt in my case (assuming I know what it means) and
"presumptuous" is my middle name.

Let me chew on it a bit and I will get back to you with a solution - Mine of
course and very presumptuous, but I will try and avoid 'snarky' the second
time around.


Sourcesafe's ACCURSED 'share' feature - any workarounds?

Post by FUspamme » Sat, 06 May 2006 05:16:02

I thought you were going to be all upset. See, maybe you're not so
bad. Sorry if got snarky in response myself, which is sort of a less
inflammatory word for " *** y".

Sourcesafe's ACCURSED 'share' feature - any workarounds?

Post by Ralp » Sat, 06 May 2006 09:58:50

Hey, the truth is the truth. I was *** y.

Would like some clarification...

The "custom controls" are .OCXs, correct?
"Common Libraries" are a loose collection of BAS and CLS files, or are they
DLLs that supply support?
And exactly do you mean by "WinAPI header files"? VB doesn't have headers.

Could you perhaps supply your directory structure again - only this time
applify with file types (extensions)?
Something like this...
+ CommonLibraries
- ErrorHandling : .cls, bas
- WindowsAPI : bas
+ CustomControls
- AnimatedCommandButtons
acb1.ocx - cls
acb2.ocx - cls, bas
- ColorizedSpreadsheet
+ Applications
- SuperWebBrowser: StandardExe.exe
(frm, bas, cls, ???)
- ExtraCoolMailReader: ActiveX.exe


Sourcesafe's ACCURSED 'share' feature - any workarounds?

Post by UmljaGFyZC » Tue, 09 May 2006 00:22:02

After reading all the replies and counter-replies to this original message,
one idea that I never saw mentioned is ...

Reference your "shared" source, classes, and API functions from a single
folder; this way, in your .VBP file, the path to SharedClass.cls would be

In this way, you can separate your projects in VSS the same way you have
them on your local drive. There is no sharing issue from the VSS viewpoint
since all shared code is referenced from a single location in your .VBP files.

In your hierarchy you specified in a later post, your ExtraCoolMailReader
project file would contain a reference to: ..\Common\WindowsAPI instead of
simply WindowsAPI, where it is looking in the same directory as your project

Gee, I hope that makes some kind of sense.

Sourcesafe's ACCURSED 'share' feature - any workarounds?

Post by Mike Blake » Tue, 09 May 2006 23:12:56

In article < XXXX@XXXXX.COM >, Richard J

It certainly does to me.

Visual Studio's concept of a source control hierarchy to disk mapping is that
there's a single "Unified Root" below which the hierarchies match while VSS is
more flexible allowing you to set a working directory on a per directory or
file basis. . Visual Studio seems to automatically choose the root when the
solution file is created and doesn't update it as you add projects. As a
result, Visual Studio gives you many (somewhat intimidating) warnings that
other developers will have problems with some of these layouts.

I found that this can be resolved by going into the VS Change Source Control
dialog (where the relative paths are typically empty), selecting all the
solution/projects and unbinding them. (Sometimes you'll need to click unbind
for each project). I then select all the projects/solutions and click bind. VS
then chooses an appropriate binding spot and uses relative paths from that
unified root to each project.

Hope this helps.