×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
David:
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:
Hi,
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?
midrange.com
