不受信任团队的版本控制

发布于 2024-11-08 21:43:40 字数 296 浏览 4 评论 0原文

我的任务是重新设计一个相当复杂的系统。几周后我们应该开始雇用新的开发人员,但事实证明我的老板担心他们窃取源代码并将其出售给他的竞争对手。同时,我关于实施 DVCS 的请求已获得批准(我们正在放弃共享文件夹,耶!),所以我想知道如何通过允许开发人员上传代码来协调这两个概念之间的差异到主分支,同时使它们远离核心功能。

有没有直接的方法可以做到这一点? GIT 似乎有与 filter-branch 命令类似的东西,但我真的很期待使用 Bazaar...从我收集的情况来看,最好的方法似乎是为每个部分创建分支系统的。有人能建议更好的方法吗?

I've been tasked with the redesign of a rather complex system. In a couple weeks we should start hiring new developers, but it turns out my boss is worried about them stealing the source code and selling it to his competitors. At the same time, my request for the implementation of a DVCS has been approved (we are moving away from the shared folder, yay!), so I'm wondering how can I reconcile differences between both concepts, by allowing developers to upload code to the main branch while keeping them away from the core functionality.

Is there any straightforward way of doing this? GIT seems to have something similar with the filter-branch command, but I was really looking forward to use Bazaar... From what I've gathered, the best way seems to be creating branches for each part of the system. Can anyone suggest a better way?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

感情洁癖 2024-11-15 21:43:40

如果您需要 filter-branch 等效项,您可以使用 bzr-fastimport 插件中的过滤器命令。
但这会破坏旧历史和新历史之间的兼容性,因此这可能不是最好的方法。

If you need filter-branch equivalent you can use filter command from bzr-fastimport plugin.
But this will break compatibility between your old history and new one, so this is not the best approach maybe.

百思不得你姐 2024-11-15 21:43:40

您可以通过 Mercurial(和 git)中的分支来完成此操作。在这些 DVCS 之上还有一些面向前端的产品,可以使这种许可变得容易(请参阅 KilnBitBucket,私人 GitHub 存储库)

但是罗伯特对你的问题的评论是真实的......我担心如果你不这样做你将会遇到的所有问题相信将源代码提交到您的存储库的开发人员。如果他们无法获得您的代码,他们将如何编译他们的开发环境?

You can do this via branching in mercurial (and git). There are front facing products on top of these DVCS's that make this permissioning easy (see Kiln, BitBucket, private GitHub repos)

But robert's comment about your problems are true... I'm worried about all the problems you are going to have if you don't trust devs that are committing source code to your repos. How will they even compile their dev environment if they can't get your code?

画▽骨i 2024-11-15 21:43:40

更好的解决方案(恕我直言)是公开相关的二进制文件并创建一致的框架或 API 来扩展这些二进制文件的功能。您必须暴露给不可信来源的最多的是 API 层,它维护着真实代码的挂钩。

我实际上认为这是一个非常好的问题。许多人使用来自其领土或国家之外的承包商,承包商窃取代码并甚至直接利用该代码发布新(或假冒)产品的情况并非闻所未闻!不过,VCS 旨在共享代码,因此您需要考虑其他方法来限制访问。

祝你好运!

The better solution (IMHO) would be to expose the relevant binaries and create a consistent framework or API for extending the functionality of those binaries. The most you would have to expose to your untrusted sources would be the API layer which maintains hooks into the real code.

I actually think this is a really good question. Lots of people use contractors from outside their territory or country and its not unheard of for a contractor to steal code and go as far as to release a new (or counterfeit) product directly utilizing this code! VCS are meant to SHARE code though, so you need to think of other ways to restrict access.

Best of luck!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文