[译] How things get done on the Go Team

6天前,掌舵Go语言团队12年Rsc在golang-dev/群组发文宣布,将在9月1号后辞去当前职位,转去做 GabyOscar. 这对于Go语言发展无疑是里程碑式的事件。



本篇内容是根据6月份他和另外两位同事参与Go Time音频录制内容的整理与翻译,英文原文在gotime/go-time-318.md,过程中为符合中文惯用表达有适当删改, 版权归原作者所有.



Angelica Hill: 欢迎收听Go Time。今天我们有一个特别的节目。我们邀请到了来自Google Go团队的Cameron Balahan、Sameer Ajmani和Russ Cox。他们将和我们讨论Go团队是如何工作的。他们如何决定要改进什么?如何决定改进这些事情的顺序?除了决定要做什么,他们还会讨论什么时候做——是现在做,还是下周或明年做?然后我们会听听他们各自对Go未来的看法。当他们展望未来时,他们看到了什么?我非常兴奋能邀请到你们来参加节目。在我们开始之前,让我先简单介绍一下——正如我提到的: Cameron Balahan,他是Google的Go编程语言产品负责人; Sameer Ajmani,他是Google的工程总监,负责领导Go编程语言团队。最后,Russ Cox,他是Google的Go主要编程语言技术负责人。大家好!

Russ Cox: 你好。

Angelica Hill: 大家好吗?

Sameer Ajmani: 你好,安吉丽卡。

Cameron Balahan: 很高兴来到这里。

Angelica Hill: 我们状态如何?

Cameron Balahan: 状态很好。

Sameer Ajmani: 很兴奋能来到这里。

Russ Cox: 很高兴来到这里。

Angelica Hill: 太棒了。那么我们从一个非常基本的问题开始…对于那些可能不熟悉你们在Go领域的工作,或者可能没有看过你们做的许多精彩演讲的人,我想听听你们是如何走到今天这一步的。你们是如何进入Go领域的?也许我们可以从你开始,Russ。

Russ Cox: 我进入Go是因为我之前在贝尔实验室与Rob Pike和Ken Thompson一起工作过。我在大学时期在那里做过暑期实习生。所以当Rob去了Google后,我一直和他保持联系,当他开始从事Go的工作时,我正在读研究生,他说"你应该来加入我们。"然后我就加入了。从那以后我一直在从事Go的工作。所以已经有很多年了。很难计算具体时间… 16年了。

Angelica Hill: 太棒了。那么Sameer,你的Go之旅是怎样的?

Sameer Ajmani: 我2004年加入Google,主要用C++构建系统。大约在2010年左右,Rob Pike来做了一个关于他和他的团队正在开发的一种叫做Go的新编程语言的教程…我对此非常感兴趣,我认为它真的很酷,特别是我可以看到它如何简化我在C++中进行的大量分布式系统编程。

所以我开始在业余时间贡献。Google有名的20%时间 — 我用它来为Google内部的Go库做贡献。最终,Russ安排了一次会面。我们在MIT读研究生时就认识了…他说"嘿,你想全职从事Go工作吗?我们正在寻找人来构建我们在Google内部的库套件。"所以我在2012年加入了团队。


(译者注: Google 的"20%时间"是指鼓励员工利用周工作时间的20%进行自主研究和创新项目的开发)

Angelica Hill: 那么Cameron,你是如何听说Go的?

Cameron Balahan: 我是这里相对是新人…我在Google才工作了四年。在此之前,我的职业道路可能有点不集中,这在事后看来可能不是最优的…但我实际上当过一段时间的律师,做了一些完全不相关的事情。然后我在高频交易领域工作了将近十年,在那里我大量使用C++和一些Java,编写低延迟交易基础设施…我一直很欣赏那些贴近底层的东西,了解事物在深层次上是如何运作的…所以当我加入Google并且Go成为一个选项时,我想"哇,多么好的机会啊。"所以我想我加入Go是因为我很幸运。

Sameer Ajmani: 我也是。

Russ Cox: 我想我们都觉得能参与这个项目非常幸运。

Angelica Hill: 太棒了。所以我的假设是 — 对于那些可能不知道这一点的人来说 — Russ,当你加入Go时,它还处于非常早期的阶段,只有几个人在开发…然后它逐渐发展,然后Sameer,你加入了,然后当Cameron你加入时,Google已经有了一个成熟的团队。你能告诉我一下Go团队现在是如何组成的吗?从某人有了一个想法,开始工作,然后Sameer,你利用20%的时间参与其中…到现在已经成为一个非常成熟、功能齐全的团队,这个过程是怎样的?

Sameer Ajmani: 当然,我可以谈谈这个。一开始只有三个人: Rob Pike、Robert Griesemer和Ken Thompson。很快Russ Cox和Ian Lance Taylor也加入了。我认为这五个人是最初的Go团队。到我2012年加入时,我想大约有十几个人,那时他们正准备发布Go 1.0。所以你可以说我是在团队发布1.0版本时加入的。

我开始管理一个专注于Google内部Go的子团队,然后到2016年,我转向管理整个Go团队。那时我们已经有超过20人了。之后Go团队继续增长,特别是当我们扩展到云领域,并与Google的云业务保持一致时。这是我们增长的重要部分。那也是我们开始建立跨职能团队的时候,除了核心团队之外,我们开始有了产品经理、UX 研究人员、开发者关系合作团队、项目经理等。所以我们真的开始学习如何在更广泛的Google企业中作为一个团队运作,超越了更多的小规模项目。多年来,团队已经发生了很大的变化。我们内部的具体组织方式取决于我们的关注点,我们稍后会在播客中详细讨论这一点。

Angelica Hill: 那么在有这个内部的Go团队的同时,还有这个非常丰富的开源社区…Go是一个非常活跃的社区,我们喜欢见面,喜欢互相交流…但我想多了解一下这两个社区是如何互动的,当你有一个正式的团队,但你又有开发者在那里贡献,你有这个非常丰富的开源社区。

Russ Cox: 是的,有很多不同层次的互动。最非正式的可能是像Slack和邮件列表,Go团队的人只是参与其中…也许他们有更多的知识可以分享,但在那里大家基本上是平等的参与者。然后你有问题追踪器,我们的很多工作都在那里完成,任何想要在问题追踪器上闲逛的贡献者都随时欢迎。有些人的日常工作就是在问题追踪器上闲逛,所以你经常会看到他们,然后还有一些人在那里是因为他们关心某个特定的问题,或者有些人在那里只是因为他们喜欢这样做,但他们并没有因此得到报酬…所以你会看到不同程度的活动,这很好。真正让事情运转起来需要所有这些不同层次的参与。

我们有最正式的互动方式是提案流程,我们已经开始了很多年了。我写了一系列博客文章,讨论如何管理一个开源项目,如何做决策,我们创建了提案流程,有一种正式的方式让每个人都参与到决策中来,从像我们要在字符串包中添加什么新函数这样小的事情,到"我们应该在Go工具链中添加遥测吗"这样大的事情,它真的适用于所有这些。但提案流程的目标是有一个明确的地方,任何想要贡献和参与的人都可以参与其中。

Angelica Hill: 那么通常,在Go团队的工作方式方面,我知道你们中的一些人提到团队的组成会根据团队的重点,根据你们认为语言创新所在的地方而变化…Russ,你提到了提案流程…我很感兴趣地想了解 — Cameron,从你作为产品经理的角度来看 — 你是如何看待所有这些不同的想法流?你有你的提案,你有从你们各自不同角色对语言创新的个人看法…然后你有实际的Go工程师团队,我相信他们有大量的想法。事情是如何真正完成的?你们如何决定"好的,这就是这个团队要做的事情?"也许因为你提到了,Sameer,如果团队正在变化,如果你们正在改变团队的组成,你们是如何做出这些决定的?

Sameer Ajmani: 这是一个很好的问题。目前的Go团队主要分为三个大的子团队。 我们有所谓的核心子团队,负责编译器、运行时、链接器,并运行核心发布流程。我们有工具子团队,负责我们的构建系统、Go命令,以及我们的IDE插件和gopls语言服务器后端,这与核心发布流程是分开的。这是我们最近几年投资较多的领域。我想在过去五六年里,我们真的专注于构建我们的IDE体验。

更近期的是,我们专门建立了一个专注于安全的子团队。大约几年前,新闻中出现了几起重大的开源供应链安全攻击。Codecov、SolarWinds…这大约是在我们开发Go模块系统的同时…我们认识到Go有机会真正解决我们的模块系统和构建系统中的一些供应链安全问题,某种程度上也在语言本身中解决。所以我们接受了这个机会,说"我们要让我们团队的一部分真正专注于Go安全,如何处理安全报告,如何进行漏洞扫描,如何思考Go程序的组成…"这已经取得了很好的效果。这也是我们需要与Google对Go的兴趣保持一致的案例,以及使用Go的Google客户的关注点,以及我们内部使用Go的系统。


(译者注:

Codecov 和 SolarWinds 是两家软件公司,都因为安全相关的事件而引起广泛关注。

Codecov:

  • Codecov 是一家代码覆盖率分析服务提供商,帮助开发者衡量和改善他们的代码质量。
  • 2021 年,Codecov 遭遇了一起严重的安全漏洞事件,造成数千家公司的机密数据泄露。该漏洞被黑客利用,从 Codecov 的系统渗透到客户的系统中。
  • 这起事件引发了关于供应链安全的广泛讨论,凸显了第三方服务提供商的安全性对客户系统的重要性。

SolarWinds:

  • SolarWinds 是一家 IT 基础设施管理软件公司,其产品被广泛用于企业网络监控和管理。
  • 2020 年,SolarWinds 的软件遭遇了一起严重的供应链攻击事件。黑客在 SolarWinds 的软件更新中植入了恶意代码,导致数千家公司和政府机构的系统被入侵。
  • 这起"SolarWinds事件"被认为是近年来最严重的网络安全事件之一,突显了软件供应链安全的重要性。许多公司和政府机构由此受到重创。

Codecov 和 SolarWinds 事件揭示了第三方服务提供商和软件供应链安全面临的严峻挑战,引发了业界和政府对此的广泛关注和应对措施。)


Cameron Balahan: 补充一下,我认为另一种思考方式是Go的两个主要利益相关者,一个是Go用户和Go社区,他们从Go中寻求什么价值…另一个是Google。所以Google显然对确保其内部系统运行良好,其开发人员满意,其系统可靠、安全等感兴趣…然后事实证明,外部Go开发人员也想要这些。Google还希望这些外部Go开发人员能够成功和快乐,不仅仅是出于善意,而是因为这样这些开发人员就能更成功,更快地创造价值,或者构建更可靠的软件,更安全的软件…所有这些都有助于Google的开发者平台,然后也有助于其更大的业务;让互联网成为一个运作良好的地方,让公司能够构建他们的产品并推出它们,让用户使用它们,这符合Google的利益。

对于用户来说,我认为我们一直关注的一个价值点就是生产力。虽然有很多高生产力的编程语言,但 Go 语言的重点是保持简单。它提供了一个整体的平台,让所有部分都连接在一起,让用户可以获得端到端的解决方案,无需借助第三方工具和其他复杂的额外工具。

它同时也确保你创建的高效软件是一些最可靠、安全、高性能的软件。因为这真的很重要,确保你不会花时间更新东西或修复东西。你可以集中精力构建新的东西。

所以这实际上提供了一个很好的视角来思考一切。比如,"好吧,如果我们构建新东西,这如何进一步推进我们的使命,确保我们的开发人员在各处都更有效率,他们正在构建将使他们更成功的生产级别的东西?"这让Google满意,让我们的用户满意,让社区满意,然后Go团队也对此感到非常满意。

分隔标记:[13:53]


