rcleartool原子性
假设我有一个本地视图，它使用 rcleartool update 从中央 ClearCase 服务器定期更新。此更新任务需要 20~30 秒才能完成。
当我的本地视图在这 20~30 秒的时间范围内更新时，如果出现以下情况会发生什么：
我签出将要由rcleartool update更新的文件？
这里我只能想到3种情况：
- A.更新阻塞，因此只有更新完成后签出才能成功。事情很好。
- B. 签出发生在更新之前，在这种情况下：
- i) 更新将失败，因为文件已检出，
- ii) 更新将成功，但会将签出的文件置于劫持模式，或者
- iii) 签出的文件已成功更新。没有劫持。
- C. 各种竞争条件都会发生并且视图会爆炸。
会是哪一个呢？
另外，我在更新运行时进行签入会发生什么？
Let's say I have a local view that gets periodically updated using rcleartool update from the central ClearCase server. This update task takes 20~30 seconds to complete.
When my local view is getting updated during this 20~30 sec timeframe, what happens if:
I checkout files that are going to be updated by rcleartool update ?
Here I can only think of 3 situations:
- A. Update blocks, and thus checkout succeeds only after update finishes. Things are good.
- B. Checkout happens before update, in which case either:
- i) update will fail because files are checked out,
- ii) update will succeed but put checked out files in hijacked mode, or
- iii) Checked out files get updated successfully. No hijacks.
- C. All sorts of race conditions happen and view explodes.
Which one would it be?
Also, what happens I do a checkin while update is running?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
最简单的答案是：更新应该是按需的，而不是自动的。
但是，如果您保持定期自动更新，最终可能会遇到 此综合 CCRC 列表。
您可能会在以下情况下检测到“元素版本不一致尝试结帐：
您有一个 此技术说明中的详细信息：
至 用CCRC7.1解决，可以刷新文件或视图，要求修复所述不一致。
The simplest answer is: update should be on-demand, not automatic.
But should you keep that periodic automatic update, you could end up with one of the errors or defects mentioned in this comprehensive CCRC list.
Probably, you would have a "Version discordance detected for element when attempting a checkout:
You have a details in this technote:
To solve it with CCRC7.1, you can refresh the file or the view, asking to repair said discordance.