VB, References & Source Safe 
Author Message
 VB, References & Source Safe

Hi,
    My team is devloping VB COM objects, alot of which reference each other.
We are also using SourceSafe.
The problem is that when one developer extracts a project from the archive
that has just been edited by another user then the project will often
complain the references are incorrect.  You have to go and check out the
project, set the references, and check it back in again.  It is such a wase
of time.  How do you get round this ?  I have tried playing around with
project compatability options, but to no avail.

Regards
    Ben



Sun, 15 Oct 2000 03:00:00 GMT  
 VB, References & Source Safe

Quote:

>Hi,
>    My team is devloping VB COM objects, alot of which reference each
other.
>We are also using SourceSafe.
>The problem is that when one developer extracts a project from the archive
>that has just been edited by another user then the project will often
>complain the references are incorrect.  You have to go and check out the
>project, set the references, and check it back in again.  It is such a wase
>of time.  How do you get round this ?  I have tried playing around with
>project compatability options, but to no avail.

>Regards
>    Ben

SourceSafe is really designed to be that way. That is, only one developer
can make changes to a form, module, or project at any given time. One
developer has to make the changes and checks the changes in before another
developer can do another change. I know that this is such a waste of time
since it is very similar to a bottleneck effect.

To get around this, what I suggest is that every developer has his own copy
of the whole project and in a directory different from the SourceSafe
working directory. Then he can make his changes in that copy, do compilation
and testing. Now, if the project is still checked out, then he has no option
but to wait until the developer can check it out himself. But if he can
check it out, he should check it out and then compare his copy of the
project with that of the SourceSafe copy. (WinDiff from Visual Studio is
very good comparator). After comparing and synchronizing the copies, he then
updates the SourceSafe copy, and finally checks it back in.

I know this will be a waste of disk space but at least all the developers
are productive at any given time.

No use in playing around with project compatibility since it just applies to
any ActiveX OCX/DLL which will be registered in any machines.



Sat, 21 Oct 2000 03:00:00 GMT  
 VB, References & Source Safe

You need to use Binary Compatibility.

Matthew



Quote:


> >Hi,
> >    My team is devloping VB COM objects, alot of which reference each
> other.
> >We are also using SourceSafe.
> >The problem is that when one developer extracts a project from the
archive
> >that has just been edited by another user then the project will often
> >complain the references are incorrect.  You have to go and check out the
> >project, set the references, and check it back in again.  It is such a
wase
> >of time.  How do you get round this ?  I have tried playing around with
> >project compatability options, but to no avail.

> >Regards
> >    Ben

> SourceSafe is really designed to be that way. That is, only one developer
> can make changes to a form, module, or project at any given time. One
> developer has to make the changes and checks the changes in before
another
> developer can do another change. I know that this is such a waste of time
> since it is very similar to a bottleneck effect.

> To get around this, what I suggest is that every developer has his own
copy
> of the whole project and in a directory different from the SourceSafe
> working directory. Then he can make his changes in that copy, do
compilation
> and testing. Now, if the project is still checked out, then he has no
option
> but to wait until the developer can check it out himself. But if he can
> check it out, he should check it out and then compare his copy of the
> project with that of the SourceSafe copy. (WinDiff from Visual Studio is
> very good comparator). After comparing and synchronizing the copies, he
then
> updates the SourceSafe copy, and finally checks it back in.

> I know this will be a waste of disk space but at least all the developers
> are productive at any given time.

> No use in playing around with project compatibility since it just applies
to
> any ActiveX OCX/DLL which will be registered in any machines.



Sat, 21 Oct 2000 03:00:00 GMT  
 VB, References & Source Safe

Quote:

>You need to use Binary Compatibility.

>Matthew

As I've said, you only use the version compatibility if you are developing
an ActiveX component, whether OCX or DLL. If you are just concerned with the
files in your project being up-to-date, then there's no use for this.
Version compatibility is for the product of your project (*.dll, *.ocx) and
not the source code of your project (*.frm, *.bas, *.cls, *.ctl).


Sun, 22 Oct 2000 03:00:00 GMT  
 VB, References & Source Safe

Quote:

>You need to use Binary Compatibility.

>Matthew

As I've said, you only use the version compatibility if you are developing
an ActiveX component, whether OCX or DLL. If you are just concerned with the
files in your project being up-to-date, then there's no use for this.
Version compatibility is for the product of your project (*.dll, *.ocx) and
not the source code of your project (*.frm, *.bas, *.cls, *.ctl).


Sun, 22 Oct 2000 03:00:00 GMT  
 VB, References & Source Safe

Quote:

>You need to use Binary Compatibility.

>Matthew