Angelica Hill: 那么Russ,作为Go团队的技术负责人是什么感觉?你的日常工作是什么样的?你是不是整天都在和团队交谈,思考自己的有趣想法?我很好奇了解你与这些不同团队的互动是什么样的,作为这个拥有如此多用户的庞大语言的技术负责人意味着什么?我的意思是,就像我们过去看到的那样,你做出一个改变,有些人喜欢,有些人却大为不满。所以我很想了解你是如何看待自己的角色的,以及这到底是什么感觉。

Russ Cox: [笑] 我不知道这是什么感觉。我做这个工作已经很长时间了,就像鱼在水里一样自然。 但我的部分工作是尽量减少争议。我认为这确实是我们从提案流程中学到的,我们需要更多方式让人们参与进来,让他们有意义地贡献并确保他们的声音被听到。这真的是一个重要的部分。我认为自从我们真正实施提案流程以来,我们就没有再遇到那种问题。

举个例子,遥测…我们只听到关于遥测的正面反馈。这真是令人惊讶,主要是因为我们根据最初讨论的反馈将其设为可选加入。可选加入这一事实我认为真的让每个人都非常放心,还有我们会分享数据,所以这不是某种只有我们能访问的专有数据集,我认为这是另一个重要部分。

至于日常工作 — 这要看情况。有时我们在做一些事情,我可以写一些代码,我可以花一两周时间写新代码,这总是很有趣…很多时候是一些原型,我预计团队的其他部分会接手并可能完全替换我写的东西,但我证明了"这是可能的。这可以工作",然后让团队来做真正的版本。

有时就是和很多人开会,审查设计,和他们谈论事情进展如何,他们在做什么,试图以有用的方式引导事情。即使是像有人为某个问题绞尽脑汁这样简单的事,我也可以说"哦,我们这里有个东西,我们已经几年没讨论过了。那可能会有帮助。"成为那种资源也非常有帮助。所以每天都不一样,但…能帮助别人的日子很好,能写代码的日子很好…总的来说,大多是好日子,所以很好。

Sameer Ajmani: 我要补充一点,Go团队奇怪地拥有大量非常有才华的人。我的意思是,我认为Google到处都有很多这样的人,但Go团队可能比其他地方多一点…然后Russ就坐在所有这些人之上,像是一个奇怪的才华横溢且全面发展的人的典范例子…[笑] 我总是试图找到他不擅长的地方,但到目前为止还没成功。

Cameron Balahan: Russ,你现在必须在你的标语里加上"奇怪的全面发展"了。

Angelica Hill: 如果我有幸在GopherCon上介绍你,我会说…“这位奇怪的全面发展的个人…”[笑] 好的,所以你有所有这些很棒的方式来众包想法、提案,当然你也有自己的想法和提案…但当涉及到"好吧,我们在做什么?“时,我们有所有这些有趣的途径,我们有所有这些可以改进的有趣事物…你是怎么 — 我是说,你们是不是坐下来讨论所有冒出来的想法?你们一起做冲刺计划吗?实际的过程是什么,你们说"我们有所有这些很棒的想法,但我们实际上要用我们的时间做什么?”

Russ Cox: 规划更多是分布式的,三个不同的子团队负责自己的规划。所以有些事情来自提案过程之类的,我们会和人们交谈说"嘿,这看起来很重要。我们应该试着把它纳入进来",但这不是一种[听不清00:23:07.26]命令,我决定每个人下周要做什么之类的。我不认为那会有成效。

但总的来说,重要的是设定目标,这样我们就都朝着同一个方向努力。在Go最开始的时候,我们设定的目标是我们希望它能适用于我过去谈到的两种不同类型的规模,一种是生产规模,即扩展到大量机器、大量数据和所有那种计算机规模…另一种是人的规模,即扩展到有很多不同人参与的大型项目…即使你是一个5人的小团队,如果你使用开源包,现在你也在与数百或数千其他人一起工作。所以我们希望Go既能适应人的规模,也能适应机器的规模。

在Go目前的发展和生命周期中,很难做出改变。任何改变,尤其是语言改变 — 你从编译器开始,但然后你必须修复编译器周围的所有工具,gopls,文档和所有那些东西。即使是库的改变 — 我们也想确保这是一个我们想在未来十年支持的API,然后才会考虑重新审视它。

所以我们真的是在尝试做出我们会在10年内都满意的决定, 这是我瞄准的标准。所以,我们做什么的很多问题都基于"它是否服务于生产规模和人的规模的目标?"以及"我们现在对此满意吗?"因为不是暂时的,而是大约是永远的。所以对我们真的很重要,要对我们真正确定的事情说yes。

然后对于规划,有时会出现一些事情,比如某个外部或内部用途需要某些东西,我们会给予更多优先权…最近关于兼容性的工作就是一个例子,Kubernetes团队来找我们说"看,你们一直在以微妙的方式破坏我们,这些实际上并不违反兼容性政策…“你知道,你修复了一个bug。例如,典型的版本是我们有带前导零的IP地址。所以如果你说18.26.014 — 比如,这是十进制的14,还是像八进制的12?结果所有BSD IP地址解析器都将其视为八进制。就像"哇,好吧,当我在Go中写IP地址解析器时我不知道这一点”,我们将它们视为十进制。所以如果不同的工具正在读取它们,它们实际上对它的含义存在分歧。所以我们改为不允许前导零。

我们不能改变我们过去的内容,但我们可以说"我们不会再解析那个了。"现在至少如果我们接受一个IP地址,它对其他人来说就不会意味着不同的东西。但Kubernetes团队有理由担心可能存在一些配置写入了前导零并[听不清00:25:54.00]十进制,因为这是Go给你的…这就是我们过去常做的那种改变的一个例子,它阻止他们更新。所以我们做了大量关于兼容性的工作,我几年前在GopherCon上谈到过,使兼容性更加兼容。所以现在这些类型的改变,直到你也在go.mod文件中更新Go版本时才会触发。所以Kubernetes可以移动到更新的工具链,但保留他们的旧Go版本,然后仍然具有旧版本的那种bug对bug兼容性。这就是一个例子,我们提高了优先级,因为有一个团队来找我们说"看,我们无法获得你们的安全更新,因为我们无法更新到新的Go版本,因为存在这些微妙的破坏。"所以我们做的很多事情都是针对某些特定影响,而不是孤立地做。

Sameer Ajmani: 我要在此基础上补充说,Go团队有两个相互交织的规划周期。有我们的发布规划周期,这是公开的,每个人都看到像"嘿,下一个版本会包含什么?“工具团队有他们自己的IDE发布周期,安全团队必须处理安全发布等等。然后还有 — 我们都是Google员工,所以我们是Google规划周期的一部分。通常有一个年度规划周期,我们做OKRs,即目标和关键结果…所以Cameron和我特别要与我们的Google利益相关者打交道,说"好,这就是我们正在做的工作及其原因。”

所以在Russ的兼容性例子基础上,Kubernetes是一个被每个主要云提供商和更多人使用的公共开源项目,但也有Google Kubernetes Engine团队,这是Google的一个主要的巨大收入产品。我们可以说"看,这是一个合作伙伴团队。为了他们能为客户服务 — 这是Google的一个主要收入来源 — 我们需要解决这个问题,以及Go如何改变自身,我们如何处理兼容性。“所以我们能够排列"这是Google的利益或Google对此的兴趣,这就是为什么这实际上需要我们这边的改变”,我们能够从Kubernetes那里得到额外的利益相关者说"是的,这对我们来说确实非常重要。"但我们试图以一种不是专门针对Google或专门针对Kubernetes的方式进行这种改变,而是为Go生态系统进行一般性的提升。

所以我对兼容性工作特别兴奋,因为现在我们可以做出改变来改进Go。例如,我们最近对循环变量、range变量作用域和遮蔽所做的改变修复了Go语言中最痛苦的一个陷阱,如果没有一些兼容性工作,这真的是不可能的。所以当我们有一个特定客户或一个特定的紧急需求需要满足时,我们寻找这些双赢,并说"好,我们如何以一种能够普遍化并为整个生态系统带来价值的方式来解决这个问题?"

Cameron Balahan: 我要补充的另一件事是 — 也许这在Russ和Sameer说的话中是隐含的,但我们有这三个团队,思考这些端到端解决方案是规划过程的另一部分。所以不仅仅是编译器和运行时,还有例如IDE团队,他们有gopls、Visual Studio Code插件等。我们与安全团队一起做的一些漏洞工作…所以去年,当我们引入漏洞管理或[听不清00:29:01.01]时,有几个不同的方面需要考虑。一个是命令行,有govulncheck工具,另一个是IDE,在那里漏洞会在你编写代码时出现,还有pkg.go.dev,在那里你可能想获取关于你正在考虑使用的依赖项的已知漏洞的信息…所以我们试图创建这些 — 我们将使用所有这些不同的东西来创建一种我们发布的东西的连贯性,这额外强大。我们实际上发现Go社区会很快接受这些东西。他们都会使用 — 而在另一个生态系统中,可能有各种工具可以用于同一个工作。在Go中,大多数用户会使用我们的东西,所以我们能够将他们引导到这些连贯的端到端解决方案中,我认为这使得每个人都更容易采用他们认为有价值的东西,比如更好的漏洞检测和修复。

Russ Cox: 我想补充一点,即使这三个子团队密切合作,你在日常工作中并不真的感觉到…Cameron解释了对于漏洞检查,显然安全团队和工具团队都参与其中…编译器运行时团队也参与其中,因为有关于从二进制文件中获取信息的标准库更改,有关于嵌入用于构建这个特定二进制文件的模块信息的链接器更改和编译器更改…所以这真的是一个全队努力。在日常工作中,我们不会听到 — 你不会想"好吧,那个人在不同的子团队,所以我不能和他们交谈",或者诸如此类的事情。它真的感觉像一个连贯的团队。这是我们在Go中的一个真正优势。

我认为Go服务于两个不同但互补的目的。一个是实际上成为一个端到端的系统,我们控制它,我们可以 — 如果我们决定"嘿,[听不清00:30:54.21]漏洞管理很重要",那么我们可以从编译器一直到IDE进行任何我们想要的更改,因为我们在我们的领域内拥有整个堆栈。

然后Go重要的另一个原因是它作为其他系统的一种例子,因为我们可以在Go中证明某些东西,因为我们控制整个系统,我们很容易进行整个系统的更改。然后我们可以说"哦看,我们做了整个事情。它工作得多好。这些事情真的很好用。这可能适用于其他系统",其他系统可以利用这一点。

当我们做goroutines时,Google内部的C++团队做了fibers,我认为我们已经发布了一些看起来很像goroutines的工作…最近,我们为Go模块代理做的校验和数据库,其他包管理系统也开始采用校验和数据库…所以Go作为一个我们都可以使用的生产系统很好。它也很好,因为我们可以树立一个榜样,我们可以展示"嘿,这实际上是有效的。"我们可以把它用作这些事情的测试场,证明场。

Sameer Ajmani: Go的这种领导作用,如果说有什么变化的话,那就是在加速。例如,当我们做漏洞时,Russ与Google内部的另一个团队合作,该团队正在标准化OSV,即开源漏洞标准。所以Go的漏洞方法的一个不同之处是,我们不仅包含了关于漏洞影响的特定包和版本的信息,甚至还包含了符号信息,比如哪些函数。如果你调用这些函数,那么你就会触发漏洞,如果你不调用这些函数,那么你就不会受到影响。我们使用这个 — 再加上Go中的静态分析 — 来过滤漏洞报告并对它们进行优先排序。我们可以消除40%与你的程序无关的报告,因为你没有调用受影响的函数。通过将其纳入OSV,这现在可以用于其他生态系统。如果我没记错的话,这也是新的CSV — 抱歉,CVE 5.0标准。所以这是一个Go在安全和漏洞检查的特定领域的领导地位非常迅速地影响行业跟随的案例。

Angelica Hill: 从你的角度来看,这是否是拥有一个专门团队的核心好处之一,正如你提到的,Russ,真正的端到端,能够不断协作并确保如果在一个地方有变化,它不会产生负面的连锁反应,而且它真的会继续保持那种端到端的流畅一致性?

