blocks|key|3135273|text|通常，我只向版本控制中添加可能由我自己或其他同事维护的项。外部库通常由项目消耗-大多数项目不在业务中，正在重写它们所依赖的库。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3135274|我建议在版本控制中添加一些你可以的工具。对于其他所有内容，您可以只将包保存在一个公共位置。不需要用标准发行版中永远不会改变的代码来膨胀你的存储库。|3135275|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Generally I only add items to version control that are likely to be maintained by myself or someone else I work with. An external library is normally consumed by a project - most projects aren't in the business are re-writing the libraries they depend upon.

I would suggest adding tools that you customize to version control. For everything else, you can just save the packages in a common location. No need to bloat your repository with code that will never change from the standard distribution.

blocks|key|3135333|text|我将构建脚本置于版本控制之下，而不是工具。通常，我的版本文件要么是应用程序核心的一部分，要么可能在项目的生命周期内频繁更改(每个人都需要访问这些更改)。这包括几乎所有的配置文件。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|3135334|entityMap^0|4|2|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

I put build scripts under version control, but not tools. Generally I version files that either part of the core of the application, or are likely to change frequently during the lifetime of the project (and which everyone needs access to those changes). This includes pretty much all configuration files.

blocks|key|3135398|text|我们没有--事实上，我从来没有为一个地方工作过。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3135399|我们确实在源代码控制中保留了像Makefile、构建脚本和测试脚本这样的东西，但从不保存ant或C编译器之类的东西。|3135400|原因是，要使构建工具达到可用状态，通常需要的不仅仅是简单的签出，您还需要做一些繁重的sysadmin工作来同时维护多个版本或在不同版本之间切换。因此，将它们保持在源代码控制中将解决问题的一小部分。|3135401|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

We do not - in fact, I've never worked for a place that did.

We do keep things like Makefiles and build scripts and testing scripts in source control, but never ant or C compiler or such.

The reason is, it usually requires more than simple checkout to get the build tool to a usable state, and you need to do some heavy-duty sysadmin job to maintain multiple versions at the same time or switch between versions. So keeping them in source control would solve the tiny part of the problem.

blocks|key|353935|text|我们不会在SVN中放置来自外部的工具(Visual+Studio、Eclipse、CDT-Plugin等)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|353936|但是我们有一大套自己编写的工具(代码生成器，为VS定制的构建工具，以及一个Eclipse插件)，我们将源代码和二进制文件放到SVN中。|353937|做出这个决定的原因很简单，技术上：|353938|353939|我们的工具非常小，不需要显式的设置例程即可运行(因此，简单的svn签出会让您拥有一组正在运行的工具)|unordered-list-item|353940|我们的工具比第三方工具更频繁地更改(因此我们不需要告诉开发人员每月更新工具3次)|353941|353942|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Q|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|S|8|@]|9|@]|A|$]]|$1|J|3|K|5|I|7|T|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|N|$]]

We do not put Tools in SVN that came from outside (Visual Studio, Eclipse, CDT-Plugin, ...).

But we have a big set of self-written tools (code generators, custom build assmeblies for VS, and an Eclipse plugin) where we put the source AND the binaries into SVN.

The reasons for this decision are simple technical:

