Every ClearCase view created by the ClearCase Remote Client is supported by a ClearCase Web server. Both server and client keep a record of the versions loaded into the view and their ClearCase state. Any of the following types of events can cause these two databases to disagree on the state of one or more resources in a ClearCase view:
- The client or server shuts down abruptly.
- The network connection between the client and server is interrupted.
- A user or process on the ClearCase Remote Client host modifies one of those resources without using Rational ClearCase tools (for example, removing a file with an operating system command).
When this sort of disagreement occurs, the database on the server is considered to hold definitive information about resources that have been loaded into the view. Resources affected by such a disagreement are listed in the ClearCase Details view with a State of Discordant.
How discordance usually happens
- User performs an operation on the server which updates the server-resident state (typically the view''s database) on the CCRC Server
- A response is sent back to the client
- The ClearCase® Remote Client updates the client's copy area db. There is a hidden file in each directory on the client, these files are ClearCase operational files and should not be modified or manipulated by other means.
If step 3 is not completed for some reason (maybe a network glitch interrupts step 2) there will be discordance.
Resolving Discordance
As you can see below the file TestFile.txt is in a discordant state, the ClearCase® Remote Client Server thinks this files is not checked out, yet the client thinks (because the client reads the .copyarea.db file) that there is a checkout.
To resolve discordance, it is required to run the “Restore Resource” action. This action can be thought of as a synchronize client to server. Running another command such as “Update Resource”, merely updates the client with config spec changes, and shouldn’t be used to resolve discordance issues.
Running “Restore Resource” This has to be done at the directory level of the discordant object, yet is highly recommended to be executed at the highest root possible. Running “Restore Resource” in our example above at the Misc directory would only resolve discordant conflicts at Misc and down.
The restore resource can be run as follows:
- From the context menu
- From the ClearCase menu
When the user is presented with the restore options, it is recommended (unless the user is aware that they forcibly hijacked a file for offline access) to change the default to Replace(Overwrite) this will synchronize the clients copyarea.db file and move files down to the client if the discordant state requires it to do so.
The user interface should now reflect:
If the refresh does not happen (usually automatic), then at a minimum the user can still perform the intended operation (in this example the user can still perform a checkout), yet the user could refresh to force that status visually.
This topic is discussed in more detail in the CCRC Help files available at the following location:
Help > Help Contents > Concepts > About ClearCase views > Disagreements between client and server.
No comments:
Post a Comment