Fog Creek Software
Discussion Board




VB6 Team Development Issues with NTCVS or SrcSafe

Does team development with VB6 projects pose a problem with more then one developer "checking-out" and changing the same source files at the same time.

At first thought, I don't anticipate any problems with merging and resolving conflicts with .BAS and .CLS files since they are standard text with very little "hidden" header text at the top.

However.. i am very concerned about the .FRM files since each .frm can have a binary .FRX file associated with it that must be kept in sync with the .FRM file.  And we all known that binary files can't be merged like text.

I am also concerned about the thousands of potential hidden "control" lines that exist at the top of .frm files that is not seen in the VB6 IDE.  I anticipate potential problems with devs trying to resolve potential merge conflicts with source lines never that they never really write themselves(the IDE does that)

Anyone have any experienced advice on this topic and with the specific problem of dealing with the binary .frx files?

Heston Holtmann
Friday, January 10, 2003

You want to stay away from multiple checkouts for several reasons:

- lack of merge capabilities with binary files
- errors in resolving your changes with another's changes that you're not familiar with
- tendency for developers to not do regular checkins since nobody is locked out

Careful project management can time team efforts so developers don't work on the same areas simultaneously.

As for binary form files, be sure that developers check out/in BOTH the .FRM and .FRX files as a unit.  On one project a junior developer repeatedly checked in the .FRM file, but not the .FRX.  Said form was then modified by several other developers.  Took a LONG time to correct.

Joe Paradise
Friday, January 10, 2003

I've worked on large C/C++ projects for many years and we never had any major problems from multiple check-outs, merging or branching issues.  On a day-to-day basis many of the same .h/.cpp source files were changed by more then 3 peopel at a time; mainly because everything was text based.

I'm under the impression that MULTIPLE checkouts of .FRM/.FRX files is just not possible in VB6 becuase of the binary .frx file state. 

I fear that it is highly-likely that loss-of-work or corruption would occure if more then one dev tried to add, move, or delete controls (3rd party ActiveX or VB-Native) from the same FORM (.frm/frx pair)

What if 2 (or more) devs have the same VB6 Project file (project-name.VBP) checked out and each add new .bas/cls and Forms to the project and then check in the project file?

General in Visual C++ projects this is fine.. but i have noticed that VB6 does crazy things with its project files.  It moves around unchanged lines back-and-forth in the project file for Unnecessary reasons.

Hope this extra detail helps explain my concerns?

Heston Holtmann
Friday, January 10, 2003

Use your tool to help you.  WinCVS allows you to mark a file as being edited.  Another developer can then check the status, and not edit the file if it is already being performed.

I believe it can also check out binary filkes as read only, and insist on the edit field being used.

This also sounds like it's not neccesarily a CVS problem, but more of a general Version Control issue.

Gerald Brandt
Friday, January 10, 2003

In a properly designed and managed project it is NEVER necessary for more than one developer at a time to work on a particular form and almost never necessary with class files. You may have a few master controller/navigation classes that are used by many but in general the parallel changes are small and merges easy. So you can disallow multiple checkouts on most items.

As to adding new items to the project I've never had a problem with this.  But if you're concerned about it you could use the project owner method. Many places I have worked have had an owner for a project (or sub-project) who controls all sensitive changes such as adding new classes, components, etc. So there are never any merge problems (unless the owner screws up). This can provide numerous benefits beyond source code control.

SM
Friday, January 10, 2003

"I fear that it is highly-likely that loss-of-work or corruption would occure if more then one dev tried to add, move, or delete controls (3rd party ActiveX or VB-Native) from the same FORM (.frm/frx pair) "

It's not only likely, it's almost a certainty.  If the team is only changing the code portion of a form you can do that.  However, is everybody going to remember that rule every time they make a change?

As for the VB project file, it's plain text, albeit loosely structured.  New project files are inserted (in any order) into the project file, typically between the project references and the startup object:

Reference=*\G{00 ... #OLE Automation
Object={831FDD ... #0; MSCOMCTL.OCX
Form=Form1.frm
Startup="Form1"

Since it's text, you shouldn't have problems resolving conflicts here.  The biggest issue I've had with adding files to a project is the path to the new file VB writes in the project file.  VB (sometimes?) doesn't write a relative path to the code file.  This becomes a big issue when developers add code from different directories on their local machine.

That said, I'd still recommend leaving it off.  Ditto to everything SM said above.

Joe Paradise, SourceSafe Admin
Friday, January 10, 2003

Have to disagree with SM.

"In a properly designed and managed project it is NEVER necessary for more than one developer at a time to work on a particular form and almost never necessary with class files."

One of your most frequent opportunities for parallel development is having to fix V1 (which has been released) whilst developing V2.

(Admittedly these won't be within the same project as the V1 fix will be a new piece of work to be managed separately from the project that is developing V2 - but it will be absolutely necessary parallel development)

Gwyn Carwardine
Friday, January 10, 2003

The above comment brings up another question.

Does the binary .frx file create a problem when using branching and merging in CVS as a form of release change management?

On the surface it appears to me that since the .FRM file MUST stay in sync with its binary .FRX file within any particular branch, the concept of merging .FRM/.FRX bug fixes into other branches would be very problematic. 

Heston Holtmann
Friday, January 10, 2003

Gwyn - up until 2 or 3 years ago I would have agreed with you. But having been burned in this area many times I have shifted my development philosophy away from this type of parallelism.

If a bug is serious enough to be included in a Service Pack to V1 then it is serious enough that it must be fixed in V2 immediately. No further work can be allowed on the module containing the bug until it has been fixed. If someone is working on a V2 feature in the same module then they stop (and ideally they fix the bug) and then continue from the fixed code base after the bug has been fixed and tested. In a properly designed project, the classes/forms are designed in a sufficiently focused manner that this will never cause more than the briefest bottleneck and that bottleneck is a price well worth paying for the added code stability. Also, in a properly manged project fixes and features will be assigned intelligently so that these bottlenecks will almost never occur. You may be able to tell that I don't really believe in the effectiveness of the old idea of having separate maintenance teams for earlier versions of products that are still in an active development cycle (I prefer a shorter release cycle but this can be problematic for shrink-wrap software).  I am a strong believer in the XP(and others) idea of collective code ownership, in general, but I believe in assigning strict code ownership for the duration of any changes to a module. In addition, checkouts should rarely last more than two or three days, if that. Developers should do design work and solution prototyping prior to checking out. So again there is little chance for bottlenecks if multiple checkouts are not allowed. Caveat - this will not be true at the very beginning of a project.

I am certainly not wedded to this philosophy and am willing to be convinvced otherwise but over the years I have found it to be the most reliable approach on all sorts and sizes of projects.

SM
Saturday, January 11, 2003

In a properly designed and managed project VB would never be a sane development choice.

vb rules
Thursday, March 25, 2004

*  Recent Topics

*  Fog Creek Home