<ul>
<li>Our tools are very small and do not need an explicit setup-routine to run (so a simple svn checkout leaves you with a running set of tools)</li>
<li>Our tools change more often then the 3rd party tools (so we don't need to tell our developers to update the tools 3 times a month)</li>
</ul>

blocks|key|351320|text|是的，我将交付软件生产过程中的所有内容都放在版本控制中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|351321|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Yes, I keep EVERYTHING that is part of the process of delivering a software production in version control.

blocks|key|3348430|text|不，我没有，因为我使用MsBuild，而且它也是.NET框架的一部分|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3348431|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

No, I don't because I use MsBuild, and it's part of .NET framework anyway

blocks|key|353997|text|我将makefile、shell脚本和我编写的任何代码生成器放在版本控制中。我不会在版本控制中存储二进制文件，除非有不容易从源代码构建的库。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|353998|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I put makefiles, shell scripts, and any code generators I have written in version control. I don't store binary files in version control unless there librarys that cant easily be built from source.

blocks|key|356505|text|关于这一点，有两种流派：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|356506|356507|只需将您的源代码放入repository.|ordered-list-item|356508|Put中，而无需操作系统和语言运行时即可将您的软件构建到存储库中所需的一切。|356509|356510|我个人更倾向于#2，因为它使人们更容易启动和运行我的代码。无论如何，我认为如果你选择第一种方法，你至少应该这样做，这样一个人就可以在一个步骤中获得第二点和你的源代码所要求的东西，即使不一定是通过版本控制。|356511|不幸的是，构建系统是一种灰色区域。我个人认为，除非我使用的是晦涩难懂或非标准的东西，否则我会将其省略。而那些晦涩和非标准的东西是由你工作的环境决定的。例如，如果您的公司一直使用MSBuild，但出于某种原因决定在这个项目中使用Nant，那么我会将其包括在内。|356512|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|P|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|Q|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|R|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|S|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|N|$]]

There are two schools of thought on this:

<ol>
<li>Put just your source code into the repository.</li>
<li>Put everything someone would need to build your software short of the operating system and language runtime into the repository.</li>
</ol>

I personally tend more towards #2 because it makes it easier for someone to get up and running with my code. At any rate, I would argue that if you opt for the first method, you should at least make it so that a person can get the things required by point 2 and your source code in one step, even if not necessarily by version control.

Unfortunately, the build system is kind of a grey area. I personally leave it out unless I'm using something obscure or non-standard. And what's obscure and non-standard is dictated by the environment you work in. For example, if your company always uses MSBuild but decided to use Nant for whatever reason on this one project, then I'd include it.

blocks|key|3348574|text|不是的。大多数开发工作室都有一套相当标准的工具。然而，一个想法是保持一个标准的“快速设置”wiki或类似的深度链接到所有需要的构建工具的安装程序。编写它，以便经验相对较少的人可以轻松地设置开发机器。一个更高级的选择是保留一个包含所有内容的标准虚拟硬盘。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3348575|但是，我们会将所有其他内容都保存在源代码控制中--所有构建脚本、SQL脚本、文件依赖项(即引用的all没有安装在GAC或程序文件中)等。|3348576|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

No. Most development shops have a fairly standard set of tools. One idea, though, would be to keep a standard "quick setup" wiki or similar that deep-links to installers for all needed build tools. Write it so that a person with relatively little expirience can easily set up a development machine. A more advanced option would be to keep a standard virtual hard disk containing everything.

We do, however keep everything else in source control- all build scripts, SQL scripts, file dependencies (ie referenced dlls not installed in the GAC or program files) etc.

blocks|key|351424|text|是!这就是我的答案。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|351425|我把像NUnit和NAnt这样的构建工具放到了版本控制中。|351426|对我来说，主要的规则是：|351427|351428|构建服务器必须能够构建解决方案。|unordered-list-item|351429|351430|而且我使用的构建服务器没有安装NUnit、NAnt等。|351431|构建服务器只有.NET框架和CruiseControl.NET，没有太多其他的东西。|351432|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|S|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|T|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|U|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|V|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|P|$]]

Yes! is my answer.

I put build tools like NUnit and NAnt in version control.

The main rule for me is:

<ul>
<li>The build server has to be able to build the solution.</li>
</ul>

And the build server I use does not have NUnit, NAnt etc installed. 

The build server has got the .NET framework and CruiseControl.NET, and not much else....

