My issue with waiting until changes are made is that someone may have just wasted their time, or is about to waste some time. Myself, I save all-the-time, so it'd be a minimal impact on me. However, for the person that doesn't save until they are done (for better or worse), they could have a LOT of changes that they need to then move over to latest version of the source.
Why not establish the lock upon open. Even if you have 15 sources open when starting RDp, it's only going to take an extra second to do what it needs to do.
Has anyone entered an RFE for this yet? If not, I'll jump on the site and do it.
-Kurt
-----Original Message-----
From: wdsci-l-bounces@xxxxxxxxxxxx [mailto:wdsci-l-bounces@xxxxxxxxxxxx] On Behalf Of Sam_L
Sent: Thursday, July 28, 2011 6:44 PM
To: wdsci-l@xxxxxxxxxxxx
Subject: Re: [WDSCI-L] Refresh the member lock
Here's my take:
The desire is to ensure that two people are not editing the same source member concurrently.
If someone is editing the source member in RDP, then RDP needs to have an exclusive read lock on the member so that nobody else can change it.
This locking occurs automatically, I assume, when RDP opens the member from the host. That lock is lost when you close down RDP.
If the member was opened from the local cache, then as soon as a change is made, RDP should do two things in the background:
1) Reestablish the exclusive read lock;
2) Check the member timestamp to see if the member was changed outside RPD.
Then issue appropriate warnings if there are conflicts.
It seems to me to be much more useful to check for conflicts at the time you make your first change, rather than making changes for an hour and finding at save time that the source had changed on the host.
You can defer these checks until an actual change is made, so you could be editing for a few seconds before you receive a warning, but Ctrl-Z would be your friend. A round trip to the host to accomplish locking and timestamp checking should, I imagine, take less than 5 seconds in most cases.
Of course, does this problem occur often enough to enough people to justify an enhancement, or prioritizing an enhancement about the others that are out there? (I think it could be worked around in most cases with separate libraries and/or a source control system, but I don't work in your shop, so it's just my opinion.)
Sam
On 7/28/2011 3:55 PM, Edmund Reinhardt wrote:
I have checked with development and this would be a candidate for an RFE
Currently, when the user tries to save in the new RDP session, we compare
the last-updated timestamp and put up the 'Save Conflict' dialog prompting
them what to do.
We could explore the possibility of adding function to check the host
timestamp when RDP is started (or if they type changes in the file ? or
bring the file edit session into focus ... ) and then either put a new lock
on the file, or go into the Save Conflict prompt ... ( or a modified
version of it)
Might even be cool to offer a new option to show them the differences
between theirs and host version .. them let them decide ...
To ignore the cache and always open from the host would slow down the
reopening of RDp considerably by having to download all the files, also the
developer would not be made aware of any changes made since the last time
they edited. The solution above would defer the cost of communication
until it was necessary.
Regards,
Edmund (E.H.) Reinhardt
COBOL IDE on AIX, DDS, WebFacing, System i Application Development,
Rational Developer for Power
midrange.com
