VSS 6 & VB 6: Multi-User Dev & .VBP files

[Tom]

We are using Visual SourceSafe 6 with Visual Basic 6 on a project with
multiple developers. The project consists of one .VBP with multiple forms,
classes, components, etc etc. Each developer 'creates a project' on their
own hard disk from the 'master' VSS database on the network; then they check
in and check out the necessary forms, etc that they need to work on.

What I would like to know is what is the best way to handle the .VBP project
file among those multiple developers? Should it always be checked in EXCEPT
when a developer is adding a new form, reference, ActiveX component, etc? Or
should EVERY user check it out when they do anything (which I don't think is
possible anyway)? The reason I am asking this is that we have been doing
the first thing I mentioned (only checking out the .VBP when adding/deleting
something); however, we have had instances of someone 'refreshing' the .VBP
only to find that they have lost the 'reference' to their new form,
component, etc. This seems to happen on a regular basis - again, no problem
with checking out forms and other items, just how and when should you
checkout and/our refresh the .VBP file?

I have used VSS for awhile now, but this is the first VB project I have used
it on with multiple users working on the same VBP. Any advise appreciated.
Thanks in advance.

/Tom S

[Guillermo Talento]

We have been using VB & VSS for a long time and have not experienced the
problems you mention.

Our method is the following:

1) Do not allow multiple checkout
2) VBP files is only checkout when you need to, add a form, etc. Once the
form is added, the VBP and the new form (empty) is checked in. Then only the
form is checked-out.
3) If you only refresh the VBP file, you only bring that file to your local
directory, instead, close the project, and load the project again, and when
VSS ask to refresh the whole project click YES. That will refresh the VBP
file and bring along the new forms created.

Hope this helps.
Guillermo Talento
Insight S.R.L.
ins...@adinet.com.uy

Tom wrote in message ...

[Todd McDermid]

Been having those problems forever! Too bad MS divisions don't get together on
these two development tools...

Anyway, here's what we do:

First, ALL of our guys are required to use the "always save before run" option
in VB, due to it's notorious ability to GPF and lose all your coding changes...

Since a save requires that the VBP be saved as well, VB wants the VBP file
read-write. Lord knows why - but as long as you haven't added, removed or
renamed a form, module or component, the VBP file doesn't _really_ change, it
just reorders all of the information in it - that's what VB wants to save.

So we have the problem of having everyone having to have the VBP read-write, but
still, we want control over the REAL changes made to the VBP. Therefore, we've
resorted to a brain-ware approach (hard for developers, I know... ; ))
1. Everyone checks out the VBP (multiple checkouts), but (of course), only one
checkout on any other file is allowed.
2. Work as normal, checking out and in files in the project as you need. We
have a VERY hard rule, probably not as strict as other places, but - all
developers MUST be able to CTRL-F5 (full compile) PRIOR to checking in ANY file,
and during a check in, ALL checked out files must be checked in. This
guarantees that any other developer will only receive compile errors caused by
himself.

Here comes the exception:

When one of them needs to add, remove or rename a project component (including
adding references), they have to do the following:

1. UNDO the checkout to the VBP, THEN check it out again. This does two things
that are VERY important. First, of course, it gets them the latest version to
update. Second, and most important, is that whatever changes they are going to
make are made to the latest version according to VSS. Some of the developers
here thought that they could do the same thing simply by getting the latest
version w/o undoing and checking out - but it doesn't work that way, because
even though you may indeed have the latest version on your HD, VSS thinks that
you still have the older version checked out, and any check in will try to merge
your new one with that (possibly) older version.

2. Make your changes, and make 'em quick, in case someone else is trying this
same VBP update procedure. CTRL-F5 to make sure your changes are OK.

3. Check in the VBP.

The end result is that VSS now has your latest version of the VBP, and the
project compiles. The probable result for the other developers is that the next
time they fetch the latest version of files, they won't get the VBP (since they
have it checked out), and therefore might not be able to compile successfully,
right? Well, referring to (one of) the above rules, the developer should always
be responsible for an inability to compile. Even though they haven't changed a
thing, it's still true. Out developers are instructed to undo and re-check out
the VBP if they get a compile error they aren't familiar with (i.e.: they didn't
just cause).

This "process" has worked for us very well, and so far, we haven't "lost" any
forms into the sometimes black hole that is VSS. We'd like VB and VSS to get
along better, specifically, not having to have the VBP read-write when no real
changes are being made.

HTH

[Weston Morris]

Great description of a workflow that .....works!
Weston

Todd McDermid <mcde...@tradetec.com> wrote in message
news:393E7A1D...@tradetec.com...