blocks|key|3348632|text|我通常在java项目中使用eclipse/ant。不，我没有将JDK、Ant或eclipse置于版本控制之下，但是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3348633|3348634|all+my+|unordered-list-item|3348635|3348636|(S)|3348637|3348638|所有第三方库在其使用的版本中(是的，也是junit)|3348639|3348640|原因:我有一个几乎自包含的构建系统，任何安装了jdk和ant的系统都可以构建，而不需要网络连接(外部javadoc的包列表也已签入)。这可以是我的macbook，公司的windows桌面，任何连续的构建服务器。|3348641|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|S|8|@]|9|@]|A|$]]|$1|F|3|-4|5|E|7|T|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|U|8|@]|9|@]|A|$]]|$1|I|3|-4|5|E|7|V|8|@]|9|@]|A|$]]|$1|J|3|K|5|E|7|W|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|X|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|Y|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|P|$]]

I typically work with eclipse/ant on java projects. No, i do not keep the JDK, Ant or eclipse under version control, but:

<ul>
<li>all my source</li>
<li>the build script(s)</li>
<li>all 3rd party libraries in their used version (yes, also junit)</li>
</ul>

The reason: i have a nearly self contained build system, any system with a jdk and ant installed will be able to build, without network connection neccecary (package lists for external javadoc also checked in). This can be my macbook, the companies windows desktop, any continious build server.

blocks|key|3348700|text|不是工具，而是脚本。我们使用Ant。驱动该过程的build.xml脚本受源代码控制。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3348701|entityMap|0|LINK|mutability|MUTABLE|url|http://ant.apache.org/^0|E|3|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Not the tool, but the script. We use <a href="http://ant.apache.org/" rel="nofollow noreferrer">Ant</a>. The build.xml script that drive the process is under source control.

blocks|key|3135920|text|我们走了一条不同的道路来设置一个VM，我们在这个VM上构建我们的版本。然后将其存档(但由于某种原因不会进入修订控制系统)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3135921|只要我们有一台可以托管VM的机器，我们就可以重新创建二进制文件。使我们独立于底层操作系统。|3135922|liscence管理器的启动和运行有一些问题，但之后一切都很好。|3135923|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

We went down a different path of setting up a VM on which we make our release builds. This then gets archived (but not into the revision control system for some reason).

So long as we have a machine that can host the VM we can recreate the binaries. Giving us independance from the underlying OS.

There were a few issuses getting the liscence manager up and running, but after that all was good.

blocks|key|351553|text|我们使用maven，所以我们只签入代码、测试、配置文件，当然还有pom.xml，没有库，没有工具。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|351554|entityMap|0|LINK|mutability|MUTABLE|url|http://maven.apache.org/^0|4|5|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

We use <a href="http://maven.apache.org" rel="noreferrer">maven</a>, so we only check in the code, the tests, config files and of course the pom.xml, no libs, no tools.

blocks|key|356671|text|就我个人而言，我更喜欢将尽可能多的构建工具放在存储库中，但我在IDE和编译器中划清了界限。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|356672|我认为这是一种权衡:我可以在以下两种情况之间做出选择：|356673|356674|记录了必要的工具(包括维护文档)，每次我需要返回到项目时都必须安装它们(并用project)|unordered-list-item|356675|Putting上的每个额外开发人员乘以存储库中的工具，这样它们就会自动签出正确的版本。|356676|356677|对于像IDE这样的东西，只记录它会更容易，而且大多数开发人员都已经安装了它。对于Ant、Nant、JUnit等，将其包含在存储库中会更容易。|356678|我特别喜欢在存储库中包含Ant/Nant，因为它允许我包含这样的go.bat/go.sh脚本：|356679|set+ANT_HOME=tools/apache-ant-x.x.x
tools/apache-ant-x.x.x+%25*|code-block|syntax|javascript|356680|然后，我可以随时签出一个项目，运行"go“，它应该会构建项目(假设我已经安装了JDK/.Net+Framework+)。|356681|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|10|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|11|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|13|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|14|8|@]|9|@]|A|$]]|$1|O|3|P|5|Q|7|15|8|@]|9|@]|A|$R|S]]|$1|T|3|U|5|6|7|16|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|W|$]]

Personally, I prefer to put as many of the build tools as possible in the repository, but I draw the line at the IDE and the compiler.

I like to think it as a tradeoff: I can choose between:

