从 Eclipse 工作区 .metadata 签入什么内容
我一直在对工作区下的项目进行版本控制,但我从未想过应该检查工作区配置本身。
到目前为止。
我知道我对永远膨胀的 .log
文件绝对不感兴趣,所以我绝对不会签入它,但是......我可以丢弃其他其他子目录或文件吗?是否应该检查 .lock
(大小 0)? .plugins
子目录怎么样?
I have been version-controlling the projects under my workspace but it never occurred to me that I should be checking in the workspace configuration itself.
Until now.
I know that I have absolutely no interest in the perpetually bloating .log
file, so I am definitely not going to check it in, but... can I discard other other subdirectories or files? Should the .lock
(size 0) be checked it? What about the .plugins
subdirectory?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
简短回答:不要将 .metadata 添加到 VCS。
长答案:
进行版本控制有两个一般原因(这有点过于简单化):
如果您第一次使用版本控制原因,那么 .metadata 目录中没有任何内容应该进行版本控制。这是因为那里的信息是特定于您的机器的,如果其他机器尝试使用它,就会把事情搞砸。
如果您出于第二个原因使用版本控制,那么我仍然建议不要对元数据进行版本控制(尽管强度稍弱)。 .metadata 中的大部分信息都是二进制的,或者至少读起来极其无趣。因此,您不需要返回版本、进行任何差异或类似的操作。相反,我建议仅使用适当的备份服务来备份整个计算机,以应对紧急情况。
Short answer: do not add .metadata to VCS.
Long answer:
There are two general reasons to do version control (this is a slight over simplification):
If you are using version control for the first reason, then there is nothing in the .metadata directory that should be versioned. This is because the information there is specific to your machine and would mess things up if other machines tried to use it.
In you are using version control for the second reason, then I would still recommend against versioning the metadata (although slightly less strongly). Much of the information in the .metadata is binary, or at least extremely uninteresting to read. So, you will not need to go back versions, do any diffs, or anything like that. Instead, I'd recommend just using a proper backup service that backs up your entire computer in case of an emergency.
这样做有一个很好的理由:
对工作集文件进行版本控制,以便在团队之间有效地共享项目列表。
There would be one good to reason doing this :
versioning the working set file, to share project lists efficiently between teams.