违背组织中使用的通用源代码控制
我工作的公司专门使用 Clearcase。我觉得不值得花精力去学习和使用它，因为我的项目不会涉及太多人（最多3人），也不会涉及花哨的开发流程。当我的经理提出“整个公司由 IT 支持和统一的源代码控制”反对我的建议时，我该如何说服他们为此使用单独的源代码控制？或者这个特定的观点是否有效，我应该选择 Clearcase？
谢谢...
PS：我正在考虑使用 Subversion。
The company I work for exclusively uses Clearcase. I feel it is not worth the effort to learn and use it as my project would not involve too many people(max of upto 3 people), neither would it involve fancy development flow. How do I convince my manager on using a separate source control for this when they bring up the point of "IT supported and uniform source control through out the company" against my suggestion? Or is that particular point valid and I should go with Clearcase?
Thanks...
PS: I was thinking of using Subversion.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
如果这是公司标准，那么公司中应该有人了解它，可以帮助您开始使用它。他们应该能够设置您的特定 IDE 来使用它，并使一切为您尽可能无缝。您不必为了使用它而学习任何疯狂的东西 - 应该有明确的说明。
如果没有，那么您就无法获得“整个公司的 IT 支持和统一源代码控制”的好处，并且您使用什么都没有区别。
在完成这个过程之后，如果可以提出一个论点，即有更好的源代码控制可以在公司中更好地发挥作用，那么您应该这样做。如果这是公司标准，那么使用起来应该不会很麻烦。
If it's the company standard, then there should be people in the company that know it that can help you get started with it. They should be able to set up your particular IDE to work with it, and make everything as seamless as possible for you. You shouldn't have to learn anything crazy in order to use it - there should be clear instructions.
If there's not, then you're not getting the benefit of "IT supported and uniform source control through out the company" and it makes no difference what you use.
After working through this process, if an argument can be made that there's a better source control that would work better through the firm, you should make it. If it's a company standard, it shouldn't be a pain in the neck to use.
首先，我表示哀悼。
Clearcase有那么难学吗？如果是的话，我会认为这是对它的打击。如果没有，你最好顺其自然并学习它。
您团队中的 3 个人不太可能是在软件生命周期内维护代码的人，因此这个论点也不利于您。
该组织有多大？ 3 个人学习 Clearcase 比 X 人学习 Subversion 更容易。
这在很大程度上取决于你的老板和他/她考虑替代方案的意愿。
Subversion 肯定很容易设置和使用。我不想自己使用 Clearcase。
但有很多因素对你不利。祝你好运。
First of all, my condolences.
Is Clearcase that difficult to learn? If yes, I'd consider that a strike against it. If not, you might be better off just going with the flow and learning it.
The 3 people on your team aren't likely to be the ones that maintain the code over its software life, so that argument goes against you as well.
How big is the organization? It's easier for 3 people to learn Clearcase than for X to learn Subversion.
It would depend a lot on your boss and his/her willingness to consider alternatives.
Subversion would certainly be easy to set up and use. I'd hate to be using Clearcase myself.
But there are a lot of factors against you. Good luck.
如果我是你，那么我会想使用 SVN，因为我只是喜欢它，但就像任何开发一样，大多数时候你必须顺其自然。就像您正在扩展一个框架一样，您决定以自己的方式进行操作，与框架的其他部分完全不同，即使您的方式更好，它也会被人皱眉。另外，如果您和您的团队被公交车撞了怎么办？好吧，SVN 很容易学习，但仍然存在一个学习曲线，可能会减慢其他人继续您的工作的速度。
If I were you then I'd want to use SVN because I just love it but just like anything with developement most of the time you have to go with the flow. Same as if you were extending a framework and you decided to do it your own way completely different to the rest of the framwork it would be frowned upon even if your way was much better. Also what would happen if you and your team got hit by a bus? OK SVN is easy to learn but there is still a learning curve that could slow down other people continuing your work.
您还可以将其视为学习新的源代码控制系统并使自己更具市场价值的机会。你可能仍然更喜欢颠覆，你不能被迫改变你的观点。正如 @Erick 所说，如果这是公司标准，他们应该能够支持您，我希望您能够将其纳入您的时间表中。
You could also view this as a chance to learn a new source control system and make yourself more marketable. You could still prefer subversion, you can't be forced to change your opinion. As @Erick says if this is the company standard they should be able to support you and I'd hope you'd be able to get this factored into your timescales.
总有尝试过的&让您的团队在其内部使用 Subversion（多么合适！）并偶尔向 Clearcase 进行展示签入，这是真正的（尽管有风险）方法。
There's always the tried & true (albeit risky) approach of having your team use Subversion (how appropriate!) within itself and making the occasional show check-in to Clearcase.
您反对 Clearcase 的论点
是
人们也不会涉及
学习起来困难吗？如果您的公司已经在使用它，您将有很多人可以寻求帮助。由于您的公司已经有了 Clearcase，您的 clecase 管理工作已经完成 80%。创建 vobs、项目等将相当简单。
事实上，您的项目很小，因此在公司内部使用标准变得更加重要。我们使用标准 SCM 完成了一些奇特的项目，也有一些没有使用标准 SCM 的项目。对于使用标准SCM的系统来说，当项目报废时，代码在组织中仍然是安全的。其他产品，我们失去了人员和代码。
您是否将 ClearCase 与 UCM 结合使用？它比 Base ClearCase 更简单。
Your argument against Clearcase
are
people neither would it involve
Is it difficult to learn? If your company already using it, you will have many people to ask help from. Since your company already have clearcase, you are 80% done with clercase admin works. It will be fairly simple to create vobs, project etc.
In fact your project is small makes it more important to use standard within company. We had some fancy projects done using our standard SCM and some projects without the standard SCM. For the one which used standard SCM, when the projects is scrapped, the code is still safe with in organization. Other products, we lost people and code.
Are you using ClearCase with UCM? It is simpler than base clearcase.
正如我在“是否有任何理由仍然使用SVN？”，您不能决定放置一台新服务器，尤其是对于代码源等敏感数据。在某些时候，它们需要在中心引用中进行版本控制。
任何用于此类持久且重要数据的服务器都应该：
出于所有这些原因，您的经理可能会考虑利用现有的主要 VCS 周围的基础设施/支持（ClearCase，哀悼；））。
但这不会阻止您在不过，ClearCase 快照视图。
As I mentioned in "Are There Any Reasons To Still Use SVN?", you can't just decide to put a new server on the side, especially for sensitive data like code sources. At some point, they need to be versioned in a central referential.
Any server for that kind of persistent and important data should be:
For all those reasons, your manager might consider leveraging the existing infrastructure/support around the main VCS (ClearCase, condolences ;) ).
But that won't prevent you to manage a DVCS within a ClearCase snapshot view though.
我不了解 Clearcase，所以我不能说它是好是坏，也不能说它与 Subversion 相比如何。
但源代码控制的重点是应该有一个单一的存储库，每个人都知道他们可以去检查他们的代码。如果一个团队使用 Clearcase，而你的团队使用 Subversion，另一个团队使用 Git，另一个团队使用 CVS，等等，那么任何想要查看源代码的人不仅需要查看十个地方，而且还必须学习使用十个不同的源代码控制系统。
除非您能证明 Subversion 在某些相关且重要的方面明显优于 Clearcase，否则我会说硬着头皮学习 Clearcase。如果是我，我会把它视为学习新东西的机会。在我这样做之后，也许我会得出这样的结论：Clearcase 很糟糕，我应该尝试说服当局改用其他东西。或者我可能会得出这样的结论：Clearcase 是自 USB 发明以来最伟大的进步。不管怎样，你现在知道得更多了一些。如果不出意外的话，这也是您下次寻找另一份工作时在简历上添加的又一颗子弹。
I don't know Clearcase, so I can't say whether it's good or bad or how it compares to Subversion.
But the whole point of source control is that there's supposed to be a single repository where everyone knows they can go to check out their code. If one team uses Clearcase and your team uses Subversion and another uses Git and another uses CVS, etc etc, then anyone wanting to check out source code not only has to look in ten places, but they have to learn to use ten different source code control systems.
Unless you can make a case that Subversion is clearly better than Clearcase in some relevant and important way, I'd say just bite the bullet and learn Clearcase. If it was me, I'd see it as an opportunity to learn something new. After I did, maybe I'd conclude that Clearcase sucks big time and I should try to convince the powers that be to switch to something else. Or maybe I'd conclude that Clearcase was the greatest advance since the invention of USB. Either way, you now know a little more. If nothing else, it's one more bullet to put on your resume the next time you go looking for another job.
您是在这家公司全职工作还是作为承包商进行一次性项目？
如果您是一名全职员工，那么是时候购买《Clearcase 初学者》一书了。
如果您希望快速交付项目，那么也许只需低调并使用 Subversion 作为权宜之计。当您跑出门外时，请某人将完成的文章检查到 Clearcase 中。
:)
Are you working full-time for this company or is this a one-off project as a contractor?
If it's your full-time role as an employee then it's time to buy that "Clearcase for Beginners" book.
If you're looking to deliver a project quickly, then perhaps just keep your head down and use Subversion as an expedient. Ask someone to check the finished article into Clearcase as you run out of the door.
:)
使用 Mercurial 或 Git 等 DVCS 并创建一个分支以与 ClearCase 保持同步。您的团队可以使用更好的工具完成日常工作，但您的组织仍然可以通过通常的方式访问您的工作产品（这很重要）。定期与 ClearCase 同步，并考虑将系统 DVCS 日志（例如 hg 日志）的输出添加到 ClearCase 分支中的文件中，以便人们可以在需要时看到更精细的步骤。
DVCS 系统通常也很容易设置，并且通常可以轻松托管在网络共享或类似的东西上。由于所有开发人员都将拥有完整树的副本，因此它提供了一定量的内置备份和冗余。
这种工作流程并不罕见——gitsvn 和 hgsvn 都是人们设置的脚本，让他们自己使用这些工具，但与另一个存储库上的人们同步。
Use a DVCS like Mercurial or Git and make a branch of it to keep synced up with ClearCase. Your team can do the day to day work using a better tool but your organization still has your work products accessible the usual way (which is important). Sync up with ClearCase on a regular basis, and consider adding the output of your systems DVCS log (eg hg log) to a file in the ClearCase branch, so people can see the more granular steps if needed.
DVCS systems are also usually pretty easy to set up, and often can be easily hosted on a network share or something like that. Since all developers will have a copy of the full tree it provides a certain amount of built in backup and redundancy.
This workflow is not uncommon -- gitsvn and hgsvn are both scripts people have set up to let them use those tools by themselves but sync up with folks on another repository.