<ul>
<li>Documenting the necessary tools (including maintaining that documentation) and having to install them each time I need to get back to the project (and multiply that by each extra developer on the project)</li>
<li>Putting the tools in the repository, so they are automatically checked out with the right version. </li>
</ul>

For something like the IDE, it is easier to just document it, and most developers will have it already installed. For Ant, Nant, JUnit etc. it is easier to include it in the repository.

I especially like having Ant/Nant in the repository, because it allows me to include a go.bat/go.sh-script like this:

<pre><code>set ANT_HOME=tools/apache-ant-x.x.x
tools/apache-ant-x.x.x %*
</code></pre>

Then I can always checkout a project, run "go" and it should build the project (assuming I have the JDK/.Net Framework installed).

blocks|key|3348860|text|我们是一家Maven商店，以前是一家蚂蚁商店。在ANT时代，我们会将依赖库签入到项目结构中。现在我们只签入构建应用程序所需的资源(pom、源代码、资源等)，但肯定没有库。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3348861|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

We are a Maven shop and previously an ANT shop. In the ANT days we would check dependent libraries into the project structure. Now we only check in the resources necessary to build the application (pom, source code, resources, etc) but definitely no libraries.

blocks|key|3348893|text|代码、构建、测试、文档和任何其他自动化。我通常甚至还会将时间表和任何其他与项目相关的文档放入存储库中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3348894|对于大多数项目，如果我有依赖库的源代码，我通常会将它们放在自己的存储库中，这样我就可以随着时间的推移跟踪它们的变化。|3348895|至于可安装包中的预打包工具，我将它们都保存在一个可访问的服务器上的一个大目录树中(与旧版本一起)。这样，我就可以让任何新开发人员查看目录，并告诉他们要安装什么(并且知道他们的版本与团队其他成员的版本相同)。我会使用存储库，但它有点夸张，而且共享文件系统更容易被每个人访问。旧版本将保留，以防出现支持问题。|3348896|保罗。|3348897|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Code, build, test, documentation and any other automation. I generally even put the schedules and any other project-relevant documentation in the repository as well. 

And for most projects, if I have the source for dependent libraries, I usually put those in their own repositories, so I can track changes to them over time.

As for pre-package tools in installable packages, I keep them all in one big directory tree on a accessible server (with the old versions). That way I can point any new developers at the dir and tell them what to install (and know that they have the same versions as the rest of the team). I'd use a repository, but it's overkill, and a shared file-system is easier to access by everyone. The old versions are kept in case of support issues.

Paul.

blocks|key|3348917|text|我们的存储库中包含的内容：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3348918|3348919|我写的任何代码或者我的学生写的|unordered-list-item|3348920|所有Makefiles、测试脚本以及我们修改过的类似|3348921|外部工具的东西(我们通常放入整个工具中，而不仅仅是补丁)，包括Andrew+Hume的Make|3348922|版本|3348923|没有放进去的是：|3348924|所有编译器的|3348925|源代码我们使用|3348926|
|3348927|源代码作为shell|3348928|
的源代码|3348929|如果我们有更好的工具，我们会把它全部放到存储库中。有关如何做到这一点并跟踪所有版本的所有内容的好书，请查看Digital+SRC+Vesta+project上的这本书。|offset|length|3348930|entityMap|0|LINK|mutability|MUTABLE|url|http://books.google.com/books?id=eIcAtrxitvEC&dq=vesta%2Blevin&printsec=frontcover&source=bl&ots=s5f-GSv4fc&sig=9SRLLRgrpFnYf4bY-v2Np-7PM0w&hl=en&sa=X&oi=book_result&resnum=4&ct=result^0|0|0|0|0|0|0|0|0|0|0|0|0|1T|D|0|0^^$0|@$1|2|3|4|5|6|7|19|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1B|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|1C|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|1D|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1E|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1F|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1G|8|@]|9|@]|A|$]]|$1|P|3|Q|5|E|7|1H|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1I|8|@]|9|@]|A|$]]|$1|T|3|U|5|E|7|1J|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1K|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1L|8|@]|9|@$Z|1M|10|1N|1|1O]]|A|$]]|$1|11|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]]|12|$13|$5|14|15|16|A|$17|18]]]]