Russ Cox: 是的,绝对是。我的意思是,让Go感觉像是一个系统对我们来说真的非常重要。这并不是说在一个部分做某事会产生负面影响。我们显然不希望那样…但缺少这种情况并不是真正的标准。在一个地方做某事 — 它需要实际渗透并在各处得到很好的支持。它需要感觉像是一个整体。它不应该是语言功能但例如gopls还不支持。所以如果gopls支持还没有准备好,或者还没有就绪,或者诸如此类,那么我们会推迟语言功能。我们不想发布只在生态系统的一部分工作的东西。我们真的希望它是一个整体。

所以随着Go的成长 — 比如,在2009年Go的初始发布中,它只是一个编译器。甚至没有go命令。你只是运行像[听不清00:34:09.05]。它非常非常原始。现在我们从那里开始构建。首先我们有了Go命令,然后最终我们得到了所有围绕它的工具,诸如此类的东西,以及generate和test…然后现在我们有了IDE,以及所有其他 — 比如,我们有VS Code Go和gopls,但然后所有其他IDE现在,或编辑器,它们都使用gopls…所以我们真的不断构建Go所涉及的内容。现在我们有了代理和校验和数据库…它不断增长,我们真的希望有一个连贯的系统。

Angelica Hill: 所以我很想了解一下 — 无论是具体例子还是一般情况 — 你是如何考虑开源社区和内部Go团队之间,Go团队内部,Go社区内部存在冲突的情况的?因为你有,正如我们多次提到的,非常有才华、非常投入的工程师,无论是在Go团队内部还是外部,他们都热爱Go…我相信有很多次实现X、Y、Z事物的正确方式,或者是否引入X、Y、Z功能是有争议的。这不是一个简单的是或否。我想知道你是如何处理这些决策点的。

Russ Cox: 是的,我的意思是,它并不像你想象的那么频繁出现…当它确实出现时,我认为那是因为人们有不同的观点还没有被摆在桌面上。所以当我在做提案过程阅读时 — 我读了大量关于其他人如何运作流程的东西,以及诸如此类的东西…我发现John Ousterhout写的一份很棒的文档,标题是"开放决策"。你可以直接谷歌一下。他谈到共识驱动的过程时说, “如果你正确管理它,几乎总是可能直接达成共识。” 他说的引用是"如果一群聪明人都看同一个问题,拥有相同的信息,并且他们有相同的目标,那么他们很可能会得出相同的结论。"所以如果我们对结论存在分歧,我们需要做的是回到"我们是否有相同的信息,我们是否有相同的目标?"如果我们不同意,你追求的是什么目标,我追求的是什么目标?如果我们能从那里倒推,通常我们可以谈论目标。或者也许我有你没有的信息,我可以分享,现在我们有了相同的信息…我们试图在那个层面上工作,然后共识往往会随之而来。

所以我认为我们多年前学到的 — 可能是在2014年左右 — 当我们第一次尝试做别名时,效果真的不好,部分问题是我们实际上没有呈现我们拥有的所有信息,我们没有解释为什么它是一个重要的功能。所以我们撤回了它,然后那年11月在Gotham Go上我做了一个演讲,我称之为"渐进代码修复",以及关于一次一个包地进行大规模程序重构。特别是为什么类型别名对于实现这一点真的非常重要。没有类型别名你就无法做到这一点。

有了那个背景,然后我们做了类型别名,基本上那时没有反对意见。问题是我们没有分享足够多关于"为什么这很重要?"因为在非常大的代码库中,它超级重要。在你控制整个东西并且可以做一个大提交的小代码库中,情况就很不一样。所以再次,我认为所有的冲突最终都回到"我们是否有相同的目标?"和"我们是否有相同的信息?"我们可以通过分享更多信息来修复信息问题。至于目标 — 我们可以说,"好吧,我们有不同的目标…但这些是Go项目的目标,所以这就是我们分歧的原因。"人们往往会对此没问题。就像"好的,我理解,我的目标与你不同。这就是我们不同意的原因。不是你没有听我说话。"所以我认为这些对我们在过去十年中学到的东西真的非常重要。


译者注:
在[Go Changes–Russ Cox在GopherCon 2023的演讲]( “Go Changes–Russ Cox在GopherCon 2023的演讲”) 提到过

Gotham Go是在纽约举行的Go活动

Gotham即哥谭市,一般被认为是纽约的代称


Angelica Hill: 这是否也直接转化为 — 这个问题可能是给你的,Sameer — 你如何考虑内部冲突,或者也许是对解决已经被某种程度优先考虑的问题的方法的分歧,或者我们正在解决什么问题?这甚至是个问题吗?

Sameer Ajmani: 所以在Go团队内部 — 这是一个非常赞的团队,我认为我们建立的解决问题的文化非常非常好。我看到冲突的主要地方更多是关于优先级,也就是人们对首先做什么是重要的存在分歧。一个人可能有一套他们正在努力实现的目标,或者正在进行的项目,他们受到一些时间限制,或者有其他人依赖他们…然后另一个团队成员依赖第一个人完成某些事情,他们觉得自己没有得到所需的时间。这只是一个有限资源的情况,通常我们需要保护人们的时间和注意力,让他们完成正在做的事情,然后他们可以转移注意力…而不是要求人们同时尝试做太多事情(我们过去犯过错误),这可能非常累人,会拖慢所有人和所有事情。所以我们试图让更多的团队致力于集体的、共同的目标…所以通常,这些更大的发布,像泛型、漏洞,确实倾向于将团队团结在一起,我们尽最大努力尝试组织每个人围绕这一点,所以至少我们有一个近期的共同目标,我们可以朝着这个方向优先考虑。

我们处理目标和冲突的另一个地方是当你超越Go团队,考虑更广泛的Google,以及Go团队如何在Google中立足,我们如何在那里确定优先级。好消息是,根据我作为领导的经验,Google一直是Go极好的管理者和赞助者…通常,Go团队非常受信任,可以为Go和Go用户做正确的事。我从未感到在Google受到压力去做任何对Go或Go用户不利的事情。我们有时会对什么是必要的,或什么应该优先考虑存在分歧,但这在一个大公司中是很自然的…通常,Cameron、Russ和我所做的艺术就是找到那个双赢的情况,在那里对Go正确的事和对Google正确的事是尽量一致的。

Angelica Hill: 我认为这引出了我的下一个问题,这个问题是给你的,Cameron,因为我们从你那里听到了很多,Sameer,关于优先级的困难…你是如何管理Go作为一种软件工程语言的产品的?所以我是一名技术产品经理,我负责管理一个产品, 但它是一个平台,它是后端数据基础设施…但你是如何管理产品或如何考虑Go作为一个产品的?

Cameron Balahan: 我知道,这很奇怪,对吧?我认为你不是唯一一个想知道这一点的人。我认为产品管理通常是一个非常特定于角色、公司和产品的事情。所以也许它总是有点模糊…但我试图弄清楚从优先级路线图、愿景的角度来看什么是最好的,以及我们为用户和Google提供的价值是什么,我考虑的是我在开始时提到的那件事,即这个用于生产级软件的高效平台。

所以我们知道这样真的很有效,Go用户和Google都从中获得了很多价值。我们以传统的产品管理方式看待市场,我们考虑产品选择生命周期,我们考虑我们试图在这里解决问题的角度是什么…结果发现Go在解决云时代的问题方面非常成功。大多数云基础设施都是用Go编写的,Go在这些领域做得很好。这也意味着在这个新时代,有很多不同类型的供应链攻击,Go在所有这些基础设施中扮演着关键角色,所以安全性真的很重要,我们也知道用户也会想到这个。

所以我考虑这个框架,我想"好的,我们在考虑什么?它如何进一步实现生产力和生产级的目标?我们如何确保我们从中创造出连贯的解决方案?"而且,它是否增加了我们希望它增加的价值,即我们的开发人员能够更快地获得价值,他们能够随着时间的推移降低他们的总拥有成本,他们的软件更可靠和安全…这是一些有助于用户更成功的事。

所以知道使命、工作和客户成功之间的这种路径是我可以用来思考其他一切的基本指导方针。然后补充一下Sameer刚才说的,我认为我很幸运产品是Go,因为 — 嗯,首先,用户和社区真的很喜欢它。所以这个东西就继续自己成长。社区为它添加东西,在它周围构建库,为它找到新的用途…它只是自己拿起来用在新的计算范式中;你只会看到新的东西,“哦,它是用Go写的。太棒了。” 这一切自然而然发生。

对于Google内部而言,Google本身确实很尊重Go。我的意思是,Google做了很多很酷的东西,它的很多东西都有很多用户,诸如此类的东西都存在…但Go真的很特别。我认为Google认识到Go有多特别,以及Go用户对它的满意程度。我不知道你是否看过我们最新的开发者调查,我们的客户满意度达到了93%,我认为这在行业中是前所未有的。所以这很酷,我想每个人都认识到这一点。这也让我的工作变得更容易。

Angelica Hill: 当然。Gopher们热爱Go。所以我很想听听 — 我们已经谈了一些过去的事,我们也谈了一些当前的流程和现状…我很想听听你们每个人对未来的期待,无论是即将到来的事情,还是当你们思考Go的未来时你们在想什么,你们对什么感到兴奋,你们在思考什么有趣的问题。什么让你们感到好奇?什么让你们思考有趣的问题?也许我们从你开始,Russ。

Russ Cox: 当然。实际上我对Go 1.23非常兴奋。我最近一直在写大量的代码,能够使用新的迭代器和新的range循环真是太棒了。我的意思是,能够编写适合range语句的自定义迭代器 — 这真的有点改变了我写很多代码的方式。能够抽象出诸如数据库扫描之类的东西,以及那些类型的东西真的非常有帮助。所以我迫不及待地想让所有这些都上线,这样其他人也可以写那些类型的东西。

从长远来看,我在思考的是 — 我认为这是正确的说法 — 就是开源的整体可持续性。因为我们从像xz攻击这样的事情中看到 — 我们多年来一直知道关键的东西严重缺乏资金,这为坏人创造了一个非常容易的机会,真的可以在这些低层次上造成任意的伤害。

我问了一屋子来自不同公司的资深人士,他们认为xz攻击花费了多少钱。普遍的共识是"也许100万或200万美元"。而也许100万或200万美元就几乎可以在互联网上的每台机器上获得SSH shell — 这相当不错。这是相当好的投资回报率。所以我们需要想办法让这些攻击变得更加困难。我们不能继续在开源中做我们正在做的事情。所以这是我们作为一个行业在未来十年必须解决的有趣的疑问。


