MFC and group development
Borenstein Andrei -- boren@actcom.co.il
Wednesday, May 22, 1996
Envoronment / Version - All
Hello,
We are a group of 5 programmers developing MFC based application.
We are using Source Safe as a version control tool .
We are experiencing serious difficulties whilr trying to split our
development work between the group members , becuase everyone of us
should access very frequently CMainFrame and CDocument derived classes.
It leads to multiple checkouts, merging and eventually bugs.
I always thought that OOP should be more capable to split development
work, as objects are more loosely coupled than procedures/functions .
In fact it appears that MFC is too concentric.
Could anybody here share his/hers experience regarding this issue ?
Thanks,
//=====================================\\
// Andrei Borenstein, SD Ltd. \\
< P.O. Box 101, Migdal Haemek, ISRAEL 10551 >
\\ Tel. (972)6-547567 , FAX (972)6-547507 //
\\ E-mail : boren@actcom.co.il //
\\ CIS: 100274,2710 //
\\==================================//
Jim Beveridge -- jimb@turningpoint.com
Tuesday, May 28, 1996
[Mini-digest: 11 responses]
Borenstein Andrei wrote:
>
> We are a group of 5 programmers developing MFC based application.
> We are using Source Safe as a version control tool .
>
> We are experiencing serious difficulties whilr trying to split our
> development work between the group members , becuase everyone of us
> should access very frequently CMainFrame and CDocument derived classes.
>
> It leads to multiple checkouts, merging and eventually bugs.
>
We have several multi-developer teams using the model you describe.
The biggest key to success is to update your local copy on your drive,
do the build, make sure it works, THEN check everything into the server.
In other words, a merge/update should NEVER be checked directly into
the server, it should be built locally to make sure that it works.
It is critically important that the developer "diff" every change that
is being checked in to make sure he recognizes what is happening.
Using this procedure, it is extremely rare for us to find bugs
caused by bad merges. Maybe once every man-year.
Obviously, it is very important to employ SourceSafe headers that
show the date and version at the top of each file.
The one place that is a serious problem is resource.h.
The ID's at the end of the file are not handled by Visual C++ properly.
If you allow multiple checkouts of resource.h, VC++ will frequently
generate overlapping ID numbers. You need to manually monitor these
ID numbers whenever you check in to prevent overlap.
BTW - "resource.h" is NOT used in dependency checking. Therefore, if you
renumber some values in resource.h, everyone on the team must do a
complete rebuild to make sure the changes are applied.
We have found that SourceSafe 4.0a is a requirement. Version 4.0 has
some serious integrity problems.
-- Jim Beveridge
-----From: Niels Ull Jacobsen
We have had the same problems (and we're only two programmers).
One approach is to split implementation of the large classes (document=20
and main frame) across several files. Some of the CDocument methods in=20
one file, some in another. Unfortunately, Class Wizard doesn't handle=20
this very well. It's very much one class - one .h/.cpp pair of files.
This still leaves the problem of the header files. You could conceivably=20
split the declaration of CDocument across several files as well, but I=20
think this would lead to chaos. And the message maps have to be=20
merged manually as well.
Alternatively, maybe you could split up the functionality? Have several
levels of derivation - a document with data, a document with data and
storing, a document with data, storing and import/export, etc.
Apart from a small overhead for the message maps (which could be fixed
manually before doing the release build), this should work.
=20
>
>Thanks,=20
>
>
>
> //=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\\ =20
> // Andrei Borenstein, SD Ltd. \\ =20
> < P.O. Box 101, Migdal Haemek, ISRAEL 10551 >=20
> \\ Tel. (972)6-547567 , FAX (972)6-547507 // =20
> \\ E-mail : boren@actcom.co.il // =20
> \\ CIS: 100274,2710 // =20
> \\=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D// =20
>
>
>
>
>
>
Niels Ull Jacobsen, Kr=FCger A/S (nuj@kruger.dk)
Everything stated herein is THE OFFICIAL POLICY of the entire Kruger grou=
p
and should be taken as legally binding in every respect. Pigs will grow
wings and fly.
-----From: Ola Strandberg
I have successfully built separate applications for each document type and
then merged the projects into one, it's just a few lines of code and some
cutting and pasting. It takes some discipline, but it's probably the easiest
way to avoid this kind of problem. Another thing with using MFC in group
development is that the .rc and and resource.h are modified frequently. This
is yet another reason for splitting the project across document types.
Without knowing anything about your application, there should not be too
much interaction between document types.
>In fact it appears that MFC is too concentric.
MFC is not OO as many will argue. See MSJ June '96 for just one example.
>Could anybody here share his/hers experience regarding this issue ?
These are my experiences...
--
Ola Strandberg, Systems Developer
PharmaSoft AB, Box 1237, S-754 51 Uppsala, Sweden
http://www.pharmasoft.se/
Tel: +46 18 185459 Fax: +46 18 109200
-----From: "Ray Frohnhoefer"
It has been my experience that most software configuration management tools
and environments work best if you can break down work at the .EXE or source
module level. Give ownership of your CMainFrm.cpp file to one individual,
and provide that person with requests for updates and changes. This has the
pleasant side-effect that you should all feel a sense of team, as well as
individual accomplishment.
Regards,
Ray F.
-----From: dobrin@itls.com
Hello,
We have the same problem. One way around would be if you move
functionality from CDocument in other classes, and access those. It
is not really by the book, but it might be efficient.
Regarding CMainFrame, the person in charge for the look & feel of the
application who takes care of buttons, toolbars, etc., should take of
the updating of that one.
It is just a brief idea.
Dan Dobrin
-----From: Kevin_L_McCarthy.IACNET@ngate.zis.ziff.com
Without knowing any of the specifics, I would say that you need to
rethink the design of your application. A good OO design would, I think,
place most of the implementation work in a variety of classes (which
should be in more than one module:-)). The other possiblity is that
you've jumped into implementation too soon, before the data structures
have been defined. Now everyone needs to get at CDocument to add a field
here and a field there.
Just because it says ++ on the box, it doesn't mean you're automatically
doing OOP.
-----From: "Dan Liliedahl"
We had this same problem. You do not have to implement all of your class
in one file. We split out mainframe
and maindoc into modules (mfpaint, mflbdown, etc). The header files still
remain a problem.
-----From: Andi Giri
Looks like your problem has nothing to with MFC or OOP, but just plain
Visual SourceSafe.
Page 83 of the Visual SourceSafe User's Guide is summarized as follows:
Peter and Paul check out a file xxx.cpp, Peter makes changes and checks
a new version in, and then Paul attempts to do the same. If the lines that
Paul has changed are different from the lines that Peter has changed, the
check in proceeds normally. Otherwise, it informs Paul that a conflict
exists
and he must resolve it by editing xxx.cpp.
Andi
-----From: "Mike Ward"
Environment / Version - All
We struggled with this for a long time as well. The solution was to
abandon the generated makefiles from the developer's studio. Once we
did this we we're able to do following things:
1. One makefile that managed the entire project including the
production of several exe's and dll's.
2. The ability to integrate version control into our makefiles. When
our programmers want to version, they type "make torcs" and it
submits all the files that have changed since their last submission
to revision control.
3. We use the somewhat radical approach of allowing merging in our
revision control. Under this scheme, no one locks-out a file but
instead just checks out a current copy. When it comes time to put
stuff back into revision control, the programmer merges his/her
changes into the current set. We wrote a couple of small programs
to automate the process. It sounds horrible and it would never
work, but we have used is succussfully with as many a 10 programmers
for the last 7 years and feel its one of those practices that gives
us a competive edge. The fact is, you rarely run into a merge
conflict and they are easily avoided if you version frequently.
This has two nice affects. One, programmers are almost always
current since they version often, and two, they have a better feel
for what's changing in the project since whenever the version, they
get back both their changes plus any changes to other files made
since their last revision. We found that it also encourges code
sharing and colaboration.
4. There are several machine generated files that are difficult to
work with but managable. The class-wizard files are never versioned.
Instead, when we get changes back from revision control, we delete
all the .clw files and regenerate them when needed.
The more difficult guy is the resource.h files that the developer's
studio generates. If developer's studio simply appended the id's to
the end of the file, it wouldn't be such a big deal. Instead,
whenever a new id is added, it rewrites the entire file destroying
any header you might have added to file. Thus you can't store
revision control information in the file. We fixed this by writing a
small program that placed the contents of the resource.h file into a
different file that had the correct header and then versioning that
file. Again, our makefile does this automatically.
In summary, its possible for multiple programmers to work on an MFC
project. However, its best to avoid using the developer's studio
generated makefiles (I originally used the generated makefiles and
then went back after modifying makefiles to our liking and generated
a new project using the "makefile only" wizard). Also, you can avoid
bottle necks on certain key files by using merge method of revision
control instead of the lock and checkout method.
One final note: The make utility that comes with VC++ is pretty
lame. I've used a product called Opus Make which I've found to be
much better suited to the task.
-----From: Sunitha Kumar
Dear Andrei,
You could probably follow this:
1. If the 5 of U are handling individual objects independently, then in =
VSS, you could create folders for each object and specify per objects, =
checkin/checkout rights. So, only the person working on a particular =
object could have checkin/checkout rights over that object. However, =
the others may still obtain the files for viewing purpose by using the =
Get of VSS.
This way, only one person controls what goes into VSS
2. If someof you are making changes to the same piece of code, then one =
of you could be given the checkout rights and after making changes and =
merging the files, it could be checked into VSS.
Hope this helps
Sunitha Kumar
-----From: "D. John Anderson"
OOP won't solve your problem. The only solution is not having more =
than one person modify the same code or a better merge tool. I've =
written a merge tool that automates merges when more than one =
person modifies the same file. It only requires manual =
intervention when more than one person changes the same line. In =
practice this works great for us. Let me know if you are =
interested in it.
John Anderson
| Вернуться в корень Архива
|