What goes into our repository:

<ul>
<li>Any code I write or any of my students write</li>
<li>All Makefiles, tests scripts, and things of that ilk</li>
<li>External tools we have modified (we typically put in the whole tool, not just patches)
including Andrew Hume's version of Make</li>
</ul>

What doesn't go in:

<ul>
<li>Source code to all the compilers we're using</li>
<li>Source for the shell</li>
</ul>

If we had better tools we would put it all into the repository. For a great book on how to do this and keep track of all versions of everything since the start of time, check out the book on the Digital SRC <a href="http://books.google.com/books?id=eIcAtrxitvEC&amp;dq=vesta+levin&amp;printsec=frontcover&amp;source=bl&amp;ots=s5f-GSv4fc&amp;sig=9SRLLRgrpFnYf4bY-v2Np-7PM0w&amp;hl=en&amp;sa=X&amp;oi=book_result&amp;resnum=4&amp;ct=result" rel="nofollow noreferrer">Vesta project</a>.

blocks|key|353019|text|我们保留了两个存储库：“快速移动的存储库”包含我们的代码，以及用于发布和补丁的分支。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|353020|移动缓慢的版本包含第三方的库和工具，包括JDK版本。大多数情况下没有分支或标记，因为另一个中的代码知道如何选择它需要的内容。同一个库的两个版本以不同的名称检入，因此在检出后这两个版本都可用。我们自己的一些交叉发布工具也包含在这个存储库中。IDE不包括在内，因为它们不是官方构建过程的一部分。|353021|将工具存储在某种存储库中有两个原因：|353022|353023|任何开发人员都可以轻松地找到他们需要的工具。|ordered-list-item|353024|可以创建过去任何官方版本的副本，以便生成补丁。|353025|353026|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Q|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|S|8|@]|9|@]|A|$]]|$1|J|3|K|5|I|7|T|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|N|$]]

We keep 2 repositories: The "fast moving one" contains our code, with branches for releases and patches.

The slow moving one contains 3rd party libraries and tools, including JDK versions. There is no branching or tagging for most of this, as the code in the other knows how to select what it needs. Two versions of the same library are checked in under different names, so both will be available after a checkout. Some of our own cross-release tools are also included in this repository. IDE's are not included, as they are not part of the official build process.

There are two reasons to store tools in some sort of repository:

<ol>
<li>Any developer can easily find the tools they need.</li>
<li>A replicate of any official build from the past can be created, so that a patch can be generated.</li>
</ol>

blocks|key|351667|text|我真的对所有“不，我不做这个”的回答感到惊讶。您不能可靠地构建代码库，除非您拥有编写代码时所依据的依赖项的特定版本。因此，这将包括您引用的任何DLL，如单元测试和模拟框架、UI控件集等。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|351668|开发人员应该能够在几个步骤中完成签出和构建。有些地方需要花上一整天的时间。|351669|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I'm really surprised by all the "no I don't do this" responses. You can't reliably build the code base unless you have the specific versions of the dependencies that the code was written against. So this would include any DLLs you are referencing like unit testing and mocking frameworks, UI control sets, etc.

A developer should be able to do a checkout and build in just a couple steps. There's places out there where this takes all day.

blocks|key|3136224|text|不是的。绝对不是。绝不可能。您的VCS应该只包含您的代码。如果你想确保有人可以快速安装你的代码，你需要提供一个分发系统。希望安装您的代码的人应该使用打包的二进制发行版或从源码tarball构建。他们不应该从VCS构建。发行版tarball是放置项目构建所必需的东西的地方，这些东西要么是自动生成的，要么不是项目的直接组成部分。然而，它不是依赖的地方。如果您的项目需要boost库，则应在文档中将其作为依赖项进行说明，如果未安装，则构建将失败。从源代码tarball构建的用户应该能够安装依赖项。从打包的二进制发行版构建的用户希望让软件包系统处理依赖问题。从VCS构建的用户(即开发人员)需要安装项目所需的构建工具。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3136225|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