As I've said, you only use the version compatibility if you are developing
an ActiveX component, whether OCX or DLL. If you are just concerned with the
files in your project being up-to-date, then there's no use for this.
Version compatibility is for the product of your project (*.dll, *.ocx) and
not the source code of your project (*.frm, *.bas, *.cls, *.ctl).


Sun, 22 Oct 2000 03:00:00 GMT  
 VB, References & Source Safe

Palos,

Based on

Quote:
> >The problem is that when one developer extracts a project from the
archive
> >that has just been edited by another user then the project will often
> >complain the references are incorrect.

I assumed that the things being referenced are ActiveX DLL's or EXE's?

Based on

Quote:
>  You have to go and check out the
> >project, set the references, and check it back in again.

I am confused which project this refers to (the initial one?, another
one?). I assumed he meant a second project (which is an ActiveX component),
which if that is the problem he should be using Binary Compatibility to
force the second project (which has its reference lost in the first
project) to reuse its IDs.

Sorry if I am off the track here.

I may have missed your proposed solution?

Matthew



Quote:


> >You need to use Binary Compatibility.

> >Matthew

> As I've said, you only use the version compatibility if you are
developing
> an ActiveX component, whether OCX or DLL. If you are just concerned with
the
> files in your project being up-to-date, then there's no use for this.
> Version compatibility is for the product of your project (*.dll, *.ocx)
and
> not the source code of your project (*.frm, *.bas, *.cls, *.ctl).



Sun, 22 Oct 2000 03:00:00 GMT  
 VB, References & Source Safe

In his original message, he said he was developing COM objects which
reference each other.  Therefore, he needs to be using Binary Compatibility
so the CLSIDs don't change every time you compile.  When the CLSIDs change,
the references change and the project file (.vbp) will change.   If you
check out someone else's project file, the references won't be found in your
registry and the project won't compile.  That's why you need it.

Quote:


>>You need to use Binary Compatibility.

>>Matthew

>As I've said, you only use the version compatibility if you are developing
>an ActiveX component, whether OCX or DLL. If you are just concerned with
the
>files in your project being up-to-date, then there's no use for this.
>Version compatibility is for the product of your project (*.dll, *.ocx) and
>not the source code of your project (*.frm, *.bas, *.cls, *.ctl).



Mon, 23 Oct 2000 03:00:00 GMT  
 VB, References & Source Safe

One major consideration when using Visual Source Safe is to ensure
that file references are consistent across all developers, by:

a)      setting the Working Directory for all Developers to be the
same

b)      ensuring any components / references are the same

Hope this is of some help

N.B.  Sometimes it is possible to drop files from Projects when one
developer has the Project file checked out.  Another developer is also
wanting to write to the project file and when it is released by the
first developer rather than Getting Latest Version then Check Out,
they just Check Out the file, losing the changes made by the first
developer.

Hope this makes some
sense



Quote:


>>Hi,
>>    My team is devloping VB COM objects, alot of which reference each
>other.
>>We are also using SourceSafe.
>>The problem is that when one developer extracts a project from the archive
>>that has just been edited by another user then the project will often
>>complain the references are incorrect.  You have to go and check out the
>>project, set the references, and check it back in again.  It is such a wase
>>of time.  How do you get round this ?  I have tried playing around with
>>project compatability options, but to no avail.

>>Regards
>>    Ben

>SourceSafe is really designed to be that way. That is, only one developer
>can make changes to a form, module, or project at any given time. One
>developer has to make the changes and checks the changes in before another
>developer can do another change. I know that this is such a waste of time
>since it is very similar to a bottleneck effect.

>To get around this, what I suggest is that every developer has his own copy
>of the whole project and in a directory different from the SourceSafe
>working directory. Then he can make his changes in that copy, do compilation
>and testing. Now, if the project is still checked out, then he has no option
>but to wait until the developer can check it out himself. But if he can
>check it out, he should check it out and then compare his copy of the
>project with that of the SourceSafe copy. (WinDiff from Visual Studio is
>very good comparator). After comparing and synchronizing the copies, he then
>updates the SourceSafe copy, and finally checks it back in.

>I know this will be a waste of disk space but at least all the developers
>are productive at any given time.

>No use in playing around with project compatibility since it just applies to
>any ActiveX OCX/DLL which will be registered in any machines.



Tue, 31 Oct 2000 03:00:00 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. VB & visual source safe

2. Visual Source Safe 6.0 & Service Pack Installation

3. How safe is vb.net source

4. Problem in opening VB.Net project in Source Safe

5. VB.Net and Source Safe?

6. How to hook VB.Net into Visual Source Safe

7. creating vb project from code saved in visual source safe

8. VB Scripting and Visual Source Safe

9. Visual Source Safe not integrated with VB

10. Visual Source Safe integration with Access

11. Visual Source Safe Help

12. Qry re Source Safe to overcome Speed Ferret problem

 

 
Powered by phpBB® Forum Software