首先，在我工作的地方，我们被迫
使用 CVS 并且没有任何其他
选择。我个人使用 git。
有时我并不总是对模块进行cvs update，但我会从生产服务器下载实际文件，保证是最新的（99% 的情况）。
我最终做了一个cvs commit发现我更新失败，所以场景是这样的：
cvs commit file.xml
cvs commit: Up-to-date check failed for 'file.xml'
mv file.xml 2
cvs update file.xml
rm file.xml
cvs mv 2 file.xml
我正在考虑编写一个shell脚本来自动cvs更新我正在提交的文件并提交它们。 ..但想知道是否有一些本地方法可以做到这一点。
除了不使用简历之外的任何建议表示赞赏！
PS - 我使用 !!:n 其中 n 是数字。我只是没有在我的代码示例中使用它，因为它更清晰。
Firstly, where I work we're forced to
use CVS and don't have any other
choice. I personally use git.
Sometimes I don't always do a cvs update on a module but I'll download the actual file off the production server which is guaranteed to be the latest ( 99% of cases ).
I end up doing a cvs commit to find I failed to update so the scenario is like this:
cvs commit file.xml
cvs commit: Up-to-date check failed for 'file.xml'
mv file.xml 2
cvs update file.xml
rm file.xml
cvs mv 2 file.xml
I was thinking about writing a shell script that automatically cvs updates the files I'm committing and commits over them... but wondering if there's some native way of doing it.
Any advice other than not using cvs appreciated!
PS - And I use !!:n where n is the number. I just didn't use that in my code example since it's more legible as it is.
发布评论
评论（3）
我怀疑下载文件是一个优化步骤？更新是提交之前必需的步骤的原因是使文件的上下文与服务器上的上下文保持同步。我可以想到手动方法的几个问题：
如果您的工作需要隔离，请创建一个分支并在那里工作。手动调整 CVS 是一条让人流泪的路。
I am suspecting that the download of the file is an optimization step? The reason that an update is a required step prior to committing is to keep the context of your file in lockstep with that on the server. I can think of several problems with the manual method:
If your work needs to be in isolation, make a branch and work there. Jiggering the CVS manually is a road to tears.
您在该示例会话中所做的实际上是对最近修订版的作者的非常粗鲁的行为，这些修订版显然是同时提交的，因为您将有效地恢复所有这些更改。这正是 CVS 要求文件在提交之前必须基于提示修订（也称为“最新”）的原因。
但是，如果恢复或替换这些中间更改正是您想要做的，那么您引用的步骤确实很可能是最快的方法。但这种方法的缺点是不会跟踪恢复过程：至少在 CVSNT 上执行 正确的还原将导致合并点的记录，以便修订图表将显示您还原到的修订版本。
在
更新之前不移走文件至少会将远程更改与本地更改合并。然而，在没有验证的情况下决不应该提交此操作，因此针对此场景的完全脚本化方法毫无意义。What you're doing in that sample session is actually pretty rude behaviour towards the author(s) of the more recent revision(s) that were apparently committed in the meantime as you will effectively revert all of those changes. That's precisely why CVS requires files to be based on tip revisions (aka "be up-to-date") before allowing them to be committed.
However, if reverting or replacing those intermediate changes is exactly what you want to do then the steps you quote are indeed very possibly the quickest way to do so. The downside of that approach though is that the reversion process is not tracked: At least on CVSNT doing a proper reversion would result in the recording of mergepoints so that a revision graph would show which revision you reverted to.
Not moving the file away before the
updatewould at least merge the remote changes with your local changes. This should however never be committed without verification so a fully scripted approach to this scenario would make no sense whatsoever.按照预期用途使用 CVS。换句话说，
cvs update在cvs commit之前。cvs update修改 CVS 沙箱中的一些其他信息，仅复制文件是不行的。无论如何，您确实不应该直接访问存储库。这会带来很多潜在的问题。
Use CVS as it was intended to be used. In other words,
cvs updatebeforecvs commit.cvs updatemodifies some of the other information in a CVS sandbox, which simply copying the file won't do.You really shouldn't have direct access to the repository anyway. That allows a lot of potential problems.