No. Absolutely not. Never. Your VCS should only house your code. If you want to ensure that someone can quickly install your code, you need to provide a distribution system. Someone who wishes to install your code should be using either a packaged binary distribution or building from a source tarball. They should NOT be building from the VCS. The distribution tarball is the place to put things that are necessary for your project to build but that are either automatically generated or not directly part of your project. It is NOT the place for dependencies, however. If your project needs the boost libraries, it should be stated in the documentation as a dependency and your build should fail if it is not installed. The user building from the source tarball is expected to be able to install the dependency. The user building from the packaged binary distribution is expecting to have the package system deal with the dependency issue. The user building from the VCS (ie, a developer) is expected to install the build tools necessary for your project.

blocks|key|356775|text|我尝试始终使用虚拟机作为构建系统。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|356776|并为每个项目存储这些(最好的情况下)。|356777|在所有工具中使用tarball或存储库的主要问题是：|356778|安装它们需要花费太多的时间，几年后你总是会遇到问题才能让它重新工作。|356779|也可以通过脚本下载，或者只是简单地告诉web源是不稳定的几年后，你会得到一些新的版本与其他功能和错误。|356780|有时在较新的操作系统版本上安装构建系统会失败。|356781|或者一些新版本的工具(如Visual+Studio2025)将使用其他项目文件，并且“完全向上兼容”失败。|356782|此外，许可证在几年后是有问题的，你能在合理的时间内获得新的激活密钥吗？无论如何，该公司确实支持它吗？|356783|虚拟机只包含所有必要的已安装工具，几分钟后即可运行。|356784|很好，特别是如果我只想修改几行代码。|356785|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|X|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|10|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|11|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|12|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|13|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|14|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|U|$]]

I try to use always virtual machines as the build system. 
And store these (in the best case) for each project. 

The main problem of using a tarball or a repository with all your tools: 
It costs too much time to install them all and then you get always problems to get it working again after some years.

Also downloading via a script or simply tell only the web source is to unstable after some years, you will get some newer release with other features and bugs. 

It's sometimes simply fails to install the build system on a newer OS-Version. 
Or the newer version of some tools (like Visual Studio 2025) will use other project files and the "full upward compatibility" fails. 

Also the licenses are problematic after some years, can you get your new activation key in a reasonable time? Does the company does support it anyway?

Virtual machines simply contains all necessary installed tools and are running after a few minutes. 
Nice, especially if I only want to change only a few lines of code.

Do you keep tools that are necessary to build your project under version control?

If you do, what are your guidelines for which tools to include? I guess noone puts Visual Studio in version control, but how about your unit-test-runner? The Nant/Ant/Maven executable?

How about external dependencies? Do you have Boost in version control? The JDK? NUnit/JUnit? Where do you draw the limit here?

(See also <a href="https://stackoverflow.com/questions/191533/svn-and-binaries">this question</a>).

EDIT:
I guess my question was not completely clear: I did not want to know whether you kept them in version control vs. or some shared drive. I really wanted to know whether you checked the tools necessary for building a project into version control together with the project, so that when you checked the project out, you would automatically get the tools.

As a general follow-up to those who answer no: what is your process for keeping track of those tools? Do your script download them?

Do you keep your build tools in version control?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

您是否将构建项目所需的工具置于版本控制之下？如果你这样做了，你对包含哪些工具的指导方针是什么？我猜没有人会把Visual Studio放在版本控制中，但是你的单元测试运行器呢？Nant/Ant/Maven可执行文件？那么外部依赖关系呢？你在版本控制中有Boost吗？JDK？NUnit/JUnit？在这里你在哪里画限制？...

问您是否将构建工具保持在版本控制中？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问您是否将构建工具保持在版本控制中？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问您是否将构建工具保持在版本控制中？
EN