This is the fallacy of allowing more than one developer to make wholesale changes to the same source member at the same time, and then having to rely on a source-compare-merge tool to "merge" the changes. Even if you can easily merge the changes, there is no guarantee that the program will actually work -- you are back to "square one" as far as testing the program, because you do not know what possible "side-effects" may have been introduced by the other developer's changes, or what assumptions may have changed, etc. Also, it is not always easy (or even possible) to just "merge" the changes -- for example, what happens if the other developer has deleted a section of code into which you have inserted some new lines? This approach also quickly degenerates in those cases where one (or both) of the developers engages in what is commonly referred to as "re-factoring," where they re-arrange the code significantly. This can make it difficult or impossible to merge.

I am a harsh critic of the perceived benefits of so-called "optimistic locking" (allowing more than one developer to change the same source at the same time) for the reasons stated above.

If you follow a strict check-out and check-in locking protocol (aka. "pessimistic locking"), then you never have these problems.

In software development, you can "pay now, or pay later." (Using "optimistic locking" is a "pay later" strategy, because the amount of time and effort taken to do the "merge" is all just pure "overhead.")

The only case where I consider it "valid" to allow a second developer to make changes to the same source that another developer is already working on is when a so-called "emergency fix" to "production" is needed, where the other developer is making a larger set of changes that will require several days or more to complete, and you cannot wait that long for the "fix" -- and where the emergency fix is anticipated to require only a relatively few lines of code, in only a few places. In this case, there is still some "risk", but you have a better chance of being able to "merge" the changes again when they are smaller and isolated.

All the best,

Mark S. Waterbury

> On 12/7/2010 4:41 AM, David FOXWELL wrote:

I have an RPGLE member that I have changed while another developper was also changing it in another library. Now I have to insert my changes in the production version of the member. I cannot use the compare feature as the source is too large and too many changes have been made since I copied the production version into my development library. So, I filter all my changes by date. Now I know what to insert, but how do I find out where to insert it? I can press ctrl w to see the line immediately above the change, find that line in the target source and copy. Now to find the next change I need to filter my changes again.

What am I doing wrong?

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.