(译者注: [xz攻击](https://www.aqniu.com/industry/103405.html "xz攻击")指的是2024年3月份发现的Jia Tan长达几年潜藏底层开源项目,添加恶心代码事件)

Sameer Ajmani: 两件事…一是我们谈到了供应链安全和漏洞 — 我实际上认为在这方面还有很多可以做的。Go生态系统的一个区别特征是它的统一性。每个人,在大多数情况下,都在使用go命令来构建,使用go modules来管理依赖…这是一个巨大的杠杆。这意味着我们可以做一些事情,比如当有人对上游包进行更改时运行测试;你可以运行一些依赖测试的样本,看看在更改被提交或标记为下一个版本之前是否会破坏任何东西。你可以想象,如果我们能够大规模地做到这一点,我们可以大大降低整个生态系统中破坏性变更的比率,这将为每个人降低成本。不仅会降低成本,而且如果发生的破坏性变更更少,那么更新到最新版本就会变得更容易和更便宜。这不仅使得跟上功能变化变得更容易,而且还可以更容易地修复漏洞。所以如果你有一个有漏洞的依赖,而你知道更新不太可能破坏你的代码,因为生态系统的破坏性变更更少,那么漏洞的持续存在就不太可能了。所以如果有一个供应链攻击,就像Russ刚才提到的,我们必须能够更快地大规模修复。这些都是Go生态系统的统一性以及构建系统和模块系统特别能够实现的,我认为这在大多数其他生态系统中是不可能的。所以我觉得这很令人兴奋。

另一件事 — 我相信Cameron也会谈到这一点 — 就是AI正在吞噬我们所有人的生活,对吧?每个人都在谈论AI,询问AI…好消息是我们已经思考Go和AI有一段时间了。甚至早在去年年初或更早之前,我们就在思考"嗯,Python用户真的很喜欢Go,很多人确实采用了Go,而Python被用于AI…所以这里有什么联系吗?“我们的结论是"不太可能”,在某种意义上说,数据科学家喜欢Python是因为它是一种非常棒和非常符合人体工程学的语言,非常高效,在你的笔记本中工作得很好,而且有这个庞大的生态系统,有非常丰富和优秀的库。我们没有想要从Go那里去竞争这一点。但是现在,随着越来越多的大公司、企业和初创公司想要在AI模型之上构建系统,他们想要构建基于AI的生产级、可信赖、可靠的系统。现在我们进入了Go的领域,对吧?

所以在我脑海中的问题,我们都一直在讨论的是,“那个转变的时刻是什么?”,当你从比如说,在Python中进行原型设计,证明概念和想法,然后你说"好的,现在我们要认真了。我们想要构建一个产品,我们想要构建一个系统。我们想要构建一个服务,我们想要构建使用AI的基础设施,并有适当的检查和平衡来处理AI的不可靠性和幻觉。"如果我们希望这是用Go来实现,那么就有一个转变的时刻,在那里"好的,现在[听不清 00:49:15.26] 这看起来像什么,我们如何促进这一点?我们如何让Go成为构建生产AI系统的语言?我认为这是下一个大前沿,我们将看到对此的大量需求,我认为Go是一个非常适合的选择。

Cameron Balahan: 是的,Sameer有点说了我想要说的话,我本来想说的是,我对Go的增长感到兴奋。编程语言的采用本质上是一个缓慢的过程。没有人会回去重写已经工作的东西,我们也不希望这样…如果你已经有大量用一种语言编写的服务器,你可能会用那种语言编写下一个…所以引入一种编程语言然后让它被采用 — 这是一件大事,需要很长时间。只是看到Go的有机增长,特别是近年来,就像我说的,社区喜欢它,它就不断自我持续发展…我认为现在已经达到了一个门槛,我看到它可能会更快速地增长,或者至少在更多地方找到它。我认为部分原因可能是以特定的方式与AI前沿有关,但它实际上更普遍地与新的计算范式有关;当这些出现时,这些就是写新代码的机会。也许新公司出现了,他们必须选择一个技术栈,他们可能会使用云,他们可能会关心生产力和他们能多快地推出产品,他们可能会关心长期的总拥有成本,以及产品的安全性和可靠性,他们会发现Go非常适合所有这些事情,而他们可能在很久以前学过的其他语言,或者在早期看到过生产中的语言并不那么适合。这是非常令人兴奋的,因为Go真的很适合。所以我真的很兴奋看看会发生什么。一般来说,就是增长。所以AI是作为增长的贡献者。

然后你问到了一个担忧,或者类似的东西…我可能不担心,但只是在思考AI。我想知道这一切看起来是什么样子。这显然非常有趣,我认为特别是在软件开发生命周期中,有机会削减低效率,使工作更有成效…有时候虽然看起来其中一些被夸大了,我不知道实际的真相在哪里,但我有兴趣看看这将如何发展。更强大的代码完成实际上会对软件工程更普遍地产生什么影响。

所以正如Sameer所说,我们密切关注这一点,因为理解我们所处的市场和我们的用户想要什么是很重要的。我们希望能适应。我们希望为我们的用户提供所有让他们满意的东西,比如生产力和其他东西。所以我会说总体增长,但想知道AI在未来会如何影响我们的整个行业。

Angelica Hill: 当然。我还有一个最后的问题,这更多的是关于你们如何思考Go及其发展。我知道,比如Sameer,你提到了Python在这个领域的角色,那不是Go的领域,但这是…我有点好奇在你们的脑海中 — 任何人都可以回答这个问题 — 是关于让Go在它当前所在的领域成为最好的,真正使那个,正如你所说的,Sameer,那个房子成为你能建造的最强大的房子,用最好的材料?还是关于建造一个房子、一条船、一个平房和一架飞机…?[笑] 或者更多的是 — 请原谅我如果我用这个解释让你们迷惑了…“好的,这个房子已经足够好了。让我们现在用Go来建造这架飞机”,真正进入Go现在不在的领域?

Sameer Ajmani: 所以我将这个问题具体化为现有房子的机会与其他机会。比如说,让我们看看云。Go是一种非常棒的语言,用于构建云应用程序、多线程服务器、进行大量通信。我听到的所有估计都指向,可能在云上的大多数工作负载仍然不在云上。所以还有巨大的未来来构建可扩展的软件和基础设施,这些需要可靠、生产就绪和高效,以及Go所具备的所有特性。所以我认为我们现有的Go基础仍然非常重要,它仍然需要大量投资才能做得很好。

同时,正如Cameron指出的,软件工程和软件开发正在转变。我们需要关注它是如何变化的。所以我认为我们不知道 — 我记得在你的笔记中看到,你问"那么ML呢?前端呢?"我们甚至多年前就看过Go mobile…我们尝试不要仅仅根据什么是热门就追逐下一个新机会。我们试图有选择性。例如,当所有的加密和挖矿东西都很热门时,一些加密人采用了Go,Google的人问"哦,我们看到[听不清 00:54:56.19],我们基本上说"不,我们很好。我们不需要追逐那个潮流。"但是对于供应链安全,我们看到了做一些真正与众不同的事情的机会,这与我们现有用户想要的东西非常一致。

所以对于AI — 再次,我们不是试图追逐数据科学家和迭代模型开发的Python用户。我们关注的是那些在生产中大规模构建的人 — 他们将不得不处理AI,处理将AI整合到他们现有的系统中,他们将处理模型、安全性和可观察性。那么我们如何为他们服务呢?所以有一种方法可以利用我们现有的用户群,他们现有的关注点,同时也思考"好,他们的需求如何扩展?Go用户的工作将如何改变?"所以它既是构建使用模型的系统,也是他们自己使用AI生成Go代码或理解他们的Go程序。所以我想这就是我思考我们的工作如何改变的方式,如果你是一个普通的Go用户,你的世界如何改变,我们Go团队如何促进这种改变?

Angelica Hill: 所以如果gopher获得闪亮的新ML法拉利,你们将不得不确保你们的Go房子有一个适合那辆ML法拉利的车库?

Sameer Ajmani: 我喜欢它。这是一个完美的比喻。

Cameron Balahan: 我只是想补充一点 — 别忘了还有整个Go社区在Go之上构建。Go团队本身不能构建所有那些平房和那些汽车和所有那些东西…只需确保他们能够构建他们需要构建的东西,以继续 — 保持Go在人们需要高效地构建他们的业务、构建软件、构建他们需要构建的东西并且达到生产级别的前沿…这是思考的重要部分,就是有一整个社区在上面。

Angelica Hill: 还有什么最后的想法吗?我们即将转向不受欢迎的观点,但我想确保如果你们有任何最后的想法或你们真的很兴奋要与我们的Go Time听众分享的事情,我给你们这个机会。

Russ Cox: 当然,我有一个想法。去telemetry.go.dev并启用遥测。

Angelica Hill: 太棒了。好的。

[音乐淡入]

Sameer Ajmani: 多年前 — 嗯,可能我对Go最大的贡献实际上是context数据类型,每个人都必须处理它侵入他们的函数签名…Russ和我一起做了最初的设计,但我做了大部分的编写和推广。我们得到了很多反馈说"啊…!难道没有更好的方法吗?"我不受欢迎的观点是context很好。它实际上很好地完成了它的工作,考虑到你必须处理多线程请求处理程序、goroutine、截止日期和超时,以及请求[听不清 00:57:54.01]值,它所做的事情是非常微妙和棘手的…它基本上就是工作。而且实现足够简单,我们能够随着时间的推移对其进行优化,而且…是的,context滥用的风险并没有成为我们真正担心的巨大、普遍的问题…而且在大多数情况下,Go开发人员似乎正确地使用它,我对此很感激。

Angelica Hill: 这是一个很棒的不受欢迎的观点。接下来,Cameron或Russ,你们有什么不受欢迎的观点想要分享吗?

Cameron Balahan: 当然。所以我一直在想这个…其中一个,我想,我之前在某些场合分享过,那就是我真的很喜欢Go的错误处理。我真的很喜欢。所以当人们对此感到失望时,我总是感到困惑。但我也在想,关于非Go的不受欢迎的观点,我想我会选择的是,我认为那些酸味软糖虫和软糖熊之类的东西比巧克力或类似的东西要好得多。我不知道,你在做鬼脸,我在想你可能认为这是一个可怕的观点,但这是我真的想说的。

Angelica Hill: 为什么…?

Cameron Balahan: 我不确定如何回答为什么。它只是看起来更好。

Angelica Hill: 好的。是因为口感吗?

Sameer Ajmani: 它只是完美地结合了甜味和酸味。

Cameron Balahan: 是的,你知道吗?就像…Russ,你同意吗?

Russ Cox: 我完全同意。现在你在这个语境中提到了这些,我觉得我们需要让人做一些小小的软糖地鼠。

Cameron Balahan: 那是个好主意。

Russ Cox: 我们需要想办法让这件事发生。

Angelica Hill: 哦,天哪…呼叫任何在食品或糖果加工公司工作的gopher…在Gopher Slack上给我们发消息。联系Go Time。我们会尝试让它发生。那会很棒。

Cameron Balahan: 我会很喜欢的。

Angelica Hill: Russ,你还有其他不受欢迎的观点吗?

Russ Cox: 当然。每隔几个月我就会在Reddit或其他地方看到一些东西,问"为什么Go还没有摆脱空指针?“所以我不受欢迎的观点是空指针没问题。它们是计算机的一个基本事实,就是内存可以被置零。那些试图隐藏这一点的语言,一般来说 — 总有一些聪明的方法可以得到一个nil,或者更糟,未初始化的内存,因为他们非常确定它永远不会被看到…而空指针错误基本上是最容易处理的错误,因为在它崩溃的地方,它会打印出程序正在做什么的整个堆栈跟踪…你去那一行,或者你看看父帧,你就会说"哦,这就是你怎么在那里得到一个nil的”,然后你基本上就完成了。所以它们是我最喜欢的错误,因为它们就坐在那里,向你准确地显示发生了什么,然后你修复它。

Angelica Hill: 我很好奇看看这是不受欢迎还是受欢迎,鉴于你非常连贯地解释了为什么它们是有帮助的,我们必须保留它们。[笑]

非常感谢你们的不受欢迎的观点。我想以一个快速的 — 如果人们有兴趣,如果他们想要更多地参与Go,如果他们是Go的新手,他们说"好的,我听了这个播客。这个Go东西听起来很有趣",你们对他们的建议是什么?他们如何参与?他们应该做什么?

Russ Cox: 我会说Gopher Slack,邮件列表,问题追踪器…如果你去go.dev并滚动到底部,有一堆联系链接,任何一个都可以。

Angelica Hill: 很好。我会在这一集的描述中链接你们提到的链接,所以无论你在哪里听这个,你都可以进入这一集的描述,你会看到一个很好的链接列表供你点击。

Cameron Balahan: 当然还有聚会,会议,其他的社区活动…外面有很多东西,它们都非常令人兴奋,是一个真正好的社区。所以这些也是人们的选择。

Angelica Hill: 如果你有任何问题,Gopher Slack是我们所有人都在的地方,所以请加入那里。那里很有趣。请随意加入伟大的Go社区。非常感谢你们两位。我真的很感谢你们的时间,感谢你们今天加入我们。祝你们度过美好的一天。

, ====================================== INSTALLING SUBVERSION A Quick Guide ====================================== $LastChangedDate$ Contents: I. INTRODUCTION A. Audience B. Dependency Overview C. Dependencies in Detail D. Documentation II. INSTALLATION A. Building from a Tarball B. Building the Latest Source under Unix C. Building under Unix in Different Directories D. Installing from a Zip or Installer File under Windows E. Building the Latest Source under Windows F. Building using CMake III. BUILDING A SUBVERSION SERVER A. Setting Up Apache Httpd B. Making and Installing the Subversion Apache Server Module C. Configuring Apache Httpd for Subversion D. Running and Testing E. Alternative: 'svnserve' and ra_svn IV. PROGRAMMING LANGUAGE BINDINGS (PYTHON, PERL, RUBY, JAVA) I. INTRODUCTION ============ A. Audience This document is written for people who intend to build Subversion from source code. Normally, the only people who do this are Subversion developers and package maintainers. If neither of these labels fits you, we recommend you find an appropriate binary package of Subversion and install that. While the Subversion project doesn't officially release binary packages, a number of volunteers have made such packages available for different operating systems. Most Linux and BSD distributions already have Subversion packages ready to go via standard packaging channels, and other volunteers have built 'installers' for both Windows and OS X. Visit this page for package links: https://subversion.apache.org/packages.html For those of you who still wish to build from source, Subversion follows the Unix convention of "./configure && make", but it has a number of dependencies. B. Dependency Overview You'll need the following build tools to compile Subversion: * autoconf 2.59 or later (Unix only) * libtool 1.4 or later (Unix only) * a reasonable C compiler (gcc, Visual Studio, etc.) Subversion also depends on the following third-party libraries: * libapr and libapr-util (REQUIRED for client and server) The Apache Portable Runtime (APR) library provides an abstraction of operating-system level services such as file and network I/O, memory management, and so on. It also provides convenience routines for things like hashtables, checksums, and argument processing. While it was originally developed for the Apache HTTP server, APR is a standalone library used by Subversion and other products. It is a critical dependency for all of Subversion; it's the layer that allows Subversion clients and servers to run on different operating systems. * SQLite (REQUIRED for client and server) Subversion uses SQLite to manage some internal databases. * libz (REQUIRED for client and server) Subversion uses zlib for compressing binary differences. These diff streams are used everywhere -- over the network, in the repository, and in the client's working copy. * utf8proc (REQUIRED for client and server) Subversion uses utf8proc for UTF-8 support, including Unicode normalization. * Apache Serf (OPTIONAL for client) The Apache Serf library allows the Subversion client to send HTTP requests. This is necessary if you want your client to access a repository served by the Apache HTTP server. There is an alternate 'svnserve' server as well, though, and clients automatically know how to speak the svnserve protocol. Thus it's not strictly necessary for your client to be able to speak HTTP... though we still recommend that your client be built to speak both HTTP and svnserve protocols. * OpenSSL (OPTIONAL for client and server) OpenSSL enables your client to access SSL-encrypted https:// URLs (using Apache Serf) in addition to unencrypted http:// URLs. To use SSL with Subversion's WebDAV server, Apache needs to be compiled with OpenSSL as well. * Netwide Assembler (OPTIONAL for client and server) The Netwide Assembler (NASM) is used to build the (optional) assembler modules of OpenSSL. As of OpenSSL 1.1.0 NASM is the only supported assembler. * Berkeley DB (DEPRECATED and OPTIONAL for client and server) When you create a repository, you have the option of specifying a storage 'back-end' implementation. Currently, there are two options. The newer and recommended one, known as FSFS, does not require Berkeley DB. FSFS stores data in a flat filesystem. The older implementation, known as BDB, has been deprecated and is not recommended for new repositories, but is still available. BDB stores data in a Berkeley DB database. This back-end will only be available if the BDB libraries are discovered at compile time. * libsasl (OPTIONAL for client and server) If the Cyrus SASL library is detected at compile time, then the svn client (and svnserve server) will be able to utilize SASL to do various forms of authentication when speaking the svnserve protocol. * Python, Perl, Java, Ruby (OPTIONAL) Subversion is mostly a collection of C libraries with well-defined APIs, with a small collection of programs that use the APIs. If you want to build Subversion API bindings for other languages, you need to have those languages available at build time. * py3c (OPTIONAL, but REQUIRED for Python bindings) The Python 3 Compatibility Layer for C Extensions is required to build the Python language bindings. * KDE Framework 5, libsecret, GNOME Keyring (OPTIONAL for client) Subversion contains optional support for storing passwords in KWallet via KDE Framework 5 libraries (preferred) or kdelibs4, and GNOME Keyring via libsecret (preferred) or GNOME APIs. * libmagic (OPTIONAL) If the libmagic library is detected at compile time, it will be used to determine mime-types of binary files which are added to version control. Note that mime-types configured via auto-props or the mime-types-file option take precedence. C. Dependencies in Detail Subversion depends on a number of third party tools and libraries. Some of them are only required to run a Subversion server; others are necessary just for a Subversion client. This section explains what other tools and libraries will be required so that Subversion can be built with the set of features you want. On Unix systems, the './configure' script will tell you if you are missing the correct version of any of the required libraries or tools, so if you are in a real hurry to get building, you can skip straight to section II. If you want to gather the pieces you will need before starting out, however, you should read the following. If you're just installing a Subversion client, the Subversion team has created a script that downloads the minimal prerequisite libraries (Apache Portable Runtime, Sqlite, and Zlib). The script, 'get-deps.sh', is available in the same directory as this file. When run, it will place 'apr', 'apr-util', 'serf', 'zlib', and 'sqlite-amalgamation' directories directly into your unpacked Subversion distribution. With the exception of sqlite-amalgamation, they will still need to be configured, built and installed explicitly, and Subversion's own configure script may need to be told where to find them, if they were not installed in standard system locations. Note: there are optional dependencies (such as OpenSSL, swig, and httpd) which get-deps.sh does not download. Note: Because previous builds of Subversion may have installed older versions of these libraries, you may want to run some of the cleanup commands described in section II.B before installing the following. 1. Apache Portable Runtime 1.4 or newer (REQUIRED) Whenever you want to build any part of Subversion, you need the Apache Portable Runtime (APR) and the APR Utility (APR-util) libraries. If you do not have a pre-installed APR and APR-util, you will need to get these yourself: https://apr.apache.org/download.cgi On Unix systems, if you already have the APR libraries compiled and do not wish to regenerate them from source code, then Subversion needs to be able to find them. There are a couple of options to "./configure" that tell it where to look for the APR and APR-util libraries. By default it will try to locate the libraries using apr-config and apu-config scripts. These scripts provide all the relevant information for the APR and APR-util installations. If you want to specify the location of the APR library, you can use the "--with-apr=" option of "./configure". It should be able to find the apr-config script in the standard location under that directory (e.g. ${prefix}/bin). Similarly, you can specify the location of APR-util using the "--with-apr-util=" option to "./configure". It will look for the apu-config script relative to that directory. For example, if you want to use the APR libraries you built with the Apache httpd server, you could run: $ ./configure --with-apr=/usr/local/apache2 \ --with-apr-util=/usr/local/apache2 ... Notes on Windows platforms: * Do not use APR version 1.7.3 as that release contains a bug that makes it impossible for Subversion to use it properly. This issue only affects APR builds on Windows. This issue was fixed in APR version 1.7.4. See: https://lists.apache.org/thread/xd5t922jvb9423ph4j84rsp5fxks1k0z * If you check out APR and APR-util sources from their Subversion repository, be sure to use a native Windows SVN client (as opposed to Cygwin's version) so that the .dsp files get carriage-returns at the ends of their lines. Otherwise Visual Studio will complain that it doesn't recognize the .dsp files. Notes on Unix platforms: * If you check out APR and APR-util sources from their Subversion repository, you need to run the 'buildconf' script in each library's directory to regenerate the configure scripts and other files required for compiling the libraries. Afterwards, configure, build, and install both libraries before running Subversion's configure script. For example: $ cd apr $ ./buildconf $ ./configure <options...> $ make $ make install $ cd .. $ cd apr-util $ ./buildconf $ ./configure <options...> $ make $ make install $ cd .. 2. SQLite (REQUIRED) Subversion requires SQLite version 3.24.0 or above. You can meet this dependency several ways: * Use an SQLite amalgamation file. * Specify an SQLite installation to use. * Let Subversion find an installed SQLite. To use an SQLite-provided amalgamation, just drop sqlite3.c into Subversion's sqlite-amalgamation/ directory, or point to it with the --with-sqlite configure option. This file also ships with the Subversion dependencies distribution, or you can download it from SQLite: https://www.sqlite.org/download.html 3. Zlib (REQUIRED) Subversion's binary-differencing engine depends on zlib for compression. Most Unix systems have libz pre-installed, but if you need it, you can get it from http://www.zlib.net/ 4. utf8proc (REQUIRED) Subversion uses utf8proc for UTF-8 support. Configure will attempt to locate utf8proc by default using pkg-config and known paths. If it is installed in a non-standard location, then use: --with-utf8proc=/path/to/libutf8proc Alternatively, a copy of utf8proc comes bundled with the Subversion sources. If configure should use the bundled copy, use: --with-utf8proc=internal 5. autoconf 2.59 or newer (Unix only) This is required only if you plan to build from the latest source (see section II.B). Generally only developers would be doing this. 6. libtool 1.4 or newer (Unix only) This is required only if you plan to build from the latest source (see section II.B). Note: Some systems (Solaris, for example) require libtool 1.4.3 or newer. The autogen.sh script knows about that. 7. Apache Serf library 1.3.4 or newer (OPTIONAL) If you want your client to be able to speak to an Apache server (via a http:// or https:// URL), you must link against Apache Serf. Though optional, we strongly recommend this. In order to use ra_serf, you must install serf, and run Subversion's ./configure with the argument --with-serf. If serf is installed in a non-standard place, you should use --with-serf=/path/to/serf/install instead. Apache Serf can be obtained via your system's package distribution system or directly from https://serf.apache.org/. For more information on Apache Serf and Subversion's ra_serf, see the file subversion/libsvn_ra_serf/README. 8. OpenSSL (OPTIONAL) ### needs some updates. I think Apache Serf automagically handles ### finding OpenSSL, but we may need more docco here. and w.r.t ### zlib. The Apache Serf library has support for SSL encryption by relying on the OpenSSL library. a. Using OpenSSL on the client through Apache Serf On Unix systems, to build Apache Serf with OpenSSL, you need OpenSSL installed on your system, and you must add "--with-ssl" as a "./configure" parameter. If your OpenSSL installation is hard for Apache Serf to find, you may need to use "--with-libs=/path/to/lib" in addition. In particular, on Red Hat (but not Fedora Core) it is necessary to specify "--with-libs=/usr/kerberos" for OpenSSL to be found. You can also specify a path to the zlib library using "--with-libs". Under Windows, you can specify the paths to these libraries by passing the options --with-zlib and --with-openssl to gen-make.py. b. Using OpenSSL on the Apache server You can also add support for these features to an Apache httpd server to be used for Subversion using the same support libraries. The Subversion build system will not provide them, however. You add them by specifying parameters to the "./configure" script of the Apache Server instead. For getting SSL on your server, you would add the "--enable-ssl" or "--with-ssl=/path/to/lib" option to Apache's "./configure" script. Apache enables zlib support by default, but you can specify a nonstandard location for the library with the "--with-z=/path/to/dir" option. Consult the Apache documentation for more details, and for other modules you may wish to install to enhance your Subversion server. If you don't already have it, you can get a copy of OpenSSL, including instructions for building and packaging on both Unix systems and Windows, at: https://www.openssl.org/ 9. Berkeley DB 4.X (DEPRECATED and OPTIONAL) You need the Berkeley DB libraries only if you are building a Subversion server that supports the older BDB repository storage back-end, or a Subversion client that can access local BDB repositories via the file:// URI scheme. The BDB back-end has been deprecated and is not recommended for new repositories. BDB may be removed in Subversion 2.0. We recommend the newer FSFS back-end for all new repositories. FSFS does not require the Berkeley DB libraries. If in doubt, the 'svnadmin info' command, added in Subversion 1.9, can identify whether an existing repository uses BDB or FSFS. The current recommended version of Berkeley DB is 4.4.20 or newer, which brings auto-recovery functionality to the Berkeley DB database environment. If you must use an older version of Berkeley DB, we *strongly* recommend using 4.3 or 4.2 over the 4.1 or 4.0 versions. Not only are these significantly faster and more stable, but they also enable Subversion repositories to automatically clean up database journal files to save disk space. You'll need Berkeley DB installed on your system. You can get it from: http://www.oracle.com/technetwork/database/database-technologies/berkeleydb/overview/index.html If you have Berkeley DB installed in a place not searched by default for includes and libraries, add something like this: --with-berkeley-db=db.h:/usr/local/include/db4.7:/usr/local/lib/db4.7:db-4.7 to your `configure' switches, and the build process will use the Berkeley DB header and library in the named directories. You may need to use a different path, of course. Note that in order for the detection to succeed, the dynamic linker must be able to find the libraries at configure time. 10. Cyrus SASL library (OPTIONAL) If the Simple Authentication and Security Layer (SASL) library is detected on your system, then the Subversion client and svnserve server can utilize its abilities for various forms of authentication. To learn more about SASL or to get the source code, visit: http://freshmeat.net/projects/cyrussasl/ 11. Apache Web Server 2.2.X or newer (OPTIONAL) (https://httpd.apache.org/download.cgi) The Apache httpd server is one of two methods to make your Subversion repository available over a network - the other is a custom server program called svnserve, which requires no extra software packages. Building Subversion, the Apache server, and the modules that Apache needs to communicate with Subversion are complicated enough that there is a whole section at the end of this document that describes how it is done: See section III for details. 12. Python 3.x or newer (https://www.python.org/) (OPTIONAL) Subversion does not require Python for its basic operation. However, Python is required for building and testing Subversion and for using Subversion's SWIG Python bindings or hook scripts coded in Python. The majority of Subversion's test suite is written in Python, as is part of Subversion's build system. In more detail, Python is required to do any of the following: * Use the SWIG Python bindings. * Use the ctypes Python bindings. * Use hook scripts coded in Python. * Build Subversion from a tarball on Unix-like systems and run Subversion's test suite as described in section II.B. * Build Subversion on Windows as described in section II.E. * Build Subversion from a working copy checked out from Subversion's own repository (whether or not running the test suite). * Build the SWIG Python bindings. * Build the ctypes Python bindings. * Testing as described in section III.D. The Python bindings are used by: * Third-party programs (e.g., ViewVC) * Scripts distributed with Subversion itself in the tools/ subdirectory. * Any in-house scripts you may have. Python is NOT required to do any of the following: * Use the core command-line binaries (svn, svnadmin, svnsync, etc.) * Use Subversion's C libraries. * Use any of Subversion's other language bindings. * Build Subversion from a tarball on Unix-like systems without running Subversion's test suite Although this section calls for Python 3.x, Subversion still technically works with Python 2.7. However, Support for Python 2.7 is being phased out. As of 1 January 2020, Python 2.7 has reached end of life. All users are strongly encouraged to move to Python 3. Note: If you are using a Subversion distribution tarball and want to build the Python bindings for Python 2, you should rebuild the build environment in non-release mode by running 'sh autogen.sh' before running the ./configure script; see section II.B for more about autogen.sh. 13. Perl 5.8 or newer (Windows only) (OPTIONAL) To build Subversion under any of the MS Windows platforms, you will also need Perl 5.8 or newer to run apr-util's w32locatedb.pl script. 14. pkg-config (Unix only, OPTIONAL) Subversion uses pkg-config to find appropriate options used at build time. 15. D-Bus (Unix only, OPTIONAL) D-Bus is a message bus system. D-Bus is required for support for KWallet and GNOME Keyring. pkg-config is needed to find D-Bus headers and library. 16. Qt 5 or Qt 4 (Unix only, OPTIONAL) Qt is a cross-platform application framework. QtCore, QtDBus and QtGui modules are required for support for KWallet. pkg-config is needed to find Qt headers and libraries. 17. KDE 5 Framework libraries or KDELibs 4 (Unix only, OPTIONAL) Subversion contains optional support for storing passwords in KWallet. Subversion will look for KF5Wallet, KF5CoreAddons, KF5I18n APIs by default, and needs kf5-config to find them. The KDELibs 4 api is also supported. KDELibs contains core KDE libraries. Subversion uses libkdecore and libkdeui libraries when support for KWallet is enabled. kde4-config is used to get some necessary options. pkg-config, D-Bus and Qt 4 are also required. If you want to build support for KWallet, then pass the '--with-kwallet' option to `configure`. If KDE is installed in a non-standard prefix, then use: --with-kwallet=/path/to/KDE/prefix 18. GLib 2 (Unix only, OPTIONAL) GLib is a general-purpose utility library. GLib is required for support for GNOME Keyring. pkg-config is needed to find GLib headers and library. 19. GNOME Keyring (Unix only, OPTIONAL) Subversion contains optional support for storing passwords in GNOME Keyring. pkg-config is needed to find GNOME Keyring headers and library. D-Bus and GLib are also required. If you want to build support for GNOME Keyring, then pass the '--with-gnome-keyring' option to `configure`. 20. Ctypesgen (OPTIONAL) Ctypesgen is Python wrapper generator for ctypes. It is used to generate a part of Subversion Ctypes Python bindings (CSVN). If you want to build CSVN, then pass the '--with-ctypesgen' option to `configure`. If ctypesgen.py is installed in a non-standard place, then use: --with-ctypesgen=/path/to/ctypesgen.py For more information on CSVN, see subversion/bindings/ctypes-python/README. 21. libmagic (OPTIONAL) Subversion's configure script attempts to find libmagic automatically. If it is installed in a non-standard location, then use: --with-libmagic=/path/to/libmagic/prefix The files include/magic.h and lib/libmagic.so.1.0 (or similar) are expected beneath this prefix directory. If they cannot be found Subversion will be compiled without support for libmagic. If libmagic is installed but support for it should not be compiled in, then use: --with-libmagic=no If configure should fail when libmagic is not present, but only the default locations should be searched, then use: --with-libmagic 22. LZ4 (OPTIONAL) Subversion uses LZ4 compression library version r129 or above. Configure will attempt to locate the system library by default using pkg-config and known paths. If it is installed in a non-standard location, then use: --with-lz4=/path/to/liblz4 If configure should use the version bundled with the sources, use: --with-lz4=internal 23. py3c (OPTIONAL) Subversion uses the Python 3 Compatibility Layer for C Extensions (py3c) library when building the Python language bindings. As py3c is a header-only library, it is needed only to build the bindings, not to use them. Configure will attempt to locate py3c by default using pkg-config and known paths. If it is installed in a non-standard location, then use: --with-py3c=/path/to/py3c/prefix The library can be downloaded from GitHub: https://github.com/encukou/py3c On Unix systems, you can also use the provided get-deps.sh script to download py3c and several other dependencies; see the top of section I.C for more about get-deps.sh. D. Documentation The primary documentation for Subversion is the free book "Version Control with Subversion", a.k.a. "The Subversion Book", obtainable from https://svnbook.red-bean.com/. Various additional documentation exists in the doc/ subdirectory of the Subversion source. See the file doc/README for more information. II. INSTALLATION ============ Subversion support three different build systems: - Autoconf/make, for Unix builds - Visual Studio vcproj, for Windows builds - CMake, for both Unix and Windows The first two have been in use since 2001. Sections A-E below describe the classic build system. The CMake build system was created in 2024 and is still under development. It will be included in Subversion 1.15 and is expected to be the default build system starting with Subversion 1.16. Section F below describes the CMake build system. A. Building from a Tarball ------------------------------ 1. Building from a Tarball Download the most recent distribution tarball from: https://subversion.apache.org/download/ Unpack it, and use the standard GNU procedure to compile: $ ./configure $ make # make install You can also run the full test suite by running 'make check'. Even in successful runs, some tests will report XFAIL; that is normal. Failed runs are indicated by FAIL or XPASS results, or a non-zero exit code from "make check". B. Building the Latest Source under Unix ------------------------------------- These instructions assume you have already installed Subversion and checked out a working copy of Subversion's own code -- either the latest /trunk code, or some branch or tag. You also need to have already installed whatever prerequisites that version of Subversion requires (if you haven't, the ./configure step should complain). You can discard the directory created by the tarball; you're about to build the latest, greatest Subversion client. This is the procedure Subversion developers use. First off, if you have any Subversion libraries lying around from previous 'make installs', clean them up first! # rm -f /usr/local/lib/libsvn* # rm -f /usr/local/lib/libapr* # rm -f /usr/local/lib/libserf* Start the process by running "autogen.sh": $ sh ./autogen.sh This script will make sure you have all the necessary components available to build Subversion. If any are missing, you will be told where to get them from. (See the 'Dependency Overview' in section I.) Note: if the command "autoconf" on your machine does not run autoconf 2.59 or later, but you do have a new enough autoconf available, then you can specify the correct one with the AUTOCONF variable. (The AUTOHEADER variable is similar.) This may be required on Debian GNU/Linux, where "autoconf" is actually a Perl script that attempts to guess which version is required -- because of the interaction between Subversion's and APR's configuration systems, the Perl script may get it wrong. So for example, you might need to do: $ AUTOCONF=autoconf2.59 sh ./autogen.sh Once you've prepared the working copy by running autogen.sh, just follow the usual configuration and build procedure: $ ./configure $ make # make install (Optionally, you might want to pass --enable-maintainer-mode to the ./configure script. This enables debugging symbols in your binaries (among other things) and most Subversion developers use it.) Since the resulting binary depends on shared libraries, the destination library directory must be identified in your operating system's library search path. That is in either /etc/ld.so.conf or $LD_LIBRARY_PATH for Linux systems and in /etc/rc.conf for FreeBSD, followed by a run of the 'ldconfig' program. Check your system documentation for details. By identifying the destination directory, Subversion will be able to dynamically load repository access plugins. If you try to do a checkout and see an error like: subversion/libsvn_ra/ra_loader.c:209: (apr_err=170000) svn: Unrecognized URL scheme 'https://svn.apache.org/repos/asf/subversion/trunk' It probably means that the dynamic loader/linker can't find all of the libsvn_* libraries. C. Building under Unix in Different Directories -------------------------------------------- It is possible to configure and build Subversion on Unix in a directory other than the working copy. For example $ svn co https://svn.apache.org/repos/asf/subversion/trunk svn $ cd svn $ # get SQLite amalgamation if required $ chmod +x autogen.sh $ ./autogen.sh $ mkdir ../obj $ cd ../obj $ ../svn/configure [...with options as appropriate...] $ make puts the Subversion working copy in the directory svn and builds it in a separate, parallel directory obj. Why would you want to do this? Well there are a number of reasons... * You may prefer to avoid "polluting" the working copy with files generated during the build. * You may want to put the build directory and the working copy on different physical disks to improve performance. * You may want to separate source and object code and only backup the source. * You may want to remote mount the working copy on multiple machines, and build for different machines from the same working copy. * You may want to build multiple configurations from the same working copy. The last reason above is possibly the most useful. For instance you can have separate debug and optimized builds each using the same working copy. Or you may want a client-only build and a client-server build. Using multiple build directories you can rebuild any or all configurations after an edit without the need to either clean and reconfigure, or identify and copy changes into another working copy. D. Installing from a Zip or Installer File under Windows ----------------------------------------------------- Of all the ways of getting a Subversion client, this is the easiest. Download a Zip or self-extracting installer via: https://subversion.apache.org/packages.html#windows For a Zip file extract the DLLs and EXEs to a directory of your choice. Included in the download are among other tools the SVN client, the SVNADMIN administration tool and the SVNLOOK reporting tool. You may want to add the bin directory in the Subversion folder to your PATH environment variable so as to not have to use the full path when running Subversion commands. To test the installation, open a DOS box (run either "cmd" or "command" from the Start menu's "Run..." menu option), change to the directory you installed the executables into, and run: C:\test>svn co https://svn.apache.org/repos/asf/subversion/trunk svn This will get the latest Subversion sources and put them into the "svn" subdirectory. If using a self-extracting .exe file, just run it instead of unzipping it, to install Subversion. E. Building the Latest Source under Windows ---------------------------------------- E.1 Prerequisites * Microsoft Visual Studio. Any recent (2005+) version containing the Visual C++ component will work (E.g. Professional, Express, Community Edition). Make sure you enable C++ support during setup. * Python 2.7 or higher, downloaded from https://www.python.org/ which is used to generate the project files. * Perl 5.8 or higher from https://www.perl.org/get.html * Awk is needed to compile Apache. Source code is available in tools\dev\awk, run the buildwin.bat program to compile. * Apache apr, apr-util, and optionally apr-iconv libraries, version 1.4 or later (1.2 for apr-iconv). If you are building from a Subversion checkout and have not downloaded Apache 2, then get these 3 libraries from https://www.apache.org/dist/apr/. * SQLite 3.24.0 or higher from https://www.sqlite.org/download.html (3.39.4 or higher recommended) * ZLib 1.2 or higher is required and can be obtained from http://www.zlib.net/ * Either a Subversion client binary from https://subversion.apache.org/packages.html to do the initial checkout of the Subversion source or the zip file source distribution. Additional Options * [Optional] Apache Httpd 2 source, downloaded from https://httpd.apache.org/download.cgi, these instructions assume version 2.0.58. This is only needed for building the Subversion server Apache modules. ### FIXME Apache 2.2 or greater required. * [Optional] Berkeley DB for backend support of the server components are available from http://www.oracle.com/technetwork/database/database-technologies/berkeleydb/downloads/index-082944.html (Version 4.4.20 or in specific cases some higher version recommended) For more information see Section I.C.9. * [Optional] Openssl can be obtained from https://www.openssl.org/source/ * [Optional] NASM can be obtained from http://www.nasm.us/ * [Optional] A modified version of GNU libintl, called svn-win32-libintl.zip, can be used for displaying localized messages. Available at: http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=2627 * [Optional] GNU gettext for generating message catalog (.mo) files from message translations. You can get the latest binaries from http://gnuwin32.sourceforge.net/. You'll need the binaries (gettext-0.14.1-bin.zip) and dependencies (gettext-0.14.1-dep.zip). E.2 Notes The Apache Serf library supports secure connections with OpenSSL and on-the-wire compression with zlib. If you want to use the secure connections feature, you should pass the option "--with-openssl" to the gen-make.py script. See Section I.C.7 for more details. E.3 Preparation This section describes how to unpack the files to make a build tree. * Make a directory SVN and cd into it. * Either checkout Subversion: svn co https://svn.apache.org/repos/asf/subversion/trunk src-trunk or unpack the zip file distribution and rename the directory to src-trunk. * Install Visual Studio Environment. You either have to tell the installer to register environment variables or run VCVARS32.BAT before building anything. If you are using a newer Visual Studio, use the 'Visual Studio 20xx Command Prompt' on the Start menu. * Install Python and add it to your path * Install Perl (it should add itself to the path) ### Subversion doesn't need perl. Only some dependencies need it (OpenSSL and some apr scripts) * Copy AWK (awk95.exe) to awk.exe (e.g. SVN\awk\awk.exe) and add the directory containing it (e.g. SVN\awk) to the path. ### Subversion doesn't need awk. Only some dependencies need it (some apr scripts) * [Optional] Install NASM and add it to your path ### Subversion doesn't need NASM. Only some dependencies need it optionally (OpenSSL) * [Optional] If you checked out Subversion from the repository and want to build Subversion with http/https access support then install the Apache Serf sources into SVN\src-trunk\serf. * [Optional] If you want BDB backend support, extract the Berkeley DB files into SVN\src-trunk\db4-win32. It's a good idea to add SVN\src-trunk\db4-win32\bin to your PATH, so that Subversion can find the Berkeley DB DLLs. [NOTE: This binary package of Berkeley DB is provided for convenience only. Please don't address questions about Berkeley DB that aren't directly related to using Subversion to the project mailing list.] If you build Berkeley DB from the source, you will have to copy the file db-x.x.x\build_win32\db.h to SVN\src-trunk\db4-win32\include, and all the import libraries to SVN\src-trunk\db4-win32\lib. Again, the DLLs should be somewhere in your path. ### Just use --with-serf instead of the hardcoded path * [Optional] If you want to build the server modules, extract Apache source into SVN\httpd-2.x.x. * If you are building from a checkout of Subversion, and you are NOT building Apache, then you will need the APR libraries. Depending on how you got your version of APR, either: - Extract the APR, APR-util and APR-iconv source distributions into SVN\apr, SVN\apr-util, and SVN\apr-iconv respectively. Or: - Extract the apr, apr-util and apr-iconv directories from the srclib folder in the Apache httpd source into SVN\apr, SVN\apr-util, and SVN\apr-iconv respectively. ### Just use --with-apr, etc. instead of the hardcoded paths * Extract the ZLib sources into SVN\zlib if you are not using the zlib included in the dependencies zip file. ### Just use --with-zlib instead of the hardcoded path * [Optional] If you want secure connection (https) client support extract OpenSSL into SVN\openssl ### And pass the path to both serf and gen-make.py * [Optional] If you want localized message support, extract svn-win32-libintl.zip into SVN\svn-win32-libintl and extract gettext-x.x.x-bin.zip and gettext-x.x.x-dep.zip into SVN\gettext-x.x.x-bin. Add SVN\gettext-x.x.x-bin\bin to your path. * Download the SQLite amalgamation from https://www.sqlite.org/download.html and extract it into SVN\sqlite-amalgamation. See I.C.12 for alternatives to using the amalgamation package. E.4 Building the Binaries To build the binaries either follow these instructions. Start in the SVN directory you created. Set up the environment (commands should be one line even if wrapped here). C:>set VER=trunk C:>set DIR=trunk C:>set BUILD_ROOT=C:\SVN C:>set PYTHONDIR=C:\Python27 C:>set AWKDIR=C:\SVN\Awk C:>set ASMDIR=C:\SVN\asm C:>set SDKINC="C:\Program Files\Microsoft SDK\include" C:>set SDKLIB="C:\Program Files\Microsoft SDK\lib" C:>set GETTEXTBIN=C:\SVN\gettext-0.14.1-bin\bin C:>PATH=%PATH%;%BUILD_ROOT%\src-%DIR%\db4-win32;%ASMDIR%; %PYTHONDIR%;%AWKDIR%;%GETTEXTBIN% C:>set INCLUDE=%SDKINC%;%INCLUDE% C:>set LIB=%SDKLIB%;%LIB% OpenSSL < 1.1.0 C:>cd openssl C:>perl Configure VC-WIN32 [*] C:>call ms\do_masm C:>nmake -f ms\ntdll.mak C:>cd out32dll C:>call ..\ms\test C:>cd ..\.. *Note: Use "call ms\do_nasm" if you have nasm instead of MASM, or "call ms\do_ms" if you don't have an assembler. Also if you are using OpenSSL >= 1.0.0 masm is no longer supported. You will have to use do_nasm or do_ms in this case. OpenSSL >= 1.1.0 C:>cd openssl C:>perl Configure VC-WIN32 C:>nmake C:>nmake test C:>cd .. Apache 2 This step is only required for building the server dso modules. ### FIXME Apache 2.2 or greater required. Old build instructions for VC6. C:>set APACHEDIR=C:\Program Files\Apache Group\Apache2 C:>msdev httpd-2.0.58\apache.dsw /MAKE "BuildBin - Win32 Release" APR If you downloaded APR / APR-UTIL / APR_ICONV by source, you will have to build these libraries first. Building these libraries on Windows is straight forward and in most cases as simple as issuing these two commands: C:>nmake -f Makefile.win C:>nmake -f Makefile.win install Please refer to the build instructions provided by the library source for actual build instructions. ZLib If you downloaded the zlib source, you will have to build ZLib first. Building ZLib using Visual Studio should be quite simple. Just open the appropriate solution and build the project zlibstat using the IDE. Please refer to the build instructions provided by the library source for actual build instructions. Note that you'd make sure to define ZLIB_WINAPI in the ZLib config header and move the lib-file into the zlib root-directory. Please note that you MUST NOT build ZLib with the included assembler optimized code. It is known to be buggy, see for example the discussion https://svn.haxx.se/dev/archive-2013-10/0109.shtml. This means that you must not define ASMV or ASMINF. Note that the VS projects in contrib\visualstudio define these in the Debug configuration. Apache Serf ### Section about Apache Serf might be required/useful to add. ### scons is required too and Apache Serf needs to be configured prior to ### be able to build Subversion using: ### scons APR=[PATH_TO_APR] APU=[PATH_TO_APU] OPENSSL=[PATH_TO_OPENSSL] ### ZLIB=[PATH_TO_ZLIB] PREFIX=[PATH_TO_SERF_DEST] ### scons check ### scons install Subversion Things to note: * If you don't want to build mod_dav_svn, omit the --with-httpd option. The zip file source distribution contains apr, apr-util and apr-iconv in the default build location. If you have downloaded the apr files yourself you will have to tell the generator where to find the APR libraries; the options are --with-apr, --with-apr-util and --with-apr-iconv. * If you would like a debug build substitute Debug for Release in the msbuild command. * There have been rumors that Subversion on Win32 can be built using the latest cygwin, you probably don't want the zip file source distribution though. ymmv. * You will also have to distribute the C runtime dll with the binaries. Also, since Apache/APR do not provide .vcproj files, you will need to convert the Apache/APR .dsp files to .vcproj files with Visual Studio before building -- just open the Apache .dsw file and answer 'Yes To All' when the conversion dialog pops up, or you can open the individual .dsp files and convert them one at a time. The Apache/APR projects required by Subversion are: apr-util\libaprutil.dsp, apr\libapr.dsp, apr-iconv\libapriconv.dsp, apr-util\xml\expat\lib\xml.dsp, apr-iconv\ccs\libapriconv_ccs_modules.dsp, and apr-iconv\ces\libapriconv_ces_modules.dsp. * If the server dso modules are being built and tested Apache must not be running or the copy of the dso modules will fail. C:>cd src-%DIR% If Apache 2 has been built and the server modules are required then gen-make.py will already have been run. If the source is from the zip file, Apache 2 has not been built so gen-make.py must be run: C:>python gen-make.py --vsnet-version=20xx --with-berkeley-db=db4-win32 --with-openssl=..\openssl --with-zlib=..\zlib --with-libintl=..\svn-win32-libintl Then build subversion: C:>msbuild subversion_vcnet.sln /t:__MORE__ /p:Configuration=Release C:>cd .. The binaries have now been built. E.5 Packaging the binaries You now need to copy the binaries ready to make the release zip file. You also need to do this to run the tests as the new binaries need to be in your path. You can use the build/win32/make_dist.py script in the Subversion source directory to do that. [TBD: Describe how to do this. Note dependencies on zip, jar, doxygen.] E.6 Testing the Binaries [TBD: It's been a long, long while since it was necessary to move binaries around for testing. win-tests.py does that automagically. Fix this section accordingly, and probably reorder, putting the packaging at the end.] The build process creates the binary test programs but it does not copy the client tests into the release test area. C:>cd src-%DIR% C:>mkdir Release\subversion\tests\cmdline C:>xcopy /S /Y subversion\tests\cmdline Release\subversion\tests\cmdline If the server dso modules have been built then copy the dso files and dlls into the Apache modules directory. C:>copy Release\subversion\mod_dav_svn\mod_dav_svn.so "%APACHEDIR%"\modules C:>copy Release\subversion\mod_authz_svn\mod_authz_svn.so "%APACHEDIR%"\modules C:>copy svn-win32-%VER%\bin\intl.dll "%APACHEDIR%\bin" C:>copy svn-win32-%VER%\bin\iconv.dll "%APACHEDIR%\bin" C:>copy svn-win32-%VER%\bin\libdb42.dll "%APACHEDIR%\bin" C:>cd .. Put the svn-win32-trunk\bin directory at the start of your path so you run the newly built binaries and not another version you might have installed. Then run the client tests: C:>PATH=%BUILD_ROOT%\svn-win32-%VER%\bin;%PATH% C:>cd src-%DIR% C:>python win-tests.py -c -r -v If the server dso modules were built configure Apache to use the mod_dav_svn and mod_authz_svn modules by making sure these lines appear uncommented in httpd.conf: LoadModule dav_module modules/mod_dav.so LoadModule dav_fs_module modules/mod_dav_fs.so LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule authz_svn_module modules/mod_authz_svn.so And further down the file add location directives to point to the test repositories. Change the paths to the SVN directory you created (paths should be on one line even if wrapped here): <Location /svn-test-work/repositories> DAV svn SVNParentPath C:/SVN/src-trunk/Release/subversion/tests/cmdline/ svn-test-work/repositories </Location> <Location /svn-test-work/local_tmp/repos> DAV svn SVNPath c:/SVN/src-trunk/Release/subversion/tests/cmdline/ svn-test-work/local_tmp/repos </Location> Then restart Apache and run the tests: C:>python win-tests.py -c -r -v -u http://localhost C:>cd .. F. Building using CMake -------------------- Get the sources, either a release tarball or by checking out the official repository. The CMake build system currently only exists in /trunk and it will be included in the 1.15 release. The process for building on Unix and Windows is the same. $ python gen-make.py -t cmake $ cmake -B out [build options] $ cmake --build out "out" in the commands above is the build directory used by CMake. Build options can be added, for example: $ cmake -B out -DCMAKE_INSTALL_PREFIX=/usr/local/subversion -DSVN_ENABLE_RA_SERF=ON Build options can be listed using: $ cmake -LH Windows tricks: - Modern versions of Microsoft Visual Studio provide support for CMake projects out-of-box, including intellisense, integrated options editor, test explorer, and more. In order to use it for Subversion, open the source directory with Visual Studio, and the configuration should start automatically. For editing the cache (options), do right-click to the CMakeLists.txt file and clicking `CMake Settings for Subversion` will open the editor. After the required settings are configured, hit `F7` in order to build. For more info, check the article bellow: https://learn.microsoft.com/en-us/cpp/build/cmake-projects-in-visual-studio - There is a useful tool for bootstrapping the dependencies, vcpkg. It provides ports for the most of the Subversion's dependencies, which then could be installed via a single command. To start using it, download the registry from GitHub, bootstrap vcpkg, and install the dependencies: $ git clone https://github.com/microsoft/vcpkg $ cd vcpkg && .\bootstrap-vcpkg.bat -disableMetrics $ .\vcpkg install apr apr-util expat zlib sqlite3 [any other dependency] After this is done, vcpkg can be integrated into CMake by passing the vcpkg toolchain to CMAKE_TOOLCHAIN_FILE option. In order to do it with Visual Studio, open the CMake cache editor as explained in the previous step, and put the following into `CMake toolchain file` field, where VCPKG_ROOT is the path to vcpkg registry: <VCPKG_ROOT>/scripts/buildsystems/vcpkg.cmake III. BUILDING A SUBVERSION SERVER ============================ Subversion has two servers you can choose from: svnserve and Apache. svnserve is a small, lightweight server program that is automatically compiled when you build Subversion's source. Apache is a more heavyweight HTTP server, but tends to have more features. This section primarily focuses on how to build Apache and the accompanying mod_dav_svn server module for it. If you plan to use svnserve instead, jump right to section E for a quick explanation. A. Setting Up Apache Httpd ----------------------- 1. Obtaining and Installing Apache Httpd 2 Subversion tries to compile against the latest released version of Apache httpd 2.2+. The easiest thing for you to do is download a source tarball of the latest release and unpack that. If you have questions about the Apache httpd 2.2 build, please consult the httpd install documentation: https://httpd.apache.org/docs-2.2/install.html At the top of the httpd tree: $ ./buildconf $ ./configure --enable-dav --enable-so --enable-maintainer-mode The first arg says to build mod_dav. The second arg says to enable shared module support which is needed for a typical compile of mod_dav_svn (see below). The third arg says to include debugging information. If you built Subversion with --enable-maintainer-mode, then you should do the same for Apache; there can be problems if one was compiled with debugging and the other without. Note: if you have multiple db versions installed on your system, Apache might link to a different one than Subversion, causing failures when accessing the repository through Apache. To prevent this from happening, you have to tell Apache which db version to use and where to find db. Add --with-dbm=db4 and --with-berkeley-db=/usr/local/BerkeleyDB.4.2 to the configure line. Make sure this is the same db as the one Subversion uses. This note assumes you have installed Berkeley DB 4.2.52 at its default locations. For more info about the db requirement, see section I.C.9. You may also want to include other modules in your build. Add --enable-ssl to turn on SSL support, and --enable-deflate to turn on compression support, for example. Consult the Apache documentation for more details. All instructions below assume you configured Apache to install in its default location, /usr/local/apache2/; substitute appropriately if you chose some other location. Compile and install apache: $ make && make install B. Making and Installing the Subversion Apache Server Module --------------------------------------------------------- Go back into your subversion working copy and run ./autogen.sh if you need to. Then, assuming Apache httpd 2.2 is installed in the standard location, run: $ ./configure Note: do *not* configure subversion with "--disable-shared"! mod_dav_svn *must* be built as a shared library, and it will look for other libsvn_*.so libraries on your system. If you see a warning message that the build of mod_dav_svn is being skipped, this may be because you have Apache httpd 2.x installed in a non-standard location. You can use the "--with-apxs=" option to locate the apxs script: $ ./configure --with-apxs=/usr/local/apache2/bin/apxs Note: it *is* possible to build mod_dav_svn as a static library and link it directly into Apache. Possible, but painful. Stick with the shared library for now; if you can't, then ask. $ rm /usr/local/lib/libsvn* If you have old subversion libraries sitting on your system, libtool will link them instead of the `fresh' ones in your tree. Remove them before building subversion. $ make clean && make && make install After the make install, the Subversion shared libraries are in /usr/local/lib/. mod_dav_svn.so should be installed in /usr/local/libexec/ (or elsewhere, such as /usr/local/apache2/modules/, if you passed --with-apache-libexecdir to configure). Section II.E explains how to build the server on Windows. C. Configuring Apache Httpd for Subversion --------------------------------------- The following section is an abbreviated version of the information in the Subversion Book (https://svnbook.red-bean.com). Please read chapter 6 for more details. The following assumes you have already created a repository. For documentation on how to do that, see README. The following also assumes that you have modified /usr/local/apache2/conf/httpd.conf to reflect your setup. At a minimum you should look at the User, Group and ServerName directives. Full details on setting up apache can be found at: https://httpd.apache.org/docs-2.2/ First, your httpd.conf needs to load the mod_dav_svn module. If you pass --enable-mod-activation to Subversion's configure, 'make install' target should automatically add this line for you. In any case, if Apache HTTPD gives you an error like "Unknown DAV provider: svn", then you may want to verify that this line exists in your httpd.conf: LoadModule dav_svn_module modules/mod_dav_svn.so NOTE: if you built mod_dav as a dynamic module as well, make sure the above line appears after the one that loads mod_dav.so. Next, add this to the *bottom* of your httpd.conf: <Location /svn/repos> DAV svn SVNPath /absolute/path/to/repository </Location> This will give anyone unrestricted access to the repository. If you want limited access, read or write, you add these lines to the Location block: AuthType Basic AuthName "Subversion repository" AuthUserFile /my/svn/user/passwd/file And: a) For a read/write restricted repository: Require valid-user b) For a write restricted repository: <LimitExcept GET PROPFIND OPTIONS REPORT> Require valid-user </LimitExcept> c) For separate restricted read and write access: AuthGroupFile /my/svn/group/file <LimitExcept GET PROPFIND OPTIONS REPORT> Require group svn_committers </LimitExcept> <Limit GET PROPFIND OPTIONS REPORT> Require group svn_committers Require group svn_readers </Limit> ### FIXME Tutorials section refers to old 2.0 docs These are only a few simple examples. For a complete tutorial on Apache access control, please consider taking a look at the tutorials found under "Security" on the following page: https://httpd.apache.org/docs-2.0/misc/tutorials.html In order for 'svn cp' to work (which is actually implemented as a DAV COPY command), mod_dav needs to be able to determine the hostname of the server. A standard way of doing this is to use Apache's ServerName directive to set the server's hostname. Edit your /usr/local/apache2/conf/httpd.conf to include: ServerName svn.myserver.org If you are using virtual hosting through Apache's NameVirtualHost directive, you may need to use the ServerAlias directive to specify additional names that your server is known by. If you have configured mod_deflate to be in the server, you can enable compression support for your repository by adding the following line to your Location block: SetOutputFilter DEFLATE NOTE: If you are unfamiliar with an Apache directive, or not exactly sure about what it does, don't hesitate to look it up in the documentation: https://httpd.apache.org/docs-2.2/mod/directives.html. NOTE: Make sure that the user 'nobody' (or whatever UID the httpd process runs as) has permission to read and write the Berkeley DB files! This is a very common problem. D. Running and Testing ------------------- Fire up apache 2: $ /usr/local/apache2/bin/apachectl stop $ /usr/local/apache2/bin/apachectl start Check /usr/local/apache2/logs/error_log to make sure it started up okay. Try doing a network checkout from the repository: $ svn co http://localhost/svn/repos wc The most common reason this might fail is permission problems reading the repository db files. If the checkout fails, make sure that the httpd process has permission to read and write to the repository. You can see all of mod_dav_svn's complaints in the Apache error logfile, /usr/local/apache2/logs/error_log. To run the regression test suite for networked Subversion, see the instructions in subversion/tests/cmdline/README. For advice about tracing problems, see "Debugging the server" in https://subversion.apache.org/docs/community-guide/. E. Alternative: 'svnserve' and ra_svn ----------------------------------- An alternative network layer is libsvn_ra_svn (on the client side) and the 'svnserve' process on the server. This is a simple network layer that speaks a custom protocol over plain TCP (documented in libsvn_ra_svn/protocol): $ svnserve -d # becomes a background daemon $ svn checkout svn://localhost/usr/local/svn/repository You can use the "-r" option to svnserve to set a logical root for repositories, and the "-R" option to restrict connections to read-only access. ("Read-only" is a logical term here; svnserve still needs write access to the database in this mode, but will not allow commits or revprop changes.) 'svnserve' has built-in CRAM-MD5 authentication (so you can use non-system accounts), and can also be tunneled over SSH (so you can use existing system accounts). It's also capable of using Cyrus SASL if libsasl2 is detected at ./configure time. Please read chapter 6 in the Subversion Book (https://svnbook.red-bean.com) for details on these features. IV. PROGRAMMING LANGUAGE BINDINGS (PYTHON, PERL, RUBY, JAVA) ======================================================== For Python, Perl and Ruby bindings, see the file ./subversion/bindings/swig/INSTALL For Java bindings, see the file ./subversion/bindings/javahl/README
06-24
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值