How do you store third party libraries that you use in your project in your source control?
如何在源代码管理中存储项目中使用的第三方库?
When would you store binaries in your source control?
您何时在源代码管理中存储二进制文件?
When would you store the code in your source control?
您何时将代码存储在源代码管理中?
Would you ever store both? In what situations would you do this?
你会存两个吗?在什么情况下你会这样做?
(Btw, I'm using .NET but it doesn't really matter for this question)
(顺便说一下,我正在使用.NET,但对于这个问题并不重要)
15 个解决方案
#1
-
How: a vendor branch is generally a good approach
方式:供应商分支通常是一种好方法
-
When (thirdparties): for minimizing the number of referential involved: you could add those libraries into a separate external referential (like Maven), but that mean you need to access that extra referential for each of your environment (development - integration - homologation - preproduction - production)
当(第三方):为了最大限度地减少所涉及的参考数量:您可以将这些库添加到单独的外部参照(如Maven)中,但这意味着您需要访问每个环境的额外参考(开发 - 集成 - 认证 - 预生产 - 生产)
-
When (code): for managing the complexity of the changes, when you know updates and fixes for current versions running into production will be needed while new development are in progress.
当(代码):用于管理更改的复杂性时,当您知道正在进行新开发时,将需要更新和修复当前运行到生产中的版本。
-
Why (store both): for deployment reason: you can manage a complete configuration (list of elements you need) in one referential and query it wherever and whenever you need for:
为什么(存储两者):出于部署原因:您可以在一个参考中管理完整的配置(您需要的元素列表),并随时随地查询:
- development (you query what you need to develop and execute your code, including thirdparties needed for compilation/execution)
- tests (integration, homologation): you query the exacts tags you want to update your testing workspace with
- production: you identify exactly what goes into production from one source: your SCM.
开发(您查询开发和执行代码所需的内容,包括编译/执行所需的第三方)
测试(集成,认证):您查询要更新测试工作区的精确标记
生产:您可以确定从一个来源准确投入生产的内容:您的SCM。
For test and production environments, that also mean your own product (the packaged result of what you are building) should also go into your SCM (only the official releases, not the intermediate ones used internally).
If other projects depend on your product, they will build their own project against your packaged version stored in the SCM, not against your source code they somehow recompiled.
对于测试和生产环境,这也意味着您自己的产品(您正在构建的产品的打包结果)也应该进入您的SCM(仅限官方版本,而不是内部使用的中间版本)。如果其他项目依赖于您的产品,他们将针对存储在SCM中的打包版本构建自己的项目,而不是针对他们以某种方式重新编译的源代码。
Why this is important ?
Because in the end, what will run in production is that packaged version of your product, not your "source code re-compiled". Hence the importance to make all your test with the target final form of your product, clearly stored and tagged in your SCM.
为什么这很重要?因为最终,生产中将运行的是产品的打包版本,而不是“源代码重新编译”。因此,重要的是使用产品的目标最终形式进行所有测试,并在SCM中明确存储和标记。
Martin Lazar raises a legitimate point in his answer
马丁拉扎尔在他的回答中提出了一个合理的观点
Source control is called "source" control, because it is supposed to control sources.
源控件称为“源”控件,因为它应该控制源。
While that may have been historically true, every current RCS have evolved toward SCM (Source Code Management), which does not just control sources, but also manages changes to documents, programs, and other information stored as computer files.
Binaries can then been stored (even stored with binary-delta)
虽然这在历史上可能是正确的,但是每个当前的RCS都已经发展为SCM(源代码管理),它不仅控制源,还管理对作为计算机文件存储的文档,程序和其他信息的更改。然后可以存储二进制文件(甚至存储二进制三角形)
Plus that allows some of those SCM to propose S"C"M feature (as in Source Configuration Management).
That SCM (Configuration) not only stores any kind of "set of files", but also their relationships (aka dependencies) between those sets, in order for you to query one set of file, and to "pull" every other deliveries on which that set depends on (to build or to deploy or to run)
另外,这允许一些SCM提出S“C”M功能(如在源配置管理中)。 SCM(配置)不仅存储任何类型的“文件集”,还存储它们之间的关系(也称为依赖关系),以便您查询一组文件,并“拉”每个其他的交付。该集依赖于(构建或部署或运行)
#2
Assuming you are using .Net:
假设您正在使用.Net:
I create a "Libraries" folder in my project and source control that contains any third party assemblies.
我在我的项目和源代码控制中创建一个“库”文件夹,其中包含任何第三方程序集。
My solution then references those assemblies and my build process pulls that folder down to our build server.
我的解决方案然后引用那些程序集,我的构建过程将该文件夹拉到我们的构建服务器。
Any one pulling your code from source control should be able to compile it without having to hunt down references and assemblies.
从源代码控制中提取代码的任何人都应该能够编译它而无需查找引用和程序集。
#3
How do you store third party libraries that you use in your project in your source control?
如何在源代码管理中存储项目中使用的第三方库?
As binary or source or both. Depends on the library.
作为二进制或源或两者。取决于图书馆。
When would you store binaries in your source control?
您何时在源代码管理中存储二进制文件?
A third party library for which we don't have the source or an internal library which we haven't made any changes to or the library is too huge to be built around.
我们没有源或内部库的第三方库,我们没有对其进行任何更改,或者库太大而无法构建。
When would you store the code in your source control?
您何时将代码存储在源代码管理中?
Say, we use an internal library A but have made some bug fixed specific to product X. Then product X's depot will keep the source and build it.
比方说,我们使用内部库A,但已经修复了一些特定于产品X的错误。然后产品X的库将保留源并构建它。
Would you ever store both? In what situations would you do this?
你会存两个吗?在什么情况下你会这样做?
Yes, all the latest binaries are stored in source control.
是的,所有最新的二进制文件都存储在源代码管理中。
So the tree looks like this:
所以树看起来像这样:
product
|-- src
|-- build
|-- lib
|- 3rdparty
|- internal
...
#4
Source control is called "source" control, because it is supposed to control sources..
源代码控制称为“源”控件,因为它应该控制源代码。
In Java it's common pattern to use some version control system to store sources and other resources like configuration XML files or pictures, and than to use some dependency management tool like Apache Maven, which will store, download and manage your project's dependencies on 3rd party libraries. Then when you reinstall your OS, Maven can automatically download your dependecies from central repository (or your own private repositories as well) and store them in a local cache on your disk. You don't even have to know where the cache is :)
在Java中,使用某些版本控制系统来存储源和其他资源(如配置XML文件或图片),而不是使用某些依赖管理工具(如Apache Maven),它将存储,下载和管理项目对第三方库的依赖性。 。然后,当您重新安装操作系统时,Maven可以自动从*存储库(或您自己的私有存储库)下载您的依赖项,并将它们存储在磁盘上的本地缓存中。你甚至不必知道缓存在哪里:)
Maven can be also used with other languages and as far as I know plugins for .net and C/C++ are available, but I haven't used it with anything else than Java.
Maven也可以和其他语言一起使用,据我所知,.net和C / C ++的插件都可以使用,但是除了Java之外我还没有使用它。
#5
I don't put 3rd party source or binaries in SC. My rationale was that I would not have to update SC just to update the libraries. I am starting to regret this though. When I have had to recreate the project I find myself running around looking for the lib sources instead of just syncing to SC.
我没有在SC中放置第三方源或二进制文件。我的理由是,我不必更新SC只是为了更新库。我开始后悔这件事。当我不得不重新创建项目时,我发现自己四处寻找lib源而不是仅仅同步到SC。
#6
On a recent Java project I switched to using Maven - this was quite nice since it meant I didn't need to store any third party jars in a lib/ directory. At compile time maven would pull in the dependencies. One nice side affect is the jars have the version number in their filename.
在最近的一个Java项目中,我转而使用Maven - 这非常好,因为它意味着我不需要在lib /目录中存储任何第三方jar。在编译时,maven会引入依赖关系。一个不错的副作用是罐子的文件名中有版本号。
#7
My experience has been to create a "lib" folder and keep all 3rd party binaries in there. I will create a totally separate tree for the Source Code to these third parties if it is available.
我的经验是创建一个“lib”文件夹并保留所有第三方二进制文件。如果可用,我将为这些第三方创建一个完全独立的源代码树。
Some places where this might be different is if you are using an open source vs. a retail 3rd party, with open source solutions I tend to just include the code in my projects and not check-in the binaries.
一些可能与之不同的地方是,如果您使用的是开源而不是零售第三方,使用开源解决方案,我倾向于将代码包含在我的项目中而不是签入二进制文件。
#8
You don't need to store third party libraries in your source control repository. Those libraries (think of SDL, libcurl, etc.) should always be available on the web.
Just two raccomandations:
您无需在源代码管理存储库中存储第三方库。这些库(想想SDL,libcurl等)应始终在网上提供。只有两个raccomandations:
- make sure to state clearly in your code which version of the library you should compile against
- be sure that that specific version is always available on the web
确保在您的代码中清楚地说明您应编译的库的哪个版本
确保该特定版本始终可在网上获得
#9
Generally speaking, I would do roughly what has been prescribed by other users.
一般来说,我会粗略地做其他用户规定的内容。
In the case of Subversion, and I admit I can't speak to the inclusion of the feature in the case of other systems, one can use an External to link in a repository maintained elsewhere. In a checkout/export, you'll get a full copy of the source including the updated code from that external repository all in one go.
在Subversion的情况下,我承认我不能说在其他系统的情况下包含该功能,可以在其他地方维护的存储库中使用External链接。在结帐/导出中,您将获得源的完整副本,包括来自该外部存储库的更新代码。
This was particularly nice for me with PHP/JS development as there is no issue regarding storing binaries. I'd keep an external of the Zend Framework, Doctrine ORM, and jQuery all in a /lib/ folder of the project. Every update would give me a complete, updated copy of -all- the necessary files without any more work than adding that repository URL to an svn property.
对于PHP / JS开发来说这对我来说特别好,因为没有关于存储二进制文件的问题。我将Zend Framework,Doctrine ORM和jQuery的外部保存在项目的/ lib /文件夹中。每次更新都会给我一个完整的,更新的-all-必要文件的副本,而不是将该存储库URL添加到svn属性。
#10
If you are using git (which I recommend), and you have the source of the third party library, then storing the library in its own git repository and including it as a submodule is an excellent setup.
如果您正在使用git(我推荐),并且您拥有第三方库的源代码,那么将库存储在自己的git存储库中并将其作为子模块包含在内是一个很好的设置。
If the source library is also using git then you can clone their library and push it to your own server so you'll never lose it.
如果源库也使用git,那么您可以克隆它们的库并将其推送到您自己的服务器,这样您就永远不会丢失它。
Git submodules allow you to specify which revision of a library is required for a project, which is great for maintaining compatibility.
Git子模块允许您指定项目所需的库版本,这对于保持兼容性非常有用。
#11
Conceptually you need to store at least the binaries (and the headers if you do C/C++) That's usually the only way with third party libraries where you don't have the source.
从概念上讲,您至少需要存储二进制文件(如果使用C / C ++,则需要存储标题)这通常是第三方库中没有源代码的唯一方法。
If you have the source you can opt to store the source and build the third party libraries in your build process.
如果您有源,则可以选择存储源并在构建过程中构建第三方库。
#12
You should be able to install a fresh OS, get your sources from source control, built and run. So yes, you should put them in source control.
您应该能够安装新的操作系统,从源代码控制中获取源代码,构建和运行。所以是的,你应该把它们放在源代码管理中。
#13
It depends on how big they are. When binaries or installers are too big, it can cause havoc for remote users. The upside of storing binaries and installers is that everything a developer needs to get up and running is in source control and the versions are correct. If you have a separate installation location, versions can get messed up. So, in general I like to store small or moderate binaries in source control, but larger ones I leave out.
这取决于它们有多大。当二进制文件或安装程序太大时,它可能会对远程用户造成严重破坏。存储二进制文件和安装程序的好处是开发人员需要启动和运行的所有内容都在源代码管理中,并且版本是正确的。如果您有单独的安装位置,则版本可能会混乱。所以,一般来说,我喜欢在源代码控制中存储小型或中型二进制文件,但是我忽略了较大的二进制文件。
Edit: Oh, and I call mine "BinRef" :)
编辑:哦,我称之为“BinRef”:)
#14
When would you store binaries in your source control?
您何时在源代码管理中存储二进制文件?
I store binaries in source control when I want they ability to quickly revert back to the old version of an application. There are number of reason I would do this, those include the following:
当我希望他们能够快速恢复到旧版本的应用程序时,我将二进制文件存储在源代码管理中。我有很多理由这样做,包括以下内容:
- Application testing in an environment that exactly matches production is not always possible.
- The previous programmer may not have used source control or may have used it incorrectly. So it can be difficult to be sure the source code you are changing is the version that matches what the user is working with.
在与生产完全匹配的环境中进行应用程序测试并非总是可行。
以前的程序员可能没有使用源代码控制或者可能使用不正确。因此,很难确定您要更改的源代码是与用户正在使用的版本匹配的版本。
#15
On source code and compiled libraries (most likely standalone):
在源代码和编译库(很可能是独立的):
If I don't use the third party components (compiled libraries) or provided source to build inhouse software components, I simply take them off the shelf and install them as prescribed (which might include a compile, pl/sql code for example). I would not install them in a dependency management repo or any source control system for the simple reason that I don't want them incorporated accidently or otherwise in components I'm building and I don't want to track them in any software cycle. This is an asset (software asset) that should be tracked with other tools. If I'm not using them for software development, I don't and shouldn't see them in tools I use for software development.
如果我不使用第三方组件(编译库)或提供源来构建内部软件组件,我只需将它们从架子上下载并按照规定安装它们(例如,可能包括编译,pl / sql代码)。我不会将它们安装在依赖管理仓库或任何源代码控制系统中,原因很简单,我不希望它们无意中包含在我正在构建的组件中,或者我不希望在任何软件周期中跟踪它们。这是应该使用其他工具跟踪的资产(软件资产)。如果我不使用它们进行软件开发,我不会也不应该在我用于软件开发的工具中看到它们。
If I depend on them for building my own software, I would store them all day long.
如果我依赖它们来构建我自己的软件,我会整天存储它们。
#1
-
How: a vendor branch is generally a good approach
方式:供应商分支通常是一种好方法
-
When (thirdparties): for minimizing the number of referential involved: you could add those libraries into a separate external referential (like Maven), but that mean you need to access that extra referential for each of your environment (development - integration - homologation - preproduction - production)
当(第三方):为了最大限度地减少所涉及的参考数量:您可以将这些库添加到单独的外部参照(如Maven)中,但这意味着您需要访问每个环境的额外参考(开发 - 集成 - 认证 - 预生产 - 生产)
-
When (code): for managing the complexity of the changes, when you know updates and fixes for current versions running into production will be needed while new development are in progress.
当(代码):用于管理更改的复杂性时,当您知道正在进行新开发时,将需要更新和修复当前运行到生产中的版本。
-
Why (store both): for deployment reason: you can manage a complete configuration (list of elements you need) in one referential and query it wherever and whenever you need for:
为什么(存储两者):出于部署原因:您可以在一个参考中管理完整的配置(您需要的元素列表),并随时随地查询:
- development (you query what you need to develop and execute your code, including thirdparties needed for compilation/execution)
- tests (integration, homologation): you query the exacts tags you want to update your testing workspace with
- production: you identify exactly what goes into production from one source: your SCM.
开发(您查询开发和执行代码所需的内容,包括编译/执行所需的第三方)
测试(集成,认证):您查询要更新测试工作区的精确标记
生产:您可以确定从一个来源准确投入生产的内容:您的SCM。
For test and production environments, that also mean your own product (the packaged result of what you are building) should also go into your SCM (only the official releases, not the intermediate ones used internally).
If other projects depend on your product, they will build their own project against your packaged version stored in the SCM, not against your source code they somehow recompiled.
对于测试和生产环境,这也意味着您自己的产品(您正在构建的产品的打包结果)也应该进入您的SCM(仅限官方版本,而不是内部使用的中间版本)。如果其他项目依赖于您的产品,他们将针对存储在SCM中的打包版本构建自己的项目,而不是针对他们以某种方式重新编译的源代码。
Why this is important ?
Because in the end, what will run in production is that packaged version of your product, not your "source code re-compiled". Hence the importance to make all your test with the target final form of your product, clearly stored and tagged in your SCM.
为什么这很重要?因为最终,生产中将运行的是产品的打包版本,而不是“源代码重新编译”。因此,重要的是使用产品的目标最终形式进行所有测试,并在SCM中明确存储和标记。
Martin Lazar raises a legitimate point in his answer
马丁拉扎尔在他的回答中提出了一个合理的观点
Source control is called "source" control, because it is supposed to control sources.
源控件称为“源”控件,因为它应该控制源。
While that may have been historically true, every current RCS have evolved toward SCM (Source Code Management), which does not just control sources, but also manages changes to documents, programs, and other information stored as computer files.
Binaries can then been stored (even stored with binary-delta)
虽然这在历史上可能是正确的,但是每个当前的RCS都已经发展为SCM(源代码管理),它不仅控制源,还管理对作为计算机文件存储的文档,程序和其他信息的更改。然后可以存储二进制文件(甚至存储二进制三角形)
Plus that allows some of those SCM to propose S"C"M feature (as in Source Configuration Management).
That SCM (Configuration) not only stores any kind of "set of files", but also their relationships (aka dependencies) between those sets, in order for you to query one set of file, and to "pull" every other deliveries on which that set depends on (to build or to deploy or to run)
另外,这允许一些SCM提出S“C”M功能(如在源配置管理中)。 SCM(配置)不仅存储任何类型的“文件集”,还存储它们之间的关系(也称为依赖关系),以便您查询一组文件,并“拉”每个其他的交付。该集依赖于(构建或部署或运行)
#2
Assuming you are using .Net:
假设您正在使用.Net:
I create a "Libraries" folder in my project and source control that contains any third party assemblies.
我在我的项目和源代码控制中创建一个“库”文件夹,其中包含任何第三方程序集。
My solution then references those assemblies and my build process pulls that folder down to our build server.
我的解决方案然后引用那些程序集,我的构建过程将该文件夹拉到我们的构建服务器。
Any one pulling your code from source control should be able to compile it without having to hunt down references and assemblies.
从源代码控制中提取代码的任何人都应该能够编译它而无需查找引用和程序集。
#3
How do you store third party libraries that you use in your project in your source control?
如何在源代码管理中存储项目中使用的第三方库?
As binary or source or both. Depends on the library.
作为二进制或源或两者。取决于图书馆。
When would you store binaries in your source control?
您何时在源代码管理中存储二进制文件?
A third party library for which we don't have the source or an internal library which we haven't made any changes to or the library is too huge to be built around.
我们没有源或内部库的第三方库,我们没有对其进行任何更改,或者库太大而无法构建。
When would you store the code in your source control?
您何时将代码存储在源代码管理中?
Say, we use an internal library A but have made some bug fixed specific to product X. Then product X's depot will keep the source and build it.
比方说,我们使用内部库A,但已经修复了一些特定于产品X的错误。然后产品X的库将保留源并构建它。
Would you ever store both? In what situations would you do this?
你会存两个吗?在什么情况下你会这样做?
Yes, all the latest binaries are stored in source control.
是的,所有最新的二进制文件都存储在源代码管理中。
So the tree looks like this:
所以树看起来像这样:
product
|-- src
|-- build
|-- lib
|- 3rdparty
|- internal
...
#4
Source control is called "source" control, because it is supposed to control sources..
源代码控制称为“源”控件,因为它应该控制源代码。
In Java it's common pattern to use some version control system to store sources and other resources like configuration XML files or pictures, and than to use some dependency management tool like Apache Maven, which will store, download and manage your project's dependencies on 3rd party libraries. Then when you reinstall your OS, Maven can automatically download your dependecies from central repository (or your own private repositories as well) and store them in a local cache on your disk. You don't even have to know where the cache is :)
在Java中,使用某些版本控制系统来存储源和其他资源(如配置XML文件或图片),而不是使用某些依赖管理工具(如Apache Maven),它将存储,下载和管理项目对第三方库的依赖性。 。然后,当您重新安装操作系统时,Maven可以自动从*存储库(或您自己的私有存储库)下载您的依赖项,并将它们存储在磁盘上的本地缓存中。你甚至不必知道缓存在哪里:)
Maven can be also used with other languages and as far as I know plugins for .net and C/C++ are available, but I haven't used it with anything else than Java.
Maven也可以和其他语言一起使用,据我所知,.net和C / C ++的插件都可以使用,但是除了Java之外我还没有使用它。
#5
I don't put 3rd party source or binaries in SC. My rationale was that I would not have to update SC just to update the libraries. I am starting to regret this though. When I have had to recreate the project I find myself running around looking for the lib sources instead of just syncing to SC.
我没有在SC中放置第三方源或二进制文件。我的理由是,我不必更新SC只是为了更新库。我开始后悔这件事。当我不得不重新创建项目时,我发现自己四处寻找lib源而不是仅仅同步到SC。
#6
On a recent Java project I switched to using Maven - this was quite nice since it meant I didn't need to store any third party jars in a lib/ directory. At compile time maven would pull in the dependencies. One nice side affect is the jars have the version number in their filename.
在最近的一个Java项目中,我转而使用Maven - 这非常好,因为它意味着我不需要在lib /目录中存储任何第三方jar。在编译时,maven会引入依赖关系。一个不错的副作用是罐子的文件名中有版本号。
#7
My experience has been to create a "lib" folder and keep all 3rd party binaries in there. I will create a totally separate tree for the Source Code to these third parties if it is available.
我的经验是创建一个“lib”文件夹并保留所有第三方二进制文件。如果可用,我将为这些第三方创建一个完全独立的源代码树。
Some places where this might be different is if you are using an open source vs. a retail 3rd party, with open source solutions I tend to just include the code in my projects and not check-in the binaries.
一些可能与之不同的地方是,如果您使用的是开源而不是零售第三方,使用开源解决方案,我倾向于将代码包含在我的项目中而不是签入二进制文件。
#8
You don't need to store third party libraries in your source control repository. Those libraries (think of SDL, libcurl, etc.) should always be available on the web.
Just two raccomandations:
您无需在源代码管理存储库中存储第三方库。这些库(想想SDL,libcurl等)应始终在网上提供。只有两个raccomandations:
- make sure to state clearly in your code which version of the library you should compile against
- be sure that that specific version is always available on the web
确保在您的代码中清楚地说明您应编译的库的哪个版本
确保该特定版本始终可在网上获得
#9
Generally speaking, I would do roughly what has been prescribed by other users.
一般来说,我会粗略地做其他用户规定的内容。
In the case of Subversion, and I admit I can't speak to the inclusion of the feature in the case of other systems, one can use an External to link in a repository maintained elsewhere. In a checkout/export, you'll get a full copy of the source including the updated code from that external repository all in one go.
在Subversion的情况下,我承认我不能说在其他系统的情况下包含该功能,可以在其他地方维护的存储库中使用External链接。在结帐/导出中,您将获得源的完整副本,包括来自该外部存储库的更新代码。
This was particularly nice for me with PHP/JS development as there is no issue regarding storing binaries. I'd keep an external of the Zend Framework, Doctrine ORM, and jQuery all in a /lib/ folder of the project. Every update would give me a complete, updated copy of -all- the necessary files without any more work than adding that repository URL to an svn property.
对于PHP / JS开发来说这对我来说特别好,因为没有关于存储二进制文件的问题。我将Zend Framework,Doctrine ORM和jQuery的外部保存在项目的/ lib /文件夹中。每次更新都会给我一个完整的,更新的-all-必要文件的副本,而不是将该存储库URL添加到svn属性。
#10
If you are using git (which I recommend), and you have the source of the third party library, then storing the library in its own git repository and including it as a submodule is an excellent setup.
如果您正在使用git(我推荐),并且您拥有第三方库的源代码,那么将库存储在自己的git存储库中并将其作为子模块包含在内是一个很好的设置。
If the source library is also using git then you can clone their library and push it to your own server so you'll never lose it.
如果源库也使用git,那么您可以克隆它们的库并将其推送到您自己的服务器,这样您就永远不会丢失它。
Git submodules allow you to specify which revision of a library is required for a project, which is great for maintaining compatibility.
Git子模块允许您指定项目所需的库版本,这对于保持兼容性非常有用。
#11
Conceptually you need to store at least the binaries (and the headers if you do C/C++) That's usually the only way with third party libraries where you don't have the source.
从概念上讲,您至少需要存储二进制文件(如果使用C / C ++,则需要存储标题)这通常是第三方库中没有源代码的唯一方法。
If you have the source you can opt to store the source and build the third party libraries in your build process.
如果您有源,则可以选择存储源并在构建过程中构建第三方库。
#12
You should be able to install a fresh OS, get your sources from source control, built and run. So yes, you should put them in source control.
您应该能够安装新的操作系统,从源代码控制中获取源代码,构建和运行。所以是的,你应该把它们放在源代码管理中。
#13
It depends on how big they are. When binaries or installers are too big, it can cause havoc for remote users. The upside of storing binaries and installers is that everything a developer needs to get up and running is in source control and the versions are correct. If you have a separate installation location, versions can get messed up. So, in general I like to store small or moderate binaries in source control, but larger ones I leave out.
这取决于它们有多大。当二进制文件或安装程序太大时,它可能会对远程用户造成严重破坏。存储二进制文件和安装程序的好处是开发人员需要启动和运行的所有内容都在源代码管理中,并且版本是正确的。如果您有单独的安装位置,则版本可能会混乱。所以,一般来说,我喜欢在源代码控制中存储小型或中型二进制文件,但是我忽略了较大的二进制文件。
Edit: Oh, and I call mine "BinRef" :)
编辑:哦,我称之为“BinRef”:)
#14
When would you store binaries in your source control?
您何时在源代码管理中存储二进制文件?
I store binaries in source control when I want they ability to quickly revert back to the old version of an application. There are number of reason I would do this, those include the following:
当我希望他们能够快速恢复到旧版本的应用程序时,我将二进制文件存储在源代码管理中。我有很多理由这样做,包括以下内容:
- Application testing in an environment that exactly matches production is not always possible.
- The previous programmer may not have used source control or may have used it incorrectly. So it can be difficult to be sure the source code you are changing is the version that matches what the user is working with.
在与生产完全匹配的环境中进行应用程序测试并非总是可行。
以前的程序员可能没有使用源代码控制或者可能使用不正确。因此,很难确定您要更改的源代码是与用户正在使用的版本匹配的版本。
#15
On source code and compiled libraries (most likely standalone):
在源代码和编译库(很可能是独立的):
If I don't use the third party components (compiled libraries) or provided source to build inhouse software components, I simply take them off the shelf and install them as prescribed (which might include a compile, pl/sql code for example). I would not install them in a dependency management repo or any source control system for the simple reason that I don't want them incorporated accidently or otherwise in components I'm building and I don't want to track them in any software cycle. This is an asset (software asset) that should be tracked with other tools. If I'm not using them for software development, I don't and shouldn't see them in tools I use for software development.
如果我不使用第三方组件(编译库)或提供源来构建内部软件组件,我只需将它们从架子上下载并按照规定安装它们(例如,可能包括编译,pl / sql代码)。我不会将它们安装在依赖管理仓库或任何源代码控制系统中,原因很简单,我不希望它们无意中包含在我正在构建的组件中,或者我不希望在任何软件周期中跟踪它们。这是应该使用其他工具跟踪的资产(软件资产)。如果我不使用它们进行软件开发,我不会也不应该在我用于软件开发的工具中看到它们。
If I depend on them for building my own software, I would store them all day long.
如果我依赖它们来构建我自己的软件,我会整天存储它们。