Please correct me if I am wrong because I am really fuzzy about this scenario.
If two programmers are making edits to the same file at the same time, they can save over each others work.
For example:
Jane opens foo.fex and starts modifications.
John opens foo.fex after Jane and starts modifications.
Neither Jane nor John know each other are working on foo.fex at the same time.
Jane finishes her changes and saves her file.
John finishes after her and saves his file.
John's file does not contain Jane's edits because he opened foo.fex before Jane saved her file.
Foo.fex only reflects John's changes because he was the last to save and Jane's are lost.

If this is true, what could be put in place to prevent this from happening? All suggestions or corrections are welcome.

This message has been edited. Last edited by: Kerry,

He/She that saves last, wins.

I was afraid my scenario was true. Are there any ways to prevent this from happening?

EDIT:
Is this post pointing me to the solution to my question, using version control?
http://forums.informationbuild...1057331/m/2787066526

This message has been edited. Last edited by: Euclid,

If v3ersion control is used, then when it comes time to merge, the fun starts.

I would avoid this at any cost, the merge could be diabolical.

Well... In "normal" situations two people editting a file under version control is not often a problem, as long as they're not editting the same physical file. To that end, each person has their own "working copy" of a project in a location that's exclusively theirs to edit in. That works beautifully.

With WebFOCUS, things are a little complicated.
Firstly, the files tend to be at a single location, where everybody is doing their edits through Developer Studio. You can install a development environment for each person and that works, but that means you have to install WebFOCUS and every hotfix on each PC involved. It adds a lot of hassle.

Secondly, with WebFOCUS each file is really a procedure. If you change one part of that procedure, it tends to affect what comes after what you edited. If two people edit the same procedure like that, a merge of the changes by both can have interesting results.

Normally with version controlled projects, code is divided into many procedures that each do one specific thing. For that reason, developers tend to be active in different procedures and not influence each others results much. Conflicts are rare.

Back to WebFOCUS, where each procedure is a file. People tend to write monolithic procedures, because it's inefficient to call hundreds of files for a single report and it's hard to keep track of all those separate files too.
Therefore, WebFOCUS procedures tend to perform a lot of related actions in one procedure (monolithic) instead of separate specific tasks each in a procedure of its own. A change in such a procedure by one developer is likely to affect the results of a change by another developer in the same procedure.

So, how effective version control can be for you depends on how you work.

In our case, different developers usually work on different reports. They're all on the same WF server. It's not ideal, but version control has saved our butts a couple of times already, so we still consider it an improvement over not having version control. It sure beats having to restore things from nightly backups

Here's an idea we've kicked around, but haven't had much success implementing do to lack of enforcement (we haven't assigned anyone or group to be the enforcer). All development should happen in the test environment in your own work space making copies of whatever code you need to modify. When you are ready to promote your code to production a group or person would review the code, ensure there are no conflicts with other modifications and then promote the changes to production.

However, with more complicated fexes (especially html pages that are linked to fexes) moving the code around is a huge hassle.

That is probably more overhead than most people need or could stand.